Flatten bind9 vendor work area

48 files changed, 42044 insertions, 0 deletions

diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
new file mode 100644
index 0000000..1030e57
--- /dev/null
+++ b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
@@ -0,0 +1,336 @@
+
+
+
+
+Internet-Draft                                                   T. Baba
+Expires: March 11, 2004                                         NTT Data
+                                                      September 11, 2003
+
+
+         Requirements for Access Control in Domain Name Systems
+                   draft-baba-dnsext-acl-reqts-01.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   Distribution of this memo is unlimited.
+
+   This Internet-Draft will expire on March 11, 2004.
+
+Abstract
+
+   This document describes the requirements for access control
+   mechanisms in the Domain Name System (DNS), which authenticate
+   clients and then allow or deny access to resource records in the
+   zone according to the access control list (ACL).
+
+1. Introduction
+
+   The Domain Name System (DNS) is a hierarchical, distributed, highly
+   available database used for bi-directional mapping between domain
+   names and IP addresses, for email routing, and for other information
+   [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
+   to authenticate the data in DNS and provide key distribution services
+   using SIG, KEY, and NXT resource records (RRs) [RFC2535].
+
+
+
+Baba                     Expires March 11, 2004                 [Page 1]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+   At the 28th IETF Meeting in Houston in 1993, DNS security design team
+   started a discussion about DNSSEC and agreed to accept the assumption
+   that "DNS data is public".  Accordingly, confidentiality for queries
+   or responses is not provided by DNSSEC, nor are any sort of access
+   control lists or other means to differentiate inquirers.  However,
+   about ten years has passed, access control in DNS has been more
+   important than before.  Currently, new RRs are proposed to add new
+   functionality to DNS such as ENUM [RFC2916].  Such new RRs may
+   contain private information.  Thus, DNS access control will be
+   needed.
+
+   Furthermore, with DNS access control mechanism, access from
+   unauthorized clients can be blocked when they perform DNS name
+   resolution.  Thus, for example, Denial of Service (DoS) attacks
+   against a server used by a closed user group can be prevented using
+   this mechanism if IP address of the server is not revealed by other
+   sources.
+
+   This document describes the requirements for access control
+   mechanisms in DNS.
+
+2. Terminology
+
+   AC-aware client
+      This is the client that understands the DNS access control
+      extensions. This client may be an end host which has a stub
+      resolver, or a cashing/recursive name server which has a
+      full-service resolver.
+
+   AC-aware server
+      This is the authoritative name server that understands the DNS
+      access control extensions.
+
+   ACE
+      An Access Control Entry.  This is the smallest unit of access
+      control policy.  It grants or denies a given set of access
+      rights to a set of principals.  An ACE is a component of an ACL,
+      which is associated with a resource.
+
+   ACL
+      An Access Control List.  This contains all of the access control
+      policies which are directly associated with a particular
+      resource.  These policies are expressed as ACEs.
+
+   Client
+      A program or host which issues DNS requests and accepts its
+      responses. A client may be an end host or a cashing/recursive name
+      server.
+
+
+
+Baba                     Expires March 11, 2004                 [Page 2]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+   RRset
+      All resource records (RRs) having the same NAME, CLASS and TYPE
+      are called a Resource Record Set (RRset).
+
+3. Requirements
+
+   This section describes the requirements for access control in DNS.
+
+3.1 Authentication
+
+3.1.1 Client Authentication Mechanism
+
+   The AC-aware server must identify AC-aware clients based on IP
+   address and/or domain name (user ID or host name), and must
+   authenticate them using strong authentication mechanism such as
+   digital signature or message authentication code (MAC).
+
+   SIG(0) RR [RFC2931] contains a domain name associated with sender's
+   public key in its signer's name field, and TSIG RR [RFC2845] also
+   contains a domain name associated with shared secret key in its key
+   name field.  Each of these domain names can be a host name or a user
+   name, and can be used as a sender's identifier for access control.
+   Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
+   message authentication.  These mechanisms can be used to authenticate
+   AC-aware clients.
+
+   Server authentication may be also provided.
+
+3.1.2 End-to-End Authentication
+
+   In current DNS model, caching/recursive name servers are deployed
+   between end hosts and authoritative name servers.  Although
+   authoritative servers can authenticate caching/recursive name servers
+   using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
+   For end-to-end authentication, the mechanism for an end host to
+   discover the target authoritative name server and directly access to
+   it bypassing caching/recursive name servers is needed.  For example,
+   an end host can get the IP addresses of the authoritative name
+   servers by retrieving NS RRs for the zone via local caching/recursive
+   name server.
+
+   In many enterprise networks, however, there are firewalls that block
+   all DNS packets other than those going to/from the particular
+   caching/recursive servers.  To deal with this problem, one can
+   implement packet forwarding function on the caching/recursive servers
+   and enable end-to-end authentication via the caching/recursive
+   servers.
+
+
+
+
+Baba                     Expires March 11, 2004                 [Page 3]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+3.1.3 Authentication Key Retrieval
+
+   Keys which are used to authenticate clients should be able to be
+   automatically retrieved.  The KEY RR is used to store a public key
+   for a zone or a host that is associated with a domain name.  SIG(0)
+   RR uses a public key in KEY RR for verifying the signature.  If
+   DNSSEC is available, the KEY RR would be protected by the SIG RR.
+   KEY RR or newly defined RR can be used to automatic key retrieval.
+
+3.2 Confidentiality
+
+3.2.1 Data Encryption
+
+   To avoid disclosure to eavesdroppers, the response containing the
+   RRsets which are restricted to access from particular users should be
+   encrypted.  Currently, no encryption mechanism is specified in DNS.
+   Therefore, new RRs should be defined for DNS message encryption.
+   Instead, IPsec [RFC2401] can be used to provide confidentiality if
+   name server and resolver can set up security associations dynamically
+   using IPsec API [IPSECAPI] when encryption is required.
+
+   In case encryption is applied, entire DNS message including DNS
+   header should be encrypted to hide information including error code.
+
+   Query encryption may be also provided for hiding query information.
+
+3.2.2 Key Exchange
+
+   If DNS message encryption is provided, automatic key exchange
+   mechanism should be also provided.  [RFC2930] specifies a TKEY RR
+   that can be used to establish and delete shared secret keys used by
+   TSIG between a client and a server.  With minor extensions, TKEY can
+   be used to establish shared secret keys used for message encryption.
+
+3.2.3 Caching
+
+   The RRset that is restricted to access from particular users must not
+   be cached.  To avoid caching, the TTL of the RR that is restricted to
+   access should be set to zero during transit.
+
+3.3 Access Control
+
+3.3.1 Granularity of Access Control
+
+   Control of access on a per-user/per-host granularity must be
+   supported.  Control of access to individual RRset (not just the
+   entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
+   KEY, and DS RRs must be publicly accessible to avoid unexpected
+   results.
+   
+
+Baba                     Expires March 11, 2004                 [Page 4]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+3.3.2 ACL Representation
+
+   Access Control List (ACL) format must be standardized so that both
+   the primary and secondary AC-aware servers can recognize the same
+   ACL.  Although ACL may appear in or out of zone data, it must be
+   transferred to the secondary AC-aware server with associated zone
+   data.  It is a good idea to contain ACL in zone data, because ACL can
+   be transferred with zone data using existing zone transfer mechanisms
+   automatically.  However, ACL must not be published except for
+   authorized secondary master servers.
+   
+   In zone data master files, ACL should be specified using TXT RRs or
+   newly defined RRs.  In each access control entry (ACE), authorized
+   entities (host or user) must be described using domain name (host
+   name, user name, or IP address in in-addr.arpa/ip6.arpa format).
+   There may be other access control attributes such as access time.
+
+   It must be possible to create publicly readable entries, which may be
+   read even by unauthenticated clients.
+
+3.3.3 Zone/ACL Transfer
+
+   As mentioned above, ACL should be transferred from a primary AC-aware
+   server to a secondary AC-aware server with associated zone data.
+   When an AC-aware server receives a zone/ACL transfer request, the
+   server must authenticate the client, and should encrypt the zone
+   data and associated ACL during transfer.
+
+3.4 Backward/co-existence Compatibility
+
+   Any new protocols to be defined for access control in DNS must be
+   backward compatible with existing DNS protocol.  AC-aware servers
+   must be able to process normal DNS query without authentication, and
+   must respond if retrieving RRset is publicly accessible.
+   
+   Modifications to root/gTLD/ccTLD name servers are not allowed.
+
+4. Security Considerations
+
+   This document discusses the requirements for access control
+   mechanisms in DNS.
+
+5. Acknowledgements
+
+   This work is funded by the Telecommunications Advancement
+   Organization of Japan (TAO).
+
+   The author would like to thank the members of the NTT DATA network
+   security team for their important contribution to this work.
+
+
+Baba                     Expires March 11, 2004                 [Page 5]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+6. References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+              "Secret Key Transaction Authentication for DNS (TSIG)", 
+              RFC 2845, May 2000.
+
+   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
+              September 2000.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
+              RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s)", RFC 2931, September 2000.
+
+   [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
+              draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
+              Progress.
+
+
+Author's Address
+
+   Tatsuya Baba
+   NTT Data Corporation
+   Research and Development Headquarters
+   Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
+   Tokyo 104-0033, Japan
+   
+   Tel: +81 3 3523 8081
+   Fax: +81 3 3523 8090
+   Email: babatt@nttdata.co.jp
+
+
+
+
+
+
+
+
+Baba                     Expires March 11, 2004                 [Page 6]
diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt
new file mode 100644
index 0000000..fffa8a5
--- /dev/null
+++ b/doc/draft/draft-daigle-napstr-04.txt
@@ -0,0 +1,1232 @@
+
+
+Network Working Group                                          L. Daigle
+Internet-Draft                                                 A. Newton
+Expires: August 15, 2004                                  VeriSign, Inc.
+                                                       February 15, 2004
+
+
+    Domain-based Application Service Location Using SRV RRs and the
+              Dynamic Delegation Discovery Service (DDDS)
+                       draft-daigle-napstr-04.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 15, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This memo defines a generalized mechanism for application service
+   naming that allows service location without relying on rigid domain
+   naming conventions (so-called name hacks).  The proposal defines a
+   Dynamic Delegation Discovery System (DDDS) Application to map domain
+   name, application service name, and application protocol to target
+   server and port, dynamically.
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 1]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.    Straightforward-NAPTR (S-NAPTR) Specification  . . . . . . .  4
+   2.1   Key Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.2   S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . .  5
+   2.2.1 Ordering and Preference  . . . . . . . . . . . . . . . . . .  5
+   2.2.2 Matching and non-Matching NAPTR Records  . . . . . . . . . .  5
+   2.2.3 Terminal and Non-Terminal NAPTR Records  . . . . . . . . . .  5
+   2.2.4 S-NAPTR and Successive Resolution  . . . . . . . . . . . . .  6
+   2.2.5 Clients Supporting Multiple Protocols  . . . . . . . . . . .  6
+   3.    Guidelines . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   3.1   Guidelines for Application Protocol Developers . . . . . . .  7
+   3.1.1 Registration of application service and protocol tags  . . .  7
+   3.1.2 Definition of conditions for retry/failure . . . . . . . . .  8
+   3.1.3 Server identification and handshake  . . . . . . . . . . . .  8
+   3.2   Guidelines for Domain Administrators . . . . . . . . . . . .  8
+   3.3   Guidelines for Client Software Writers . . . . . . . . . . .  9
+   4.    Illustrations  . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.1   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.2   Service Discovery within a Domain  . . . . . . . . . . . . . 10
+   4.3   Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
+   4.4   Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
+   4.5   Sets of NAPTR RRs  . . . . . . . . . . . . . . . . . . . . . 12
+   4.6   Sample sequence diagram  . . . . . . . . . . . . . . . . . . 12
+   5.    Motivation and Discussion  . . . . . . . . . . . . . . . . . 14
+   5.1   So, why not just SRV records?  . . . . . . . . . . . . . . . 15
+   5.2   So, why not just NAPTR records?  . . . . . . . . . . . . . . 15
+   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
+   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
+   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
+   A.    Application Service Location Application of DDDS . . . . . . 18
+   A.1   Application Unique String  . . . . . . . . . . . . . . . . . 18
+   A.2   First Well Known Rule  . . . . . . . . . . . . . . . . . . . 18
+   A.3   Expected Output  . . . . . . . . . . . . . . . . . . . . . . 18
+   A.4   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+   A.5   Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
+   A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
+   A.5.2 Application Protocols  . . . . . . . . . . . . . . . . . . . 20
+   A.6   Valid Rules  . . . . . . . . . . . . . . . . . . . . . . . . 20
+   A.7   Valid Databases  . . . . . . . . . . . . . . . . . . . . . . 20
+   B.    Pseudo pseudocode for S-NAPTR  . . . . . . . . . . . . . . . 20
+   B.1   Finding the first (best) target  . . . . . . . . . . . . . . 20
+   B.2   Finding subsequent targets . . . . . . . . . . . . . . . . . 21
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 2]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+1. Introduction
+
+   This memo defines a generalized mechanism for application service
+   naming that allows service location without relying on rigid domain
+   naming conventions (so-called name hacks).  The proposal defines a
+   Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
+   map domain name, application service name, and application protocol
+   to target server and port, dynamically.
+
+   As discussed in Section 5, existing approaches to using DNS records
+   to dynamically determining the current host for a given application
+   service are limited in terms of the use cases supported.  To address
+   some of the limitations, this document defines a DDDS Application to
+   map service+protocol+domain to specific server addresses using both
+   NAPTR [7] and SRV ([5]) DNS resource records.  This can be viewed as
+   a more general version of the use of SRV and/or a very restricted
+   application of the use of NAPTR resource records.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC2119 ([2]).
+
+2. Straightforward-NAPTR (S-NAPTR) Specification
+
+   The precise details of the specification of this DDDS application are
+   given in Appendix A.  This section defines the usage of the DDDS
+   application.
+
+2.1 Key Terms
+
+   An "application service" is a generic term for some type of
+   application, indpendent of the protocol that may be used to offer it.
+   Each application service will be associated with an IANA-registered
+   tag.  For example, instant messaging is a type of application
+   service, which can be implemented by many different application-layer
+   protocols, and the tag "IM" (used as an illustration here) could be
+   registered for it.
+
+   An "application protocol" is used to implement the application
+   service.  These are also associated with IANA-registered tags.  In
+   the case where multiple transports are available for the application,
+   separate tags should be defined for each transport.
+
+   The intention is that the combination of application service and
+   protocol tags should be specific enough that finding a known pair
+   (e.g., "IM:ProtC") is sufficient for a client to identify a server
+   with which it can communicate.
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 3]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   Some protocols support multiple application services.  For example,
+   LDAP is an application protocol, and can be found supporting various
+   services (e.g., "whitepages", "directory enabled networking", etc).
+
+2.2 S-NAPTR DDDS Application Usage
+
+   As outlined in Appendix A, NAPTR records are used to store
+   application service+protocol information for a given domain.
+   Following the DDDS standard, these records are looked up,  and the
+   rewrite rules (contained in the NAPTR records) are used to determine
+   the successive DNS lookups, until a desirable target is found.
+
+   For the rest of this section, refer to the set of NAPTR resource
+   records for example.com shown in the figure below.
+
+   example.com.
+   ;;       order pref flags service     regexp replacement
+   IN NAPTR 100   10   ""    "WP:whois++" ""    bunyip.example.
+   IN NAPTR 100   20   "s"   "WP:ldap"    ""    _ldap._tcp.myldap.example.com.
+   IN NAPTR 200   10   ""    "IM:protA"   ""    someisp.example.
+   IN NAPTR 200   30   "a"   "IM:protB"   ""    myprotB.example.com.
+
+
+2.2.1 Ordering and Preference
+
+   A client retrieves all of the NAPTR records associated with the
+   target domain name (example.com, above).  These are to be sorted in
+   terms of increasing ORDER, and increasing PREF within each ORDER.
+
+2.2.2 Matching and non-Matching NAPTR Records
+
+   Starting with the first sorted NAPTR record, the client examines the
+   SERVICE field to find a match.  In the case of the S-NAPTR DDDS
+   application, that means a SERVICE field that includes the tags for
+   the desired application service and a supported application protocol.
+
+   If more than one NAPTR record matches, they are processed in
+   increasing sort order.
+
+2.2.3 Terminal and Non-Terminal NAPTR Records
+
+   A NAPTR record with an empty FLAG field is "non-terminal".  That is,
+   more NAPTR RR lookups are to be performed.  Thus, to process a NAPTR
+   record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
+   used as the target of the next DNS lookup -- for NAPTR RRs.
+
+   In S-NAPTR, the only terminal flags are "S" and "A".  These are
+   called "terminal" NAPTR lookups because they denote the end of the
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 4]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   DDDS/NAPTR processing rules.  In the case of an "S" flag, the
+   REPLACEMENT field is used as the target of a DNS query for SRV RRs,
+   and normal SRV processing is applied.  In the case of an "A" flag, an
+   address record is sought for the REPLACEMENT field target (and the
+   default protocol port is assumed).
+
+2.2.4 S-NAPTR and Successive Resolution
+
+   As shown in the example NAPTR RR set above, it is possible to have
+   multiple possible targets for a single application service+protocol
+   pair.  These are to be pursued in order until a server is
+   successfully contacted or all possible matching NAPTR records have
+   been successively pursued to terminal lookups and servers contacted.
+   That is, a client must backtrack and attempt other resolution paths
+   in the case of failure.
+
+   "Failure" is declared, and backtracking must be used when
+
+   o  the designated remote server (host and port) fail to provide
+      appropriate security credentials for the *originating* domain
+
+   o  connection to the designated remote server otherwise fails -- the
+      specifics terms of which are defined when an application protocol
+      is registered
+
+   o  the S-NAPTR-designated DNS lookup fails to yield expected results
+      -- e.g., no A RR for an "A" target, no SRV record for an "S"
+      target, or no NAPTR record with appropriate application service
+      and protocol for a NAPTR lookup.  Except in the case of the very
+      first NAPTR lookup, this last is a configuration error:  the fact
+      that example.com has a NAPTR record pointing to "bunyip.example"
+      for the "WP:Whois++" service and protocol means the administrator
+      of example.com believes that service exists.  If bunyip.example
+      has no "WP:Whois++" NAPTR record, the application client MUST
+      backtrack and try the next available "WP:Whois++" option from
+      example.com.  As there is none, the whole resolution fails.
+
+   An application client first queries for the NAPTR RRs for the domain
+   of a named application service.  The application client MUST select
+   one protocol to choose The PREF field of the NAPTR RRs may be used by
+   the domain administrator to The first DNS query is for the NAPTR RRs
+   in the original target domain (example.com, above).
+
+2.2.5 Clients Supporting Multiple Protocols
+
+   In the case of an application client that supports more than one
+   protocol for a given application service, it MUST pursue S-NAPTR
+   resolution completely for one protocol before trying another.j It MAY
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 5]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   choose which protocol to try first based on its own preference, or
+   from the PREF ranking in the first set of NAPTR records (i.e., those
+   for the target named domain).    However, the chosen protocol MUST be
+   listed in that first NAPTR RR set.
+
+   That is, what the client MUST NOT do is start looking for one
+   protocol, observe that a successive NAPTR RR set supports another of
+   its preferred protocols, and continue the S-NAPTR resolution based on
+   that protocol.  For example, even if someisp.example offers the "IM"
+   service with protocol "ProtB", there is no reason to believe it does
+   so on behalf of example.com (since there is no such pointer in
+   example.com's NAPTR RR set).
+
+3. Guidelines
+
+3.1 Guidelines for Application Protocol Developers
+
+   The purpose of S-NAPTR is to provide application standards developers
+   with a more powerful framework (than SRV RRs alone) for naming
+   service targets, without requiring each application protocol (or
+   service) standard to define a separate DDDS application.
+
+   Note that this approach is intended specifically for use when it
+   makes sense to associate services with particular domain names (e.g.,
+   e-mail addresses, SIP addresses, etc).  A non-goal is having all
+   manner of label mapped into domain names in order to use this.
+
+   Specifically not addressed in this document is how to select the
+   domain for which the service+protocol is being sought.  It is up to
+   other conventions to define how that might be used (e.g., instant
+   messaging standards can define what domain to use from IM URIs, how
+   to step down from foobar.example.com to example.com, and so on, if
+   that is applicable).
+
+   Although this document proposes a DDDS application that does not use
+   all the features of NAPTR resource records, it does not mean to imply
+   that DNS resolvers should fail to implement all aspects of the NAPTR
+   RR standard.  A DDDS application is a client use convention.
+
+   The rest of this section outlines the specific elements that protocol
+   developers must determine and document in order to make use of S-
+   NAPTR.
+
+3.1.1 Registration of application service and protocol tags
+
+   Application protocol developers that wish to make use of S-NAPTR must
+   make provision to register any relevant application service and
+   application protocol tags, as described in Section 6.
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 6]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+3.1.2 Definition of conditions for retry/failure
+
+   One other important aspect that must be defined is the expected
+   behaviour for interacting with the servers that are reached via S-
+   NAPTR.  Specifically,  under what circumstances should the client
+   retry a target that was found via S-NAPTR?  What should it consider a
+   failure that causes it to return to the S-NAPTR process to determine
+   the next serviceable target (a less preferred target)?
+
+   For example, if the client gets a "connection refused" from a server,
+   should it retry for some (protocol-dependent) period of time?  Or,
+   should it try the next-preferred target in the S-NAPTR chain of
+   resolution?  Should it only try the next-preferred target if it
+   receives a protocol-specific permanent error message?
+
+   The most important thing is to select one expected behaviour and
+   document it as part of the use of S-NAPTR.
+
+   As noted earlier, failure to provide appropriate credentials to
+   identify the server as being authoritative for the original taret
+   domain is always considered a failure condition.
+
+3.1.3 Server identification and handshake
+
+   As noted in Section 7, use of the DNS for server location increases
+   the importance of using protocol-specific handshakes to determine and
+   confirm the identity of the server that is eventually reached.
+
+   Therefore, application protocol developers using S-NAPTR should
+   identify the mechanics of the expected identification handshake when
+   the client connects to a server found through S-NAPTR.
+
+3.2 Guidelines for Domain Administrators
+
+   Although S-NAPTR aims to provide a "straightforward" application of
+   DDDS and use of NAPTR records, it is still possible to create very
+   complex chains and dependencies with the NAPTR and SRV records.
+
+   Therefore, domain administrators are called upon to use S-NAPTR with
+   as much restraint as possible, while still achieving their service
+   design goals.
+
+   The complete set of NAPTR, SRV and A RRs that are "reachable" through
+   the S-NAPTR process for a particular application service can be
+   thought of as a "tree".  Each NAPTR RR retrieved points to more NAPTR
+   or SRV records; each SRV record points to several A record lookups.
+   Even though a particular client can "prune" the tree to use only
+   those records referring to application protocols supported by the
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 7]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   client, the tree could be quite deep, and retracing the tree to retry
+   other targets can become expensive if the tree has many branches.
+
+   Therefore,
+
+   o  Fewer branches is better:  for both NAPTR and SRV records, provide
+      different targets with varying preferences where appropriate
+      (e.g., to provide backup services, etc), but don't look for
+      reasons to provide more.
+
+   o  Shallower is better:  avoid using NAPTR records to "rename"
+      services within a zone.  Use NAPTR records to identify services
+      hosted elsewhere (i.e., where you cannot reasonably provide the
+      SRV records in your own zone).
+
+
+3.3 Guidelines for Client Software Writers
+
+   To properly understand DDDS/NAPTR, an implementor must read [6].
+   However, the most important aspect to keep in mind is that, if one
+   target fails to work for the application, it is expected that the
+   application will continue through the S-NAPTR tree to try the (less
+   preferred) alternatives.
+
+4. Illustrations
+
+4.1 Use Cases
+
+   The basic intended use cases for which S-NAPTR has been developed
+   are:
+
+   o  Service discovery within a domain.  For example, this can be used
+      to find the "authoritative" server for some type of service within
+      a domain (see the specific example in Section 4.2).
+
+   o  Multiple protocols.  This is increasingly common as new
+      application services are defined.  This includes the case of
+      instant messaging (a service) which can be offered with multiple
+      protocols (see Section 4.3).
+
+   o  Remote hosting.  Each of the above use cases applies within the
+      administration of a single domain.  However, one domain operator
+      may elect to engage another organization to provide an application
+      service.  See Section 4.4 for an example that cannot be served by
+      SRV records alone.
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 8]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+4.2 Service Discovery within a Domain
+
+   There are occasions when it is useful to be able to determine the
+   "authoritative" server for a given application service within a
+   domain.  This is "discovery", because there is no a priori knowledge
+   as to whether or where the service is offered; it is therefore
+   important to determine the location and characteristics of the
+   offered service.
+
+   For example, there is growing discussion of having a generic
+   mechanism for locating the keys or certificates associated with
+   particular application (servers) operated in (or for) a particular
+   domain.  Here's a hypothetical case for storing application key or
+   certificate data for a given domain.  The premise is that some
+   credentials registry (CredReg) service has been defined to be a leaf
+   node service holding the keys/certs for the servers operated by (or
+   for) the domain.  Furthermore, it is assumed that more than one
+   protocol is available to provide the service for a particular domain.
+   This DDDS-based approach is used to find the CredReg server that
+   holds the information.
+
+   Thus, the set of NAPTR records for thinkingcat.example might look
+   like this:
+
+   thinkingcat.example.
+   ;;       order pref flags service                 regexp  replacement
+   IN NAPTR 100   10   ""    "CREDREG:ldap:iris-beep" ""     theserver.thinkingcat.example.
+
+   Note that another domain, offering the same application service,
+   might offer it using a different set of application protocols:
+
+   anotherdomain.example.
+   ;;       order pref flags service                    regexp replacement
+   IN NAPTR 100   10   ""    "CREDREG:iris-lw:iris-beep" ""    foo.anotherdomain.example.
+
+
+4.3 Multiple Protocols
+
+   As it stands, there are several different protocols proposed for
+   offering "instant message" services.  Assuming that "IM" was
+   registered as an application service, this DDDS application could be
+   used to determine the available services for delivering to a target.
+
+   Two particular features of instant messaging should be noted:
+
+   1.  gatewaying is expected to bridge communications across protocols
+
+   2.  instant messaging servers are likely to be operated out of a
+
+
+
+Daigle & Newton          Expires August 15, 2004                [Page 9]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+       different domain than the instant messaging address, and servers
+       of different protocols may be offered by independent
+       organizations
+
+   For example, "thinkingcat.example" may support its own servers for
+   the "ProtA" instant messaging protocol, but rely on outsourcing from
+   "example.com" for "ProtC" and "ProtB" servers.
+
+   Using this DDDS-based approach, thinkingcat.example can indicate a
+   preference ranking for the different types of servers for the instant
+   messaging service, and yet the out-sourcer can independently rank the
+   preference and ordering of servers.  This independence is not
+   achievable through the use of SRV records alone.
+
+   Thus, to find the IM services for thinkingcat.example, the NAPTR
+   records for thinkingcat.example are retrieved:
+
+   thinkingcat.example.
+   ;;	order pref flags service   regexp replacement
+   IN NAPTR 100  10   "s"   "IM:ProtA" ""    _ProtA._tcp.thinkingcat.example.
+   IN NAPTR 100  20   "s"   "IM:ProtB" ""    _ProtB._tcp.example.com.
+   IN NAPTR 100  30   "s"   "IM:ProtC" ""    _ProtC._tcp.example.com.
+
+   and then the administrators at example.com can manage the preference
+   rankings of the servers they use to support the ProtB service:
+
+   _ProtB._tcp.example.com.
+    ;;    Pref Weight Port  Target
+   IN SRV 10    0     10001 bigiron.example.com
+   IN SRV 20    0     10001 backup.im.example.com
+   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
+
+
+4.4 Remote Hosting
+
+   In the Instant Message hosting example in Section 4.3, the service
+   owner (thinkingcat.example) had to host pointers to the hosting
+   service's SRV records in the thinkingcat.example domain.
+
+   A better way to approach this is to have one NAPTR RR in the
+   thinkingcat.example domain pointing to all the hosted services, and
+   the hosting domain has NAPTR records for each service to map them to
+   whatever local hosts it chooses (and may change from time to time).
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 10]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   thinkingcat.example.
+   ;;      order pref flags service         regexp replacement
+   IN NAPTR 100  10   "s"   "IM:ProtA"       ""    _ProtA._tcp.thinkingcat.example.
+   IN NAPTR 100  20   ""    "IM:ProtB:ProtC" ""    thinkingcat.example.com.
+
+
+   and then the administrators at example.com can break out the
+   individual application protocols and manage the preference rankings
+   of the servers they use to support the ProtB service (as before):
+
+   thinkingcat.example.com.
+   ;;      order pref flags service   regexp  replacement
+   IN NAPTR 100  10   "s"   "IM:ProtC" ""     _ProtC._tcp.example.com.
+   IN NAPTR 100  20   "s"   "IM:ProtB" ""     _ProtB._tcp.example.com.
+
+
+
+   _ProtC._tcp.example.com.
+    ;;    Pref Weight Port  Target
+   IN SRV 10    0     10001 bigiron.example.com
+   IN SRV 20    0     10001 backup.im.example.com
+   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
+
+
+4.5 Sets of NAPTR RRs
+
+   Note that the above sections assumed that there was one service
+   available (via S-NAPTR) per domain.  Often, that will not be the
+   case.  Assuming thinkingcat.example had the CredReg service set up as
+   described in Section 4.2 and the instant messaging service set up as
+   described in Section 4.4, then a client querying for the NAPTR RR set
+   from thinkingcat.com would get the following answer:
+
+   thinkingcat.example.
+   ;;       order pref flags service          regexp  replacement
+   IN NAPTR 100   10   "s"   "IM:ProtA"        ""     _ProtA._tcp.thinkingcat.example.
+   IN NAPTR 100   20   ""    "IM:ProtB:ProtC:" ""     thinkingcat.example.com.
+   IN NAPTR 200   10   ""    "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
+
+   Sorting them by increasing "ORDER", the client would look through the
+   SERVICE strings to determine if there was a NAPTR RR that matched the
+   application service it was looking for, with an application protocol
+   it could use.  The first (lowest PREF) record that so matched is the
+   one the client would use to continue.
+
+4.6 Sample sequence diagram
+
+   Consider the example in Section 4.3.  Visually, the sequence of steps
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 11]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   required for the client to reach the final server for a "ProtB"
+   service for IM for the thinkingcat.example domain is as follows:
+
+
+   Client   NS for                NS for
+            thinkingcat.example   example.com    backup.im.example.com
+                |                     |                  |
+     1 -------->|                     |                  |
+     2 <--------|                     |                  |
+     3 ------------------------------>|                  |
+     4 <------------------------------|                  |
+     5 ------------------------------>|                  |
+     6 <------------------------------|                  |
+     7 ------------------------------>|                  |
+     8 <------------------------------|                  |
+     9 ------------------------------------------------->|
+    10 <-------------------------------------------------|
+    11 ------------------------------------------------->|
+    12 <-------------------------------------------------|
+   (...)
+
+
+
+   1.  the name server (NS) for thinkingcat.example is reached with a
+        request for all NAPTR records
+
+   2.  the server responds with the NAPTR records shown in Section 4.3.
+
+   3.  the second NAPTR record matches the desired criteria; that has an
+        "s" flag and a replacement fields of "_ProtB._tcp.example.com".
+        So, the client looks up SRV records for that target, ultimately
+        making the request of the NS for example.com.
+
+   4.  the response includes the SRV records listed in Section 4.3.
+
+   5.  the client attempts to reach the server with the lowest PREF in
+        the SRV list -- looking up the A record for the SRV record's
+        target (bigiron.example.com).
+
+   6.  the example.com NS responds with an error message -- no such
+        machine!
+
+   7.  the client attempts to reach the second server in the SRV list,
+        and looks up the A record for backup.im.example.com
+
+   8.  the client gets the A record with the IP address for
+        backup.im.example.com from example.com's NS.
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 12]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   9.  the client connects to that IP address, on port 10001 (from the
+        SRV record), using ProtB over tcp.
+
+   10.  the server responds with an "OK" message.
+
+   11.  the client uses ProtB to challenge that this server has
+        credentials to operate the service for the original domain
+        (thinkingcat.example)
+
+   12.  the server responds, and the rest is IM.
+
+
+5. Motivation and Discussion
+
+   Increasingly, application protocol standards are using domain names
+   to identify server targets, and stipulating that clients should look
+   up SRV resource records to determine the host and port providing the
+   server.  This enables a distinction between naming an application
+   service target and actually hosting the server.  It also increases
+   flexibility in hosting the target service:
+
+   o  the server may be operated by a completely different organization
+      without having to list the details of that organization's DNS
+      setup (SRVs)
+
+   o  multiple instances can be set up (e.g., for load balancing or
+      secondaries)
+
+   o  it can be moved from time to time without disrupting clients'
+      access, etc.
+
+   This is quite useful, but Section 5.1 outlines some of the
+   limitations inherent in the approach.
+
+   That is, while SRV records can be used to map from a specific service
+   name and protocol for a specific domain to a specific server, SRV
+   records are limited to one layer of indirection, and are focused on
+   server administration rather than on application naming.  And, while
+   the DDDS specification and use of NAPTR allows multiple levels of
+   redirection before locating the target server machine with an SRV
+   record, this proposal requires only a subset of NAPTR strictly bound
+   to domain names, without making use of the REGEXP field of NAPTR.
+   These restrictions make the client's resolution process much more
+   predictable and efficient than with some potential uses of NAPTR
+   records.  This is dubbed "S-NAPTR" -- a "S"traightforward use of
+   NAPTR records.
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 13]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+5.1 So, why not just SRV records?
+
+   An expected question at this point is: this is so similar in
+   structure to SRV records, why are we doing this with DDDS/NAPTR?
+
+   Limitations of SRV include:
+
+   o  SRV provides a single layer of indirection -- the outcome of an
+      SRV lookup is a new domain name for which the A RR is to be found.
+
+   o  the purpose of SRV is focused on individual server administration,
+      not application naming: as stated in [5] "The SRV RR allows
+      administrators to use several servers for a single domain, to move
+      services from host to host with little fuss, and to designate some
+      hosts as primary servers for a service and others as backups."
+
+   o  target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
+      "tcp") in a given domain.  The definition of these terms implies
+      specific things (e.g., that protocol should be one of UDP or TCP)
+      without being precise.  Restriction to UDP and TCP is insufficient
+      for the uses described here.
+
+   The basic answer is that SRV records provide mappings from protocol
+   names to host and port.  The use cases described herein require an
+   additional layer -- from some service label to servers that may in
+   fact be hosted within different administrative domains.  We could
+   tweak SRV to say that the next lookup could be something other than
+   an address record, but that is more complex than is necessary for
+   most applications of SRV.
+
+5.2 So, why not just NAPTR records?
+
+   That's a trick question.  NAPTR records cannot appear in the wild --
+   see [6].  They must be part of a DDDS application.
+
+   The purpose here is to define a single, common mechanism (the DDDS
+   application) to use NAPTR when all that is desired is simple DNS-
+   based location of services.  This should be easy for applications to
+   use -- some simple IANA registrations and it's done.
+
+   Also, NAPTR has very powerful tools for expressing "rewrite" rules.
+   That power (==complexity) makes some protocol designers and service
+   administrators nervous.  The concern is that it can translate into
+   unintelligible, noodle-like rule sets that are difficult to test and
+   administer.
+
+   This proposed DDDS application specifically uses a subset of NAPTR's
+   abilities.  Only "replacement" expressions are allowed, not "regular
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 14]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   expressions".
+
+6. IANA Considerations
+
+   This document calls for 2 IANA registries:  one for application
+   service tags, and one for application protocol tags.
+
+   Application service and protocol tags should be defined in an RFC
+   (unless the "x-" experimental form is used, in which case they are
+   unregistered).  There are no restrictions placed on the tags other
+   than that they must conform with the syntax defined below (Appendix
+   A.5).  The IANA registries should list the tags and the RFC that
+   defines their use.
+
+7. Security Considerations
+
+   The security of this approach to application service location is only
+   as good as the security of the DNS servers along the way.  If any of
+   them is compromised, bogus NAPTR and SRV records could be inserted to
+   redirect clients to unintended destinations.  This problem is hardly
+   unique to S-NAPTR (or NAPTR in general).
+
+   To protect against DNS-vectored attacks, applications should define
+   some form of end-to-end authentication to ensure that the correct
+   destination has been reached.  Many application protocols such as
+   HTTPS, BEEP, IMAP, etc...  define the necessary handshake mechansims
+   to accomplish this task.
+
+   The basic mechanism works in the following way:
+
+   1.  During some portion of the protocol handshake, the client sends
+       to the server the original name of the desired destination (i.e.
+       no transformations that may have resulted from NAPTR
+       replacements, SRV targets, or CNAME changes).  In certain cases
+       where the application protocol does not have such a feature but
+       TLS may be used, it is possible to use the "server_name" TLS
+       extension.
+
+   2.  The server sends back to the client a credential with the
+       appropriate name.  For X.509 certificates, the name would either
+       be in the subjectDN or subjectAltName fields.  For Kerberos, the
+       name would be a service principle name.
+
+   3.  Using the matching semantics defined by the application protocol,
+       the client compares the name in the credential with the name sent
+       to the server.
+
+   4.  If the names match, there is reasonable assurance that the
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 15]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+       correct end point has been reached.
+
+   It is important to note that this document does not define either the
+   handshake mechanism, the specific credenential naming fields, nor the
+   name matching semantics.  Definitions of S-NAPTR for particular
+   application protocols MUST define these.
+
+8. Acknowledgements
+
+   Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
+   discussion and input that has (hopefully!) provoked clarifying
+   revisions of this document.
+
+References
+
+   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        One: The Comprehensive DDDS", RFC 3401, October 2002.
+
+   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Three: The Domain Name System (DNS) Database", RFC 3403, October
+        2002.
+
+   [8]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
+        2002.
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 16]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+Authors' Addresses
+
+   Leslie Daigle
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
+
+
+   Andrew Newton
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   EMail: anewton@verisignlabs.com
+
+Appendix A. Application Service Location Application of DDDS
+
+   This section defines the DDDS application, as described in [6].
+
+A.1 Application Unique String
+
+   The Application Unique String is domain label for which an
+   authoritative server for a particular service is sought.
+
+A.2 First Well Known Rule
+
+   The "First Well Known Rule" is identity -- that is, the output of the
+   rule is the Application Unique String, the domain label for which the
+   authoritative server for a particular service is sought.
+
+A.3 Expected Output
+
+   The expected output of this Application is the information necessary
+   to connect to authoritative server(s) (host, port, protocol) for an
+   application service within a given a given domain.
+
+A.4 Flags
+
+   This DDDS Application uses only 2 of the Flags defined for the
+   URI/URN Resolution Application ([8]): "S" and "A".  No other Flags
+   are valid.
+
+   Both are for terminal lookups.  This means that the Rule is the last
+   one and that the flag determines what the next stage should be.  The
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 17]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   "S" flag means that the output of this Rule is a domain label for
+   which one or more SRV [5] records exist.  "A" means that the output
+   of the Rule is a domain name and should be used to lookup address
+   records for that domain.
+
+   Consistent with the DDDS algorithm, if the Flag string is empty the
+   next lookup is for another NAPTR record (for the replacement target).
+
+A.5 Service Parameters
+
+   Service Parameters for this Application take the form of a string of
+   characters that follow this ABNF ([3]):
+
+      service-parms = [ [app-service] *(":" app-protocol)]
+      app-service   = experimental-service  / iana-registered-service
+      app-protocol  = experimental-protocol / iana-registered-protocol
+      experimental-service      = "x-" 1*30ALPHANUMSYM
+      experimental-protocol     = "x-" 1*30ALPHANUMSYM
+      iana-registered-service   = ALPHA *31ALPHANUMSYM
+      iana-registered-protocol  = ALPHA *31ALPHANUM
+      ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
+      DIGIT         =  %x30-39 ; 0-9
+      SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
+      ALPHANUMSYM   =  ALPHA / DIGIT / SYM
+      ; The app-service and app-protocol tags are limited to 32
+      ; characters and must start with an alphabetic character.
+      ; The service-parms are considered case-insensitive.
+
+   Thus, the Service Parameters may consist of an empty string, just an
+   app-service, or an app-service with one or more app-protocol
+   specifications separated by the ":" symbol.
+
+   Note that this is similar to, but not the same as the syntax used in
+   the URI DDDS application ([8]).  The DDDS DNS database requires each
+   DDDS application to define the syntax of allowable service strings.
+   The syntax here is expanded to allow the characters that are valid in
+   any URI scheme name (see [1]).  Since "+" (the separator used in the
+   RFC3404 service parameter string) is an allowed character for URI
+   scheme names, ":" is chosen as the separator here.
+
+A.5.1 Application Services
+
+   The "app-service" must be a registered service [this will be an IANA
+   registry; this is not the IANA port registry, because we want to
+   define services for which there is no single protocol, and we don't
+   want to use up port space for nothing].
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 18]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+A.5.2 Application Protocols
+
+   The protocol identifiers that are valid for the "app-protocol"
+   production are any standard, registered protocols [IANA registry
+   again -- is this the list of well known/registered ports?].
+
+A.6 Valid Rules
+
+   Only substitution Rules are permitted for this application.  That is,
+   no regular expressions are allowed.
+
+A.7 Valid Databases
+
+   At present only one DDDS Database is specified for this Application.
+   [7] specifies a DDDS Database that uses the NAPTR DNS resource record
+   to contain the rewrite rules.  The Keys for this database are encoded
+   as domain-names.
+
+   The First Well Known Rule produces a domain name, and this is the Key
+   that is used for the first lookup -- the NAPTR records for that
+   domain are requested.
+
+   DNS servers MAY interpret Flag values and use that information to
+   include appropriate NAPTR, SRV or A records in the Additional
+   Information portion of the DNS packet.  Clients are encouraged to
+   check for additional information but are not required to do so.  See
+   the Additional Information Processing section of [7] for more
+   information on NAPTR records and the Additional Information section
+   of a DNS response packet.
+
+Appendix B. Pseudo pseudocode for S-NAPTR
+
+B.1 Finding the first (best) target
+
+   Assuming the client supports 1 protocol for a particular application
+   service, the following pseudocode outlines the expected process to
+   find the first (best) target for the client, using S-NAPTR.
+
+
+    target = [initial domain]
+    naptr-done = false
+
+    while (not naptr-done)
+     {
+      NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
+      [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
+      rr-done = false
+      cur-rr = [first NAPTR RR]
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 19]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+      while (not rr-done)
+         if ([SERVICE field of cur-rr contains desired application
+              service and application protocol])
+            rr-done = true
+            target= [REPLACEMENT target of NAPTR RR]
+         else
+            cur-rr = [next rr in list]
+
+         if (not empty [FLAG in cur-rr])
+            naptr-done = true
+     }
+
+    port = -1
+
+    if ([FLAG in cur-rr is "S"])
+     {
+      SRV-RRset = [DNSlookup of SRV RRs for target]
+      [sort SRV-RRset based on PREF]
+      target = [target of first RR of SRV-RRset]
+      port = [port in first RR of SRV-RRset]
+     }
+
+    ; now, whether it was an "S" or an "A" in the NAPTR, we
+    ; have the target for an A record lookup
+
+    host = [DNSlookup of target]
+
+    return (host, port)
+
+
+
+B.2 Finding subsequent targets
+
+   The pseudocode in Appendix B is crafted to find the first, most
+   preferred, host-port pair for a particular application service an
+   protocol.  If, for any reason, that host-port pair did not work
+   (connection refused, application-level error), the client is expected
+   to try the next host-port in the S-NAPTR tree.
+
+   The pseudocode above does not permit retries -- once complete, it
+   sheds all context of where in the S-NAPTR tree it finished.
+   Therefore, client software writers could
+
+   o  entwine the application-specific protocol with the DNS lookup and
+      RRset processing described in the pseudocode and continue the S-
+      NAPTR processing if the application code fails to connect to a
+      located host-port pair;
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 20]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+   o  use callbacks for the S-NAPTR processing;
+
+   o  use an S-NAPTR resolution routine that finds *all* valid servers
+      for the required application service and protocol from the
+      originating domain, and provides them in sorted order for the
+      application to try in order.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 21]
+
+Internet-Draft           draft-daigle-napstr-04            February 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton          Expires August 15, 2004               [Page 22]
+
diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
new file mode 100644
index 0000000..4a01d91
--- /dev/null
+++ b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
@@ -0,0 +1,1960 @@
+
+
+
+INTERNET-DRAFT                                           Hadmut Danisch
+Category: Experimental                                         Oct 2003
+Expires: Apr 1, 2004
+
+ The RMX DNS RR and method for lightweight SMTP sender authorization
+                   draft-danisch-dns-rr-smtp-03.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months and may be updated, replaced, or obsoleted by other
+   documents at any time.  It is inappropriate to use Internet-Drafts
+   as reference material or to cite them other than as "work in
+   progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+Abstract
+
+   This memo introduces a new authorization scheme for SMTP e-mail
+   transport. It is designed to be a simple and robust protection
+   against e-mail fraud, spam and worms. It is based solely on
+   organisational security mechanisms and does not require but still
+   allow use of cryptography. This memo also focuses on security and
+   privacy problems and requirements in context of spam defense. In
+   contrast to prior versions of the draft a new RR type is not
+   required anymore.
+
+
+
+
+
+
+
+
+
+
+
+
+Hadmut Danisch                Experimental                      [Page 1]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+                           Table of Contents
+
+
+1.  General Issues . . . . . . . . . . . . . . . . . . . . . . . . .   4
+2.  Problem and threat description . . . . . . . . . . . . . . . . .   4
+    2.1.  Mail sender forgery  . . . . . . . . . . . . . . . . . . .   4
+          2.1.1  Definition of sender forgery  . . . . . . . . . . .   4
+          2.1.2  Spam  . . . . . . . . . . . . . . . . . . . . . . .   5
+          2.1.3  E-Mail Worms  . . . . . . . . . . . . . . . . . . .   5
+          2.1.4  E-Mail spoofing and fraud . . . . . . . . . . . . .   5
+    2.2.  Indirect damage caused by forgery  . . . . . . . . . . . .   6
+    2.3.  Technical problem analysis . . . . . . . . . . . . . . . .   6
+    2.4.  Shortcomings of cryptographical approaches . . . . . . . .   7
+3.  A DNS based sender address verification  . . . . . . . . . . . .   7
+    3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   7
+    3.2.  Envelope vs. header sender address . . . . . . . . . . . .   9
+    3.3.  Domain part vs. full sender address  . . . . . . . . . . .   9
+4.  Mapping of E-Mail addresses to DNS names . . . . . . . . . . . .  10
+    4.1.  Domain part only . . . . . . . . . . . . . . . . . . . . .  10
+    4.2.  Full address . . . . . . . . . . . . . . . . . . . . . . .  11
+    4.3.  Empty address  . . . . . . . . . . . . . . . . . . . . . .  11
+5.  Mandatory entry types and their syntax . . . . . . . . . . . . .  11
+    5.1.  Overall structure  . . . . . . . . . . . . . . . . . . . .  11
+    5.2.  Unused . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+    5.3.  IPv4 and IPv6 address ranges . . . . . . . . . . . . . . .  12
+    5.4.  DNS Hostname . . . . . . . . . . . . . . . . . . . . . . .  13
+          5.4.1  Road warriors and DynDNS entries  . . . . . . . . .  13
+    5.5.  APL Reference  . . . . . . . . . . . . . . . . . . . . . .  14
+    5.6.  Domain Member  . . . . . . . . . . . . . . . . . . . . . .  14
+    5.7.  Full Address Query . . . . . . . . . . . . . . . . . . . .  15
+    5.8.  DNS mapped authorization . . . . . . . . . . . . . . . . .  15
+    5.9.  RMX reference  . . . . . . . . . . . . . . . . . . . . . .  16
+6.  Optional and experimental entry types  . . . . . . . . . . . . .  16
+    6.1.  TLS fingerprint  . . . . . . . . . . . . . . . . . . . . .  16
+    6.2.  TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . .  16
+    6.3.  PGP or S/MIME signature  . . . . . . . . . . . . . . . . .  16
+    6.4.  Transparent Challenge/Response . . . . . . . . . . . . . .  17
+    6.5.  SASL Challenge/Response  . . . . . . . . . . . . . . . . .  17
+7.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
+    7.1.  Alternative encoding as TXT records  . . . . . . . . . . .  17
+    7.2.  RMX Records  . . . . . . . . . . . . . . . . . . . . . . .  17
+          7.2.1  Overall structure . . . . . . . . . . . . . . . . .  18
+          7.2.2  Record encoding . . . . . . . . . . . . . . . . . .  18
+          7.2.3  Encoding of IPv4 and IPv6 address ranges  . . . . .  18
+          7.2.4  Encoding of DNS . . . . . . . . . . . . . . . . . .  18
+          7.2.5  Encoding of unused and full query . . . . . . . . .  19
+          7.2.6  Additional Records  . . . . . . . . . . . . . . . .  19
+8.  Message Headers  . . . . . . . . . . . . . . . . . . . . . . . .  19
+
+
+
+Hadmut Danisch                Experimental                      [Page 2]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+9.  SMTP error messages  . . . . . . . . . . . . . . . . . . . . . .  20
+10.  Message relaying and forwarding . . . . . . . . . . . . . . . .  20
+    10.1.  Problem description . . . . . . . . . . . . . . . . . . .  20
+    10.2.  Trusted relaying/forwarding . . . . . . . . . . . . . . .  21
+    10.3.  Untrusted relaying/forwarding . . . . . . . . . . . . . .  21
+11.  Security Considerations . . . . . . . . . . . . . . . . . . . .  22
+    11.1.  Draft specific considerations . . . . . . . . . . . . . .  22
+          11.1.1  Authentication strength  . . . . . . . . . . . . .  22
+          11.1.2  Where Authentication and Authorization end . . . .  22
+          11.1.3  Vulnerability of DNS . . . . . . . . . . . . . . .  23
+          11.1.4  Sneaking RMX attack?   . . . . . . . . . . . . . .  25
+          11.1.5  Open SMTP relays . . . . . . . . . . . . . . . . .  25
+          11.1.6  Unforged Spam  . . . . . . . . . . . . . . . . . .  25
+          11.1.7  Reliability of Whois Entries . . . . . . . . . . .  26
+          11.1.8  Hazards for Freedom of Speech  . . . . . . . . . .  26
+    11.2.  General Considerations about spam defense . . . . . . . .  27
+          11.2.1  Action vs. reaction  . . . . . . . . . . . . . . .  27
+          11.2.2  Content based Denial of Service attacks  . . . . .  27
+12.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . .  28
+    12.1.  Draft specific considerations . . . . . . . . . . . . . .  28
+          12.1.1  No content leaking . . . . . . . . . . . . . . . .  28
+          12.1.2  Message reception and sender domain  . . . . . . .  28
+          12.1.3  Network structure  . . . . . . . . . . . . . . . .  29
+          12.1.4  Owner information distribution . . . . . . . . . .  29
+    12.2.  General Considerations about spam defense . . . . . . . .  29
+          12.2.1  Content leaking of content filters . . . . . . . .  29
+          12.2.2  Black- and Whitelists  . . . . . . . . . . . . . .  30
+13.  Deployment Considerations . . . . . . . . . . . . . . . . . . .  30
+    13.1.  Compatibility . . . . . . . . . . . . . . . . . . . . . .  30
+          13.1.1  Compatibility with old mail receivers  . . . . . .  30
+          13.1.2  Compatibility with old mail senders  . . . . . . .  30
+          13.1.3  Compatibility with old DNS clients . . . . . . . .  30
+          13.1.4  Compatibility with old DNS servers . . . . . . . .  30
+    13.2.  Enforcement policy  . . . . . . . . . . . . . . . . . . .  31
+14.  General considerations about fighting spam  . . . . . . . . . .  31
+    14.1.  The economical problem  . . . . . . . . . . . . . . . . .  31
+    14.2.  The POP problem . . . . . . . . . . . . . . . . . . . . .  32
+    14.3.  The network structure problem . . . . . . . . . . . . . .  33
+    14.4.  The mentality problem . . . . . . . . . . . . . . . . . .  33
+    14.5.  The identity problem  . . . . . . . . . . . . . . . . . .  33
+    14.6.  The multi-legislation problem . . . . . . . . . . . . . .  34
+Implementation and further Information . . . . . . . . . . . . . . .  34
+References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  34
+Draft History  . . . . . . . . . . . . . . . . . . . . . . . . . . .  35
+Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  35
+
+
+
+
+
+
+Hadmut Danisch                Experimental                      [Page 3]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+1.  General Issues
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
+   this document are to be interpreted as described in RFC 2119 [1].
+
+2.  Problem and threat description
+
+2.1.  Mail sender forgery
+
+   The amount of e-mails with forged sender addresses has dramatically
+   increased. As a consequence, damages and annoyances caused by such
+   e-mails increased as well. In the majority of examined e-mails the
+   domain name of the envelope sender address was forged, and the e-
+   mail was sent from an IP address which does not belong to a network
+   used by the actual owner of the domain.
+
+2.1.1.  Definition of sender forgery
+
+   As discussions, comments to prior versions of this draft, and
+   different approaches to stop forgery showed, different perceptions
+   of "mail forgery" exist. For example, there are mechanisms to
+   verify e-mail addresses for mailing lists, web servers, or to stop
+   spam, which do send a message with a random number to the given
+   address and expect the user to send a reply. Here, someone is
+   considered to be allowed to use a particular e-mail address, if and
+   only if he is able to receive informations sent to this address,
+   and is able to reply to such a message. While this definition
+   appears to be quite plausible and natural, it can't be used for a
+   simple technical solution. Sending back a challenge and expecting a
+   reply is simply too much overhead and time delay, and not every
+   authorized sender is able or willing to reply (e.g. because he went
+   offline or is not a human).
+
+   Within the scope of this memo, sender forgery means that the
+   initiator of an e-mail transfer (which is the original sender in
+   contrast to relays) uses a sender address which he was not
+   authorized to use. Being authorized to use an address means that
+   the owner (administrator) of the internet domain has given
+   permission, i.e. agrees with the use of the address by that
+   particular sender. This memo will cover both the permission of the
+   full e-mail address and the domain part only for simplicity.
+
+   Within context of Internet and SMTP, the sender address usually
+   occurs twice, once as the envelope sender address in SMTP, and once
+   as the address given in the RFC822 mail header. While the following
+   considerations apply to both addresses in principle, it is
+   important to stress that both addresses have distinct semantics and
+
+
+
+Hadmut Danisch                Experimental                      [Page 4]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   are not neccessarily the same. The envelope address identifies the
+   initiator of the transport, while the header identifies the author
+   of the message content. Since this memo deals with the message
+   transport only and completely ignores the message content, the
+   method should naturally be applied to the envelope sender address.
+
+2.1.2.  Spam
+
+   A common and well known problem is the dramatic increase of
+   unsolicited e-mail, commonly called "spam". Again, the majority of
+   examined e-mails had forged sender addresses.  The abused domains
+   were mainly those of common webmailers as hotmail or yahoo, or
+   well-known companies.
+
+   Unfortunately, there is no accurate definition of spam availabe
+   yet, and neither are the concise technical criterions to filter or
+   block spam with technical mechanisms. There are efforts to design
+   content based filters, but these filters are expensive in
+   calculation time (and sometimes money), and they do not reliably
+   provide predictable results. Usually they give false positives
+   and/or require user interaction. Content filters in general suffer
+   from a design problem described later in this memo.  Therefore,
+   this proposal does not use the content based approach to block
+   spam.
+
+   As analysis of spam messages showed, most of spam messages were
+   sent with forged envelope sender addresses. This has mainly three
+   reasons.  The first reason is, that spam senders usually do not
+   want to be contacted by e-mail. The second reason is, that they do
+   not want to be blacklisted easily. The third reason is, that spam
+   is or is going to be unlawful in many countries, and the sender
+   does not want to reveal his identity. Therefore, spam is considered
+   to be a special case of sender forgery.
+
+2.1.3.  E-Mail Worms
+
+   Another example of sender forgery is the reproduction of e-mail
+   worms. Most worms do choose random sender addresses, e.g.  using
+   the addresses found in mailboxes on the infected system. In most
+   cases analyzed by the author, the e-mails sent by the reproduction
+   process can also be categorized as forged, since the infected
+   system would under normal circumstances not be authorized to send
+   e-mails with such e-mail addresses. So forgery does not require a
+   malicious human to be directly involved. This memo covers any kind
+   of e-mail sender address forgery, included those generated by
+   malicious software.
+
+2.1.4.  E-Mail spoofing and fraud
+
+
+
+Hadmut Danisch                Experimental                      [Page 5]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   Forging e-mail sender addresses for fraud or other kinds of
+   deception ("human engineering") has also dramatically increased.
+   There are many known cases where single or mass e-mails were sent
+   with wrong sender addresses, pretending to come from service
+   provider, software manufacturers etc., and asking the receiver to
+   install any software or patches, or to reply with any confidential
+   information. The Internet is becoming more and more a scene of
+   crime, and so are it's services, including e-mail. It is obvious
+   that crime based on e-mail is eased by the fact that SMTP allows
+   arbitrary sender address spoofing.
+
+2.2.  Indirect damage caused by forgery
+
+   As observed by the author, mass mails and worms with forged sender
+   addresses can cause a severe damage for the real owner of the
+   abused sender addresses. If a sender A is sending an e-mail to the
+   receiver B, pretending to be C by using a sender address of C's
+   domain, then C has currently no chance to prevent this, since C's
+   machines and software are not involved in any way in the delivery
+   process between A and B.  B will nevertheless send any error
+   messages (virus/spam alert, "no such user", etc.) to C, erroneously
+   assuming that the message was sent by C. The author found several
+   cases where this flood of error messages caused a severe denial of
+   service or a dramatic increase of costs, e.g. when C was
+   downloading the e-mail through expensive or low bandwidth
+   connections (e.g. modem or mobile phones), or where disk space was
+   limited. The author examined mass mailings, where several tens or
+   hundreds of thousands of messages were sent to several addresses
+   around the world, where these messages caused only annoyance. But
+   since several thousands of these addresses were invalid or didn't
+   accept the message, the owner of the DNS domain which was abused by
+   the spammer to forge sender addresses was flooded for several
+   months with thousands of error messages, jamming the e-mail system
+   and causing severe costs and damages.
+
+   As a consequence, when A sends a message to B, pretending to be C,
+   there must be any mechanism to allow C to inform B about the fact,
+   that A is not authorized to use C as a sender address. This is what
+   this memo is about.
+
+2.3.  Technical problem analysis
+
+   Why does e-mail forgery actually exist? Because of the lack of the
+   Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
+   authentication, authorisation, or verification. This protocol was
+   designed at a time where security was not an issue. Efforts have
+   been made to block forged e-mails by requiring the sender address
+   domain part to be resolvable.  This method provides protection from
+
+
+
+Hadmut Danisch                Experimental                      [Page 6]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   e-mails with non-existing sender domains, and indeed, for some time
+   it blocked most spam e-mails. However, since attackers and spam
+   senders began to abuse existing domain names, this method was
+   rendered ineffective.
+
+2.4.  Shortcomings of cryptographical approaches
+
+   At a first glance, the problem of sender address forgery might
+   appear to be solvable with cryptographic methods such as challenge
+   response authentications or digital signatures. A deeper analysis
+   shows that only a small, closed user group could be covered with
+   cryptographical methods. Any method used to stop spam forgery must
+   be suitable to detect forgery not only for a small number of
+   particular addresses, but for all addresses on the world. An
+   attacker does not need to know the secrets belonging to a
+   particular address. It is sufficient to be able to forge any
+   address and thus to know any secret key. Since there are several
+   hundreds of millions of users, there will always be a large amount
+   of compromised keys, thus spoiling any common cryptographic method.
+   Furthermore, cryptography has proven to be far too complicated and
+   error prone to be commonly administered and reliably implemented.
+   Many e-mail and DNS administrators do not have the knowledge
+   required to deal with cryptographic mechanisms. Many legislations
+   do not allow the general deployment of cryptography and a directory
+   service with public keys. For these reasons, cryptography is
+   applicable only to a small and closed group of users, but not to
+   all participants of the e-mail service.
+
+3.  A DNS based sender address verification
+
+3.1.  Overview
+
+   To gain improvement in e-mail authenticity while keeping as much
+   SMTP compatibility as possible, a method is suggested which doesn't
+   change SMTP at all.
+
+   The idea is to store informations about how to verify who is
+   authorized to transmit e-mails through SMTP with a particular
+   sender address (either full address or - for simplicity - only the
+   domain part of the address) in a directory service, which is
+   currently the DNS. To be precise, the verification consists of two
+   steps, the classical pair of authentication and authorization:
+
+   The first step is the authentication. While several methods are
+   possible to perform authentication (see below), the most important
+   and robust method is the verification of the sender's IP address.
+   This is done implicitely by TCP/IP and the TCP sequence number. The
+   authenticated identity is the IP address. It has to be stressed
+
+
+
+Hadmut Danisch                Experimental                      [Page 7]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   that this TCP/IP "authentication" is a weak authentication and
+   vulnerable to several attacks. It is nevertheless sufficient for
+   this purpose, especially for blocking spam. It doesn't take any
+   implementation and it doesn't cost: It is already there, it is a
+   functionality of TCP/IP. An incoming SMTP connection based on
+   TCP/IP already carries the sender's IP address without any
+   modification of SMTP. See below (section Entry types) for more
+   details about authentication methods.
+
+   The second step is the authorization. It is based on the identity
+   given by the previous authentication step, e.g. the IP address of
+   the originator of the incoming SMTP connection,  and on the
+   envelope sender address. The mechanism proposed in this memo
+   answers the question "Is that particular sender (IP address,...)
+   allowed to send with that sender address" by querying and
+   processing informations stored in a directory service, which is
+   DNS.
+
+   When the sender has issued the "MAIL FROM:" SMTP command, the
+   receiving mail transfer agent (MTA) can - and modern MTAs do -
+   perform some authorization checks, e.g. run a local rule database
+   or check whether the sender domain is resolvable.
+
+   The suggested method is to let the DNS server for the sender domain
+   provide informations about who - this means for example which IP
+   address - is authorized to use an address or a domain as a part of
+   it.  After receiving the "MAIL FROM:" SMTP command, the receiving
+   MTA can verify, whether e. g. the IP address of the sending MTA is
+   authorized to send mails with this domain name. Therefore, a list
+   of entries with authorized IP addresses or other informations is
+   provided by the authoritative DNS server of that domain. The entry
+   types are described in the subsequent chapters. Some of these
+   methods are
+
+     - An IPv4 or IPv6 network address and mask
+     - A fully qualified domain name referring to an A record
+     - A fully qualified domain name referring to an APL record
+
+   RMX records of these types would look like this:
+
+      somedomain.de.      IN RMX ipv4:10.0.0.0/8
+      rmxtest.de.         IN RMX host:relay.provider.com
+      danisch.de.         IN RMX apl:relays.rackland.de
+      relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
+
+   where the machine with the example address 213.133.101.23 and the
+   machines in the example subnet 1.2.3.0/24 are the only machines
+   allowed to send e-mails with an envelope sender address of domain
+
+
+
+Hadmut Danisch                Experimental                      [Page 8]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   danisch.de. Since the APL records do not necessarily belong to the
+   same domain or zone table as the RMX records, this easily allows to
+   refer to APL records defined by someone else, e.g. the internet
+   access or server hosting provider, thus reducing administrative
+   overhead to a minimum. In the example given above, the domain
+   danisch.de and several other domains are hosted by the service
+   provider Rackland. So if the relay structure of Rackland is
+   modified, only the zone of rackland.de needs to be modified. The
+   domain owners don't need to care about such details.
+
+3.2.  Envelope vs. header sender address
+
+   Questions were raised why the proposed mechanism is based on the
+   envelope sender address, and not on the sender address given in the
+   message header. Technically, both can be used. Actually, it makes
+   sense to use the envelope address.
+
+   In common, the header sender address identifies the author of the
+   content, while the envelope sender tells who caused the
+   transmission.  The approach proposed in this memo is transmission
+   based, not content based. We can not authorize the author of a
+   message if we don't have contact with him, if the message does not
+   already contain a signature. In contrast, the sending MTA is linked
+   to an IP address which can be used for authentication. This
+   mechanism might not be very strong, but it is available and
+   sufficient to solve today's e-mail security problems.
+
+   Some people argued that it is the header address and not the sender
+   address, which is displayed in common mail readers (MUAs), and
+   where the receiver believes the mail comes from. That's true, but
+   it doesn't help. There are many cases where the header sender
+   differs from the envelope sender for good reasons (see below in the
+   consequences chapter for the discussion about relaying).  Relaying,
+   mailing lists etc. require to replace the sender address used for
+   RMX. If this were the header address, the message header would have
+   to be modified. This is undesirable.
+
+3.3.  Domain part vs. full sender address
+
+   Former versions of this draft were limited to the domain part of
+   the sender address. The first reason is that it is common and MX-
+   like, to lookup only the domain part of an e-mail address in DNS.
+   The second reason is, that it was left to the private business of
+   the domain administration to handle details of user verification.
+   The idea was that the domain administration takes care to verify
+   the left part of an e-mail address with an arbitrary method of
+   their individual taste. RMX was originally designed to ignore the
+   left part of the address and to expect the domain administration to
+
+
+
+Hadmut Danisch                Experimental                      [Page 9]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   take over responsibility for enforcing their policy. If, e.g., a
+   spam message arrived and passed the RMX mechanism, it is known to
+   be authorized by the domain administration and they can be blamed,
+   no matter what is on the left side of the sender address - it's
+   their private problem what happens on the left side of the @. By
+   far the most of the comments to prior versions of this draft agreed
+   with that. A few comments asked for a finer granularity.
+
+   And indeed, there is no technical reason against a finer
+   granularity.  All it takes is a mapping from a given envelope
+   sender address to a DNS name, and the RMX lookup for that
+   particular e-mail address could be done instead of a lookup for the
+   domain part only.  However, to my knowledge, most domain
+   administrators would not like to provide an RMX entry for every
+   single e-mail address. In many cases, this would also overload DNS
+   servers.
+
+   It is to be discussed how to cover both views. One method could be
+   to query the full address, and if no RMX records were found to
+   query the domain part only. A different approach would be to query
+   the domain part only, and if it's RMX record contain a special
+   entry, then a new query for the full address is triggered. A third
+   way would be to always query the full address and to leave the
+   problem to the wildcard mechanism of DNS. This still has to be
+   discussed and will be described in future versions of this draft.
+
+
+
+
+
+
+
+
+
+
+
+4.  Mapping of E-Mail addresses to DNS names
+
+   To perform the RMX query, a mapping is needed from E-Mail addresses
+   to DNS fully qualified domain names.
+
+   This chapter is under development and just a first approach.
+
+4.1.  Domain part only
+
+   Mapping of the domain part is trivial, since the domain part of an
+   e-mail address itself is a valid DNS name and does not need
+   translation. It might be nevertheless desirable to distinguish the
+
+
+
+Hadmut Danisch                Experimental                     [Page 10]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   RMX entries from other entries, depending of the encoding of the
+   records. If the RMX entries are encoded in TXT record types, they
+   might collide with other uses of TXT records.  It might be
+   necessary to prepend the domain part with a special prefix, e.g.
+   _rmx. So the e-mail address some.user@example.com could be mapped
+   to example.com or _rmx.example.com.
+
+4.2.  Full address
+
+   Mapping a full address is slightly more difficult. The @ sign must
+   be unambiguously translated, and therefore can not be simply
+   translated into a dot. The e-mail addresses some.user@example.com
+   and some@user.example.com must have different mappings. Therefore,
+   the @ sign could be translated into _rmx, implicitely assuming that
+   this is not an allowed domain name component of normal domain
+   names. Then the rightmost _rmx in the mapped DNS name always
+   corresponds to the @ sign. some.user@example.com would e translated
+   into some.user._rmx.example.com and can be covered by a wildcard
+   entry like *._rmx.example.com.
+
+   Character encoding and character sets are still to be discussed.
+
+4.3.  Empty address
+
+   Unfortunately, SMTP allows empty envelope sender addresses to be
+   used for error messages. Empty sender addresses can therefore not
+   be prohibited. As observed, a significant amount of spam was sent
+   with such an empty sender address. To solve this problem, the host
+   name given in the HELO or EHLO command is taken to lookup the RMX
+   records instead. This makes sense, since such messages were
+   generated by the machine, not a human.
+
+
+
+
+5.  Mandatory entry types and their syntax
+
+   The entry types described in this section MUST be supported by any
+   implementation of this draft.
+
+5.1.  Overall structure
+
+   Similar to APL, an RMX record is just a concatenation of zero or
+   more RMX entries. The entries within one record form an ordered
+   rule base as commonly usual in packet filtes and firewall rulesets,
+   i. e. they are processed one ofter another until the first entry
+   matches. This entry determines the result of the query. Once a
+   matching entry is found, the RMX processing is finished.
+
+
+
+Hadmut Danisch                Experimental                     [Page 11]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   For any domain name there should not exist more than a single RMX
+   record. Due to the structure of DNS, it is nevertheless possible to
+   have more than a single RMX record. Multiple RMX records are
+   treated as a single record consisting of the concatenation of all
+   records. While the entries in a record are ordered, the records are
+   not ordered and may be processed in arbitrary order. If the order
+   of the entries matters, it is the zone maintainer's responsibility
+   to keep those entries in a single record. For example, there are
+   negative entries, which exclude IP addresses from authorization.
+   It is important that these entries are processed before positive
+   entries giving permission to a wider address range. Since order is
+   guaranteed only within a record, corresponding negative and
+   positive entries must be put in the same record.
+
+   An RMX record may consist of one or more entries, where the entries
+   are separated by whitespace. An entry must not contain white space.
+   Each entry consists of an optional exclamation sign, a tag, a
+   colon, and the entry data:
+
+      [!] TAG : ENTRY-SPECIFIC-DATA
+
+   If the entry starts with an exclamation sign, the entry is negated.
+   See the entry type description below for details.
+
+   The TAG is the mnemonic type identifier or the decimal number of
+   the entry. The TAG is case-insensitive. It is immediately followed
+   by a colon.
+
+   The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
+   entry type. See description below.
+
+   Example:
+
+      danisch.de.  IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
+   ipv4:1.2.3.0/24
+
+5.2.  Unused
+
+   This is a primitive entry which just says that this sender address
+   will never be used as a sender address under any circumstances.
+   Example:
+
+   testdomain.danisch.de    IN RMX unused:
+
+5.3.  IPv4 and IPv6 address ranges
+
+   These entry types contain a bit sequence representing a CIDR
+   address part. If that bit sequence matches the given IP address,
+
+
+
+Hadmut Danisch                Experimental                     [Page 12]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   authorization is granted or denied, depending on the negation flag.
+
+   The entry is prepended with the tag "IPv4" or "IPv6". The colon is
+   followed with an IPv4 or IPv6 address in standard notation,
+   optionally followed by a slash and a mask length. If the negation
+   flag is set, then the given address range is excluded.  Examples:
+
+   danisch.de   IN RMX ipv4:213.133.101.23 ipv6:fe00::0
+                IN RMX ipv4:10.0.0.0/8     ipv6:fec0::0/16
+                IN RMX !ipv4:1.2.3.4
+
+   (Please note that it does not make much sense to use
+   RFC1918-Addresses in RMX records, this is just to give a syntax
+   example.)
+
+
+5.4.  DNS Hostname
+
+   This entry type simply contains a regular DNS name, which is to be
+   resolved as a host name (fetch the A record or IPv6 equivalent). If
+   the given IP address matches the result, authorization is granted
+   or denied, depending on the negation flag.  It is still to be
+   defined how to treat unresolvable entries.
+
+   The entry is prepended with the tag "host", followed by a colon and
+   the hostname. Examples:
+
+   danisch.de  IN RMX host:relay.provider.de
+               IN RMX !host:badmachine.domain.de apl:relays.domain.de
+
+5.4.1.  Road warriors and DynDNS entries
+
+   Several people argued against RMX that it would break their
+   existing installation which delivers e-mail from dynamically
+   assigned IP addresses, because their IP providers didn't assign a
+   static address, or because they are a road warrior, plugging their
+   notebook in any hotel room on the world.
+
+   RMX provides a simple solution. If such a machine has a dynamically
+   updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
+   the hostname type pointing to this dynamic DNS entry.
+
+   The cleaner solution would be to deliver mail the same way as it is
+   received: If downloaded by POP from a central relay with a static
+   address, where the MX points to, then it would be a good idea to
+   deliver e-mail the same way in reverse direction. Unfortunately,
+   plain POP does not support uploading yet.
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 13]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+5.5.  APL Reference
+
+   This entry type simply contains a regular DNS name, which is to be
+   resolved as an APL record index  (fetch the APL record).  If the
+   given IP address positively  matches the APL, authorization is
+   granted. Details of the semantic (espially when the negation bit is
+   set) are still to be defined.  It is still to be defined how to
+   treat unresolvable entries.
+
+   The entry is prepended with the tag "host", followed by a colon and
+   the hostname. Example:
+
+   danisch.de     IN RMX apl:relays.rackland.de
+
+5.6.  Domain Member
+
+   In many cases it is desirable to cover all hosts of a given domain
+   with an RMX record without the need to duplicate the list of these
+   hosts. This entry type does it (thanks to Eric A. Hall for pointing
+   out this entry type).  It contains a regular DNS name.
+
+   If this entry type is given, a reverse DNS query for the IP address
+   of the sending MTA is performed to find its official fully
+   qualified domain name. To prevent spoofing, this domain name is
+   accepted only if a subsequent address query to the given domain
+   name points to exactly the IP address of the sending MTA (the usual
+   procedure to verify PTR records).
+
+   The entry matches if the fully qualified domain name of the sending
+   MTA ends in the given domain. The negation flag works as usual.
+
+   The tag for this entry type is "domain". After the colon the domain
+   name is given, but might be empty, thus pointing to itself.
+   Example:
+
+      somedomain.org  IN RMX domain:somedomain.org domain:provider.com
+
+   would authorize all machines which's hostname can be verified
+   through an PTR and A query, and which ends in "somedomain.org" or
+   "provider.com".
+
+   With such an entry, large companies with different networks can
+   easily be covered with just a single and simple RMX entry.
+   Obviously, it requires proper PTR records.
+
+   As a special shortcut, the DNS name may be empty. In this case the
+   domain name of the zone itself is taken. Thus, with a very simple
+   entry of the type
+
+
+
+Hadmut Danisch                Experimental                     [Page 14]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+     somecompany.com  IN RMX domain:
+
+   a company could authorize all machines which's IP addresses map to
+   DNS names end in somecompany.com, which applies in the majority of
+   companies.
+
+
+
+
+5.7.  Full Address Query
+
+   As described above, RMX records will in most cases apply to the
+   domain part of the sender address. In special cases it might be
+   desirable to query the RMX record for a particular address.  An RMX
+   entry of the Full Address Query type may occur in a domain RMX
+   record only. It signals that the RMX record for the full address is
+   to be fetched and processed.
+
+   This entry type does not take arguments. The negation flag is not
+   supported. The tag is "full".
+
+   If such a full address query is to be performed, the mail address
+   must be mapped to a valid and non-ambiguos DNS name. This mapping
+   is still to be defined. It is not sufficient to simply replace the
+   @ with a dot, because of case sensitivity, character sets, etc. The
+   e-mail addresses
+
+      john.doe@example.org
+      John.Doe@example.org
+      john@doe.example.org
+
+   must all be mapped to different DNS entries. This entry type might
+   vanish in future versions of the draft, depending on the discussion
+   about whether to query the domain name part only or the full
+   address.
+
+5.8.  DNS mapped authorization
+
+   As I learned from comments to prior versions of the draft and from
+   alternative proposals, many users wish to have a DNS mapped
+   authorization table, i. e. the client queries a DNS entry of the
+   form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
+   Since people wish to have this, RMX will now include such a mapping
+   entry. The entry has a parameter giving the DNS domain name where
+   to look at. If the parameter is empty, then the same domain is
+   taken as for the RMX lookup.
+
+   As this is currently under construction and discussion in an IETF
+
+
+
+Hadmut Danisch                Experimental                     [Page 15]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   group, details will be published in future versions of this draft.
+
+5.9.  RMX reference
+
+   This entry type has no parameters. It means that all those machines
+   are authorized, which are pointed to by an MX record.
+
+6.  Optional and experimental entry types
+
+   The following subsections roughly describe further entry types
+   which might not be supported by all implementations and might not
+   be allowed in all legislations. These methods might vanish in
+   future versions of the draft and are just considerations about what
+   to include in RMX and what to not include. The main purpose of this
+   section is to start discussion about such entry types.
+
+   The disadvantage of the following methods is that they violate the
+   basic idea of RMX, i. e. to be simple, robust, easy to implement
+   and easy to administer. I personally do not believe that it is a
+   good idea or even feasible to implement cryptography for a world
+   wide e-mail transfer network. Keep in mind that cryptographic keys
+   can be copied.  If only <0.1% of cryptographic keys were revealed,
+   this completely compromises and spoils RMX. Cryptography is simply
+   the wrong tool for the problem RMX is intended to solve. I
+   nevertheless like to discuss these methods.
+
+6.1.  TLS fingerprint
+
+   The sender is considered to be authorized if the message was
+   transmitted through SMTP and TLS, and the sender used a certificate
+   matching the fingerprint given in the RMX record.
+
+6.2.  TLS and LDAP
+
+   This means that the receiver should perform an LDAP query for the
+   sender address (through the LDAP SRV record or given in the RMX
+   record), fetch the X.509 certificate for the sender. The sender is
+   considered to be authorized when the message was transmitted
+   through SMTP and TLS using this certificate.
+
+6.3.  PGP or S/MIME signature
+
+   It would be possible to accept a message only if it was signed with
+   PGP or S/MIME with a key which's fingerprint is given in the RMX
+   record or to be fetched from LDAP or any PGP database.  This is
+   just for discussion, since it violates the idea of RMX to focus on
+   the transport, not on the content. It would also allow replay
+   attacks and not cover the envelope sender address or message
+
+
+
+Hadmut Danisch                Experimental                     [Page 16]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   header.
+
+6.4.  Transparent Challenge/Response
+
+   It would also be possible to implement a challenge-response
+   mechanism without modifying the syntax of SMTP. For example, the
+   receiving MTA could issue a challenge with it's very first greeting
+   message, the sending MTA could hide the response in the HELO
+   parameter and when the receiving MTA later learns the sender
+   envelope address, it could verify the response based on
+   informations in the RMX record.
+
+6.5.  SASL Challenge/Response
+
+   Modern SMTP implementations already include a SASL mechanisms,
+   which easily allows to plugin new authentication mechanisms. While
+   common SASL mechanisms require to use a previously shared password,
+   a new mechanism could perform a challenge response authentication
+   as a SASL method.
+
+
+
+
+
+
+7.  Encoding
+
+7.1.  Alternative encoding as TXT records
+
+   The main objection against the prior versions of this draft was
+   that it requires a new RR entry type and upgrading all DNS servers.
+
+   Therefore and alternative encoding is proposed. Instead of using a
+   new RR type, the TXT record type is used to contain the RMX record.
+   The records would simply look as described in the entry type
+   chapters above, e.g.
+
+      _rmx.danisch.de.   IN TXT "apl:relays.rackland.de"
+
+   To allow smooth introduction of RMX without the need to immediately
+   upgrade all DNS servers, all clients (which have to be newly
+   installed anyway) MUST support both the TXT and the RMX records. A
+   client has to perform an ANY or a TXT and a RMX query. Servers/zone
+   tables may currently use TXT entries but SHOULD use RMX entries in
+   future.
+
+7.2.  RMX Records
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 17]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+7.2.1.  Overall structure
+
+   Each entry starts with an octet containting the entry type and the
+   negation flag:
+
+      +---+---+---+---+---+---+---+---+------
+      | N |    Entry Type Code        | Parameters...
+      +---+---+---+---+---+---+---+---+------
+
+      N           If this bit (MSB) is set, an IP address
+                  matching this entry is not authorized,
+                  but explicitely rejected. See entry
+                  type descriptions for details.
+
+      Entry Type  A 7bit number simply determining the entry
+                  type.
+
+
+   Currently, entries do not have an explicit length field, the entry
+   length is determined implicitely by the entry type. Applications
+   are required to abort if an unknown entry type is found, instead of
+   skipping unknown entries.
+
+7.2.2.  Record encoding
+
+   A RMX record is simply a concatenation of RMX entries.
+
+7.2.3.  Encoding of IPv4 and IPv6 address ranges
+
+   After the entry type tag as described above, one octet follows
+   giving the length L of the bit sequence. Then a sequence of exactly
+   as many octets follows as needed to carry L bits of information (=
+   trunc((L+7)/8) ).
+
+      +---+---+---+---+---+---+---+---+
+      | N | Entry Type Code  (1 or 2) |
+      +---+---+---+---+---+---+---+---+
+      |         Length Field L        |
+      +---+---+---+---+---+---+---+---+
+      |           Bit Field           |
+      /        ((L+7)/8) Octets       /
+      +---+---+---+---+---+---+---+---+
+
+
+7.2.4.  Encoding of DNS
+
+   After the entry type tag immediately follows a DNS encoded and
+   compressed [3] domain name.
+
+
+
+Hadmut Danisch                Experimental                     [Page 18]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+      +---+---+---+---+---+---+---+---+
+      | N |  Entry Type Code  (3..5)  |
+      +---+---+---+---+---+---+---+---+
+      |         Length Field L        |
+      +---+---+---+---+---+---+---+---+
+      |  Encoded DNS                  |
+      /  Name as described in RFC1035 /
+      +---+---+---+---+---+---+---+---+
+
+   In contrast to earlier versions of this draft, the DNS name cannot
+   be compressed, since this would cause decompression errors when a
+   DNS server is part of the query chain which does not know this
+   particular RR type.
+
+7.2.5.  Encoding of unused and full query
+
+   These entries do not contain parameters and does not allow the
+   negation flag.  So the encoding is quite simple:
+
+      +---+---+---+---+---+---+---+---+
+      | 0 |  Entry Type Code  (6 or 7)|
+      +---+---+---+---+---+---+---+---+
+
+
+
+7.2.6.  Additional Records
+
+   In order to avoid the need of a second query to resolve the given
+   host name, a DNS server should enclose the A record for that domain
+   name in the additional section of the additional section of the DNS
+   reply, if the server happens to be authoritative.
+
+   In order to avoid the need of a second query to resolve the given
+   host name, a DNS server should enclose the APL record for that
+   domain name in the additional section of the additional section of
+   the DNS reply, if the server happens to be authoritative.
+
+
+
+8.  Message Headers
+
+   An RMX query must be followed by any kind of action depending on
+   the RMX result. One action might be to reject the message.  Another
+   action might be to add a header line to the message body, thus
+   allowing MUAs and delivery programs to filter or sort messages.
+
+   In future, the RMX result might be melted into the Received: header
+   line.
+
+
+
+Hadmut Danisch                Experimental                     [Page 19]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   The details of such entries are to be discussed. As a proposal the
+   following form is suggested:
+
+     X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
+
+   where
+
+   RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
+   "TempFail", "BadData", "Trusted".
+
+   ADDRESS is the IP address of the sending machine
+
+   HOST is the name of the machine performing the RMX query.
+
+   DATE is the date of the query.
+
+   MECHANISM is the RMX method used to authorize the sender.
+
+
+
+9.  SMTP error messages
+
+   If a message is rejected because of RMX records, an error message
+   should be issued which explains the details.  It is to be discussed
+   whether new SMTP error codes are to be defined.
+
+
+10.  Message relaying and forwarding
+
+10.1.  Problem description
+
+   Message forwarding and relaying means that an MTA which received an
+   e-mail by SMTP does not deliver it locally, but resends the message
+   - usually unchanged except for an additional Received header line
+   and maybe the recipient's address rewritten - to the next SMTP MTA.
+   Message forwarding is an essential functionality of e-mail
+   transport services, for example:
+
+     - Message transport from outer MX relay to the intranet
+     - Message forwarding and Cc-ing by .forward or .procmail-alike
+       mechanisms
+     - Mailing list processing
+     - Message reception by mail relays with low MX priority,
+       usually provided by third parties as a stand-by service
+       in case of relay failure or maintenance
+     - "Forwarding" and "Bouncing" as a MUA functionality
+
+   In all these cases a message is sent by SMTP from a host which is
+
+
+
+Hadmut Danisch                Experimental                     [Page 20]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   not covered by the original sender domain's RMX records.  While the
+   RMX records would forbid accepting this message, it still must be
+   accepted. The following subsections explain how to cope with
+   relaying.
+
+10.2.  Trusted relaying/forwarding
+
+   In some cases the receiving MTA trusts the sending MTA to not fake
+   messages and to already have checked the RMX records at message
+   reception. As a typical example, a company might have an outer mail
+   relay which receives messages from the Internet and checks the RMX
+   records. This relay then forwards the messages to the different
+   department's mail servers. It does not make sense for these
+   department mail servers to check the RMX record, since the RMX
+   records have already been checked and - since the message was
+   relayed by the outer relay - always would deny the message. In this
+   case there is a trust relationship between the department relays
+   and the outer relay.  So RMX checking is turned off for trusted
+   relays. In this example, the department relays would not check
+   messages from the outer relay (but for intranet security, they
+   could still check RMX records of the other departments sub-domains
+   to avoid internal forgery between departments).
+
+   Another common example are the low-priority MX relays, which
+   receive and cache e-mails when the high-priority relays are down.
+   In this case, the high-priority relay would trust the low-priority
+   relay to have verified the sender authorization and would not
+   perform another RMX verification (which would obviously fail).
+
+   When a relay forwards a message to a trusting machine, the envelope
+   sender address should remain unchanged.
+
+10.3.  Untrusted relaying/forwarding
+
+   If the receiving MTA does not trust the forwarding MTA, then there
+   is no chance to leave the sender envelope address unchanged. At a
+   first glance this might appear impracticable, but this is
+   absolutely necessary. If an untrusted MTA could claim to have
+   forwarded a message from a foreign sender address, it could have
+   forged the message as well. Spammers and forgers would just have to
+   act as such a relay.
+
+   Therefore, it is required that, when performing untrusted
+   forwarding, the envelope sender address has to be replaced by the
+   sender address of someone responsible for the relaying mechanism,
+   e.g. the owner of the mailing list or the mail address of the user
+   who's .forward caused the transmission. It is important to stress
+   that untrusted relaying/forwarding means taking over responsibility
+
+
+
+Hadmut Danisch                Experimental                     [Page 21]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   for the message.  It is the idea of RMX records to tie
+   responsibility to message transmission. Untrusted relaying without
+   replacing the sender address would mean to transmit without taking
+   responsibility.
+
+   The disadvantage is that the original sender address is lost.
+   Therefore, whenever a sender address replacement happens, the
+   Received-Line must contain the old address. Many of today's MTAs
+   already insert the envelope recipient address, but not the sender
+   address into the Received header line. It seems reasonable to
+   require every Received line to include both the sender and
+   recipient address of the incoming SMTP connection.
+
+
+11.  Security Considerations
+
+11.1.  Draft specific considerations
+
+11.1.1.  Authentication strength
+
+   It is important to stress, that the suggested method does not
+   provide high level security and does not completely prevent forged
+   e-mails or spam under any circumstances. It is a robust, but not
+   highly reliable and completely secure security mechanism. Keep in
+   mind that it is based on DNS, and DNS is not secure today.
+   Authorization is based on the IP address. The very same machine
+   with the very same IP address could be authorized to send e-mail
+   with a given sender address and sending spam at the same time.
+   Maybe because several users are logged in. Or because several
+   customers use the same relay of the same ISP, where one customer
+   could use the sender address of a different customer. It is up to
+   the ISP to prevent this or not. Machines can still be hijacked.
+   Spammers are also domain owners. They can simply use their own
+   domain and authorize themselves. You will always find people on the
+   world who do not care about security and open their relays and RMX
+   records for others to abuse them.  RMX is to be considered as a
+   very cheap and simple light weight mechanism, which can
+   nevertheless provide a significant improvement in mail security
+   against a certain class of attacks, until a successor of SMTP has
+   been defined and commonly accepted.
+
+11.1.2.  Where Authentication and Authorization end
+
+   Previous versions of RMX records did not cover the local part of
+   the e-mail address, i.e. what's on the left side of the @ sign.
+   This is still to be discussed. Authentication and authorization are
+   limited to the sending MTA's IP address. The authentication is
+   limited to the TCP functionality, which is sufficient for light
+
+
+
+Hadmut Danisch                Experimental                     [Page 22]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   weight authentication. The RMX records authorize the IP address of
+   the sending host only, not the particular sender of the message. So
+   if a machine is authorized to use sender addresses of more than a
+   single domain, the authentication scheme does not prevent that any
+   user on this machine can send with any of these domains. RMX is not
+   a substitute for the host security of the involved machines.
+
+   The proposed authentication scheme can be seen as a "half way
+   authentication": It does not track back an e-mail to the effective
+   sender. It tracks only half of the way, i. e. it tracks back to the
+   domain and it's DNS administrators who authorized that particular
+   sender IP address to use it for sending e-mail. How the party
+   responsible for that domain performs user authentication, whom it
+   grants access to, how it helds people responsible for abuse, is
+   completely left as the private business of those who are in charge
+   of that domain. So this draft does not interfere with the domain's
+   individual security policy or any legislation about such policies.
+   On the other hand, the proposed authentication scheme does not give
+   any statement about the nature and quality of the domain's security
+   policy. This is an essential feature of the proposal: E-mail
+   authentication must be deployed world wide, otherwise it won't do
+   the job. Any security scheme interfering with the local
+   legislations or the domain's security policy will not be accepted
+   and can't effectively deployed. Therefore, the security policy must
+   remain the domain's private business, no matter how lousy the
+   policy might be.
+
+   In order to achieve this and to make use of the only existing world
+   wide Internet directory scheme (DNS), the approach of this proposal
+   is to just ignore the local part of the sender address (i.e. what's
+   left of the @ part) and limit view to the domain part. After all,
+   that's what we do anyway when delivering to a given address with
+   SMTP.
+
+11.1.3.  Vulnerability of DNS
+
+   DNS is an essential part of the proposed authentication scheme,
+   since it requires any directory service, and DNS is currently the
+   only one available. Unfortunately, DNS is vulnerable and can be
+   spoofed and poisoned. This flaw is commonly known and weakens many
+   network services, but for reasons beyond that draft DNS has not
+   been significantly improved yet. After the first version of this
+   draft, I received several comments who asked me not to use DNS
+   because of its lack of security. I took this into consideration,
+   but came to the conclusion that this is unfeasible: Any
+   authentication scheme linked to some kind of symbolic identity (in
+   this case the domain name) needs some kind of infrastructure and
+   trusted assignment. There are basically two ways to do it: Do it
+
+
+
+Hadmut Danisch                Experimental                     [Page 23]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   yourself and trust nobody else, or let someone else do it. There
+   are methods to do it the former way, e.g. to give someone some kind
+   of authentication information after a first successful e-mail
+   exchange, e.g. some kind of cookie or special e-mail address. This
+   is certainly interesting and powerful, but it does not solve the
+   problem on a world wide scale and is far to complicated and error
+   prone for the average user, i. e. 99% of the users.
+
+   The latter method to let someone else do the symbolic name
+   assignment and create the authentication framework is well known.
+   It context of public key cryptography, this is called a Public Key
+   Infrastructure (PKI). On of the best known facts about PKIs is
+   that, until now, we don't have any covering a significant part of
+   the Internet. And we won't have any in near future. The complexity
+   is far too high, it is too expensive, and it involves cooperation
+   of every single user, which is simply unrealistic and extremely
+   error prone. So what do we have we can use? All we have is the DNS
+   and the Whois database. And we have countries who don't allow
+   cryptography. So the proposal was designed to use DNS without
+   cryptography. It does not avoid DNS because of its vulnerability,
+   it asks for a better DNS, but accepts the DNS as it is for the
+   moment. Currently there are two main threats caused by the DNS
+   weakness:
+
+      - A spammer/forger could spoof DNS in order to gain false
+        authorization to send fake e-mails.
+
+      - An attacker could spoof DNS in order to block delivery from
+        authorized machines, i. e. perform a Denial of Service attack.
+
+   The first one is rather unrealistic, because it would require an
+   average spammer to poison a significant part of the DNS servers of
+   its victims. A spammer sending messages to one million receipients
+   would need to poison at least 1-10% which is 10,000 to 100,000
+   receipient's DNS servers. This should be unfeasible in most cases.
+
+   In contrast, the second threat is a severe one. If an attacker
+   wanted to block messages from one company to another, he just needs
+   to poison the recipients DNS server with a wrong RMX record in
+   order to make the recipient's SMTP machine reject all messages. And
+   this is feasible since the attacker needs to poison only a single
+   DNS server. But does this make SMTP more vulnerable? No. Because
+   the attacker can already do even more without RMX. By poisoning the
+   sender's DNS server with wrong MX records, the attacker can also
+   block message delivery or even redirect the messages to the
+   attacker's machine, thus preventing any delivery error messages and
+   furthermore getting access to the messages.
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 24]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   As a consequence, e-mail delivery by SMTP requires a better DNS
+   anyway. The requirements are not significantly expanded by RMX.
+
+11.1.4.  Sneaking RMX attack?
+
+   While writing a test implementation, a certain kind of attack came
+   into my mind. I'm still not sure, whether this attack is possible
+   on any DNS server, but I believe it should be mentioned:
+
+   Imagine an unauthorized sender is sending a forged mail (e.g.
+   spam).  At connection time, before querying the RMX record, the
+   receiving MTA usually performs a PTR query for the IP address of
+   the sending MTA. If the sender has control over the authoritative
+   name server for that particular IP address, the sender could give a
+   normal PTR answer, but could append a wrong RMX, APL, or A record
+   in the additional section of the query. A subsequent RMX query
+   could receive wrong DNS data if the DNS server used by the
+   receiving MTA accepted those forged records.
+
+11.1.5.  Open SMTP relays
+
+   Open SMTP relays (i.e. machines who accept any e-mail message from
+   anyone and deliver to the world) abused by spammers are a one of
+   the main problems of spam defense and sender backtracking. In most
+   cases this problem just vanishes because foreign open relay
+   machines will not be covered by the RMX records of the forged
+   sender address. But there are two special cases:
+
+   If the spammer knows about a domain which authorizes this
+   particular machine, that domain can be used for forgery. But in
+   this case, the IP address of the relay machine and the RMX records
+   of the domain track back to the persons responsible. Both can be
+   demanded to fix the relay or remove the RMX record for this
+   machine. An open relay is a security flaw like leaving the machine
+   open for everybody to login and send random mails from inside. Once
+   the administrative persons refuse to solve the problem, they can be
+   identified as spammers and held responsible.
+
+   The second special case is when a domain authorizes all IP
+   addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
+   this case, open relays don't make things worse. It's up to the
+   recipient's MTA to reject mails from domains with loose security
+   policies.
+
+11.1.6.  Unforged Spam
+
+   This proposal does not prevent spam (which is, by the way, not yet
+   exactly defined), it prevents forgery. Since spam is against law
+
+
+
+Hadmut Danisch                Experimental                     [Page 25]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   and violates the recipients rights, spam depends on untracability
+   of the sender. In practice the sender forges the sender address
+   (other cases see below). This proposal is designed to detect such
+   forgeries.
+
+   However, the RMX approach is rendered ineffective, if the sender
+   doesn't forge. If the sender uses just a normal address of it's own
+   domain, this is just a plain, normal e-mail, which needs to be let
+   through. Since it is up to the human's taste whether this is spam
+   or not, there's no technical way to reliably identify this as spam.
+   But since the sender domain is known, this domain can be
+   blacklisted or legal steps can be gone into.
+
+11.1.7.  Reliability of Whois Entries
+
+   Once the RMX infrastructure gets deployed, what's the security
+   gain?  It allows to determine the domain which's DNS zone
+   authorized the sending machine. What's that good for? There are
+   some immediate uses of the domain name, e.g. in black- and
+   whitelisting. But in most cases this is just the starting point of
+   further investigations, either performed automatically before
+   message acceptance, or manually after spam has been received and
+   complainted about.
+
+   The next step after determining the domain is determining the
+   people responsible for this domain. This can sometimes be achieved
+   by querying the Whois databases. Unfortunately, many whois entries
+   are useless because they are incomplete, wrong, obsolete, or in
+   uncommon languages. Furthermore, there are several formats of
+   address informations which make it difficult to automatically
+   extract the address. Sometimes the whois entry identifies the
+   provider and not the owner of the domain. Whois servers are not
+   built for high availability and sometimes unreachable.
+
+   Therefore, a mandatory standard is required about the contents and
+   the format of whois entries, and the availability of the servers.
+   After receiving the MAIL FROM SMTP command with the sender envelope
+   address, the receiving MTA could check the RMX record and Whois
+   entry. If it doesn't point to a real human, the message could be
+   rejected and an error message like "Ask your provider to fix your
+   Whois entry" could be issued. Obviously, domain providers must be
+   held responsible for wrong entries. It might still be acceptable to
+   allow anonymous domains, i. e. domains which don't point to a
+   responsible human. But it is the receivers choice to accept e-mails
+   from such domains or not.
+
+11.1.8.  Hazards for Freedom of Speech
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 26]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   Currently, some governments try to enforce limitations of internet
+   traffic in order to cut unwanted content providers from the
+   network. Some of these governments try to hide a whole country
+   behind firewalls, others try to force Internet providers to poison
+   DNS servers with wrong A records for web servers, e.g. one county
+   administration in Germany tries to do so. If message reception
+   depends on DNS entries, the same governments will try to block not
+   only HTTP, but SMTP also.
+
+   However, since most MTAs already reject messages from unresolvable
+   domain names this is not a new threat.
+
+11.2.  General Considerations about spam defense
+
+   After discussing security requirements of the proposal, now the
+   security advantages of the RMX approach over content based filters
+   will be explained. Basically, there are three kinds of content
+   filters:
+
+      - Those who upload the message or some digest to an external
+        third party and ask "Is this spam"?
+
+      - Those who download a set of patterns and rules from a third
+        party and apply this set to incoming messages in order to
+        determine whether it is spam.
+
+      - Those who are independent and don't contact any third party,
+        but try to learn themselves what is spam and what isn't.
+
+
+   The message filters provided by some e-mail service providers are
+   usually not a kind of their own, but a combination of the first two
+   kinds.
+
+11.2.1.  Action vs. reaction
+
+   Content filters suffer from a fundamental design problem: They are
+   late. They need to see some content of the same kind before in
+   order to learn and to block further distribution.
+
+   This works for viruses and worms, which redistribute. This doesn't
+   work for spam, since spam is usually not redistributed after the
+   first delivery. When the filters have learned or downloaded new
+   pattern sets, it's too late.
+
+   This proposal does not have this problem.
+
+11.2.2.  Content based Denial of Service attacks
+
+
+
+Hadmut Danisch                Experimental                     [Page 27]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   All three kinds of content filters, but especially the second and
+   the third kind are vulnerable to content based Denial of Service
+   attacks.
+
+   If some kind of third party (e.g. non-democratic government,
+   intellectual property warriors, religious groups, military, secret
+   services, patriots, public relation agents, etc.) wants certain
+   contents not to be distributed, they could either poison the
+   pattern/rule databases or feed wrong sets to particular receivers.
+
+   Such pattern/rule sets are the perfect tool for censoring e-mail
+   traffic and denial of service attacks by governments and other
+   parties, and a similar threat are virus filters. E. g. the content
+   industry could demand to teach all virus and spam filters to delete
+   all e-mails containing the URL of an MP3 web server outside the
+   legislations. Software manufacturers could try to block all e-mails
+   containing software license keys, thus trying to make unallowed
+   distribution more difficult. Governments could try to block
+   distribution of unwanted informations.
+
+   This proposal does not have this problem.
+
+
+12.  Privacy Considerations
+
+   (It was proposed on the 56th IETF meeting to have a privacy section
+   in drafts and RFCs.)
+
+12.1.  Draft specific considerations
+
+12.1.1.  No content leaking
+
+   Since the RMX approach doesn't touch the contents of a message in
+   any way, there is obviously no way of leaking out any information
+   about the content of the message. RMX is based solely on the
+   envelope recipient address. However, methods to fix problems not
+   covered by RMX might allow content leaking, e.g. if the acceptance
+   of a message with an empty sender address requires the reference to
+   the message id of an e-mail recently sent, this allows an attacker
+   to verify whether a certain message was delivered from there.
+
+12.1.2.  Message reception and sender domain
+
+   Message delivery triggers RMX and APL requests by the recipient.
+   Thus, the admin of the DNS server or an eavesdropper could learn
+   that the given machine has just received a message with a sender
+   from this address, even if the SMTP traffic itself had been
+   encrypted.
+
+
+
+Hadmut Danisch                Experimental                     [Page 28]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   However, most of today's MTAs do query the MX and A records of the
+   domain after the MAIL FROM command, so this is not a real new
+   threat.
+
+12.1.3.  Network structure
+
+   Since RMX and its associated APL records provide a complete list of
+   all IP addresses of hosts authorized to send messages from this
+   address, they do reveal informations about the network structure
+   and maybe the lifestyle of the domain owner, since a growing number
+   of domains are owned by single persons or families. E.g. the RMX
+   records could reveal where someone has his job or spends his time
+   at weekends.
+
+   If such informations are to be kept secret, it is the user's job to
+   not sent e-mails from there and to relay them from non-compromising
+   IP addresses.
+
+12.1.4.  Owner information distribution
+
+   As described above, RMX depends partly on the reliability of the
+   whois database entries. It does not make anonymous domains
+   impossible, but it requires to keep the database entries "true", i.
+   e. if a whois entry does not contain informations about the
+   responsible person, this must be unambigously labeled as anonymous.
+   It must not contain fake names and addresses to pretend a non-
+   existing person. However, since most Internet users on the world
+   feel extremely annoyed by spam, they will urge their MTA admin to
+   reject messages from anonymous domains. The domain owner will have
+   the choice to either remain anonymous but be not able to send e-
+   mail to everyone in the world, or to be able but to reveal his
+   identity to everyone on the world.
+
+   It would be possible to provide whois-like services only to
+   recipients of recent messages, but this would make things too
+   complicated to be commonly adopted.
+
+12.2.  General Considerations about spam defense
+
+12.2.1.  Content leaking of content filters
+
+   As described above in the Security chapter, there are spam filters
+   which inherently allow leakage of the message body. Those filters
+   upload either the message body, or in most cases just some kind of
+   checksum to a third party, which replies whether this is to be seen
+   as spam or not. The idea is to keep a databases of all digests of
+   all messages.  If a message is sent more often than some threshold,
+   it is to be considered as a mass mail and therefore tagged as spam.
+
+
+
+Hadmut Danisch                Experimental                     [Page 29]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   While the digest itself does not reveal the content of the message,
+   it perfectly reveals where a particular message has been delivered
+   to. If a government finds just a single unwanted message, if a
+   software manufacturer finds a single message with a stolen product
+   license key, if someone finds a message with unpatriotic content,
+   it takes just a single database lookup to get a list of all people
+   who received this particular message. Content filters with digest
+   upload are the perfect "Big Brother".
+
+12.2.2.  Black- and Whitelists
+
+   Some proposals against spam are based on a central database of
+   white- or blacklisted IP addresses, Sender names, Message IDs or
+   whatever. Again, there is a central database which learns who has
+   received which e-mail or from which sender with every query. This
+   allows tracking relations between persons, which is also a breach
+   of privacy.
+
+
+
+13.  Deployment Considerations
+
+13.1.  Compatibility
+
+13.1.1.  Compatibility with old mail receivers
+
+   Since the suggested extension doesn't change the SMTP protocol at
+   all, it is fully compatible with old mail receivers. They simply
+   don't ask for the RMX records and don't perform the check.
+
+13.1.2.  Compatibility with old mail senders
+
+   Since the SMTP protocol is unchanged and the SMTP sender is not
+   involved in the check, the method is fully compatible with old mail
+   senders.
+
+13.1.3.  Compatibility with old DNS clients
+
+   Since the RMX is a new RR, the existing DNS protocol and zone
+   informations remain completely untouched.
+
+   If RMX is provided as a TXT record instead, it must be ensured that
+   no other software is misinterpreting this entry.
+
+13.1.4.  Compatibility with old DNS servers
+
+   Full compatibility: If the server does not support RMX records, RMX
+   in TXT records can be used.
+
+
+
+Hadmut Danisch                Experimental                     [Page 30]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+13.2.  Enforcement policy
+
+   Obviously, for reasons of backward compatibility and smooth
+   introduction of this scheme, RMX records can't be required
+   immediately. Domains without RMX records must temporarily be
+   treated the same way as they are treated right now, i.e. e-mail
+   must be accepted from anywhere. But once the scheme becomes
+   sufficiently widespread, mail relays can start to refuse e-mails
+   with sender addresses from domains without RMX records, thus
+   forcing the owner of the domain to include a statement of
+   authorization into the domain's zone table.  Domain owners will
+   still be free to have an RMX record with a network and mask
+   0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
+   On the other hand, mail receivers will be free to refuse mails from
+   domains without RMX records or RMX records which are too loose.
+   Advanced MTAs might have a configuration option to set the maximum
+   number of IP addresses authorized to use a domain. E-mails from a
+   domain, which's RMX records exceed this limit, would be rejected.
+   For example, a relay could reject e-mails from domains which
+   authorize more than 8 IP addresses. That allows to accept e-mails
+   only from domains with a reasonable security policy.
+
+
+
+14.  General considerations about fighting spam
+
+   Is there a concise technical solution against spam? Yes.
+
+   Will it be deployed? Certainly not.
+
+   Why not? Because of the strong non-technical interests of several
+   parties against a solution to the problem, as described below.
+   Since these are non-technical reasons, they might be beyond the
+   scope of such a draft. But since they are the main problems that
+   prevent fighting spam, it is unavoidable to address them. This
+   chapter exists temporarily only and should support the discussion
+   of solutions. It is not supposed to be included in a later RFC.
+
+14.1.  The economical problem
+
+   As has been recently illustrated in the initial session of the
+   IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
+   sending spam is a business with significant revenues.
+
+   But a much bigger business is selling Anti-Spam software. This is a
+   billion dollar market, and it is rapidly growing. Any simple and
+   effective solution against spam would defeat revenues and drive
+   several companies into bankrupt, would make consultants jobless.
+
+
+
+Hadmut Danisch                Experimental                     [Page 31]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   Therefore, spam is essential for the Anti-Spam business. If there
+   is no spam, then no Anti-Spam software can be sold, similar to the
+   Anti-Virus business. There are extremely strong efforts to keep
+   this market growing. Viruses, Worms, and now spam are just perfect
+   to keep this market alive: It is not sufficient to just buy a
+   software. Databases need to be updated continuously, thus making
+   the cash flow continuously. Have a single, simple, and permanent
+   solution to the problem and - boom - this billion dollar market is
+   dead.
+
+   That's one of the reasons why people are expected to live with
+   spam. They have to live with it to make them buy Anti-Spam
+   software.  Content filters are perfect products to keep this market
+   alive.
+
+14.2.  The POP problem
+
+   Another problem is the history of mail delivery. Once upon a time,
+   there used to be very few SMTP relays which handled the e-mail
+   traffic of all the world, and everybody was happy with that. Then
+   odd things like Personal Computers, which are sometimes switched
+   off, portable computers, dynamicly assigned IP addresses, IP access
+   from hotel rooms, etc. was invented, and people became unhappy,
+   because SMTP does not support delivery to such machines. To make
+   them happy again, the Post Office Protocol[4] was invented, which
+   turned the last part of message delivery from SMTP's push style
+   into a pull style, thus making virtually every computer on the
+   world with any random IP address a potential receiver of mails for
+   random domains. Unfortunately, only receiving e-mail was covered,
+   but sending e-mail was left to SMTP.
+
+   The result is that today we have only very few SMTP relays pointed
+   to by MX records, but an extreme number of hosts sending e-mail
+   with SMTP from any IP address with sender addresses from any
+   domain. Mail delivery has become very asymmetric. Insecurity,
+   especially forgeability, has become an essential part of mail
+   transport.
+
+   That problem could easily be fixed: Use protocols which allow
+   uploading of messages to be delivered. If a host doesn't receive
+   messages by SMTP, it shouldn't deliver by SMTP.  Mail delivery
+   should go the same way back that incoming mail went in.  This is
+   not a limitation to those people on the road who plug their
+   portable computer in any hotel room's phone plug and use any
+   provider. If there is a POP server granting download access from
+   anywhere, then the same server should be ready to accept uploading
+   of outgoing messages.
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 32]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   But as I saw from the comments on the first version of this draft,
+   people religiously insist on sending e-mail with their domain from
+   any computer with any IP address in the world, e.g. when visiting a
+   friend using her computer. It appears to be impossible to convince
+   people that stopping mail forgery requires every one of them to
+   give up forging.
+
+14.3.  The network structure problem
+
+   A subsequent problem is that many organisations failed to implement
+   a proper mail delivery structure and heavily based their network on
+   this asymmetry. I received harsh comments from Universities who
+   were unable to give their network a good structure. While they do
+   have a central mail relay for incoming mail to the universities
+   domain, they developed a structure where every member of the
+   University randomly sends e-mails with that University's domain as
+   a sender address from home or everywhere in the world with any
+   dynamically assigned IP address from any provider. So this domain
+   is to be used from every possible IP address on earth, and they are
+   unable to operate any authentication scheme. Furthermore, they were
+   unable to understand that such a policy heavily supports spam and
+   that they have to expect that people don't accept such e-mails
+   anymore once they become blacklisted.
+
+   As long as organisations insist on having such policies, spammers
+   will have a perfect playground.
+
+14.4.  The mentality problem
+
+   Another problem is the mentality of many internet users of certain
+   countries. I received harsh comments from people who strongly
+   insisted on the freedom to send any e-mail with any sender address
+   from anywhere, and who heavily refused any kind of authentication
+   step or any limitation, because they claimed that this would
+   infringe their constitutional "Freedom of speech". They are
+   undeviatingly convinced that "Freedom of speech" guarantees their
+   right to talk to everybody with any sender address, and that is has
+   to be kept the recipient's own problem to sort out what he doesn't
+   want to read - on the recipient's expense.
+
+   It requires a clear statement that the constitutional "Freedom of
+   Speech" does not cover molesting people with unsolicited e-mail
+   with forged sender address.
+
+14.5.  The identity problem
+
+   How does one fight against mail forgery? With authentication.  What
+   is authentication? In simple words: Making sure that the sender's
+
+
+
+Hadmut Danisch                Experimental                     [Page 33]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+   real identity meets the recipients idea of who is the sender, based
+   on the sender address which came with the message.
+
+   What is identity? It is the main problem. Several countries have
+   different ideas of "identity", which turn out to be somehow
+   incompatible. In some countries people have identity cards and
+   never change their name and birthday. Identities are created by
+   human birth, not by identity changes. Other countries do not have
+   such a tight idea about identity. People's temporary identity is
+   based on nothing more than a driving license and a social security
+   number.  With this background, it is virtually impossible to create
+   a trustworthy PKI covering all Internet users. I learned that it is
+   extremely difficult to convince some people to give up random e-
+   mail sending.
+
+14.6.  The multi-legislation problem
+
+   Many proposals about fighting spam are feasible under certain
+   legislations only, and are inacceptable under some of the
+   legislations. But a world wide applicable method is required.
+   That's why the approach to ask everone on the world to sign
+   messages with cryptographic keys is not feasible.
+
+
+Implementation and further Information
+
+   Further informations and a test implementation are available at
+
+      http://www.danisch.de/work/security/antispam.html
+      http://www.danisch.de/software/rmx/
+
+
+   Additional informations and a technology overview are also
+   available at
+
+      http://www.mikerubel.org/computers/rmx_records/
+
+
+References
+
+
+
+1.   S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
+     els," RFC 2119 (March 1997).
+
+2.   J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
+
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 34]
+
+INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
+
+
+3.   P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
+     RFC 1035 (November 1987).
+
+4.   J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
+     (May 1996).
+
+
+Draft History
+
+   00  Dec 2002
+   01  Apr 2003
+   02  Jun 2003
+   03  Oct 2003
+
+Author's Address
+
+   Hadmut Danisch
+
+   Tennesseeallee 58
+   76149 Karlsruhe
+   Germany
+
+   Phone:  ++49-721-843004 or ++49-351-4850477
+   E-Mail: rfc@danisch.de
+
+Comments
+
+   Please send comments to rfc@danisch.de.
+
+Expiry
+
+   This drafts expires on Apr 1, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hadmut Danisch                Experimental                     [Page 35]
+
diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt
new file mode 100644
index 0000000..7b5e8cc
--- /dev/null
+++ b/doc/draft/draft-dnsext-opcode-discover-02.txt
@@ -0,0 +1,241 @@
+
+IETF DNSEXT WG                                             Bill Manning
+draft-dnsext-opcode-discover-02.txt                              ep.net
+                                                             Paul Vixie
+                                                                    ISC
+                                                            13 Oct 2003
+
+
+                         The DISCOVER opcode
+
+This document is an Internet-Draft and is subject to all provisions of
+Section 10 of RFC2026.
+
+Comments may be submitted to the group mailing list at "mdns@zocalo.net"
+or the authors.
+
+Distribution of this memo is unlimited.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups.  Note that other groups
+may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time.  It
+is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119
+
+0. Abstract:
+
+   The QUERY opcode in the DNS is designed for unicast. With the
+   development of multicast capabilities in the DNS, it is desireable
+   to have a more robust opcode for server interactions since a single
+   request may generate replies from multiple responders. So DISCOVER
+   is defined to deal with replies from multiple responders.
+
+   As such, this document extends the core DNS specifications to allow
+   clients to have a method for coping with replies from multiple
+   responders. Use of this new opcode may facilitate DNS operations in
+   modern networking topologies. A prototype of the DISCOVER opcode
+   was developed during the TBDS project (1999-2000), funded under DARPA
+   grant F30602-99-1-0523.
+
+1. Introduction:
+
+   This document describes an experimental extension to the DNS to receive
+   multiple responses which is the likely result when using DNS that has
+   enabled multicast queries.  This approach was developed as part of the
+   TBDS research project, funded under DARPA grant F30602-99-1-0523.  The
+   full processing rules used by TBDS are documented here for possible
+   incorporation in a future revision of the DNS specification."
+
+2. Method:
+
+        DISCOVER works like QUERY except:
+
+        1. it can be sent to a broadcast or multicast destination. QUERY
+           isn't defined for non-unicast, and arguably shouldn't be.
+
+        2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
+           tuples. TBDS tried to augment this structure as follows:
+           <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
+           TBDS, it is cleaner to place the SRV question in a separate pass.
+
+        3. if QDCOUNT equals 0 then only servers willing to do recursion should
+           answer. Other servers must silently discard the DISCOVER request.
+
+        4. if QDCOUNT is not equal to 0 then only servers who are authoritative
+           for the zones named by some QNAME should answer.
+
+        5. responses may echo the request's Question section or leave it blank,
+           just like QUERY.
+
+        6. responses have standard Answer, Authority, and Additional sections.
+           e.g. the response is the same as that to a QUERY. It is desireable
+           that zero content answers not be sent to avoid badly formed or
+           unfulfilled requests. Responses should be sent to the unicast
+           address of the requester and the source address should reflect
+           the unicast address of the responder.
+
+   Example usage for gethostby{name,addr}-style requestors:
+
+        Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
+        ip6.arpa domain.
+
+        DISCOVER whether anyone in-scope is authoritative for this zone.
+
+                If so, query these authoritative servers for local
+                in-addr/ip6 names.
+
+        If not, DISCOVER whether there are recursive servers available.
+
+                If so, query these recursive servers for local
+                in-addr/ip6 names.
+
+        So, a node will issue a multicast request with the DISCOVER opcode at
+        some particular multicast scope.  Then determine, from the replies,
+        whether there are any DNS servers which are authoritative (or support
+        recursion) for the zone. Replies to DISCOVER requests MUST set the
+        Recursion Available (RA) flag in the DNS message header.
+
+        It is important to recognize that a requester must be prepared to
+        receive multiple replies from multiple responders. We expect that
+        there will be a single response per responder.
+
+        Once one learns a host's FQDN by the above means, repeat the process
+        for discovering the closest enclosing authoritative server of such
+        local name.
+
+        Cache all NS and A data learned in this process, respecting TTL's.
+
+   TBDS usage for SRV requestors:
+
+        Do the gethostbyaddr() and gethostbyname() on one's own link-local
+        address, using the above process.
+
+        Assume that the closest enclosing zone for which an authority server
+        answers an in-scope DISCOVER packet is "this host's parent domain".
+
+        Compute the SRV name as _service._transport.*.parentdomain.
+
+        This is a change to the definition as defined in RFC 1034.
+        A wildcard label ("*") in the QNAME used in a DNS message with
+        opcode DISCOVER SHOULD be evaluated with special rules.  The
+        wildcard matches any label for which the DNS server data is
+        authoritative.  For example 'x.*.example.com.' would match
+        'x.y.example.com.' and 'x.yy.example.com.' provided that the
+        server was authoritative for 'example.com.'  In this particular
+        case, we suggest the follwing considerations be made:
+
+   getservbyname() can be satisfied by issuing a request with
+   this computed SRV name.  This structure can be
+   populated by values returned from a request as follows:
+
+        s_name    The name of the service, "_service" without the
+                  preceding underscore.
+        s_aliases The names returned in the SRV RRs in replies
+                  to the query.
+        s_port    The port number in the SRV RRs replies to the
+                  query.  If these port numbers disagree - one
+                  of the port numbers is chosen, and only those
+                  names which correspond are returned.
+        s_proto   The transport protocol from named by the
+                  "_transport" label, without the preceding
+                  underscore.
+
+        Send SRV query for this name to discovered local authoritative servers.
+
+     Usage for disconnected networks with no authoritative servers:
+
+        Hosts should run a "stub server" which acts as though its FQDN is a
+        zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
+        ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
+        and the other timers.  Compute NS as the host's FQDN.  Compute the
+        glue as the host's link-local address. Or Hosts may run a
+        "DNS stub server" which acts as though its FQDN is a zone name.  The
+        rules governing the behavior of this stub server are given elsewhere
+        [1] [2].
+
+        Such stub servers should answer DISCOVER packets for its zone, and
+        will be found by the iterative "discover closest enclosing authority
+        server" by DISCOVER clients, either in the gethostbyname() or SRV
+        cases described above.  Note that stub servers only answer with
+        zone names which exactly match QNAME's, not with zone names which
+        are owned by QNAME's.
+
+   The main deviation from the DNS[3][4] model is that a host (like, say, a
+   printer offering LPD services) has a DNS server which answers authoritatively
+   for something which hasn't been delegated to it.  However, the only way that
+   such DNS servers can be discovered is with a new opcode, DISCOVER, which
+   is explicitly defined to discover undelegated zones for tightly scoped
+   purposes.  Therefore this isn't officially a violation of DNS's coherency
+   principles. In some cases a responder to DISCOVER may not be traditional
+   DNS software, it could be special purpose software.
+
+3. IANA Considerations
+
+        As a new opcode, the IANA will need to assign a numeric value
+        for the memnonic. The last OPCODE assigned was "5", for UPDATE.
+        Test implementations have used OPCODE "6".
+
+4. Security Considerations
+
+        No new security considerations are known to be introduced with any new
+        opcode, however using multicast for service discovery has the potential
+        for denial of service, primarly from flooding attacks. It may also be
+        possible to enable deliberate misconfiguration of clients simply by
+        running a malicious DNS resolver that claims to be authoritative for
+        things that it is not. One possible way to mitigate this effect is by
+        use of credentials, such as CERT resource records within an RR set.
+        The TBDS project took this approach.
+
+5. Attribution:
+
+        This material was generated in discussions on the mdns mailing list
+hosted by Zocalo in March 2000. Updated by discussion in September/October
+2003.  David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
+Erik Guttman, Bill Manning and Paul Vixie were active contributors.
+
+6. Author's Address
+
+   Bill Manning
+   PO 12317
+   Marina del Rey, CA. 90295
+   +1.310.322.8102
+   bmanning@karoshi.com
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+   +1 650 779 7001
+   <vixie@isc.org>
+
+7. References
+
+Informational References:
+
+[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
+        draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
+
+[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
+        draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.
+
+Normative References:
+[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+        RFC 1034, November 1987.
+[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
+        RFC 1035, November 1987
+
+        ----------------------------EOL-----------------------
+
diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
new file mode 100644
index 0000000..224e7ad1
--- /dev/null
+++ b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
@@ -0,0 +1,240 @@
+Internet Engineering Task Force                             Alain Durand
+INTERNET-DRAFT                                          SUN Microsystems
+Feb 21, 2003
+Expires Aug 2, 2003
+
+
+
+                Dynamic reverse DNS for IPv6
+              <draft-durand-dnsop-dynreverse-00.txt>
+
+
+
+Status of this memo
+
+
+   This memo provides information to the Internet community.  It does
+   not specify an Internet standard of any kind.  This memo is in full
+   conformance with all provisions of Section 10 of RFC2026 [RFC2026].
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+   This document describes a method to dynamically generate PTR records
+   and corresponding A or AAAA records when the reverse path DNS tree is
+   not populated.
+
+   A special domain dynrev.arpa. is reserved for that purpose.
+
+
+1. Introduction
+
+   In IPv4, the reverse path tree of the DNS under in-addr.arpa.
+   although not perfectly maintained, is still mostly usable and its
+   existence is important for a number of applications that relies on
+   its existence and decent status.  Some applications performs some
+   (very) weak security checks based on it. Mail relays relies on it for
+   some anti-spams checks an some FTP server will not let you in unless
+   your IP address resolve properly with a PTR record.
+
+   IPv6 addresses being much longer (and cumbersome) than IPv4
+   addresses, it is to fear that the reverse path tree under ip6.arpa.
+   would not be as well maintained.  Also, tools like 6to4, Isatap and
+   others have made creative use of the 128 bits of an IPv6 address to
+   automatically embed an IPv4 address to enable seamless connection to
+   the IPv6 Internet. However, no provision has been made to make sure
+   the reverse path tree gets automatically updated as well for those
+   new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
+   to basically use random bits in the bottom part of an IPv6 address to
+   preserver anonymity. If those addresses are to resolve in the reverse
+   path tree, it obviously has to be with anonymous data as well.
+   Another point to note is that home customer ISPs in IPv4 have a
+   current practice to pre-populate the reverse path tree with names
+   automatically derived from the IP addresses. This practice is no
+   longer possible in IPv6, where IP address allocation is not dense as
+   it is the case in IPv4. The mere size of typical customer allocation
+   (2^48 according to the recommendation of RFC3177) makes it
+   impossible.
+
+   Applications that check the existence of PTR records usually follow
+   this by checking if the name pointed by the PTR resolve in a A (or
+   AAAA for IPv6) that match the original IP address. Thus the forward
+   path tree must also include the corresponding data.
+
+   One simple approach of this problem is to simply declare the usage of
+   the reverse path DNS as described above obsolete.  The author believe
+   this is too strong an approach for now.
+
+   Similarly, a completely different approach would be to deprecate the
+   usage of DNS for the reverse tree altogether and replace it by
+   something inspired from ICMP name-info messages. The author believes
+   that this approached is an important departure from the current
+   practise and thus not very realistic.  Also, there are some concerns
+   about the the security implications of this method as any node could
+   easily impersonate any name. This approach would fundamentally change
+   the underlying assumption of "I trust what has been put in the DNS by
+   the local administrators" to "I trust what has been configured on
+   each machine I query directly".
+
+
+
+2. Dynamic record generation
+
+   If static pre-population of the tree is not possible anymore and data
+   still need to be returned to applications using getnameinfo(), the
+   alternative is dynamic record generation.  This can be done is two
+   places: in the DNS servers responsible for the allocated space (/64
+   or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
+   sub resolver library or the recursive DNS server).
+
+   2.1. On the resolver side.
+
+   The resolver, either in the recursive DNS server or in the stub
+   library could theoretically generate this data.
+
+   In case DNSsec is in place, the recursive DNS server would have to
+   pretend these records are authentic.
+
+   If the synthesis is done in the stub-resolver library, no record
+   needs to be actually generated, only the right information needs to
+   be passed to getnameinfo() and getaddrinfo().  If the synthesis is
+   done in the recursive DNS server, no modification is required to
+   existing stub resolvers.
+
+
+2.2. On the server side.
+
+   PTR records could be generated automatically by the server
+   responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
+   prefixes or basically anything in between) when static data is not
+   available.
+
+   There could be impact on DNSsec as the zone or some parts of the zone
+   may need to be resigned each time a DNS query is made for an
+   unpopulated address. This can be seen as a DOS attack on a DNSsec
+   zone, so server side synthesis is not recommended if DNSsec is
+   deployed.
+
+
+
+3. Synthesis
+
+   The algorithm is simple: Do the normal queries. If the query returns
+   No such domain, replace this answer by the synthetized one if
+   possible.
+
+3.1. PTR synthesis
+
+   The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
+   where [X] is any valid DNS name.
+
+   The fact that the synthetized PTR points to the dynrev.arpa. domain
+   is an indication to the applications that this record has been
+   dynamically generated.
+
+
+3.2. A synthesis
+
+   If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
+   record for the string [X].dynrev.arpa. which value is d.c.b.a. with
+   a,b,c & d being integer [0..255]
+
+
+3.3. AAAA synthesis
+
+   If [X] is in the form
+   a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
+   addr.arpa, one can synthetized a AAAA record for the string
+   [X].dynrev.arpa. which value is
+   FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
+   a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
+
+
+3.4. Server side synthesis
+
+   If synthesis is done on the server side, PTR could be set not to use
+   the dynrev.arpa domain but the local domain name instead.  It culd be
+   for instance dynrev.mydomain.com.
+
+   Note also that server side synthesis is not incompatible with
+   resolver side synthesis.
+
+
+
+4. IANA considerations
+
+   The dynrev.arpa. domain is reserved for the purpose of this document.
+
+
+
+5. Security considerations
+
+   Section 2. discusses the the interactions with DNSsec.
+
+
+
+6. Authors addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17, Network Circle
+   UMPK17-202
+   Menlo Park, CA 94025
+   USA
+   Mail: Alain.Durand@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
new file mode 100644
index 0000000..fa41e76
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
@@ -0,0 +1,928 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+Obsoletes RFC 2929, Updates RFC 1183               Motorola Laboratories
+Expires: February 2006                                       August 2005
+
+
+
+              Domain Name System (DNS) IANA Considerations
+              ------ ---- ------ ----- ---- --------------
+                   <draft-ietf-dnsext-2929bis-01.txt>
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this draft is unlimited.  It is intended to become
+   the new BCP 42 obsoleting RFC 2929.  Comments should be sent to the
+   DNS Working Group mailing list <namedroppers@ops.ietf.org>.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+
+Abstract
+
+   Internet Assigned Number Authority (IANA) parameter assignment
+   considerations are given for the allocation of Domain Name System
+   (DNS) classes, RR types, operation codes, error codes, RR header
+   bits, and AFSDB subtypes.
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. DNS Query/Response Headers..............................3
+      2.1 One Spare Bit?.........................................4
+      2.2 Opcode Assignment......................................4
+      2.3 RCODE Assignment.......................................5
+      3. DNS Resource Records....................................6
+      3.1 RR TYPE IANA Considerations............................7
+      3.1.1 DNS TYPE Allocation Policy...........................8
+      3.1.2 Special Note on the OPT RR...........................9
+      3.1.3 The AFSDB RR Subtype Field...........................9
+      3.2 RR CLASS IANA Considerations...........................9
+      3.3 RR NAME Considerations................................11
+      4. Security Considerations................................11
+
+      Appendix: Changes from RFC 2929...........................12
+
+      Copyright and Disclaimer..................................13
+      Normative References......................................13
+      Informative References....................................14
+
+      Authors Addresses.........................................16
+      Expiration and File Name..................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+1. Introduction
+
+   The Domain Name System (DNS) provides replicated distributed secure
+   hierarchical databases which hierarchically store "resource records"
+   (RRs) under domain names.  DNS data is structured into CLASSes and
+   zones which can be independently maintained.  See [RFC 1034, 1035,
+   2136, 2181, 4033] familiarity with which is assumed.
+
+   This document provides, either directly or by reference, general IANA
+   parameter assignment considerations applying across DNS query and
+   response headers and all RRs.  There may be additional IANA
+   considerations that apply to only a particular RR type or
+   query/response opcode.  See the specific RFC defining that RR type or
+   query/response opcode for such considerations if they have been
+   defined, except for AFSDB RR considerations [RFC 1183] which are
+   included herein. This RFC obsoletes [RFC 2929].
+
+   IANA currently maintains a web page of DNS parameters.  See
+   <http://www.iana.org/numbers.htm>.
+
+   "IETF Standards Action", "IETF Consensus", "Specification Required",
+   and "Private Use" are as defined in [RFC 2434].
+
+
+
+2. DNS Query/Response Headers
+
+   The header for DNS queries and responses contains field/bits in the
+   following diagram taken from [RFC 2136, 2929]:
+
+                                              1  1  1  1  1  1
+                0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                      ID                       |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                QDCOUNT/ZOCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                ANCOUNT/PRCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                NSCOUNT/UPCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                    ARCOUNT                    |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   The ID field identifies the query and is echoed in the response so
+   they can be matched.
+
+   The QR bit indicates whether the header is for a query or a response.
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
+   only in queries or only in responses, depending on the bit.  However,
+   many DNS implementations copy the query header as the initial value
+   of the response header without clearing bits.  Thus any attempt to
+   use a "query" bit with a different meaning in a response or to define
+   a query meaning for a "response" bit is dangerous given existing
+   implementation.  Such meanings may only be assigned by an IETF
+   Standards Action.
+
+   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
+   authority count (NSCOUNT), and additional information count (ARCOUNT)
+   express the number of records in each section for all opcodes except
+   Update.  These fields have the same structure and data type for
+   Update but are instead the counts for the zone (ZOCOUNT),
+   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
+   (ARCOUNT) sections.
+
+
+
+2.1 One Spare Bit?
+
+   There have been ancient DNS implementations for which the Z bit being
+   on in a query meant that only a response from the primary server for
+   a zone is acceptable.  It is believed that current DNS
+   implementations ignore this bit.
+
+   Assigning a meaning to the Z bit requires an IETF Standards Action.
+
+
+
+2.2 Opcode Assignment
+
+   Currently DNS OpCodes are assigned as follows:
+
+          OpCode Name                      Reference
+
+           0     Query                     [RFC 1035]
+           1     IQuery  (Inverse Query, Obsolete) [RFC 3425]
+           2     Status                    [RFC 1035]
+           3     available for assignment
+           4     Notify                    [RFC 1996]
+           5     Update                    [RFC 2136]
+          6-15   available for assignment
+
+   New OpCode assignments require an IETF Standards Action as modified
+   by [RFC 4020].
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+2.3 RCODE Assignment
+
+   It would appear from the DNS header above that only four bits of
+   RCODE, or response/error code are available.  However, RCODEs can
+   appear not only at the top level of a DNS response but also inside
+   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
+   The OPT RR provides an eight bit extension resulting in a 12 bit
+   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
+
+   Error codes appearing in the DNS header and in these three RR types
+   all refer to the same error code space with the single exception of
+   error code 16 which has a different meaning in the OPT RR from its
+   meaning in other contexts.  See table below.
+
+        RCODE   Name    Description                        Reference
+        Decimal
+          Hexadecimal
+         0    NoError   No Error                           [RFC 1035]
+         1    FormErr   Format Error                       [RFC 1035]
+         2    ServFail  Server Failure                     [RFC 1035]
+         3    NXDomain  Non-Existent Domain                [RFC 1035]
+         4    NotImp    Not Implemented                    [RFC 1035]
+         5    Refused   Query Refused                      [RFC 1035]
+         6    YXDomain  Name Exists when it should not     [RFC 2136]
+         7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
+         8    NXRRSet   RR Set that should exist does not  [RFC 2136]
+         9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
+        10    NotZone   Name not contained in zone         [RFC 2136]
+        11 - 15         Available for assignment
+        16    BADVERS   Bad OPT Version                    [RFC 2671]
+        16    BADSIG    TSIG Signature Failure             [RFC 2845]
+        17    BADKEY    Key not recognized                 [RFC 2845]
+        18    BADTIME   Signature out of time window       [RFC 2845]
+        19    BADMODE   Bad TKEY Mode                      [RPC 2930]
+        20    BADNAME   Duplicate key name                 [RPF 2930]
+        21    BADALG    Algorithm not supported            [RPF 2930]
+
+        22 - 3,840
+          0x0016 - 0x0F00   Available for assignment
+
+        3,841 - 4,095
+          0x0F01 - 0x0FFF   Private Use
+
+        4,096 - 65,534
+          0x1000 - 0xFFFE   Available for assignment
+
+        65,535
+          0xFFFF            Reserved, can only be allocated by an IETF
+                            Standards Action.
+
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   Since it is important that RCODEs be understood for interoperability,
+   assignment of new RCODE listed above as "available for assignment"
+   requires an IETF Consensus.
+
+
+
+3. DNS Resource Records
+
+   All RRs have the same top level format shown in the figure below
+   taken from [RFC 1035]:
+
+                                       1  1  1  1  1  1
+         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                                               |
+       /                                               /
+       /                      NAME                     /
+       |                                               |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                      TYPE                     |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                     CLASS                     |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                      TTL                      |
+       |                                               |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                   RDLENGTH                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+       /                     RDATA                     /
+       /                                               /
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   NAME is an owner name, i.e., the name of the node to which this
+   resource record pertains.  NAMEs are specific to a CLASS as described
+   in section 3.2.  NAMEs consist of an ordered sequence of one or more
+   labels each of which has a label type [RFC 1035, 2671].
+
+   TYPE is a two octet unsigned integer containing one of the RR TYPE
+   codes.  See section 3.1.
+
+   CLASS is a two octet unsigned integer containing one of the RR CLASS
+   codes.  See section 3.2.
+
+   TTL is a four octet (32 bit) bit unsigned integer that specifies the
+   number of seconds that the resource record may be cached before the
+   source of the information should again be consulted.  Zero is
+   interpreted to mean that the RR can only be used for the transaction
+   in progress.
+
+   RDLENGTH is an unsigned 16 bit integer that specifies the length in
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   octets of the RDATA field.
+
+   RDATA is a variable length string of octets that constitutes the
+   resource. The format of this information varies according to the TYPE
+   and in some cases the CLASS of the resource record.
+
+
+
+3.1 RR TYPE IANA Considerations
+
+   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
+   and MetaTYPEs.
+
+   Data TYPEs are the primary means of storing data.  QTYPES can only be
+   used in queries.  Meta-TYPEs designate transient data associated with
+   an particular DNS message and in some cases can also be used in
+   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
+   the block from 100 through 103 while Q and Meta Types have been
+   assigned from 255 downwards except for the OPT Meta-RR which is
+   assigned TYPE 41.  There have been DNS implementations which made
+   caching decisions based on the top bit of the bottom byte of the RR
+   TYPE.
+
+   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
+   [RFC 2845], and TKEY [RFC 2930].
+
+   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
+   AXFR, and IXFR.
+
+   Considerations for the allocation of new RR TYPEs are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
+          2535] and in other circumstances and must never be allocated
+          for ordinary use.
+
+     1 - 127
+   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
+          TYPEs by the DNS TYPE Allocation Policy as specified in
+          section 3.1.1.
+
+     128 - 255
+   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
+          Meta TYPEs by the DNS TYPE Allocation Policy as specified in
+          section 3.1.1.
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+     256 - 32,767
+   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
+          TYPE Allocation Policy as specified in section 3.1.1.
+
+     32,768 - 65,279
+   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
+
+     65,280 - 65534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+
+3.1.1 DNS TYPE Allocation Policy
+
+   Parameter values specified above as assigned based on DNS TYPE
+   Allocation Policy. That is, Expert Review with the additional
+   requirement that the review be based on a complete template as
+   specified below which has been posted for three weeks to the
+   namedroppers@ops.ietf.org mailing list.
+
+   Partial or draft templates may be posted with the intend of
+   soliciting feedback.
+
+
+                 DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
+
+        Date:
+
+        Name and email of originator:
+
+        Pointer to internet-draft or other document giving a detailed
+        description of the protocol use of the new RR Type:
+
+        What need is the new RR TYPE intended to fix?
+
+        What existing RR TYPE(s) come closest to filling that need and why are
+        they unsatisfactory?
+
+        Does the proposed RR TYPR require special handling within the DNS
+        different from an Unknown RR TYPE?
+
+        Comments:
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+3.1.2 Special Note on the OPT RR
+
+   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
+   primary purpose is to extend the effective field size of various DNS
+   fields including RCODE, label type, OpCode, flag bits, and RDATA
+   size.  In particular, for resolvers and servers that recognize it, it
+   extends the RCODE field from 4 to 12 bits.
+
+
+
+3.1.3 The AFSDB RR Subtype Field
+
+   The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
+   RDATA field structure as the MX RR but the 16 bit unsigned integer
+   field at the beginning of the RDATA is interpreted as a subtype as
+   follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 -  Allocation requires IETF Standards Action.
+
+     1
+   0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
+
+     2
+   0x0002 - DCE/NCA root cell directory node [RFC 1183].
+
+     3 - 65,279
+   0x0003 - 0xFEFF - Allocation by IETF Consensus.
+
+     65,280 - 65,534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, allocation requires IETF Standards Action.
+
+
+
+3.2 RR CLASS IANA Considerations
+
+   DNS CLASSes have been little used but constitute another dimension of
+   the DNS distributed database.  In particular, there is no necessary
+   relationship between the name space or root servers for one CLASS and
+   those for another CLASS.  The same name can have completely different
+   meanings in different CLASSes; however, the label types are the same
+   and the null label is usable only as root in every CLASS.  However,
+   as global networking and DNS have evolved, the IN, or Internet, CLASS
+   has dominated DNS use.
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   There are two subcategories of DNS CLASSes: normal data containing
+   classes and QCLASSes that are only meaningful in queries or updates.
+
+   The current CLASS assignments and considerations for future
+   assignments are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - Reserved, assignment requires an IETF Standards Action.
+
+     1
+   0x0001 - Internet (IN).
+
+     2
+   0x0002 - Available for assignment by IETF Consensus as a data CLASS.
+
+     3
+   0x0003 - Chaos (CH) [Moon 1981].
+
+     4
+   0x0004 - Hesiod (HS) [Dyer 1987].
+
+     5 - 127
+   0x0005 - 0x007F - available for assignment by IETF Consensus for data
+          CLASSes only.
+
+     128 - 253
+   0x0080 - 0x00FD - available for assignment by IETF Consensus for
+          QCLASSes only.
+
+     254
+   0x00FE - QCLASS None [RFC 2136].
+
+     255
+   0x00FF - QCLASS Any [RFC 1035].
+
+     256 - 32,767
+   0x0100 - 0x7FFF - Assigned by IETF Consensus.
+
+     32,768 - 65,279
+   0x8000 - 0xFEFF - Assigned based on Specification Required as defined
+          in [RFC 2434].
+
+     65,280 - 65,534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+D. Eastlake 3rd                                                [Page 10]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+3.3 RR NAME Considerations
+
+   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
+   NAME is "ROOT" which is the zero length label.  By definition, the
+   null or ROOT label can not be used for any other NAME purpose.
+
+   At the present time, there are two categories of label types, data
+   labels and compression labels.  Compression labels are pointers to
+   data labels elsewhere within an RR or DNS message and are intended to
+   shorten the wire encoding of NAMEs.  The two existing data label
+   types are sometimes referred to as Text and Binary.  Text labels can,
+   in fact, include any octet value including zero value octets but most
+   current uses involve only [US-ASCII].  For retrieval, Text labels are
+   defined to treat ASCII upper and lower case letter codes as matching
+   [insensitive].  Binary labels are bit sequences [RFC 2673]. The
+   Binary label type is Experimental [RFC 3363].
+
+   IANA considerations for label types are given in [RFC 2671].
+
+   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
+   1981] CLASSes are essentially for local use.  The IN or Internet
+   CLASS is thus the only DNS CLASS in global use on the Internet at
+   this time.
+
+   A somewhat out-of-date description of name allocation in the IN Class
+   is given in [RFC 1591].  Some information on reserved top level
+   domain names is in BCP 32 [RFC 2606].
+
+
+
+4. Security Considerations
+
+   This document addresses IANA considerations in the allocation of
+   general DNS parameters, not security.  See [RFC 4033, 4034, 4035] for
+   secure DNS considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 11]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Appendix: Changes from RFC 2929
+
+   RFC Editor: This Appendix should be deleted for publication.
+
+   Changes from RFC 2929 to this draft:
+
+   1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
+   Allocation Policy" and add the specification of that policy. Change
+   some remaining "IETF Standards Action" allocation requirements to say
+   "as modified by [RFC 4020]".
+
+   2. Updated various RFC references.
+
+   3. Mentioned that the Binary label type is now Experimental and
+   IQuery is Obsolete.
+
+   4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
+   IETF Standards Action required.
+
+   5. Add an IANA allocation policy for the AFSDB RR Subtype field.
+
+   6. Addition of reference to case insensitive draft.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 12]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Normative References
+
+   [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
+   Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
+   Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
+   Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
+
+   [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
+   Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+   April 1997.
+
+   [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
+   Specification", RFC 2181, July 1997.
+
+   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
+   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
+   2671, August 1999.
+
+   [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
+   RFC 2673, August 1999.
+
+   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+   RFC 2845, May 2000.
+
+
+D. Eastlake 3rd                                                [Page 13]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
+   RR)", September 2000.
+
+   [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+   Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
+   the Domain Name System (DNS)", RFC 3363, August 2002.
+
+   [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+   2002.
+
+   [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
+   Standards Track Code Points", BCP 100, RFC 4020, February 2005.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+   [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
+   X3.4, American National Standards Institute: New York, 1968.
+
+
+
+Informative References
+
+   [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
+   Technical Plan - Name Service, April 1987,
+
+   [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
+   Institute of Technology Artificial Intelligence Laboratory, June
+   1981.
+
+   [RFC 1591] - Postel, J., "Domain Name System Structure and
+   Delegation", RFC 1591, March 1994.
+
+   [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
+   "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+   September 2000.
+
+   [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+   Names", RFC 2606, June 1999.
+
+   [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
+
+
+D. Eastlake 3rd                                                [Page 14]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
+   work in progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 15]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Authors Addresses
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554 (w)
+   email:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires February 2006.
+
+   Its file name is draft-ietf-dnsext-2929bis-01.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
new file mode 100644
index 0000000..f0ce70a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
@@ -0,0 +1,393 @@
+
+
+
+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/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
new file mode 100644
index 0000000..07749d9
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
@@ -0,0 +1,674 @@
+
+
+
+
+DNSEXT                                                          M. Stapp
+Internet-Draft                                       Cisco Systems, Inc.
+Expires: September 1, 2006                                      T. Lemon
+                                                           Nominum, Inc.
+                                                           A. Gustafsson
+                                          Araneus Information Systems Oy
+                                                       February 28, 2006
+
+
+           A DNS RR for Encoding DHCP Information (DHCID RR)
+                  <draft-ietf-dnsext-dhcid-rr-12.txt>
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 1, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   It is possible for DHCP clients to attempt to update the same DNS
+   FQDN or attempt to update a DNS FQDN that has been added to the DNS
+   for another purpose as they obtain DHCP leases.  Whether the DHCP
+   server or the clients themselves perform the DNS updates, conflicts
+   can arise.  To resolve such conflicts, "Resolution of DNS Name
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 1]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   Conflicts" [1] proposes storing client identifiers in the DNS to
+   unambiguously associate domain names with the DHCP clients to which
+   they refer.  This memo defines a distinct RR type for this purpose
+   for use by DHCP clients and servers, the "DHCID" RR.
+
+
+Table of Contents
+
+   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.1.  DHCID RDATA format . . . . . . . . . . . . . . . . . . . .  3
+     3.2.  DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
+     3.3.  The DHCID RR Identifier Type Codes . . . . . . . . . . . .  4
+     3.4.  The DHCID RR Digest Type Code  . . . . . . . . . . . . . .  4
+     3.5.  Computation of the RDATA . . . . . . . . . . . . . . . . .  5
+       3.5.1.  Using the Client's DUID  . . . . . . . . . . . . . . .  5
+       3.5.2.  Using the Client Identifier Option . . . . . . . . . .  5
+       3.5.3.  Using the Client's htype and chaddr  . . . . . . . . .  6
+     3.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       3.6.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
+       3.6.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
+       3.6.3.  Example 3  . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 2]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+
+2.  Introduction
+
+   A set of procedures to allow DHCP [6] [10] clients and servers to
+   automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
+   in "Resolution of DNS Name Conflicts" [1].
+
+   Conflicts can arise if multiple DHCP clients wish to use the same DNS
+   name or a DHCP client attempts to use a name added for another
+   purpose.  To resolve such conflicts, "Resolution of DNS Name
+   Conflicts" [1] proposes storing client identifiers in the DNS to
+   unambiguously associate domain names with the DHCP clients using
+   them.  In the interest of clarity, it is preferable for this DHCP
+   information to use a distinct RR type.  This memo defines a distinct
+   RR for this purpose for use by DHCP clients or servers, the "DHCID"
+   RR.
+
+   In order to obscure potentially sensitive client identifying
+   information, the data stored is the result of a one-way SHA-256 hash
+   computation.  The hash includes information from the DHCP client's
+   message as well as the domain name itself, so that the data stored in
+   the DHCID RR will be dependent on both the client identification used
+   in the DHCP protocol interaction and the domain name.  This means
+   that the DHCID RDATA will vary if a single client is associated over
+   time with more than one name.  This makes it difficult to 'track' a
+   client as it is associated with various domain names.
+
+
+3.  The DHCID RR
+
+   The DHCID RR is defined with mnemonic DHCID and type code [TBD].  The
+   DHCID RR is only defined in the IN class.  DHCID RRs cause no
+   additional section processing.  The DHCID RR is not a singleton type.
+
+3.1.  DHCID RDATA format
+
+   The RDATA section of a DHCID RR in transmission contains RDLENGTH
+   octets of binary data.  The format of this data and its
+   interpretation by DHCP servers and clients are described below.
+
+   DNS software should consider the RDATA section to be opaque.  DHCP
+   clients or servers use the DHCID RR to associate a DHCP client's
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 3]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   identity with a DNS name, so that multiple DHCP clients and servers
+   may deterministically perform dynamic DNS updates to the same zone.
+   From the updater's perspective, the DHCID resource record RDATA
+   consists of a 2-octet identifier type, in network byte order,
+   followed by a 1-octet digest type, followed by one or more octets
+   representing the actual identifier:
+
+           < 2 octets >    Identifier type code
+           < 1 octet >     Digest type code
+           < n octets >    Digest (length depends on digest type)
+
+3.2.  DHCID Presentation Format
+
+   In DNS master files, the RDATA is represented as a single block in
+   base 64 encoding identical to that used for representing binary data
+   in RFC 3548 [7].  The data may be divided up into any number of white
+   space separated substrings, down to single base 64 digits, which are
+   concatenated to form the complete RDATA.  These substrings can span
+   lines using the standard parentheses.
+
+3.3.  The DHCID RR Identifier Type Codes
+
+   The DHCID RR Identifier Type Code specifies what data from the DHCP
+   client's request was used as input into the hash function.  The
+   identifier type codes are defined in a registry maintained by IANA,
+   as specified in Section 7.  The initial list of assigned values for
+   the identifier type code is:
+
+   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
+   0x0001 = The data octets (i.e., the Type and Client-Identifier
+      fields) from a DHCPv4 client's Client Identifier option [9].
+   0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
+      client's Client Identifier option [10] or the DUID field from a
+      DHCPv4 client's Client Identifier option [12]).
+
+   0x0003 - 0xfffe = Available to be assigned by IANA.
+
+   0xffff = RESERVED
+
+3.4.  The DHCID RR Digest Type Code
+
+   The DHCID RR Digest Type Code is an identifier for the digest
+   algorithm used.  The digest is calculated over an identifier and the
+   canonical FQDN as described in the next section.
+
+   The digest type codes are defined in a registry maintained by IANA,
+   as specified in Section 7.  The initial list of assigned values for
+   the digest type codes is: value 0 is reserved and value 1 is SHA-256.
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 4]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   Reserving other types requires IETF standards action.  Defining new
+   values will also require IETF standards action to document how DNS
+   updaters are to deal with multiple digest types.
+
+3.5.  Computation of the RDATA
+
+   The DHCID RDATA is formed by concatenating the 2-octet identifier
+   type code with variable-length data.
+
+   The RDATA for all type codes other than 0xffff, which is reserved for
+   future expansion, is formed by concatenating the 2-octet identifier
+   type code, the 1-octet digest type code, and the digest value (32
+   octets for SHA-256).
+
+       < identifier-type > < digest-type > < digest >
+
+   The input to the digest hash function is defined to be:
+
+       digest = SHA-256(< identifier > < FQDN >)
+
+   The FQDN is represented in the buffer in unambiguous canonical form
+   as described in RFC 4034 [8], section 6.1.  The identifier type code
+   and the identifier are related as specified in Section 3.3: the
+   identifier type code describes the source of the identifier.
+
+   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
+   option is present in the DHCPv4 messages and it is encoded as
+   specified in [12].  Otherwise, the updater uses 0x0001 if a Client
+   Identifier option is present and 0x0000 if not.
+
+   A DHCPv6 updater always uses the 0x0002 type code.
+
+3.5.1.  Using the Client's DUID
+
+   When the updater is using the Client's DUID (either from a DHCPv6
+   Client Identifier option or from a portion of the DHCPv4 Client
+   Identifier option encoded as specified in [12]), the first two octets
+   of the DHCID RR MUST be 0x0002, in network byte order.  The third
+   octet is the digest type code (1 for SHA-256).  The rest of the DHCID
+   RR MUST contain the results of computing the SHA-256 hash across the
+   octets of the DUID followed by the FQDN.
+
+3.5.2.  Using the Client Identifier Option
+
+   When the updater is using the DHCPv4 Client Identifier option sent by
+   the client in its DHCPREQUEST message, the first two octets of the
+   DHCID RR MUST be 0x0001, in network byte order.  The third octet is
+   the digest type code (1 for SHA-256).  The rest of the DHCID RR MUST
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 5]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   contain the results of computing the SHA-256 hash across the data
+   octets (i.e., the Type and Client-Identifier fields) of the option,
+   followed by the FQDN.
+
+3.5.3.  Using the Client's htype and chaddr
+
+   When the updater is using the client's link-layer address as the
+   identifier, the first two octets of the DHCID RDATA MUST be zero.
+   The third octet is the digest type code (1 for SHA-256).  To generate
+   the rest of the resource record, the updater computes a one-way hash
+   using the SHA-256 algorithm across a buffer containing the client's
+   network hardware type, link-layer address, and the FQDN data.
+   Specifically, the first octet of the buffer contains the network
+   hardware type as it appeared in the DHCP 'htype' field of the
+   client's DHCPREQUEST message.  All of the significant octets of the
+   'chaddr' field in the client's DHCPREQUEST message follow, in the
+   same order in which the octets appear in the DHCPREQUEST message.
+   The number of significant octets in the 'chaddr' field is specified
+   in the 'hlen' field of the DHCPREQUEST message.  The FQDN data, as
+   specified above, follows.
+
+3.6.  Examples
+
+3.6.1.  Example 1
+
+   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
+   Ethernet MAC address 01:02:03:04:05:06 using domain name
+   "client.example.com" uses the client's link-layer address to identify
+   the client.  The DHCID RDATA is composed by setting the two type
+   octets to zero, the 1-octet digest type to 1 for SHA-256, and
+   performing an SHA-256 hash computation across a buffer containing the
+   Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
+   domain name (represented as specified in Section 3.5).
+
+     client.example.com.   A       10.0.0.1
+     client.example.com.   DHCID   ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
+                                     ytcKD//7es/deY= )
+
+   If the DHCID RR type is not supported, the RDATA would be encoded
+   [13] as:
+
+     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
+             fffedeb3f75e6 )
+
+3.6.2.  Example 2
+
+   A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
+   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 6]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   in its DHCP request.  The server updates the name "chi.example.com"
+   on the client's behalf, and uses the DHCP client identifier option
+   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
+   setting the two type octets to the value 0x0001, the 1-octet digest
+   type to 1 for SHA-256, and performing a SHA-256 hash computation
+   across a buffer containing the seven octets from the client-id option
+   and the FQDN (represented as specified in Section 3.5).
+
+     chi.example.com.      A       10.0.12.99
+     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
+                                     L3b/NaiUDlW2No= )
+
+   If the DHCID RR type is not supported, the RDATA would be encoded
+   [13] as:
+
+     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
+             6a2503956d8da )
+
+3.6.3.  Example 3
+
+   A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
+   which included the DHCPv6 client-identifier option data 00:01:00:06:
+   41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request.  The server
+   updates the name "chi6.example.com" on the client's behalf, and uses
+   the DHCP client identifier option data as input in forming a DHCID
+   RR.  The DHCID RDATA is formed by setting the two type octets to the
+   value 0x0002, the 1-octet digest type to 1 for SHA-256, and
+   performing a SHA-256 hash computation across a buffer containing the
+   14 octets from the client-id option and the FQDN (represented as
+   specified in Section 3.5).
+
+     chi6.example.com.     AAAA    2000::1234:5678
+     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
+                                     OjxfNuVAA2kjEA= )
+
+   If the DHCID RR type is not supported, the RDATA would be encoded
+   [13] as:
+
+     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
+             b95000da48c40 )
+
+
+4.  Use of the DHCID RR
+
+   This RR MUST NOT be used for any purpose other than that detailed in
+   "Resolution of DNS Name Conflicts" [1].  Although this RR contains
+   data that is opaque to DNS servers, the data must be consistent
+   across all entities that update and interpret this record.
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 7]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   Therefore, new data formats may only be defined through actions of
+   the DHC Working Group, as a result of revising [1].
+
+
+5.  Updater Behavior
+
+   The data in the DHCID RR allows updaters to determine whether more
+   than one DHCP client desires to use a particular FQDN.  This allows
+   site administrators to establish policy about DNS updates.  The DHCID
+   RR does not establish any policy itself.
+
+   Updaters use data from a DHCP client's request and the domain name
+   that the client desires to use to compute a client identity hash, and
+   then compare that hash to the data in any DHCID RRs on the name that
+   they wish to associate with the client's IP address.  If an updater
+   discovers DHCID RRs whose RDATA does not match the client identity
+   that they have computed, the updater SHOULD conclude that a different
+   client is currently associated with the name in question.  The
+   updater SHOULD then proceed according to the site's administrative
+   policy.  That policy might dictate that a different name be selected,
+   or it might permit the updater to continue.
+
+
+6.  Security Considerations
+
+   The DHCID record as such does not introduce any new security problems
+   into the DNS.  In order to obscure the client's identity information,
+   a one-way hash is used.  And, in order to make it difficult to
+   'track' a client by examining the names associated with a particular
+   hash value, the FQDN is included in the hash computation.  Thus, the
+   RDATA is dependent on both the DHCP client identification data and on
+   each FQDN associated with the client.
+
+   However, it should be noted that an attacker that has some knowledge,
+   such as of MAC addresses commonly used in DHCP client identification
+   data, may be able to discover the client's DHCP identify by using a
+   brute-force attack.  Even without any additional knowledge, the
+   number of unknown bits used in computing the hash is typically only
+   48 to 80.
+
+   Administrators should be wary of permitting unsecured DNS updates to
+   zones, whether or not they are exposed to the global Internet.  Both
+   DHCP clients and servers SHOULD use some form of update
+   authentication (e.g., TSIG [11]) when performing DNS updates.
+
+
+7.  IANA Considerations
+
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 8]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+   IANA is requested to allocate a DNS RR type number for the DHCID
+   record type.
+
+   This specification defines a new number-space for the 2-octet
+   identifier type codes associated with the DHCID RR.  IANA is
+   requested to establish a registry of the values for this number-
+   space.  Three initial values are assigned in Section 3.3, and the
+   value 0xFFFF is reserved for future use.  New DHCID RR identifier
+   type codes are assigned through Standards Action, as defined in RFC
+   2434 [5].
+
+   This specification defines a new number-space for the 1-octet digest
+   type codes associated with the DHCID RR.  IANA is requested to
+   establish a registry of the values for this number-space.  Two
+   initial values are assigned in Section 3.4.  New DHCID RR digest type
+   codes are assigned through Standards Action, as defined in RFC 2434
+   [5].
+
+
+8.  Acknowledgements
+
+   Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
+   Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
+   Volz for their review and suggestions.
+
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
+        DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Mockapetris, P., "Domain names - concepts and facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [4]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006               [Page 9]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+9.2.  Informative References
+
+   [6]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+         March 1997.
+
+   [7]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+         RFC 3548, July 2003.
+
+   [8]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+         Extensions", RFC 2132, March 1997.
+
+   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+         Carney, "Dynamic Host Configuration Protocol for IPv6
+         (DHCPv6)", RFC 3315, July 2003.
+
+   [11]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
+         "Secret Key Transaction Authentication for DNS (TSIG)",
+         RFC 2845, May 2000.
+
+   [12]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
+         for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
+         RFC 4361, February 2006.
+
+   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+         Types", RFC 3597, September 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006              [Page 10]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+Authors' Addresses
+
+   Mark Stapp
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   USA
+
+   Phone: 978.936.1535
+   Email: mjs@cisco.com
+
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   USA
+
+   Email: mellon@nominum.com
+
+
+   Andreas Gustafsson
+   Araneus Information Systems Oy
+   Ulappakatu 1
+   02320 Espoo
+   Finland
+
+   Email: gson@araneus.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.           Expires September 1, 2006              [Page 11]
+
+Internet-Draft                The DHCID RR                 February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Stapp, et al.           Expires September 1, 2006              [Page 12]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
new file mode 100644
index 0000000..438e800
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
@@ -0,0 +1,1397 @@
+DNS Extensions Working Group                                   G. Sisson
+Internet-Draft                                                 B. Laurie
+Expires: January 11, 2006                                        Nominet
+                                                           July 10, 2005
+
+
+            Derivation of DNS Name Predecessor and Successor
+                   draft-ietf-dnsext-dns-name-p-s-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 11, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes two methods for deriving the canonically-
+   ordered predecessor and successor of a DNS name.  These methods may
+   be used for dynamic NSEC resource record synthesis, enabling
+   security-aware name servers to provide authenticated denial of
+   existence without disclosing other owner names in a DNSSEC-secured
+   zone.
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 1]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
+   3.  Absolute Method  . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  4
+     3.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  4
+   4.  Modified Method  . . . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  6
+     4.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  6
+   5.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     5.1.  Case Considerations  . . . . . . . . . . . . . . . . . . .  7
+     5.2.  Choice of Range  . . . . . . . . . . . . . . . . . . . . .  7
+     5.3.  Wild Card Considerations . . . . . . . . . . . . . . . . .  8
+     5.4.  Possible Modifications . . . . . . . . . . . . . . . . . .  8
+       5.4.1.  Restriction of Effective Maximum DNS Name Length . . .  8
+       5.4.2.  Use of Modified Method With Zones Containing
+               SRV RRs  . . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.1.  Examples of Immediate Predecessors Using Absolute
+           Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     6.2.  Examples of Immediate Successors Using Absolute Method . . 13
+     6.3.  Examples of Predecessors Using Modified Method . . . . . . 19
+     6.4.  Examples of Successors Using Modified Method . . . . . . . 20
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
+   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 22
+     A.1.  Changes from sisson-02 to ietf-00  . . . . . . . . . . . . 22
+     A.2.  Changes from sisson-01 to sisson-02  . . . . . . . . . . . 23
+     A.3.  Changes from sisson-00 to sisson-01  . . . . . . . . . . . 23
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
+   Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 2]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+1.  Introduction
+
+   One of the proposals for avoiding the exposure of zone information
+   during the deployment DNSSEC is dynamic NSEC resource record (RR)
+   synthesis.  This technique is described in [I-D.ietf-dnsext-dnssec-
+   trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the
+   generation of NSEC RRs that just span the query name for non-existent
+   owner names.  In order to do this, the DNS names which would occur
+   just prior to and just following a given query name must be
+   calculated in real time, as maintaining a list of all possible owner
+   names that might occur in a zone would be impracticable.
+
+   Section 6.1 of [RFC4034] defines canonical DNS name order.  This
+   document does not amend or modify this definition.  However, the
+   derivation of immediate predecessor and successor, while trivial, is
+   non-obvious.  Accordingly, several methods are described here as an
+   aid to implementors and a reference to other interested parties.
+
+   This document describes two methods:
+
+   1.  An ``absolute method'', which returns the immediate predecessor
+       or successor of a domain name such that no valid DNS name could
+       exist between that DNS name and the predecessor or successor.
+
+   2.  A ``modified method'', which returns a predecessor and successor
+       which are more economical in size and computation.  This method
+       is restricted to use with zones consisting only of single-label
+       owner names where a maximum-length owner name would not result in
+       a DNS name exceeding the maximum DNS name length.  This is,
+       however, the type of zone for which the technique of online-
+       signing is most likely to be used.
+
+
+2.  Notational Conventions
+
+   The following notational conventions are used in this document for
+   economy of expression:
+
+   N: An unspecified DNS name.
+
+   P(N): Immediate predecessor to N (absolute method).
+
+   S(N): Immediate successor to N (absolute method).
+
+   P'(N): Predecessor to N (modified method).
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 3]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   S'(N): Successor to N (modified method).
+
+
+3.  Absolute Method
+
+   These derivations assume that all uppercase US-ASCII letters in N
+   have already been replaced by their corresponding lowercase
+   equivalents.  Unless otherwise specified, processing stops after the
+   first step in which a condition is met.
+
+3.1.  Derivation of DNS Name Predecessor
+
+   To derive P(N):
+
+   1.  If N is the same as the owner name of the zone apex, prepend N
+       repeatedly with labels of the maximum length possible consisting
+       of octets of the maximum sort value (e.g. 0xff) until N is the
+       maximum length possible; otherwise continue to the next step.
+
+   2.  If the least significant (left-most) label of N consists of a
+       single octet of the minimum sort value (e.g. 0x00), remove that
+       label; otherwise continue to the next step.
+
+   3.  If the least significant (right-most) octet in the least
+       significant (left-most) label of N is the minimum sort value,
+       remove the least significant octet and continue with step 5.
+
+   4.  Decrement the value of the least significant (right-most) octet,
+       skipping any values that correspond to uppercase US-ASCII
+       letters, and then append the label with as many octets as
+       possible of the maximum sort value.  Continue to the next step.
+
+   5.  Prepend N repeatedly with labels of as long a length as possible
+       consisting of octets of the maximum sort value until N is the
+       maximum length possible.
+
+3.2.  Derivation of DNS Name Successor
+
+   To derive S(N):
+
+   1.  If N is two or more octets shorter than the maximum DNS name
+       length, prepend N with a label containing a single octet of the
+       minimum sort value (e.g. 0x00); otherwise continue to the next
+       step.
+
+   2.  If N is one or more octets shorter than the maximum DNS name
+       length and the least significant (left-most) label is one or more
+       octets shorter than the maximum label length, append an octet of
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 4]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+       the minimum sort value to the least significant label; otherwise
+       continue to the next step.
+
+   3.  Increment the value of the least significant (right-most) octet
+       in the least significant (left-most) label that is less than the
+       maximum sort value (e.g. 0xff), skipping any values that
+       correspond to uppercase US-ASCII letters, and then remove any
+       octets to the right of that one.  If all octets in the label are
+       the maximum sort value, then continue to the next step.
+
+   4.  Remove the least significant (left-most) label.  If N is now the
+       same as the owner name of the zone apex, do nothing.  (This will
+       occur only if N is the maximum possible name in canonical DNS
+       name order, and thus has wrapped to the owner name of zone apex.)
+       Otherwise repeat starting at step 2.
+
+
+4.  Modified Method
+
+   This method is for use with zones consisting only of single-label
+   owner names where an owner name consisting of label of maximum length
+   would not result in a DNS name which exceeded the maximum DNS name
+   length.  This method is computationally simpler and returns values
+   which are more economical in size than the absolute method.  It
+   differs from the absolute method detailed above in the following
+   ways:
+
+   1.  Step 1 of the derivation P(N) has been omitted as the existence
+       of the owner name of the zone apex never requires denial.
+
+   2.  A new step 1 has been introduced which removes unnecessary
+       labels.
+
+   3.  Step 4 of the derivation P(N) has been omitted as it is only
+       necessary for zones containing owner names consisting of more
+       than one label.  This omission generally results in a significant
+       reduction of the length of derived predecessors.
+
+   4.  Step 1 of the derivation S(N) had been omitted as it is only
+       necessary for zones containing owner names consisting of more
+       than one label.  This omission results in a tiny reduction of the
+       length of derived successors, and maintains consistency with the
+       modification of step 4 of the derivation P(N) described above.
+
+   5.  Steps 2 and 4 of the derivation S(N) have been modified to
+       eliminate checks for maximum DNS name length, as it is an
+       assumption of this method that no DNS name in the zone can exceed
+       the maximum DNS name length.
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 5]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   These derivations assume that all uppercase US-ASCII letters in N
+   have already been replaced by their corresponding lowercase
+   equivalents.  Unless otherwise specified, processing stops after the
+   first step in which a condition is met.
+
+4.1.  Derivation of DNS Name Predecessor
+
+   To derive P'(N):
+
+   1.  If N has more labels than the number of labels in the owner name
+       of the apex + 1, repeatedly remove the least significant (left-
+       most) label until N has no more labels than the number of labels
+       in the owner name of the apex + 1; otherwise continue to next
+       step.
+
+   2.  If the least significant (left-most) label of N consists of a
+       single octet of the minimum sort value (e.g. 0x00), remove that
+       label; otherwise continue to the next step.
+
+   3.  If the least significant (right-most) octet in the least
+       significant (left-most) label of N is the minimum sort value,
+       remove the least significant octet.
+
+   4.  Decrement the value of the least significant (right-most) octet,
+       skipping any values which correspond to uppercase US-ASCII
+       letters, and then append the label with as many octets as
+       possible of the maximum sort value.
+
+4.2.  Derivation of DNS Name Successor
+
+   To derive S'(N):
+
+   1.  If N has more labels than the number of labels in the owner name
+       of the apex + 1, repeatedly remove the least significant (left-
+       most) label until N has no more labels than the number of labels
+       in the owner name of the apex + 1.  Continue to next step.
+
+   2.  If the least significant (left-most) label of N is one or more
+       octets shorter than the maximum label length, append an octet of
+       the minimum sort value to the least significant label; otherwise
+       continue to the next step.
+
+   3.  Increment the value of the least significant (right-most) octet
+       in the least significant (left-most) label that is less than the
+       maximum sort value (e.g. 0xff), skipping any values which
+       correspond to uppercase US-ASCII letters, and then remove any
+       octets to the right of that one.  If all octets in the label are
+       the maximum sort value, then continue to the next step.
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 6]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   4.  Remove the least significant (left-most) label.  (This will occur
+       only if the least significant label is the maximum label length
+       and consists entirely of octets of the maximum sort value, and
+       thus has wrapped to the owner name of the zone apex.)
+
+
+5.  Notes
+
+5.1.  Case Considerations
+
+   Section 3.5 of [RFC1034] specifies that "while upper and lower case
+   letters are allowed in [DNS] names, no significance is attached to
+   the case".  Additionally, Section 6.1 of [RFC4034] states that when
+   determining canonical DNS name order, "uppercase US-ASCII letters are
+   treated as if they were lowercase US-ASCII letters".  Consequently,
+   values corresponding to US-ASCII uppercase letters must be skipped
+   when decrementing and incrementing octets in the derivations
+   described in Section 3.1 and Section 3.2.
+
+   The following pseudo-code is illustrative:
+
+   Decrement the value of an octet:
+
+      if (octet == '[')       // '[' is just after uppercase 'Z'
+              octet = '@';    // '@' is just prior to uppercase 'A'
+      else
+              octet--;
+
+   Increment the value of an octet:
+
+      if (octet == '@')       // '@' is just prior to uppercase 'A'
+              octet = '[';    // '[' is just after uppercase 'Z'
+      else
+              octet++;
+
+5.2.  Choice of Range
+
+   [RFC2181] makes the clarification that "any binary string whatever
+   can be used as the label of any resource record".  Consequently the
+   minimum sort value may be set as 0x00 and the maximum sort value as
+   0xff, and the range of possible values will be any DNS name which
+   contains octets of any value other than those corresponding to
+   uppercase US-ASCII letters.
+
+   However, if all owner names in a zone are in the letter-digit-hyphen,
+   or LDH, format specified in [RFC1034], it may be desirable to
+   restrict the range of possible values to DNS names containing only
+   LDH values.  This has the effect of:
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 7]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   1.  making the output of tools such as `dig' and `nslookup' less
+       subject to confusion;
+
+   2.  minimising the impact that NSEC RRs containing DNS names with
+       non-LDH values (or non-printable values) might have on faulty DNS
+       resolver implementations; and
+
+   3.  preventing the possibility of results which are wildcard DNS
+       names (see Section 5.3).
+
+   This may be accomplished by using a minimum sort value of 0x1f (US-
+   ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
+   character lowercase `z'), and then skipping non-LDH, non-lowercase
+   values when incrementing or decrementing octets.
+
+5.3.  Wild Card Considerations
+
+   Neither derivation avoids the possibility that the result may be a
+   DNS name containing a wildcard label, i.e. a label containing a
+   single octet with the value 0x2a (US-ASCII character `*').  With
+   additional tests, wildcard DNS names may be explicitly avoided;
+   alternatively, if the range of octet values can be restricted to
+   those corresponding to letter-digit-hyphen, or LDH, characters (see
+   Section 5.2), such DNS names will not occur.
+
+   Note that it is improbable that a result which is a wildcard DNS name
+   will occur unintentionally; even if one does occur either as the
+   owner name of, or in the RDATA of an NSEC RR, it is treated as a
+   literal DNS name with no special meaning.
+
+5.4.  Possible Modifications
+
+5.4.1.  Restriction of Effective Maximum DNS Name Length
+
+   [RFC1034] specifies that "the total number of octets that represent a
+   [DNS] name (i.e., the sum of all label octets and label lengths) is
+   limited to 255", including the null (zero-length) label which
+   represents the root.  For the purpose of deriving predecessors and
+   successors during NSEC RR synthesis, the maximum DNS name length may
+   be effectively restricted to the length of the longest DNS name in
+   the zone.  This will minimise the size of responses containing
+   synthesised NSEC RRs but, especially in the case of the modified
+   method, may result in some additional computational complexity.
+
+   Note that this modification will have the effect of revealing
+   information about the longest name in the zone.  Moreover, when the
+   contents of the zone changes, e.g. during dynamic updates and zone
+   transfers, care must be taken to ensure that the effective maximum
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 8]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   DNS name length agrees with the new contents.
+
+5.4.2.  Use of Modified Method With Zones Containing SRV RRs
+
+   Normally the modified method cannot be used in zones that contain
+   SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple
+   labels.  However the use of SRV RRs can be accommodated by various
+   techniques.  There are at least four possible ways to do this:
+
+   1.  Use conventional NSEC RRs for the region of the zone that
+       contains first-level labels beginning with the underscore (`_')
+       character.  For the purposes of generating these NSEC RRs, the
+       existence of (possibly fictional) ownernames `9{63}' and `a'
+       could be assumed, providing a lower and upper bound for this
+       region.  Then all queries where the QNAME doesn't exist but
+       contains a first-level label beginning with an underscore could
+       be handled using the normal DNSSEC protocol.
+
+       This approach would make it possible to enumerate all DNS names
+       in the zone containing a first-level label beginning with
+       underscore, including all SRV RRs, but this may be of less a
+       concern to the zone administrator than incurring the overhead of
+       the absolute method or of the following variants of the modified
+       method.
+
+   2.  The absolute method could be used for synthesising NSEC RRs for
+       all queries where the QNAME contains a leading underscore.
+       However this re-introduces the susceptibility of the absolute
+       method to denial of service activity, as an attacker could send
+       queries for an effectively inexhaustible supply of domain names
+       beginning with a leading underscore.
+
+   3.  A variant of the modified method could be used for synthesising
+       NSEC RRs for all queries where the QNAME contains a leading
+       underscore.  This variant would assume that all predecessors and
+       successors to queries where the QNAME contains a leading
+       underscore may consist of two lablels rather than only one.  This
+       introduces a little additional complexity without incurring the
+       full increase in response size and computational complexity as
+       the absolute method.
+
+   4.  Finally, a variant the modified method which assumes that all
+       owner names in the zone consist of one or two labels could be
+       used.  However this negates much of the reduction in response
+       size of the modified method and may be nearly as computationally
+       complex as the absolute method.
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006                [Page 9]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+6.  Examples
+
+   In the following examples:
+
+      the owner name of the zone apex is "example.com.";
+
+      the range of octet values is 0x00 - 0xff excluding values
+      corresponding to uppercase US-ASCII letters; and
+
+      non-printable octet values are expressed as three-digit decimal
+      numbers preceded by a backslash (as specified in Section 5.1 of
+      [RFC1035]).
+
+6.1.  Examples of Immediate Predecessors Using Absolute Method
+
+   Example of typical case:
+
+      P(foo.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.fon\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
+
+      where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 10]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where least significant (left-most) label of DNS name
+   consists of a single octet of the minimum sort value:
+
+      P(\000.foo.example.com.) = foo.example.com.
+
+   Example where least significant (right-most) octet of least
+   significant (left-most) label has the minimum sort value:
+
+      P(foo\000.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.foo.example.com.
+
+      or, in alternate notation:
+
+           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 11]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name contains an octet which must be decremented by
+   skipping values corresponding to US-ASCII uppercase letters:
+
+      P(fo\[.example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.fo\@\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
+
+      where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 12]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the owner name of the zone apex, and
+   consequently wraps to the DNS name with the maximum possible sort
+   order in the zone:
+
+      P(example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+6.2.  Examples of Immediate Successors Using Absolute Method
+
+   Example of typical case:
+
+      S(foo.example.com.) = \000.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 13]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is one octet short of the maximum DNS name
+   length:
+
+      N =  fooooooooooooooooooooooooooooooooooooooooooooooo
+           .ooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooo.ooooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooo.ooooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           \000.ooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooo.ooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooo.ooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\000.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 14]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length:
+
+      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
+           o.oooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooo.oooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooo.oooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           o.example.com.
+
+      or, in alternate notation:
+
+           fo{48}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           p.oooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooo.oooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooo.oooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           o.example.com.
+
+      or, in alternate notation:
+
+           fo{47}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 15]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length and the least
+   significant (left-most) label has the maximum sort value:
+
+      N =  \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.ooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooo.ooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooo.ooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooo.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooop.oooooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooo.oooooooooooooooo
+           ooooooooooooooooooooooooooooooooooooooooooooooo.
+           example.com.
+
+      or, in alternate notation:
+
+           o{62}p.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 16]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length and the eight
+   least significant (right-most) octets of the least significant (left-
+   most) label have the maximum sort value:
+
+      N  = foooooooooooooooooooooooooooooooooooooooo\255
+           \255\255\255\255\255\255\255.ooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooo.ooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooo.ooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooop.oooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           ooooooooo.oooooooooooooooooooooooooooooooooooooo
+           ooooooooooooooooooooooooo.oooooooooooooooooooooo
+           ooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+      or, in alternate notation:
+
+           fo{39}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 17]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name is the maximum DNS name length and contains an
+   octet which must be incremented by skipping values corresponding to
+   US-ASCII uppercase letters:
+
+      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
+           \@.ooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooo.ooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooo.ooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\@.o{63}.o{63}.o{63}.example.com.
+
+      S(N) =
+
+           fooooooooooooooooooooooooooooooooooooooooooooooo
+           \[.ooooooooooooooooooooooooooooooooooooooooooooo
+           oooooooooooooooooo.ooooooooooooooooooooooooooooo
+           oooooooooooooooooooooooooooooooooo.ooooooooooooo
+           oooooooooooooooooooooooooooooooooooooooooooooooo
+           oo.example.com.
+
+      or, in alternate notation:
+
+           fo{47}\[.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 18]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name has the maximum possible sort order in the
+   zone, and consequently wraps to the owner name of the zone apex:
+
+      N  = \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255.\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255.\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+      S(N) = example.com.
+
+6.3.  Examples of Predecessors Using Modified Method
+
+   Example of typical case:
+
+      P'(foo.example.com.) =
+
+           fon\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255.example.com.
+
+      or, in alternate notation:
+
+           fon\255{60}.example.com.
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 19]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where DNS name contains more labels than DNS names in the
+   zone:
+
+      P'(bar.foo.example.com.) = foo.example.com.
+
+   Example where least significant (right-most) octet of least
+   significant (left-most) label has the minimum sort value:
+
+      P'(foo\000.example.com.) = foo.example.com.
+
+   Example where least significant (left-most) label has the minimum
+   sort value:
+
+      P'(\000.example.com.) = example.com.
+
+   Example where DNS name is the owner name of the zone apex, and
+   consequently wraps to the DNS name with the maximum possible sort
+   order in the zone:
+
+      P'(example.com.) =
+
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{63}.example.com.
+
+6.4.  Examples of Successors Using Modified Method
+
+   Example of typical case:
+
+      S'(foo.example.com.) = foo\000.example.com.
+
+   Example where DNS name contains more labels than DNS names in the
+   zone:
+
+      S'(bar.foo.example.com.) = foo\000.example.com.
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 20]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+   Example where least significant (left-most) label has the maximum
+   sort value, and consequently wraps to the owner name of the zone
+   apex:
+
+      N  = \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255\255\255\255\255\255\255\255\255\255
+           \255\255\255.example.com.
+
+      or, in alternate notation:
+
+           \255{63}.example.com.
+
+      S'(N) = example.com.
+
+
+7.  Security Considerations
+
+   The derivation of some predecessors/successors requires the testing
+   of more conditions than others.  Consequently the effectiveness of a
+   denial-of-service attack may be enhanced by sending queries that
+   require more conditions to be tested.  The modified method involves
+   the testing of fewer conditions than the absolute method and
+   consequently is somewhat less susceptible to this exposure.
+
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+   Note to RFC Editor: This section is included to make it clear during
+   pre-publication review that this document has no IANA actions.  It
+   may therefore be removed should it be published as an RFC.
+
+
+9.  Acknowledgments
+
+   The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and
+   Niall O'Reilly for their review and input.
+
+
+10.  References
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 21]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+10.1  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+10.2  Informative References
+
+   [I-D.ietf-dnsext-dnssec-online-signing]
+              Ihren, J. and S. Weiler, "Minimally Covering NSEC Records
+              and DNSSEC On-line Signing",
+              draft-ietf-dnsext-dnssec-online-signing-00 (work in
+              progress), May 2005.
+
+   [I-D.ietf-dnsext-dnssec-trans]
+              Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC
+              Transition Mechanisms",
+              draft-ietf-dnsext-dnssec-trans-02 (work in progress),
+              February 2005.
+
+
+Appendix A.  Change History
+
+A.1.  Changes from sisson-02 to ietf-00
+
+   o  Added notes on use of SRV RRs with modified method.
+
+   o  Changed reference from weiler-dnssec-online-signing to ietf-
+      dnsext-dnssec-online-signing.
+
+   o  Changed reference from ietf-dnsext-dnssec-records to RFC 4034.
+
+   o  Miscellaneous minor changes to text.
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 22]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+A.2.  Changes from sisson-01 to sisson-02
+
+   o  Added modified version of derivation (with supporting examples).
+
+   o  Introduced notational conventions N, P(N), S(N), P'(N) and S'(N).
+
+   o  Added clarification to derivations about when processing stops.
+
+   o  Miscellaneous minor changes to text.
+
+A.3.  Changes from sisson-00 to sisson-01
+
+   o  Split step 3 of derivation of DNS name predecessor into two
+      distinct steps for clarity.
+
+   o  Added clarifying text and examples related to the requirement to
+      avoid uppercase characters when decrementing or incrementing
+      octets.
+
+   o  Added optimisation using restriction of effective maximum DNS name
+      length.
+
+   o  Changed examples to use decimal rather than octal notation as per
+      [RFC1035].
+
+   o  Corrected DNS name length of some examples.
+
+   o  Added reference to weiler-dnssec-online-signing.
+
+   o  Miscellaneous minor changes to text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 23]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+Authors' Addresses
+
+   Geoffrey Sisson
+   Nominet
+   Sandford Gate
+   Sandy Lane West
+   Oxford
+   OX4 6LB
+   GB
+
+   Phone: +44 1865 332339
+   Email: geoff@nominet.org.uk
+
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London
+   W3 7LR
+   GB
+
+   Phone: +44 20 8735 0686
+   Email: ben@algroup.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 24]
+
+Internet-Draft     DNS Name Predecessor and Successor          July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Sisson & Laurie         Expires January 11, 2006               [Page 25]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
new file mode 100644
index 0000000..bcc2b4e
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
@@ -0,0 +1,442 @@
+
+
+INTERNET-DRAFT                                             Samuel Weiler
+Expires: June 2004                                     December 15, 2003
+Updates: RFC 2535, [DS]
+
+	 Legacy Resolver Compatibility for Delegation Signer
+	 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months and may be updated, replaced, or obsoleted by other
+   documents at any time.  It is inappropriate to use Internet-Drafts
+   as reference material or to cite them other than as "work in
+   progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   Comments should be sent to the author or to the DNSEXT WG mailing
+   list: namedroppers@ops.ietf.org
+
+Abstract
+
+   As the DNS Security (DNSSEC) specifications have evolved, the
+   syntax and semantics of the DNSSEC resource records (RRs) have
+   changed.  Many deployed nameservers understand variants of these
+   semantics.  Dangerous interactions can occur when a resolver that
+   understands an earlier version of these semantics queries an
+   authoritative server that understands the new delegation signer
+   semantics, including at least one failure scenario that will cause
+   an unsecured zone to be unresolvable.  This document changes the
+   type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
+   avoid those interactions.
+
+Changes between 05 and 06:
+
+   Signifigantly reworked the IANA section -- went back to one
+   algorithm registry.
+
+   Removed Diffie-Hellman from the list of zone-signing algorithms
+   (leaving only DSA, RSA/SHA-1, and private algorithms).
+
+   Added a DNSKEY flags field registry.
+
+Changes between 04 and 05:
+
+   IESG approved publication.
+
+   Cleaned up an internal reference in the acknowledgements section.
+
+   Retained KEY and SIG for TKEY, too.  Added TKEY (2930) reference.
+
+   Changed the names of both new registries.  Added algorithm
+   mnemonics to the new zone signing algorithm registry.  Minor
+   rewording in the IANA section for clarity.
+
+   Cleaned up formatting of references.  Replaced unknown-rr draft
+   references with RFC3597.  Bumped DS version number.
+
+Changes between 03 and 04:
+
+   Clarified that RRSIG(0) may be defined by standards action.
+
+   Created a new algorithm registry and renamed the old algorithm
+   registry for SIG(0) only.  Added references to the appropriate
+   crypto algorithm and format specifications.
+
+   Several minor rephrasings.
+
+Changes between 02 and 03:
+
+   KEY (as well as SIG) retained for SIG(0) use only.
+
+Changes between 01 and 02:
+
+   SIG(0) still uses SIG, not RRSIG.  Added 2931 reference.
+
+   Domain names embedded in NSECs and RRSIGs are not compressible and
+   are not downcased.  Added unknown-rrs reference (as informative).
+
+   Simplified the last paragraph of section 3 (NSEC doesn't always
+   signal a negative answer).
+
+   Changed the suggested type code assignments.
+
+   Added 2119 reference.
+
+   Added definitions of "unsecure delegation" and "unsecure referral",
+   since they're not clearly defined elsewhere.
+
+   Moved 2065 to informative references, not normative.
+
+1. Introduction
+
+   The DNSSEC protocol has been through many iterations whose syntax
+   and semantics are not completely compatible.  This has occurred as
+   part of the ordinary process of proposing a protocol, implementing
+   it, testing it in the increasingly complex and diverse environment
+   of the Internet, and refining the definitions of the initial
+   Proposed Standard.  In the case of DNSSEC, the process has been
+   complicated by DNS's criticality and wide deployment and the need
+   to add security while minimizing daily operational complexity.
+
+   A weak area for previous DNS specifications has been lack of detail
+   in specifying resolver behavior, leaving implementors largely on
+   their own to determine many details of resolver function.  This,
+   combined with the number of iterations the DNSSEC spec has been
+   through, has resulted in fielded code with a wide variety of
+   behaviors.  This variety makes it difficult to predict how a
+   protocol change will be handled by all deployed resolvers.  The
+   risk that a change will cause unacceptable or even catastrophic
+   failures makes it difficult to design and deploy a protocol change.
+   One strategy for managing that risk is to structure protocol
+   changes so that existing resolvers can completely ignore input that
+   might confuse them or trigger undesirable failure modes.
+
+   This document addresses a specific problem caused by Delegation
+   Signer's [DS] introduction of new semantics for the NXT RR that are
+   incompatible with the semantics in RFC 2535 [RFC2535].  Answers
+   provided by DS-aware servers can trigger an unacceptable failure
+   mode in some resolvers that implement RFC 2535, which provides a
+   great disincentive to sign zones with DS.  The changes defined in
+   this document allow for the incremental deployment of DS.
+
+1.1 Terminology
+
+   In this document, the term "unsecure delegation" means any
+   delegation for which no DS record appears at the parent.  An
+   "unsecure referral" is an answer from the parent containing an NS
+   RRset and a proof that no DS record exists for that name.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.2 The Problem
+
+   Delegation Signer introduces new semantics for the NXT RR that are
+   incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
+   records were only required to be returned as part of a
+   non-existence proof.  With DS, an unsecure referral returns, in
+   addition to the NS, a proof of non-existence of a DS RR in the form
+   of an NXT and SIG(NXT).  RFC 2535 didn't specify how a resolver was
+   to interpret a response with both an NS and an NXT in the authority
+   section, RCODE=0, and AA=0.  Some widely deployed 2535-aware
+   resolvers interpret any answer with an NXT as a proof of
+   non-existence of the requested record.  This results in unsecure
+   delegations being invisible to 2535-aware resolvers and violates
+   the basic architectural principle that DNSSEC must do no harm --
+   the signing of zones must not prevent the resolution of unsecured
+   delegations.
+
+2. Possible Solutions
+
+   This section presents several solutions that were considered.
+   Section 3 describes the one selected.
+
+2.1. Change SIG, KEY, and NXT type codes
+
+   To avoid the problem described above, legacy (RFC2535-aware)
+   resolvers need to be kept from seeing unsecure referrals that
+   include NXT records in the authority section.  The simplest way to
+   do that is to change the type codes for SIG, KEY, and NXT.
+
+   The obvious drawback to this is that new resolvers will not be able
+   to validate zones signed with the old RRs.  This problem already
+   exists, however, because of the changes made by DS, and resolvers
+   that understand the old RRs (and have compatibility issues with DS)
+   are far more prevalent than 2535-signed zones.
+
+2.2. Change a subset of type codes
+
+   The observed problem with unsecure referrals could be addressed by
+   changing only the NXT type code or another subset of the type codes
+   that includes NXT.  This has the virtue of apparent simplicity, but
+   it risks introducing new problems or not going far enough.  It's
+   quite possible that more incompatibilities exist between DS and
+   earlier semantics.  Legacy resolvers may also be confused by seeing
+   records they recognize (SIG and KEY) while being unable to find
+   NXTs.  Although it may seem unnecessary to fix that which is not
+   obviously broken, it's far cleaner to change all of the type codes
+   at once.  This will leave legacy resolvers and tools completely
+   blinded to DNSSEC -- they will see only unknown RRs.
+
+2.3. Replace the DO bit
+
+   Another way to keep legacy resolvers from ever seeing DNSSEC
+   records with DS semantics is to have authoritative servers only
+   send that data to DS-aware resolvers.  It's been proposed that
+   assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
+   called "DA"), and having authoritative servers send DNSSEC data
+   only in response to queries with the DA bit set, would accomplish
+   this.  This bit would presumably supplant the DO bit described in
+   RFC 3225.
+
+   This solution is sufficient only if all 2535-aware resolvers zero
+   out EDNS0 flags that they don't understand.  If one passed through
+   the DA bit unchanged, it would still see the new semantics, and it
+   would probably fail to see unsecure delegations.  Since it's
+   impractical to know how every DNS implementation handles unknown
+   EDNS0 flags, this is not a universal solution.  It could, though,
+   be considered in addition to changing the RR type codes.
+
+2.4. Increment the EDNS version
+
+   Another possible solution is to increment the EDNS version number
+   as defined in RFC 2671 [RFC2671], on the assumption that all
+   existing implementations will reject higher versions than they
+   support, and retain the DO bit as the signal for DNSSEC awareness.
+   This approach has not been tested.
+
+2.5. Do nothing
+
+   There is a large deployed base of DNS resolvers that understand
+   DNSSEC as defined by the standards track RFC 2535 and RFC 2065
+   and, due to under specification in those documents, interpret any
+   answer with an NXT as a non-existence proof.  So long as that is
+   the case, zone owners will have a strong incentive to not sign any
+   zones that contain unsecure delegations, lest those delegations be
+   invisible to such a large installed base.  This will dramatically
+   slow DNSSEC adoption.
+
+   Unfortunately, without signed zones there's no clear incentive for
+   operators of resolvers to upgrade their software to support the new
+   version of DNSSEC, as defined in [DS].  Historical data suggests
+   that resolvers are rarely upgraded, and that old nameserver code
+   never dies.
+
+   Rather than wait years for resolvers to be upgraded through natural
+   processes before signing zones with unsecure delegations,
+   addressing this problem with a protocol change will immediately
+   remove the disincentive for signing zones and allow widespread
+   deployment of DNSSEC.
+
+3. Protocol changes
+
+   This document changes the type codes of SIG, KEY, and NXT.  This
+   approach is the cleanest and safest of those discussed above,
+   largely because the behavior of resolvers that receive unknown type
+   codes is well understood.  This approach has also received the most
+   testing.
+
+   To avoid operational confusion, it's also necessary to change the
+   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
+   with the mnemonic indicating that these keys are not for
+   application use, per [RFC3445].  RRSIG (Resource Record SIGnature)
+   will replace SIG, and NSEC (Next SECure) will replace NXT.  These
+   new types completely replace the old types, except that SIG(0)
+   [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
+
+   The new types will have exactly the same syntax and semantics as
+   specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
+   the following:
+
+      1) Consistent with [RFC3597], domain names embedded in
+      RRSIG and NSEC RRs MUST NOT be compressed,
+
+      2) Embedded domain names in RRSIG and NSEC RRs are not downcased
+      for purposes of DNSSEC canonical form and ordering nor for
+      equality comparison, and
+
+      3) An RRSIG with a type-covered field of zero has undefined
+      semantics.  The meaning of such a resource record may only be
+      defined by IETF Standards Action.
+
+   If a resolver receives the old types, it SHOULD treat them as
+   unknown RRs and SHOULD NOT assign any special meaning to them or
+   give them any special treatment.  It MUST NOT use them for DNSSEC
+   validations or other DNS operational decision making.  For example,
+   a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
+   validate RRSIGs.  If SIG, KEY, or NXT RRs are included in a zone,
+   they MUST NOT receive special treatment.  As an example, if a SIG
+   is included in a signed zone, there MUST be an RRSIG for it.
+   Authoritative servers may wish to give error messages when loading
+   zones containing SIG or NXT records (KEY records may be included
+   for SIG(0) or TKEY).
+
+   As a clarification to previous documents, some positive responses,
+   particularly wildcard proofs and unsecure referrals, will contain
+   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as
+   negative answers merely because they contain an NSEC.
+
+4. IANA Considerations
+
+4.1 DNS Resource Record Types
+
+   This document updates the IANA registry for DNS Resource Record
+   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
+   DNSKEY RRs, respectively.
+
+   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
+   TKEY [RFC2930] use only.
+
+   Type 30 (NXT) should be marked as Obsolete.
+
+4.2 DNS Security Algorithm Numbers
+
+   To allow zone signing (DNSSEC) and transaction security mechanisms
+   (SIG(0) and TKEY) to use different sets of algorithms, the existing
+   "DNS Security Algorithm Numbers" registry is modified to include
+   the applicability of each algorithm.  Specifically, two new columns
+   are added to the registry, showing whether each algorithm may be
+   used for zone signing, transaction security mechanisms, or both.
+   Only algorithms usable for zone signing may be used in DNSKEY,
+   RRSIG, and DS RRs.  Only algorithms usable for SIG(0) and/or TSIG
+   may be used in SIG and KEY RRs.
+
+   All currently defined algorithms remain usable for transaction
+   security mechanisms.  Only RSA/SHA-1, DSA/SHA-1, and private
+   algorithms (types 253 and 254) may be used for zone signing.  Note
+   that the registry does not contain the requirement level of each
+   algorithm, only whether or not an algorithm may be used for the
+   given purposes.  For example, RSA/MD5, while allowed for
+   transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
+
+   Additionally, the presentation format algorithm mnemonics from
+   RFC2535 Section 7 are added to the registry.  This document assigns
+   RSA/SHA-1 the mnemonic RSASHA1.
+
+   As before, assignment of new algorithms in this registry requires
+   IETF Standards Action.  Additionally, modification of algorithm
+   mnemonics or applicability requires IETF Standards Action.
+   Documents defining a new algorithm must address the applicability
+   of the algorithm and should assign a presentation mnemonic to the
+   algorithm.
+
+4.3 DNSKEY Flags
+
+   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
+   This document creates a new registry for the DNSKEY flags field.
+
+   Initially, this registry only contains an assignment for bit 7 (the
+   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
+   Standards Action.
+
+4.4 DNSKEY Protocol Octet
+
+   Like the KEY resource record, DNSKEY contains an eight bit protocol
+   field.  The only defined value for this field is 3 (DNSSEC).  No
+   other values are allowed, hence no IANA registry is needed for this
+   field.
+
+5. Security Considerations
+
+   The changes introduced here do not materially affect security.
+   The implications of trying to use both new and legacy types
+   together are not well understood, and attempts to do so would
+   probably lead to unintended and dangerous results.
+
+   Changing type codes will leave code paths in legacy resolvers that
+   are never exercised.  Unexercised code paths are a frequent source
+   of security holes, largely because those code paths do not get
+   frequent scrutiny.
+
+   Doing nothing, as described in section 2.5, will slow DNSSEC
+   deployment.  While this does not decrease security, it also fails
+   to increase it.
+
+6. Normative references
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+             RFC 2535, March 1999.
+
+   [DS]      Gudmundsson, O., "Delegation Signer Resource Record",
+             draft-ietf-dnsext-delegation-signer-15.txt, work in
+             progress, June 2003.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+             (SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+             RR)", RFC 2930, September 2000.
+
+   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
+             System (DNS)", RFC 2436, March 1999.
+
+   [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
+             Domain Name System (DNS)", RFC 2539, March 1999.
+
+   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+             Domain Name System (DNS)", RFC 3110, May 2001.
+
+7. Informative References
+
+   [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
+             Extensions", RFC 2065, January 1997.
+
+   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+	     2671, August 1999.
+
+   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+             3225, December 2001.
+
+   [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
+	     "Domain Name System (DNS) IANA Considerations", BCP 42,
+	     RFC 2929, September 2000.
+
+   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
+	     Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
+             Record (RR) Types", RFC 3597, September 2003.
+
+8. Acknowledgments
+
+   The changes introduced here and the analysis of alternatives had
+   many contributors.  With apologies to anyone overlooked, those
+   include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
+   Lewis, Bill Manning, and Suzanne Woolf.
+
+   Thanks to Jakob Schlyter and Mark Andrews for identifying the
+   incompatibility described in section 1.2.
+
+   In addition to the above, the author would like to thank Scott
+   Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
+   comments.
+
+9. Author's Address
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, MD 21046
+   USA
+   weiler@tislabs.com
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
new file mode 100644
index 0000000..3a800f9
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
@@ -0,0 +1,616 @@
+
+
+
+Network Working Group                                          S. Weiler
+Internet-Draft                                               SPARTA, Inc
+Updates: 4034, 4035 (if approved)                           May 23, 2005
+Expires: November 24, 2005
+
+
+         Clarifications and Implementation Notes for DNSSECbis
+                draft-ietf-dnsext-dnssec-bis-updates-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 24, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document is a collection of minor technical clarifications to
+   the DNSSECbis document set.  It is meant to serve as a resource to
+   implementors as well as an interim repository of possible DNSSECbis
+   errata.
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 1]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+Proposed additions in future versions
+
+   An index sorted by the section of DNSSECbis being clarified.
+
+   A list of proposed protocol changes being made in other documents,
+   such as NSEC3 and Epsilon.  This document would not make those
+   changes, merely provide an index into the documents that are making
+   changes.
+
+Changes between -00 and -01
+
+   Document significantly restructured.
+
+   Added section on QTYPE=ANY.
+
+Changes between personal submission and first WG draft
+
+   Added Section 2.1 based on namedroppers discussions from March 9-10,
+   2005.
+
+   Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
+
+   Added the DNSSECbis RFC numbers.
+
+   Figured out the confusion in Section 4.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 2]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+Table of Contents
+
+   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
+     1.1   Structure of this Document . . . . . . . . . . . . . . . .  4
+     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Significant Concerns . . . . . . . . . . . . . . . . . . . . .  4
+     2.1   Clarifications on Non-Existence Proofs . . . . . . . . . .  4
+     2.2   Empty Non-Terminal Proofs  . . . . . . . . . . . . . . . .  5
+     2.3   Validating Responses to an ANY Query . . . . . . . . . . .  5
+   3.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
+     3.1   Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
+     3.2   Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
+     3.3   Caution About Local Policy and Multiple RRSIGs . . . . . .  6
+     3.4   Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
+   4.  Minor Corrections and Clarifications . . . . . . . . . . . . .  7
+     4.1   Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  7
+     4.2   Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  7
+     4.3   Errors in Examples . . . . . . . . . . . . . . . . . . . .  8
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     7.1   Normative References . . . . . . . . . . . . . . . . . . .  8
+     7.2   Informative References . . . . . . . . . . . . . . . . . .  9
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
+       Intellectual Property and Copyright Statements . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 3]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+1.  Introduction and Terminology
+
+   This document lists some minor clarifications and corrections to
+   DNSSECbis, as described in [1], [2], and [3].
+
+   It is intended to serve as a resource for implementors and as a
+   repository of items that need to be addressed when advancing the
+   DNSSECbis documents from Proposed Standard to Draft Standard.
+
+   In this version (-01 of the WG document), feedback is particularly
+   solicited on the structure of the document and whether the text in
+   the recently added sections is correct and sufficient.
+
+   Proposed substantive additions to this document should be sent to the
+   namedroppers mailing list as well as to the editor of this document.
+   The editor would greatly prefer text suitable for direct inclusion in
+   this document.
+
+1.1  Structure of this Document
+
+   The clarifications to DNSSECbis are sorted according to the editor's
+   impression of their importance, starting with ones which could, if
+   ignored, lead to security and stability problems and progressing down
+   to clarifications that are likely to have little operational impact.
+   Mere typos and awkward phrasings are not addressed unless they could
+   lead to misinterpretation of the DNSSECbis documents.
+
+1.2  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+2.  Significant Concerns
+
+   This section provides clarifications that, if overlooked, could lead
+   to security issues or major interoperability problems.
+
+2.1  Clarifications on Non-Existence Proofs
+
+   RFC4035 Section 5.4 slightly underspecifies the algorithm for
+   checking non-existence proofs.  In particular, the algorithm there
+   might incorrectly allow the NSEC from the parent side of a zone cut
+   to prove the non-existence of either other RRs at that name in the
+   child zone or other names in the child zone.  It might also allow a
+   NSEC at the same name as a DNAME to prove the non-existence of names
+   beneath that DNAME.
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 4]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   A parent-side delegation NSEC (one with the NS bit set, but no SOA
+   bit set, and with a singer field that's shorter than the owner name)
+   must not be used to assume non-existence of any RRs below that zone
+   cut (both RRs at that ownername and at ownernames with more leading
+   labels, no matter their content).  Similarly, an NSEC with the DNAME
+   bit set must not be used to assume the non-existence of any
+   descendant of that NSEC's owner name.
+
+2.2  Empty Non-Terminal Proofs
+
+   To be written, based on Roy Arends' May 11th message to namedroppers.
+
+2.3  Validating Responses to an ANY Query
+
+   RFC4035 does not address now to validate responses when QTYPE=*.  As
+   described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
+   may include a subset of the RRsets at a given name -- it is not
+   necessary to include all RRsets at the QNAME in the response.
+
+   When validating a response to QTYPE=*, validate all received RRsets
+   that match QNAME and QCLASS.  If any of those RRsets fail validation,
+   treat the answer as Bogus.  If there are no RRsets matching QNAME and
+   QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
+   clarified in this document).  To be clear, a validator must not
+   insist on receiving all records at the QNAME in response to QTYPE=*.
+
+3.  Interoperability Concerns
+
+3.1  Unknown DS Message Digest Algorithms
+
+   Section 5.2 of RFC4035 includes rules for how to handle delegations
+   to zones that are signed with entirely unsupported algorithms, as
+   indicated by the algorithms shown in those zone's DS RRsets.  It does
+   not explicitly address how to handle DS records that use unsupported
+   message digest algorithms.  In brief, DS records using unknown or
+   unsupported message digest algorithms MUST be treated the same way as
+   DS records referring to DNSKEY RRs of unknown or unsupported
+   algorithms.
+
+   The existing text says:
+
+      If the validator does not support any of the algorithms listed
+      in an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+
+
+
+Weiler                  Expires November 24, 2005               [Page 5]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   To paraphrase the above, when determining the security status of a
+   zone, a validator discards (for this purpose only) any DS records
+   listing unknown or unsupported algorithms.  If none are left, the
+   zone is treated as if it were unsigned.
+
+   Modified to consider DS message digest algorithms, a validator also
+   discards any DS records using unknown or unsupported message digest
+   algorithms.
+
+3.2  Private Algorithms
+
+   As discussed above, section 5.2 of RFC4035 requires that validators
+   make decisions about the security status of zones based on the public
+   key algorithms shown in the DS records for those zones.  In the case
+   of private algorithms, as described in RFC4034 Appendix A.1.1, the
+   eight-bit algorithm field in the DS RR is not conclusive about what
+   algorithm(s) is actually in use.
+
+   If no private algorithms appear in the DS set or if any supported
+   algorithm appears in the DS set, no special processing will be
+   needed.  In the remaining cases, the security status of the zone
+   depends on whether or not the resolver supports any of the private
+   algorithms in use (provided that these DS records use supported hash
+   functions, as discussed in Section 3.1).  In these cases, the
+   resolver MUST retrieve the corresponding DNSKEY for each private
+   algorithm DS record and examine the public key field to determine the
+   algorithm in use.  The security-aware resolver MUST ensure that the
+   hash of the DNSKEY RR's owner name and RDATA matches the digest in
+   the DS RR.  If they do not match, and no other DS establishes that
+   the zone is secure, the referral should be considered BAD data, as
+   discussed in RFC4035.
+
+   This clarification facilitates the broader use of private algorithms,
+   as suggested by [5].
+
+3.3  Caution About Local Policy and Multiple RRSIGs
+
+   When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
+   suggests that "the local resolver security policy determines whether
+   the resolver also has to test these RRSIG RRs and how to resolve
+   conflicts if these RRSIG RRs lead to differing results."  In most
+   cases, a resolver would be well advised to accept any valid RRSIG as
+   sufficient.  If the first RRSIG tested fails validation, a resolver
+   would be well advised to try others, giving a successful validation
+   result if any can be validated and giving a failure only if all
+   RRSIGs fail validation.
+
+   If a resolver adopts a more restrictive policy, there's a danger that
+
+
+
+Weiler                  Expires November 24, 2005               [Page 6]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   properly-signed data might unnecessarily fail validation, perhaps
+   because of cache timing issues.  Furthermore, certain zone management
+   techniques, like the Double Signature Zone-signing Key Rollover
+   method described in section 4.2.1.2 of [6] might not work reliably.
+
+3.4  Key Tag Calculation
+
+   RFC4034 Appendix B.1 incorrectly defines the Key Tag field
+   calculation for algorithm 1.  It correctly says that the Key Tag is
+   the most significant 16 of the least significant 24 bits of the
+   public key modulus.  However, RFC4034 then goes on to incorrectly say
+   that this is 4th to last and 3rd to last octets of the public key
+   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
+
+4.  Minor Corrections and Clarifications
+
+4.1  Finding Zone Cuts
+
+   Appendix C.8 of RFC4035 discusses sending DS queries to the servers
+   for a parent zone.  To do that, a resolver may first need to apply
+   special rules to discover what those servers are.
+
+   As explained in Section 3.1.4.1 of RFC4035, security-aware name
+   servers need to apply special processing rules to handle the DS RR,
+   and in some situations the resolver may also need to apply special
+   rules to locate the name servers for the parent zone if the resolver
+   does not already have the parent's NS RRset.  Section 4.2 of RFC4035
+   specifies a mechanism for doing that.
+
+4.2  Clarifications on DNSKEY Usage
+
+   Questions of the form "can I use a different DNSKEY for signing the
+   X" have occasionally arisen.
+
+   The short answer is "yes, absolutely".  You can even use a different
+   DNSKEY for each RRset in a zone, subject only to practical limits on
+   the size of the DNSKEY RRset.  However, be aware that there is no way
+   to tell resolvers what a particularly DNSKEY is supposed to be used
+   for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
+   authenticate any RRset in the zone.  For example, if a weaker or less
+   trusted DNSKEY is being used to authenticate NSEC RRsets or all
+   dynamically updated records, that same DNSKEY can also be used to
+   sign any other RRsets from the zone.
+
+   Furthermore, note that the SEP bit setting has no effect on how a
+   DNSKEY may be used -- the validation process is specifically
+   prohibited from using that bit by RFC4034 section 2.1.2.  It possible
+   to use a DNSKEY without the SEP bit set as the sole secure entry
+
+
+
+Weiler                  Expires November 24, 2005               [Page 7]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   point to the zone, yet use a DNSKEY with the SEP bit set to sign all
+   RRsets in the zone (other than the DNSKEY RRset).  It's also possible
+   to use a single DNSKEY, with or without the SEP bit set, to sign the
+   entire zone, including the DNSKEY RRset itself.
+
+4.3  Errors in Examples
+
+   The text in RFC4035 Section C.1 refers to the examples in B.1 as
+   "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
+   obvious in the second paragraph where it states that the RRSIG labels
+   field value of 3 indicates that the answer was not the result of
+   wildcard expansion.  This is true for "x.w.example" but not for
+   "x.w.example.com", which of course has a label count of 4
+   (antithetically, a label count of 3 would imply the answer was the
+   result of a wildcard expansion).
+
+   The first paragraph of RFC4035 Section C.6 also has a minor error:
+   the reference to "a.z.w.w.example" should instead be "a.z.w.example",
+   as in the previous line.
+
+5.  IANA Considerations
+
+   This document specifies no IANA Actions.
+
+6.  Security Considerations
+
+   This document does not make fundamental changes to the DNSSEC
+   protocol, as it was generally understood when DNSSECbis was
+   published.  It does, however, address some ambiguities and omissions
+   in those documents that, if not recognized and addressed in
+   implementations, could lead to security failures.  In particular, the
+   validation algorithm clarifications in Section 2 are critical for
+   preserving the security properties DNSSEC offers.  Furthermore,
+   failure to address some of the interoperability concerns in Section 3
+   could limit the ability to later change or expand DNSSEC, including
+   by adding new algorithms.
+
+7.  References
+
+7.1  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+
+
+Weiler                  Expires November 24, 2005               [Page 8]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+7.2  Informative References
+
+   [5]  Blacka, D., "DNSSEC Experiments",
+        draft-blacka-dnssec-experiments-00 (work in progress),
+        December 2004.
+
+   [6]  Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practices-04 (work in
+        progress), May 2005.
+
+
+Author's Address
+
+   Samuel Weiler
+   SPARTA, Inc
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   Email: weiler@tislabs.com
+
+Appendix A.  Acknowledgments
+
+   The editor is extremely grateful to those who, in addition to finding
+   errors and omissions in the DNSSECbis document set, have provided
+   text suitable for inclusion in this document.
+
+   The lack of specificity about handling private algorithms, as
+   described in Section 3.2, and the lack of specificity in handling ANY
+   queries, as described in Section 2.3, were discovered by David
+   Blacka.
+
+   The error in algorithm 1 key tag calculation, as described in
+   Section 3.4, was found by Abhijit Hayatnagarkar.  Donald Eastlake
+   contributed text for Section 3.4.
+
+   The bug relating to delegation NSEC RR's in Section 2.1 was found by
+   Roy Badami.  Roy Arends found the related problem with DNAME.
+
+   The errors in the RFC4035 examples were found by Roy Arends, who also
+   contributed text for Section 4.3 of this document.
+
+
+
+Weiler                  Expires November 24, 2005               [Page 9]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+   The editor would like to thank Olafur Gudmundsson and Scott Rose for
+   their substantive comments on the text of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                  Expires November 24, 2005              [Page 10]
+
+Internet-Draft       DNSSECbis Implementation Notes             May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Weiler                  Expires November 24, 2005              [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
new file mode 100644
index 0000000..ee03583
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
@@ -0,0 +1,784 @@
+
+
+
+DNSEXT                                                         D. Blacka
+Internet-Draft                                            Verisign, Inc.
+Expires: January 19, 2006                                  July 18, 2005
+
+
+                           DNSSEC Experiments
+                draft-ietf-dnsext-dnssec-experiments-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   In the long history of the development of the DNS security extensions
+   [1] (DNSSEC), a number of alternate methodologies and modifications
+   have been proposed and rejected for practical, rather than strictly
+   technical, reasons.  There is a desire to be able to experiment with
+   these alternate methods in the public DNS.  This document describes a
+   methodology for deploying alternate, non-backwards-compatible, DNSSEC
+   methodologies in an experimental fashion without disrupting the
+   deployment of standard DNSSEC.
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 1]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+Table of Contents
+
+   1.   Definitions and Terminology  . . . . . . . . . . . . . . . .   3
+   2.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.   Experiments  . . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+   5.   Defining an Experiment . . . . . . . . . . . . . . . . . . .   8
+   6.   Considerations . . . . . . . . . . . . . . . . . . . . . . .   9
+   7.   Transitions  . . . . . . . . . . . . . . . . . . . . . . . .  10
+   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  11
+   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
+   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
+     10.1   Normative References . . . . . . . . . . . . . . . . . .  13
+     10.2   Informative References . . . . . . . . . . . . . . . . .  13
+        Author's Address . . . . . . . . . . . . . . . . . . . . . .  13
+        Intellectual Property and Copyright Statements . . . . . . .  14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 2]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+1.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [4]) and the DNS security extensions ([1], [2], and [3].
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 3]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+2.  Overview
+
+   Historically, experimentation with DNSSEC alternatives has been a
+   problematic endeavor.  There has typically been a desire to both
+   introduce non-backwards-compatible changes to DNSSEC, and to try
+   these changes on real zones in the public DNS.  This creates a
+   problem when the change to DNSSEC would make all or part of the zone
+   using those changes appear bogus (bad) or otherwise broken to
+   existing DNSSEC-aware resolvers.
+
+   This document describes a standard methodology for setting up public
+   DNSSEC experiments.  This methodology addresses the issue of co-
+   existence with standard DNSSEC and DNS by using unknown algorithm
+   identifiers to hide the experimental DNSSEC protocol modifications
+   from standard DNSSEC-aware resolvers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 4]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+3.  Experiments
+
+   When discussing DNSSEC experiments, it is necessary to classify these
+   experiments into two broad categories:
+
+   Backwards-Compatible: describes experimental changes that, while not
+      strictly adhering to the DNSSEC standard, are nonetheless
+      interoperable with clients and server that do implement the DNSSEC
+      standard.
+
+   Non-Backwards-Compatible: describes experiments that would cause a
+      standard DNSSEC-aware resolver to (incorrectly) determine that all
+      or part of a zone is bogus, or to otherwise not interoperable with
+      standard DNSSEC clients and servers.
+
+   Not included in these terms are experiments with the core DNS
+   protocol itself.
+
+   The methodology described in this document is not necessary for
+   backwards-compatible experiments, although it certainly could be used
+   if desired.
+
+   Note that, in essence, this metholodolgy would also be used to
+   introduce a new DNSSEC algorithm, independently from any DNSSEC
+   experimental protocol change.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 5]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+4.  Method
+
+   The core of the methodology is the use of strictly "unknown"
+   algorithms to sign the experimental zone, and more importantly,
+   having only unknown algorithm DS records for the delegation to the
+   zone at the parent.
+
+   This technique works because of the way DNSSEC-compliant validators
+   are expected to work in the presence of a DS set with only unknown
+   algorithms.  From [3], Section 5.2:
+
+      If the validator does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+   And further:
+
+      If the resolver does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver will not be able to
+      verify the authentication path to the child zone.  In this case,
+      the resolver SHOULD treat the child zone as if it were unsigned.
+
+   While this behavior isn't strictly mandatory (as marked by MUST), it
+   is unlikely that a validator would not implement the behavior, or,
+   more to the point, it will not violate this behavior in an unsafe way
+   (see below (Section 6).)
+
+   Because we are talking about experiments, it is RECOMMENDED that
+   private algorithm numbers be used (see [2], appendix A.1.1.  Note
+   that secure handling of private algorithms requires special handing
+   by the validator logic.  See [6] for futher details.)  Normally,
+   instead of actually inventing new signing algorithms, the recommended
+   path is to create alternate algorithm identifiers that are aliases
+   for the existing, known algorithms.  While, strictly speaking, it is
+   only necessary to create an alternate identifier for the mandatory
+   algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
+   aliased as well.
+
+   It is RECOMMENDED that for a particular DNSSEC experiment, a
+   particular domain name base is chosen for all new algorithms, then
+   the algorithm number (or name) is prepended to it.  For example, for
+   experiment A, the base name of "dnssec-experiment-a.example.com" is
+   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
+   defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
+   experiment-a.example.com".  However, any unique identifier will
+
+
+
+Blacka                  Expires January 19, 2006                [Page 6]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+   suffice.
+
+   Using this method, resolvers (or, more specificially, DNSSEC
+   validators) essentially indicate their ability to understand the
+   DNSSEC experiment's semantics by understanding what the new algorithm
+   identifiers signify.
+
+   This method creates two classes of DNSSEC-aware servers and
+   resolvers: servers and resolvers that are aware of the experiment
+   (and thus recognize the experiments algorithm identifiers and
+   experimental semantics), and servers and resolvers that are unware of
+   the experiment.
+
+   This method also precludes any zone from being both in an experiment
+   and in a classic DNSSEC island of security.  That is, a zone is
+   either in an experiment and only experimentally validatable, or it
+   isn't.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 7]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+5.  Defining an Experiment
+
+   The DNSSEC experiment must define the particular set of (previously
+   unknown) algorithms that identify the experiment, and define what
+   each unknown algorithm identifier means.  Typically, unless the
+   experiment is actually experimenting with a new DNSSEC algorithm,
+   this will be a mapping of private algorithm identifiers to existing,
+   known algorithms.
+
+   Normally the experiment will choose a DNS name as the algorithm
+   identifier base.  This DNS name SHOULD be under the control of the
+   authors of the experiment.  Then the experiment will define a mapping
+   between known mandatory and optional algorithms into this private
+   algorithm identifier space.  Alternately, the experiment MAY use the
+   OID private algorithm space instead (using algorithm number 254), or
+   may choose non-private algorithm numbers, although this would require
+   an IANA allocation (see below (Section 9).)
+
+   For example, an experiment might specify in its description the DNS
+   name "dnssec-experiment-a.example.com" as the base name, and provide
+   the mapping of "3.dnssec-experiment-a.example.com" is an alias of
+   DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
+   an alias of DNSSEC algorithm 5 (RSASHA1).
+
+   Resolvers MUST then only recognize the experiment's semantics when
+   present in a zone signed by one or more of these private algorithms.
+
+   In general, however, resolvers involved in the experiment are
+   expected to understand both standard DNSSEC and the defined
+   experimental DNSSEC protocol, although this isn't required.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 8]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+6.  Considerations
+
+   There are a number of considerations with using this methodology.
+
+   1.  Under some circumstances, it may be that the experiment will not
+       be sufficiently masked by this technique and may cause resolution
+       problem for resolvers not aware of the experiment.  For instance,
+       the resolver may look at the not validatable response and
+       conclude that the response is bogus, either due to local policy
+       or implementation details.  This is not expected to be the common
+       case, however.
+
+   2.  In general, it will not be possible for DNSSEC-aware resolvers
+       not aware of the experiment to build a chain of trust through an
+       experimental zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006                [Page 9]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+7.  Transitions
+
+   If an experiment is successful, there may be a desire to move the
+   experiment to a standards-track extension.  One way to do so would be
+   to move from private algorithm numbers to IANA allocated algorithm
+   numbers, with otherwise the same meaning.  This would still leave a
+   divide between resolvers that understood the extension versus
+   resolvers that did not.  It would, in essence, create an additional
+   version of DNSSEC.
+
+   An alternate technique might be to do a typecode rollover, thus
+   actually creating a definitive new version of DNSSEC.  There may be
+   other transition techniques available, as well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 10]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+8.  Security Considerations
+
+   Zones using this methodology will be considered insecure by all
+   resolvers except those aware of the experiment.  It is not generally
+   possible to create a secure delegation from an experimental zone that
+   will be followed by resolvers unaware of the experiment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 11]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+9.  IANA Considerations
+
+   IANA may need to allocate new DNSSEC algorithm numbers if that
+   transition approach is taken, or the experiment decides to use
+   allocated numbers to begin with.  No IANA action is required to
+   deploy an experiment using private algorithm identifiers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 12]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+10.  References
+
+10.1  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+10.2  Informative References
+
+   [4]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]  Weiler, S., "Clarifications and Implementation Notes for
+        DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
+        progress), March 2005.
+
+
+Author's Address
+
+   David Blacka
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 13]
+
+Internet-Draft             DNSSEC Experiments                  July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Blacka                  Expires January 19, 2006               [Page 14]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
new file mode 100644
index 0000000..7503c66
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
@@ -0,0 +1,616 @@
+
+
+
+Network Working Group                                          S. Weiler
+Internet-Draft                                               SPARTA, Inc
+Updates: 4034, 4035 (if approved)                               J. Ihren
+Expires: July 24, 2006                                     Autonomica AB
+                                                        January 20, 2006
+
+
+       Minimally Covering NSEC Records and DNSSEC On-line Signing
+               draft-ietf-dnsext-dnssec-online-signing-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 24, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to construct DNSSEC NSEC resource records
+   that cover a smaller range of names than called for by RFC4034.  By
+   generating and signing these records on demand, authoritative name
+   servers can effectively stop the disclosure of zone contents
+   otherwise made possible by walking the chain of NSEC records in a
+   signed zone.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 1]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Changes from ietf-01 to ietf-02
+
+   Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
+   and NSEC bits set, to be consistent with DNSSECbis -- previous text
+   said SHOULD.
+
+   Made the applicability statement a little less oppressive.
+
+Changes from ietf-00 to ietf-01
+
+   Added an applicability statement, making reference to ongoing work on
+   NSEC3.
+
+   Added the phrase "epsilon functions", which has been commonly used to
+   describe the technique and already appeared in the header of each
+   page, in place of "increment and decrement functions".  Also added an
+   explanatory sentence.
+
+   Corrected references from 4034 section 6.2 to section 6.1.
+
+   Fixed an out-of-date reference to [-bis] and other typos.
+
+   Replaced IANA Considerations text.
+
+   Escaped close parentheses in examples.
+
+   Added some more acknowledgements.
+
+Changes from weiler-01 to ietf-00
+
+   Inserted RFC numbers for 4033, 4034, and 4035.
+
+   Specified contents of bitmap field in synthesized NSEC RR's, pointing
+   out that this relaxes a constraint in 4035.  Added 4035 to the
+   Updates header.
+
+Changes from weiler-00 to weiler-01
+
+   Clarified that this updates RFC4034 by relaxing requirements on the
+   next name field.
+
+   Added examples covering wildcard names.
+
+   In the 'better functions' section, reiterated that perfect functions
+   aren't needed.
+
+   Added a reference to RFC 2119.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 2]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Table of Contents
+
+   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
+   2.  Applicability of This Technique  . . . . . . . . . . . . . . .  4
+   3.  Minimally Covering NSEC Records  . . . . . . . . . . . . . . .  5
+   4.  Better Epsilon Functions . . . . . . . . . . . . . . . . . . .  6
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  8
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 3]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+1.  Introduction and Terminology
+
+   With DNSSEC [1], an NSEC record lists the next instantiated name in
+   its zone, proving that no names exist in the "span" between the
+   NSEC's owner name and the name in the "next name" field.  In this
+   document, an NSEC record is said to "cover" the names between its
+   owner name and next name.
+
+   Through repeated queries that return NSEC records, it is possible to
+   retrieve all of the names in the zone, a process commonly called
+   "walking" the zone.  Some zone owners have policies forbidding zone
+   transfers by arbitrary clients; this side-effect of the NSEC
+   architecture subverts those policies.
+
+   This document presents a way to prevent zone walking by constructing
+   NSEC records that cover fewer names.  These records can make zone
+   walking take approximately as many queries as simply asking for all
+   possible names in a zone, making zone walking impractical.  Some of
+   these records must be created and signed on demand, which requires
+   on-line private keys.  Anyone contemplating use of this technique is
+   strongly encouraged to review the discussion of the risks of on-line
+   signing in Section 6.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+
+2.  Applicability of This Technique
+
+   The technique presented here may be useful to a zone owner that wants
+   to use DNSSEC, is concerned about exposure of its zone contents via
+   zone walking, and is willing to bear the costs of on-line signing.
+
+   As discussed in Section 6, on-line signing has several security
+   risks, including an increased likelihood of private keys being
+   disclosed and an increased risk of denial of service attack.  Anyone
+   contemplating use of this technique is strongly encouraged to review
+   the discussion of the risks of on-line signing in Section 6.
+
+   Furthermore, at the time this document was published, the DNSEXT
+   working group was actively working on a mechanism to prevent zone
+   walking that does not require on-line signing (tentatively called
+   NSEC3).  The new mechanism is likely to expose slightly more
+   information about the zone than this technique (e.g. the number of
+   instantiated names), but it may be preferable to this technique.
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 4]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+3.  Minimally Covering NSEC Records
+
+   This mechanism involves changes to NSEC records for instantiated
+   names, which can still be generated and signed in advance, as well as
+   the on-demand generation and signing of new NSEC records whenever a
+   name must be proven not to exist.
+
+   In the 'next name' field of instantiated names' NSEC records, rather
+   than list the next instantiated name in the zone, list any name that
+   falls lexically after the NSEC's owner name and before the next
+   instantiated name in the zone, according to the ordering function in
+   RFC4034 [2] section 6.1.  This relaxes the requirement in section
+   4.1.1 of RFC4034 that the 'next name' field contains the next owner
+   name in the zone.  This change is expected to be fully compatible
+   with all existing DNSSEC validators.  These NSEC records are returned
+   whenever proving something specifically about the owner name (e.g.
+   that no resource records of a given type appear at that name).
+
+   Whenever an NSEC record is needed to prove the non-existence of a
+   name, a new NSEC record is dynamically produced and signed.  The new
+   NSEC record has an owner name lexically before the QNAME but
+   lexically following any existing name and a 'next name' lexically
+   following the QNAME but before any existing name.
+
+   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
+   bits set and SHOULD NOT have any other bits set.  This relaxes the
+   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
+   names that did not exist before the zone was signed.
+
+   The functions to generate the lexically following and proceeding
+   names need not be perfect nor consistent, but the generated NSEC
+   records must not cover any existing names.  Furthermore, this
+   technique works best when the generated NSEC records cover as few
+   names as possible.  In this document, the functions that generate the
+   nearby names are called 'epsilon' functions, a reference to the
+   mathematical convention of using the greek letter epsilon to
+   represent small deviations.
+
+   An NSEC record denying the existence of a wildcard may be generated
+   in the same way.  Since the NSEC record covering a non-existent
+   wildcard is likely to be used in response to many queries,
+   authoritative name servers using the techniques described here may
+   want to pregenerate or cache that record and its corresponding RRSIG.
+
+   For example, a query for an A record at the non-instantiated name
+   example.com might produce the following two NSEC records, the first
+   denying the existence of the name example.com and the second denying
+   the existence of a wildcard:
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 5]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+             exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
+
+             \).com 3600 IN NSEC +.com ( RRSIG NSEC )
+
+   Before answering a query with these records, an authoritative server
+   must test for the existence of names between these endpoints.  If the
+   generated NSEC would cover existing names (e.g. exampldd.com or
+   *bizarre.example.com), a better epsilon function may be used or the
+   covered name closest to the QNAME could be used as the NSEC owner
+   name or next name, as appropriate.  If an existing name is used as
+   the NSEC owner name, that name's real NSEC record MUST be returned.
+   Using the same example, assuming an exampldd.com delegation exists,
+   this record might be returned from the parent:
+
+             exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
+
+   Like every authoritative record in the zone, each generated NSEC
+   record MUST have corresponding RRSIGs generated using each algorithm
+   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
+   described in RFC4035 [3] section 2.2.  To minimize the number of
+   signatures that must be generated, a zone may wish to limit the
+   number of algorithms in its DNSKEY RRset.
+
+
+4.  Better Epsilon Functions
+
+   Section 6.1 of RFC4034 defines a strict ordering of DNS names.
+   Working backwards from that definition, it should be possible to
+   define epsilon functions that generate the immediately following and
+   preceding names, respectively.  This document does not define such
+   functions.  Instead, this section presents functions that come
+   reasonably close to the perfect ones.  As described above, an
+   authoritative server should still ensure than no generated NSEC
+   covers any existing name.
+
+   To increment a name, add a leading label with a single null (zero-
+   value) octet.
+
+   To decrement a name, decrement the last character of the leftmost
+   label, then fill that label to a length of 63 octets with octets of
+   value 255.  To decrement a null (zero-value) octet, remove the octet
+   -- if an empty label is left, remove the label.  Defining this
+   function numerically: fill the left-most label to its maximum length
+   with zeros (numeric, not ASCII zeros) and subtract one.
+
+   In response to a query for the non-existent name foo.example.com,
+   these functions produce NSEC records of:
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 6]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
+
+     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
+
+   The first of these NSEC RRs proves that no exact match for
+   foo.example.com exists, and the second proves that there is no
+   wildcard in example.com.
+
+   Both of these functions are imperfect: they don't take into account
+   constraints on number of labels in a name nor total length of a name.
+   As noted in the previous section, though, this technique does not
+   depend on the use of perfect epsilon functions: it is sufficient to
+   test whether any instantiated names fall into the span covered by the
+   generated NSEC and, if so, substitute those instantiated owner names
+   for the NSEC owner name or next name, as appropriate.
+
+
+5.  IANA Considerations
+
+   This document specifies no IANA Actions.
+
+
+6.  Security Considerations
+
+   This approach requires on-demand generation of RRSIG records.  This
+   creates several new vulnerabilities.
+
+   First, on-demand signing requires that a zone's authoritative servers
+   have access to its private keys.  Storing private keys on well-known
+   internet-accessible servers may make them more vulnerable to
+   unintended disclosure.
+
+   Second, since generation of digital signatures tends to be
+   computationally demanding, the requirement for on-demand signing
+   makes authoritative servers vulnerable to a denial of service attack.
+
+   Lastly, if the epsilon functions are predictable, on-demand signing
+   may enable a chosen-plaintext attack on a zone's private keys.  Zones
+   using this approach should attempt to use cryptographic algorithms
+   that are resistant to chosen-plaintext attacks.  It's worth noting
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 7]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+   that while DNSSEC has a "mandatory to implement" algorithm, that is a
+   requirement on resolvers and validators -- there is no requirement
+   that a zone be signed with any given algorithm.
+
+   The success of using minimally covering NSEC record to prevent zone
+   walking depends greatly on the quality of the epsilon functions
+   chosen.  An increment function that chooses a name obviously derived
+   from the next instantiated name may be easily reverse engineered,
+   destroying the value of this technique.  An increment function that
+   always returns a name close to the next instantiated name is likewise
+   a poor choice.  Good choices of epsilon functions are the ones that
+   produce the immediately following and preceding names, respectively,
+   though zone administrators may wish to use less perfect functions
+   that return more human-friendly names than the functions described in
+   Section 4 above.
+
+   Another obvious but misguided concern is the danger from synthesized
+   NSEC records being replayed.  It's possible for an attacker to replay
+   an old but still validly signed NSEC record after a new name has been
+   added in the span covered by that NSEC, incorrectly proving that
+   there is no record at that name.  This danger exists with DNSSEC as
+   defined in [3].  The techniques described here actually decrease the
+   danger, since the span covered by any NSEC record is smaller than
+   before.  Choosing better epsilon functions will further reduce this
+   danger.
+
+7.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+Appendix A.  Acknowledgments
+
+   Many individuals contributed to this design.  They include, in
+   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 8]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
+   Jakob Schlyter, Bill Manning, and Joao Damas.
+
+   In addition, the editors would like to thank Ed Lewis, Scott Rose,
+   and David Blacka for their careful review of the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 9]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Authors' Addresses
+
+   Samuel Weiler
+   SPARTA, Inc
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   Email: weiler@tislabs.com
+
+
+   Johan Ihren
+   Autonomica AB
+   Bellmansgatan 30
+   Stockholm  SE-118 47
+   Sweden
+
+   Email: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                [Page 10]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
new file mode 100644
index 0000000..17e28e8
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
@@ -0,0 +1,896 @@
+
+
+
+DNSEXT                                                         R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: January 19, 2006                                     M. Kosters
+                                                               D. Blacka
+                                                          Verisign, Inc.
+                                                           July 18, 2005
+
+
+                             DNSSEC Opt-In
+                   draft-ietf-dnsext-dnssec-opt-in-07
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
+   4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
+   cryptographically secured.  Maintaining this cryptography is not
+   practical or necessary.  This document describes an experimental
+   "Opt-In" model that allows administrators to omit this cryptography
+   and manage the cost of adopting DNSSEC with large zones.
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 1]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Table of Contents
+
+   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1   Server Considerations  . . . . . . . . . . . . . . . . . .  5
+       4.1.1   Delegations Only . . . . . . . . . . . . . . . . . . .  5
+       4.1.2   Insecure Delegation Responses  . . . . . . . . . . . .  6
+       4.1.3   Wildcards and Opt-In . . . . . . . . . . . . . . . . .  6
+       4.1.4   Dynamic Update . . . . . . . . . . . . . . . . . . . .  7
+     4.2   Client Considerations  . . . . . . . . . . . . . . . . . .  7
+       4.2.1   Delegations Only . . . . . . . . . . . . . . . . . . .  7
+       4.2.2   Validation Process Changes . . . . . . . . . . . . . .  7
+       4.2.3   NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
+       4.2.4   Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
+   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 10
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 12
+   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     11.1  Normative References . . . . . . . . . . . . . . . . . . . 13
+     11.2  Informative References . . . . . . . . . . . . . . . . . . 13
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+   A.  Implementing Opt-In using "Views"  . . . . . . . . . . . . . . 14
+       Intellectual Property and Copyright Statements . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 2]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+1.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [1]), DNS security extensions ([3], [4], and [5], referred to in this
+   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
+   [10]) is assumed.
+
+   The following abbreviations and terms are used in this document:
+
+   RR: is used to refer to a DNS resource record.
+   RRset: refers to a Resource Record Set, as defined by [8].  In this
+      document, the RRset is also defined to include the covering RRSIG
+      records, if any exist.
+   signed name: refers to a DNS name that has, at minimum, a (signed)
+      NSEC record.
+   unsigned name: refers to a DNS name that does not (at least) have a
+      NSEC record.
+   covering NSEC record/RRset: is the NSEC record used to prove
+      (non)existence of a particular name or RRset.  This means that for
+      a RRset or name 'N', the covering NSEC record has the name 'N', or
+      has an owner name less than 'N' and "next" name greater than 'N'.
+   delegation: refers to a NS RRset with a name different from the
+      current zone apex (non-zone-apex), signifying a delegation to a
+      subzone.
+   secure delegation: refers to a signed name containing a delegation
+      (NS RRset), and a signed DS RRset, signifying a delegation to a
+      signed subzone.
+   insecure delegation: refers to a signed name containing a delegation
+      (NS RRset), but lacking a DS RRset, signifying a delegation to an
+      unsigned subzone.
+   Opt-In insecure delegation: refers to an unsigned name containing
+      only a delegation NS RRset.  The covering NSEC record uses the
+      Opt-In methodology described in this document.
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [7].
+
+2.  Overview
+
+   The cost to cryptographically secure delegations to unsigned zones is
+   high for large delegation-centric zones and zones where insecure
+   delegations will be updated rapidly.  For these zones, the costs of
+   maintaining the NSEC record chain may be extremely high relative to
+   the gain of cryptographically authenticating existence of unsecured
+   zones.
+
+   This document describes an experimental method of eliminating the
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 3]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   superfluous cryptography present in secure delegations to unsigned
+   zones.  Using "Opt-In", a zone administrator can choose to remove
+   insecure delegations from the NSEC chain.  This is accomplished by
+   extending the semantics of the NSEC record by using a redundant bit
+   in the type map.
+
+3.  Experimental Status
+
+   This document describes an EXPERIMENTAL extension to DNSSEC.  It
+   interoperates with non-experimental DNSSEC using the technique
+   described in [6].  This experiment is identified with the following
+   private algorithms (using algorithm 253):
+
+   "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
+      and
+   "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
+      RSASHA1.
+
+   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
+   the zone with only one or more of these private algorithms.  This
+   requires the signing tools and servers to support private algorithms,
+   as well as Opt-In.
+
+   Resolvers wishing to validate Opt-In zones MUST only do so when the
+   zone is only signed using one or more of these private algorithms.
+
+   The remainder of this document assumes that the servers and resolvers
+   involved are aware of and are involved in this experiment.
+
+4.  Protocol Additions
+
+   In DNSSEC, delegation NS RRsets are not signed, but are instead
+   accompanied by a NSEC RRset of the same name and (possibly) a DS
+   record.  The security status of the subzone is determined by the
+   presence or absence of the DS RRset, cryptographically proven by the
+   NSEC record.  Opt-In expands this definition by allowing insecure
+   delegations to exist within an otherwise signed zone without the
+   corresponding NSEC record at the delegation's owner name.  These
+   insecure delegations are proven insecure by using a covering NSEC
+   record.
+
+   Since this represents a change of the interpretation of NSEC records,
+   resolvers must be able to distinguish between RFC standard DNSSEC
+   NSEC records and Opt-In NSEC records.  This is accomplished by
+   "tagging" the NSEC records that cover (or potentially cover) insecure
+   delegation nodes.  This tag is indicated by the absence of the NSEC
+   bit in the type map.  Since the NSEC bit in the type map merely
+   indicates the existence of the record itself, this bit is redundant
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 4]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   and safe for use as a tag.
+
+   An Opt-In tagged NSEC record does not assert the (non)existence of
+   the delegations that it covers (except for a delegation with the same
+   name).  This allows for the addition or removal of these delegations
+   without recalculating or resigning records in the NSEC chain.
+   However, Opt-In tagged NSEC records do assert the (non)existence of
+   other RRsets.
+
+   An Opt-In NSEC record MAY have the same name as an insecure
+   delegation.  In this case, the delegation is proven insecure by the
+   lack of a DS bit in type map and the signed NSEC record does assert
+   the existence of the delegation.
+
+   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
+   records and standard DNSSEC NSEC records.  If a NSEC record is not
+   Opt-In, there MUST NOT be any insecure delegations (or any other
+   records) between it and the RRsets indicated by the 'next domain
+   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
+   insecure delegations between it and the next node indicated by the
+   'next domain name' in the NSEC RDATA.
+
+   In summary,
+
+   o  An Opt-In NSEC type is identified by a zero-valued (or not-
+      specified) NSEC bit in the type bit map of the NSEC record.
+   o  A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
+      the type bit map of the NSEC record.
+
+   and,
+
+   o  An Opt-In NSEC record does not assert the non-existence of a name
+      between its owner name and "next" name, although it does assert
+      that any name in this span MUST be an insecure delegation.
+   o  An Opt-In NSEC record does assert the (non)existence of RRsets
+      with the same owner name.
+
+4.1  Server Considerations
+
+   Opt-In imposes some new requirements on authoritative DNS servers.
+
+4.1.1  Delegations Only
+
+   This specification dictates that only insecure delegations may exist
+   between the owner and "next" names of an Opt-In tagged NSEC record.
+   Signing tools SHOULD NOT generate signed zones that violate this
+   restriction.  Servers SHOULD refuse to load and/or serve zones that
+   violate this restriction.  Servers also SHOULD reject AXFR or IXFR
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 5]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   responses that violate this restriction.
+
+4.1.2  Insecure Delegation Responses
+
+   When returning an Opt-In insecure delegation, the server MUST return
+   the covering NSEC RRset in the Authority section.
+
+   In standard DNSSEC, NSEC records already must be returned along with
+   the insecure delegation.  The primary difference that this proposal
+   introduces is that the Opt-In tagged NSEC record will have a
+   different owner name from the delegation RRset.  This may require
+   implementations to search for the covering NSEC RRset.
+
+4.1.3  Wildcards and Opt-In
+
+   Standard DNSSEC describes the practice of returning NSEC records to
+   prove the non-existence of an applicable wildcard in non-existent
+   name responses.  This NSEC record can be described as a "negative
+   wildcard proof".  The use of Opt-In NSEC records changes the
+   necessity for this practice.  For non-existent name responses when
+   the query name (qname) is covered by an Opt-In tagged NSEC record,
+   servers MAY choose to omit the wildcard proof record, and clients
+   MUST NOT treat the absence of this NSEC record as a validation error.
+
+   The intent of the standard DNSSEC negative wildcard proof requirement
+   is to prevent malicious users from undetectably removing valid
+   wildcard responses.  In order for this cryptographic proof to work,
+   the resolver must be able to prove:
+
+   1.  The exact qname does not exist.  This is done by the "normal"
+       NSEC record.
+   2.  No applicable wildcard exists.  This is done by returning a NSEC
+       record proving that the wildcard does not exist (this is the
+       negative wildcard proof).
+
+   However, if the NSEC record covering the exact qname is an Opt-In
+   NSEC record, the resolver will not be able to prove the first part of
+   this equation, as the qname might exist as an insecure delegation.
+   Thus, since the total proof cannot be completed, the negative
+   wildcard proof NSEC record is not useful.
+
+   The negative wildcard proof is also not useful when returned as part
+   of an Opt-In insecure delegation response for a similar reason: the
+   resolver cannot prove that the qname does or does not exist, and
+   therefore cannot prove that a wildcard expansion is valid.
+
+   The presence of an Opt-In tagged NSEC record does not change the
+   practice of returning a NSEC along with a wildcard expansion.  Even
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 6]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   though the Opt-In NSEC will not be able to prove that the wildcard
+   expansion is valid, it will prove that the wildcard expansion is not
+   masking any signed records.
+
+4.1.4  Dynamic Update
+
+   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
+   particular, it introduces the need for rules that describe when to
+   add or remove a delegation name from the NSEC chain.  This document
+   does not attempt to define these rules.  Until these rules are
+   defined, servers MUST NOT process DNS Dynamic Update requests against
+   zones that use Opt-In NSEC records.  Servers SHOULD return responses
+   to update requests with RCODE=REFUSED.
+
+4.2  Client Considerations
+
+   Opt-In imposes some new requirements on security-aware resolvers
+   (caching or otherwise).
+
+4.2.1  Delegations Only
+
+   As stated in the "Server Considerations" section above, this
+   specification restricts the namespace covered by Opt-In tagged NSEC
+   records to insecure delegations only.  Thus, resolvers MUST reject as
+   invalid any records that fall within an Opt-In NSEC record's span
+   that are not NS records or corresponding glue records.
+
+4.2.2  Validation Process Changes
+
+   This specification does not change the resolver's resolution
+   algorithm.  However, it does change the DNSSEC validation process.
+   Resolvers MUST be able to use Opt-In tagged NSEC records to
+   cryptographically prove the validity and security status (as
+   insecure) of a referral.  Resolvers determine the security status of
+   the referred-to zone as follows:
+
+   o  In standard DNSSEC, the security status is proven by the existence
+      or absence of a DS RRset at the same name as the delegation.  The
+      existence of the DS RRset indicates that the referred-to zone is
+      signed.  The absence of the DS RRset is proven using a verified
+      NSEC record of the same name that does not have the DS bit set in
+      the type map.  This NSEC record MAY also be tagged as Opt-In.
+   o  Using Opt-In, the security status is proven by the existence of a
+      DS record (for signed) or the presence of a verified Opt-In tagged
+      NSEC record that covers the delegation name.  That is, the NSEC
+      record does not have the NSEC bit set in the type map, and the
+      delegation name falls between the NSEC's owner and "next" name.
+
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 7]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   Using Opt-In does not substantially change the nature of following
+   referrals within DNSSEC.  At every delegation point, the resolver
+   will have cryptographic proof that the referred-to subzone is signed
+   or unsigned.
+
+   When receiving either an Opt-In insecure delegation response or a
+   non-existent name response where that name is covered by an Opt-In
+   tagged NSEC record, the resolver MUST NOT require proof (in the form
+   of a NSEC record) that a wildcard did not exist.
+
+4.2.3  NSEC Record Caching
+
+   Caching resolvers MUST be able to retrieve the appropriate covering
+   Opt-In NSEC record when returning referrals that need them.  This
+   requirement differs from standard DNSSEC in that the covering NSEC
+   will not have the same owner name as the delegation.  Some
+   implementations may have to use new methods for finding these NSEC
+   records.
+
+4.2.4  Use of the AD bit
+
+   The AD bit, as defined by [2] and [5], MUST NOT be set when:
+
+   o  sending a Name Error (RCODE=3) response where the covering NSEC is
+      tagged as Opt-In.
+   o  sending an Opt-In insecure delegation response, unless the
+      covering (Opt-In) NSEC record's owner name equals the delegation
+      name.
+
+   This rule is based on what the Opt-In NSEC record actually proves:
+   for names that exist between the Opt-In NSEC record's owner and
+   "next" names, the Opt-In NSEC record cannot prove the non-existence
+   or existence of the name.  As such, not all data in the response has
+   been cryptographically verified, so the AD bit cannot be set.
+
+5.  Benefits
+
+   Using Opt-In allows administrators of large and/or changing
+   delegation-centric zones to minimize the overhead involved in
+   maintaining the security of the zone.
+
+   Opt-In accomplishes this by eliminating the need for NSEC records for
+   insecure delegations.  This, in a zone with a large number of
+   delegations to unsigned subzones, can lead to substantial space
+   savings (both in memory and on disk).  Additionally, Opt-In allows
+   for the addition or removal of insecure delegations without modifying
+   the NSEC record chain.  Zones that are frequently updating insecure
+   delegations (e.g., TLDs) can avoid the substantial overhead of
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 8]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   modifying and resigning the affected NSEC records.
+
+6.  Example
+
+   Consider the zone EXAMPLE, shown below.  This is a zone where all of
+   the NSEC records are tagged as Opt-In.
+
+   Example A: Fully Opt-In Zone.
+
+         EXAMPLE.               SOA    ...
+         EXAMPLE.               RRSIG  SOA ...
+         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
+         EXAMPLE.               RRSIG  NS ...
+         EXAMPLE.               DNSKEY ...
+         EXAMPLE.               RRSIG  DNSKEY ...
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
+                                       SOA NS RRSIG DNSKEY )
+         EXAMPLE.               RRSIG  NSEC ...
+
+         FIRST-SECURE.EXAMPLE.  A      ...
+         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
+         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
+         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
+
+         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
+         NS.NOT-SECURE.EXAMPLE. A      ...
+
+         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
+         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
+         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
+
+         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
+         SECOND-SECURE.EXAMPLE. DS     ...
+         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+
+   In this example, a query for a signed RRset (e.g., "FIRST-
+   SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
+   SECURE.EXAMPLE A") will result in a standard DNSSEC response.
+
+   A query for a nonexistent RRset will result in a response that
+   differs from standard DNSSEC by: the NSEC record will be tagged as
+   Opt-In, there may be no NSEC record proving the non-existence of a
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 9]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   matching wildcard record, and the AD bit will not be set.
+
+   A query for an insecure delegation RRset (or a referral) will return
+   both the answer (in the Authority section) and the corresponding
+   Opt-In NSEC record to prove that it is not secure.
+
+   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
+
+
+         RCODE=NOERROR, AD=0
+
+         Answer Section:
+
+         Authority Section:
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         Additional Section:
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
+   NSEC record, because there are no insecure delegations that occur
+   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
+   Example A would still be a valid zone if the NSEC record for EXAMPLE.
+   was changed to the following RR:
+
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
+                                       RRSIG DNSKEY NSEC )
+
+   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
+   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
+   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
+   UNSIGNED.EXAMPLE., respectively).
+
+   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
+   part of the NSEC chain and also covered by an Opt-In tagged NSEC
+   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
+   removed from the zone without modifying and resigning the prior NSEC
+   record.  Delegations with names that fall between NOT-SECURE-
+   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
+   resigning any NSEC records.
+
+7.  Transition Issues
+
+   Opt-In is not backwards compatible with standard DNSSEC and is
+   considered experimental.  Standard DNSSEC compliant implementations
+   would not recognize Opt-In tagged NSEC records as different from
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 10]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   standard NSEC records.  Because of this, standard DNSSEC
+   implementations, if they were to validate Opt-In style responses,
+   would reject all Opt-In insecure delegations within a zone as
+   invalid.  However, by only signing with private algorithms, standard
+   DNSSEC implementations will treat Opt-In responses as unsigned.
+
+   It should be noted that all elements in the resolution path between
+   (and including) the validator and the authoritative name server must
+   be aware of the Opt-In experiment and implement the Opt-In semantics
+   for successful validation to be possible.  In particular, this
+   includes any caching middleboxes between the validator and
+   authoritative name server.
+
+8.  Security Considerations
+
+   Opt-In allows for unsigned names, in the form of delegations to
+   unsigned subzones, to exist within an otherwise signed zone.  All
+   unsigned names are, by definition, insecure, and their validity or
+   existence cannot by cryptographically proven.
+
+   In general:
+
+   o  Records with unsigned names (whether existing or not) suffer from
+      the same vulnerabilities as records in an unsigned zone.  These
+      vulnerabilities are described in more detail in [12] (note in
+      particular sections 2.3, "Name Games" and 2.6, "Authenticated
+      Denial").
+   o  Records with signed names have the same security whether or not
+      Opt-In is used.
+
+   Note that with or without Opt-In, an insecure delegation may have its
+   contents undetectably altered by an attacker.  Because of this, the
+   primary difference in security that Opt-In introduces is the loss of
+   the ability to prove the existence or nonexistence of an insecure
+   delegation within the span of an Opt-In NSEC record.
+
+   In particular, this means that a malicious entity may be able to
+   insert or delete records with unsigned names.  These records are
+   normally NS records, but this also includes signed wildcard
+   expansions (while the wildcard record itself is signed, its expanded
+   name is an unsigned name).
+
+   For example, if a resolver received the following response from the
+   example zone above:
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 11]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
+
+         RCODE=NOERROR
+
+         Answer Section:
+
+         Authority Section:
+         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
+         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
+                                        RRSIG DNSKEY
+         EXAMPLE.                RRSIG  NSEC ...
+
+         Additional Section:
+
+
+   The resolver would have no choice but to believe that the referral to
+   NS.FORGED. is valid.  If a wildcard existed that would have been
+   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+   have undetectably removed it and replaced it with the forged
+   delegation.
+
+   Note that being able to add a delegation is functionally equivalent
+   to being able to add any record type: an attacker merely has to forge
+   a delegation to nameserver under his/her control and place whatever
+   records needed at the subzone apex.
+
+   While in particular cases, this issue may not present a significant
+   security problem, in general it should not be lightly dismissed.
+   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+   In particular, zone signing tools SHOULD NOT default to Opt-In, and
+   MAY choose to not support Opt-In at all.
+
+9.  IANA Considerations
+
+   None.
+
+10.  Acknowledgments
+
+   The contributions, suggestions and remarks of the following persons
+   (in alphabetic order) to this draft are acknowledged:
+
+      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
+      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
+      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
+      Wellington.
+
+11.  References
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 12]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+11.1  Normative References
+
+   [1]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+        Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [6]  Blacka, D., "DNSSEC Experiments",
+        draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
+        July 2005.
+
+11.2  Informative References
+
+   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+   [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
+         RFC 2137, April 1997.
+
+   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
+         Status", RFC 3090, March 2001.
+
+   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+         December 2001.
+
+   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 13]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Drienerlolaan 5
+   7522 NB  Enschede
+   NL
+
+   Email: roy.arends@telin.nl
+
+
+   Mark Kosters
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: markk@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+   David Blacka
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+Appendix A.  Implementing Opt-In using "Views"
+
+   In many cases, it may be convenient to implement an Opt-In zone by
+   combining two separately maintained "views" of a zone at request
+   time.  In this context, "view" refers to a particular version of a
+   zone, not to any specific DNS implementation feature.
+
+   In this scenario, one view is the secure view, the other is the
+   insecure (or legacy) view.  The secure view consists of an entirely
+   signed zone using Opt-In tagged NSEC records.  The insecure view
+   contains no DNSSEC information.  It is helpful, although not
+   necessary, for the secure view to be a subset (minus DNSSEC records)
+   of the insecure view.
+
+   In addition, the only RRsets that may solely exist in the insecure
+   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 14]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   the zone apex NS RRset) MUST be signed and in the secure view.
+
+   These two views may be combined at request time to provide a virtual,
+   single Opt-In zone.  The following algorithm is used when responding
+   to each query:
+      V_A is the secure view as described above.
+      V_B is the insecure view as described above.
+      R_A is a response generated from V_A, following RFC 2535bis.
+      R_B is a response generated from V_B, following DNS resolution as
+      per RFC 1035 [1].
+      R_C is the response generated by combining R_A with R_B, as
+      described below.
+      A query is DNSSEC-aware if it either has the DO bit [11] turned
+      on, or is for a DNSSEC-specific record type.
+
+
+
+   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
+       generate and return R_B, otherwise
+   2.  Generate R_A.
+   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
+   4.  Generate R_B and combine it with R_A to form R_C:
+          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
+          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
+          record, if R_B's RCODE = NOERROR.
+   5.  Return R_C.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 15]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
new file mode 100644
index 0000000..390420a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
@@ -0,0 +1,392 @@
+
+
+
+DNS Extensions working group                                   J. Jansen
+Internet-Draft                                                NLnet Labs
+Expires: July 5, 2006                                       January 2006
+
+
+     Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
+                 draft-ietf-dnsext-dnssec-rsasha256-00
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 5, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
+   resource records for use in the Domain Name System Security
+   Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 1]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
+   3.  RSA/SHA-256 RRSIG Resource Records  . . . . . . . . . . . . . . 3
+   4.  Implementation Considerations . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 2]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Addressing.  The DNS has been extended to use
+   digital signatures and cryptographic keys for the verification of
+   data.  RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
+   Security Extensions.
+
+   RFC4034 describes how to store DNSKEY and RRSIG resource records, and
+   specifies a list of cryptographic algorithms to use.  This document
+   extends that list with the algorithm RSA/SHA-256, and specifies how
+   to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
+   resource records.
+
+   Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
+   this document.
+
+
+2.  RSA/SHA-256 DNSKEY Resource Records
+
+   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
+   resource records (RRs) with the algorithm number [TBA].
+
+   The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
+   [6].
+
+
+3.  RSA/SHA-256 RRSIG Resource Records
+
+   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
+   records (RRs) with algorithm number [TBA].
+
+   The value of the signature field in the RRSIG RR is calculated as
+   follows.  The values for the fields that precede the signature data
+   are specified in RFC4034 [2].
+
+   hash = SHA-256(data)
+
+   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+   Where SHA-256 is the message digest algorithm as specified in FIPS
+   180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
+   corresponding hexadecimal value, "e" is the private exponent of the
+   signing RSA key, and "n" is the public modulus of the signing key.
+   The FF octet MUST be repeated the maximum number of times so that the
+   total length of the signature equals the length of the modulus of the
+   signer's public key ("n"). "data" is the data of the resource record
+   set that is signed, as specified in RFC4034 [2].
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 3]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+   The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
+   specified in PKCS 2.1 [4]:
+
+   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
+
+   This prefix should make the use of standard cryptographic libraries
+   easier.  These specifications are taken directly from PKCS #1 v2.1
+   section 9.2 [4].
+
+
+4.  Implementation Considerations
+
+   DNSSEC aware implementations MUST be able to support RRSIG resource
+   records with the RSA/SHA-256 algorithm.
+
+   If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
+   available for a certain rrset, with a secure path to their keys, the
+   validator SHOULD ignore the SHA-1 signature.  If the RSA/SHA-256
+   signature does not verify the data, and the RSA/SHA-1 does, the
+   validator SHOULD mark the data with the security status from the RSA/
+   SHA-256 signature.
+
+
+5.  IANA Considerations
+
+   IANA has not yet assigned an algorithm number for RSA/SHA-256.
+
+   The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
+   following entry:
+
+                                   Zone
+   Value Algorithm    [Mnemonic] Signing  References   Status
+   ----- ----------- ----------- -------- ----------  ---------
+   [tba] RSA/SHA-256 [RSASHA256]      y        [TBA]  MANDATORY
+
+
+6.  Security Considerations
+
+   Recently, weaknesses have been discovered in the SHA-1 hashing
+   algorithm.  It is therefore strongly encouraged to deploy SHA-256
+   where SHA-1 is used now, as soon as the DNS software supports it.
+
+   SHA-256 is considered sufficiently strong for the immediate future,
+   but predictions about future development in cryptography and
+   cryptanalysis are beyond the scope of this document.
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 4]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+7.  Acknowledgments
+
+   This document is a minor extension to RFC4034 [2].  Also, we try to
+   follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
+   [8] for consistency.  The authors of and contributors to these
+   documents are gratefully acknowledged for their hard work.
+
+   The following people provided additional feedback and text: Jaap
+   Akkerhuis, Miek Gieben and Wouter Wijngaards.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
+        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
+        RFC 3447, February 2003.
+
+   [5]  National Institute of Standards and Technology, "Secure Hash
+        Standard", FIPS PUB 180-2, August 2002.
+
+   [6]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+        System (DNS)", RFC 3110, May 2001.
+
+8.2.  Informative References
+
+   [7]  Schneier, B., "Applied Cryptography Second Edition: protocols,
+        algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
+        11709-9, 1996.
+
+   [8]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+        Resource Records (RRs)", Work in Progress Feb 2006.
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 5]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Author's Address
+
+   Jelte Jansen
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098VA
+   NL
+
+   Email: jelte@NLnetLabs.nl
+   URI:   http://www.nlnetlabs.nl/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 6]
+
+Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Jansen                    Expires July 5, 2006                  [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
new file mode 100644
index 0000000..dd8cbf0
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
@@ -0,0 +1,839 @@
+
+DNS Extensions Working Group                                   R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: August 25, 2005                                         P. Koch
+                                                                DENIC eG
+                                                             J. Schlyter
+                                                                  NIC-SE
+                                                       February 21, 2005
+
+
+                Evaluating DNSSEC Transition Mechanisms
+                 draft-ietf-dnsext-dnssec-trans-02.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 25, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document collects and summarizes different proposals for
+   alternative and additional strategies for authenticated denial in DNS
+   responses, evaluates these proposals and gives a recommendation for a
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 1]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   way forward.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . . .  3
+     2.1   Mechanisms With Need of Updating DNSSEC-bis  . . . . . . .  4
+       2.1.1   Dynamic NSEC Synthesis . . . . . . . . . . . . . . . .  4
+       2.1.2   Add Versioning/Subtyping to Current NSEC . . . . . . .  5
+       2.1.3   Type Bit Map NSEC Indicator  . . . . . . . . . . . . .  6
+       2.1.4   New Apex Type  . . . . . . . . . . . . . . . . . . . .  6
+       2.1.5   NSEC White Lies  . . . . . . . . . . . . . . . . . . .  7
+       2.1.6   NSEC Optional via DNSSKEY Flag . . . . . . . . . . . .  8
+       2.1.7   New Answer Pseudo RR Type  . . . . . . . . . . . . . .  9
+       2.1.8   SIG(0) Based Authenticated Denial  . . . . . . . . . .  9
+     2.2   Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
+       2.2.1   Partial Type-code and Signal Rollover  . . . . . . . . 10
+       2.2.2   A Complete Type-code and Signal Rollover . . . . . . . 11
+       2.2.3   Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
+   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
+   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
+     5.2   Informative References . . . . . . . . . . . . . . . . . . 13
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+       Intellectual Property and Copyright Statements . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 2]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+1.  Introduction
+
+   This report shall document the process of dealing with the NSEC
+   walking problem late in the Last Call for
+   [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
+   I-D.ietf-dnsext-dnssec-records].  It preserves some of the discussion
+   that took place in the DNSEXT WG during the first half of June 2004
+   as well as some additional ideas that came up subsequently.
+
+   This is an edited excerpt of the chairs' mail to the WG:
+      The working group consents on not including NSEC-alt in the
+      DNSSEC-bis documents.  The working group considers to take up
+      "prevention of zone enumeration" as a work item.
+      There may be multiple mechanisms to allow for co-existence with
+      DNSSEC-bis.  The chairs allow the working group a little over a
+      week (up to June 12, 2004) to come to consensus on a possible
+      modification to the document to enable gentle rollover.  If that
+      consensus cannot be reached the DNSSEC-bis documents will go out
+      as-is.
+
+   To ease the process of getting consensus, a summary of the proposed
+   solutions and analysis of the pros and cons were written during the
+   weekend.
+
+   This summary includes:
+
+      An inventory of the proposed mechanisms to make a transition to
+      future work on authenticated denial of existence.
+      List the known Pros and Cons, possibly provide new arguments, and
+      possible security considerations of these mechanisms.
+      Provide a recommendation on a way forward that is least disruptive
+      to the DNSSEC-bis specifications as they stand and keep an open
+      path to other methods for authenticated denial of existence.
+
+   The descriptions of the proposals in this document are coarse and do
+   not cover every detail necessary for implementation.  In any case,
+   documentation and further study is needed before implementaion and/or
+   deployment, including those which seem to be solely operational in
+   nature.
+
+2.  Transition Mechanisms
+
+   In the light of recent discussions and past proposals, we have found
+   several ways to allow for transition to future expansion of
+   authenticated denial.  We tried to illuminate the paths and pitfalls
+   in these ways forward.  Some proposals lead to a versioning of
+   DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
+   proposals are 'clean' but may cause delay, while again others may be
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 3]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   plain hacks.
+
+   Some paths do not introduce versioning, and might require the current
+   DNSSEC-bis documents to be fully updated to allow for extensions to
+   authenticated denial mechanisms.  Other paths introduce versioning
+   and do not (or minimally) require DNSSEC-bis documents to be updated,
+   allowing DNSSEC-bis to be deployed, while future versions can be
+   drafted independent from or partially depending on DNSSEC-bis.
+
+2.1  Mechanisms With Need of Updating DNSSEC-bis
+
+   Mechanisms in this category demand updates to the DNSSEC-bis document
+   set.
+
+2.1.1  Dynamic NSEC Synthesis
+
+   This proposal assumes that NSEC RRs and the authenticating RRSIG will
+   be generated dynamically to just cover the (non existent) query name.
+   The owner name is (the) one preceding the name queried for, the Next
+   Owner Name Field has the value of the Query Name Field + 1 (first
+   successor in canonical ordering).  A separate key (the normal ZSK or
+   a separate ZSK per authoritative server) would be used for RRSIGs on
+   NSEC RRs.  This is a defense against enumeration, though it has the
+   presumption of online signing.
+
+2.1.1.1  Coexistence and Migration
+
+   There is no change in interpretation other then that the next owner
+   name might or might not exist.
+
+2.1.1.2  Limitations
+
+   This introduces an unbalanced cost between query and response
+   generation due to dynamic generation of signatures.
+
+2.1.1.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents might need to be updated to indicate
+   that the next owner name might not be an existing name in the zone.
+   This is not a real change to the spec since implementers have been
+   warned not to synthesize with previously cached NSEC records.  A
+   specific bit to identify the dynamic signature generating key might
+   be useful as well, to prevent it from being used to fake positive
+   data.
+
+2.1.1.4  Cons
+
+   Unbalanced cost is a ground for DDoS.  Though this protects against
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 4]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   enumeration, it is not really a path for versioning.
+
+2.1.1.5  Pros
+
+   Hardly any amendments to DNSSEC-bis.
+
+2.1.2  Add Versioning/Subtyping to Current NSEC
+
+   This proposal introduces versioning for the NSEC RR type (a.k.a.
+   subtyping) by adding a (one octet) version field to the NSEC RDATA.
+   Version number 0 is assigned to the current (DNSSEC-bis) meaning,
+   making this an 'Must Be Zero' (MBZ) for the to be published docset.
+
+2.1.2.1  Coexistence and Migration
+
+   Since the versioning is done inside the NSEC RR, different versions
+   may coexist.  However, depending on future methods, that may or may
+   not be useful inside a single zone.  Resolvers cannot ask for
+   specific NSEC versions but may be able to indicate version support by
+   means of a to be defined EDNS option bit.
+
+2.1.2.2  Limitations
+
+   There are no technical limitations, though it will cause delay to
+   allow testing of the (currently unknown) new NSEC interpretation.
+
+   Since the versioning and signaling is done inside the NSEC RR, future
+   methods will likely be restricted to a single RR type authenticated
+   denial (as opposed to e.g.  NSEC-alt, which currently proposes three
+   RR types).
+
+2.1.2.3  Amendments to DNSSEC-bis
+
+   Full Update of the current DNSSEC-bis documents to provide for new
+   fields in NSEC, while specifying behavior in case of unknown field
+   values.
+
+2.1.2.4  Cons
+
+   Though this is a clean and clear path without versioning DNSSEC, it
+   takes some time to design, gain consensus, update the current
+   dnssec-bis document, test and implement a new authenticated denial
+   record.
+
+2.1.2.5  Pros
+
+   Does not introduce an iteration to DNSSEC while providing a clear and
+   clean migration strategy.
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 5]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.3  Type Bit Map NSEC Indicator
+
+   Bits in the type-bit-map are reused or allocated to signify the
+   interpretation of NSEC.
+
+   This proposal assumes that future extensions make use of the existing
+   NSEC RDATA syntax, while it may need to change the interpretation of
+   the RDATA or introduce an alternative denial mechanism, invoked by
+   the specific type-bit-map-bits.
+
+2.1.3.1  Coexistence and migration
+
+   Old and new NSEC meaning could coexist, depending how the signaling
+   would be defined.  The bits for NXT, NSEC, RRSIG or other outdated RR
+   types are available  as well as those covering meta/query types or
+   types to be specifically allocated.
+
+2.1.3.2  Limitations
+
+   This mechanism uses an NSEC field that was not designed for that
+   purpose.  Similar methods were discussed during the Opt-In discussion
+   and the Silly-State discussion.
+
+2.1.3.3  Amendments to DNSSEC-bis
+
+   The specific type-bit-map-bits must be allocated and they need to be
+   specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
+   interpretation.  Also, behaviour of the resolver and validator must
+   be documented in case unknown values are encountered for the MBZ
+   field.  Currently the protocol document specifies that the validator
+   MUST ignore the setting of the NSEC and the RRSIG bits, while other
+   bits are only used for the specific purpose of the type-bit-map field
+
+2.1.3.4  Cons
+
+   The type-bit-map was not designed for this purpose.  It is a
+   straightforward hack.  Text in protocol section 5.4 was put in
+   specially to defend against this usage.
+
+2.1.3.5  Pros
+
+   No change needed to the on-the-wire protocol as specified in the
+   current docset.
+
+2.1.4  New Apex Type
+
+   This introduces a new Apex type (parallel to the zone's SOA)
+   indicating the DNSSEC version (or authenticated denial) used in or
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 6]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   for this zone.
+
+2.1.4.1  Coexistence and Migration
+
+   Depending on the design of this new RR type multiple denial
+   mechanisms may coexist in a zone.  Old validators will not understand
+   and thus ignore the new type, so interpretation of the new NSEC
+   scheme may fail, negative responses may appear 'bogus'.
+
+2.1.4.2  Limitations
+
+   A record of this kind is likely to carry additional
+   feature/versioning indications unrelated to the current question of
+   authenticated denial.
+
+2.1.4.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents need to be updated to indicate that
+   the absence of this type indicates dnssec-bis, and that the (mere)
+   presence of this type indicated unknown versions.
+
+2.1.4.4  Cons
+
+   The only other 'zone' or 'apex' record is the SOA record.  Though
+   this proposal is not new, it is yet unknown how it might fulfill
+   authenticated denial extensions.  This new RR type would only provide
+   for a generalized signaling mechanism, not the new authenticated
+   denial scheme.  Since it is likely to be general in nature, due to
+   this generality consensus is not to be reached soon.
+
+2.1.4.5  Pros
+
+   This approach would allow for a lot of other per zone information to
+   be transported or signaled to both (slave) servers and resolvers.
+
+2.1.5  NSEC White Lies
+
+   This proposal disables one part of NSEC (the pointer part) by means
+   of a special target (root, apex, owner, ...), leaving intact only the
+   ability to authenticate denial of existence of RR sets, not denial of
+   existence of domain names (NXDOMAIN).  It may be necessary to have
+   one working NSEC to prove the absence of a wildcard.
+
+2.1.5.1  Coexistence and Migration
+
+   The NSEC target can be specified per RR, so standard NSEC and 'white
+   lie' NSEC can coexist in a zone.  There is no need for migration
+   because no versioning is introduced or intended.
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 7]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.5.2  Limitations
+
+   This proposal breaks the protocol and is applicable to certain types
+   of zones only (no wildcard, no deep names, delegation only).  Most of
+   the burden is put on the resolver side and operational consequences
+   are yet to be studied.
+
+2.1.5.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents need to be updated to indicate that
+   the NXDOMAIN responses may be insecure.
+
+2.1.5.4  Cons
+
+   Strictly speaking this breaks the protocol and doesn't fully fulfill
+   the requirements for authenticated denial of existence.  Security
+   implications need to be carefully documented: search path problems
+   (forged denial of existence may lead to wrong expansion of non-FQDNs
+   [RFC1535]) and replay attacks to deny existence of records.
+
+2.1.5.5  Pros
+
+   Hardly any amendments to DNSSEC-bis.  Operational "trick" that is
+   available anyway.
+
+2.1.6  NSEC Optional via DNSSKEY Flag
+
+   A new DNSKEY may be defined to declare NSEC optional per zone.
+
+2.1.6.1  Coexistence and Migration
+
+   Current resolvers/validators will not understand the Flag bit and
+   will have to treat negative responses as bogus.  Otherwise, no
+   migration path is needed since NSEC is simply turned off.
+
+2.1.6.2  Limitations
+
+   NSEC can only be made completely optional at the cost of being unable
+   to prove unsecure delegations (absence of a DS RR [RFC3658]).  A next
+   to this approach would just disable authenticated denial for
+   non-existence of nodes.
+
+2.1.6.3  Amendments to DNSSEC-bis
+
+   New DNSKEY Flag to be defined.  Resolver/Validator behaviour needs to
+   be specified in the light of absence of authenticated denial.
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 8]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.6.4  Cons
+
+   Doesn't fully meet requirements.  Operational consequences to be
+   studied.
+
+2.1.6.5  Pros
+
+   Official version of the "trick" presented in (8).  Operational
+   problems can be addressed during future work on validators.
+
+2.1.7  New Answer Pseudo RR Type
+
+   A new pseudo RR type may be defined that will be dynamically created
+   (and signed) by the responding authoritative server.  The RR in the
+   response will cover the QNAME, QCLASS and QTYPE and will authenticate
+   both denial of existence of name (NXDOMAIN) or RRset.
+
+2.1.7.1  Coexistence and Migration
+
+   Current resolvers/validators will not understand the pseudo RR and
+   will thus not be able to process negative responses so testified.  A
+   signaling or solicitation method would have to be specified.
+
+2.1.7.2  Limitations
+
+   This method can only be used with online keys and online signing
+   capacity.
+
+2.1.7.3  Amendments to DNSSEC-bis
+
+   Signaling method needs to be defined.
+
+2.1.7.4  Cons
+
+   Keys have to be held and processed online with all security
+   implications.  An additional flag for those keys identifying them as
+   online or negative answer only keys should be considered.
+
+2.1.7.5  Pros
+
+   Expands DNSSEC authentication to the RCODE.
+
+2.1.8  SIG(0) Based Authenticated Denial
+
+
+2.1.8.1  Coexistence and Migration
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 9]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.8.2  Limitations
+
+
+2.1.8.3  Amendments to DNSSEC-bis
+
+
+2.1.8.4  Cons
+
+
+2.1.8.5  Pros
+
+
+2.2  Mechanisms Without Need of Updating DNSSEC-bis
+
+2.2.1  Partial Type-code and Signal Rollover
+
+   Carefully crafted type code/signal rollover to define a new
+   authenticated denial space that extends/replaces DNSSEC-bis
+   authenticated denial space.  This particular path is illuminated by
+   Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
+   posted to <namedroppers@ops.ietf.org> 2004-06-02.
+
+2.2.1.1  Coexistence and Migration
+
+   To protect the current resolver for future versions, a new DNSSEC-OK
+   bit must be allocated to make clear it does or does not understand
+   the future version.  Also, a new DS type needs to be allocated to
+   allow differentiation between a current signed delegation and a
+   'future' signed delegation.  Also, current NSEC needs to be rolled
+   into a new authenticated denial type.
+
+2.2.1.2  Limitations
+
+   None.
+
+2.2.1.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.1.4  Cons
+
+   It is cumbersome to carefully craft an TCR that 'just fits'.  The
+   DNSSEC-bis protocol has many 'borderline' cases that needs special
+   consideration.  It might be easier to do a full TCR, since a few of
+   the types and signals need upgrading anyway.
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 10]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.2.1.5  Pros
+
+   Graceful adoption of future versions of NSEC, while there are no
+   amendments to DNSSEC-bis.
+
+2.2.2  A Complete Type-code and Signal Rollover
+
+   A new DNSSEC space is defined which can exist independent of current
+   DNSSEC-bis space.
+
+   This proposal assumes that all current DNSSEC type-codes
+   (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
+   future versions of DNSSEC.  Any future version of DNSSEC has its own
+   types to allow for keys, signatures, authenticated denial, etcetera.
+
+2.2.2.1  Coexistence and Migration
+
+   Both spaces can co-exist.  They can be made completely orthogonal.
+
+2.2.2.2  Limitations
+
+   None.
+
+2.2.2.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.2.4  Cons
+
+   With this path we abandon the current DNSSEC-bis.  Though it is easy
+   to role specific well-known and well-tested parts into the re-write,
+   once deployment has started this path is very expensive for
+   implementers, registries, registrars and registrants as well as
+   resolvers/users.  A TCR is not to be expected to occur frequently, so
+   while a next generation authenticated denial may be enabled by a TCR,
+   it is likely that that TCR will only be agreed upon if it serves a
+   whole basket of changes or additions.  A quick introduction of
+   NSEC-ng should not be expected from this path.
+
+2.2.2.5  Pros
+
+   No amendments/changes to current DNSSEC-bis docset needed.  It is
+   always there as last resort.
+
+2.2.3  Unknown Algorithm in RRSIG
+
+   This proposal assumes that future extensions make use of the existing
+   NSEC RDATA syntax, while it may need to change the interpretation of
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 11]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   the RDATA or introduce an alternative denial mechanism, invoked by
+   the specific unknown signing algorithm.  The different interpretation
+   would be signaled by use of different signature algorithms in the
+   RRSIG records covering the NSEC RRs.
+
+   When an entire zone is signed with a single unknown algorithm, it
+   will cause implementations that follow current dnssec-bis documents
+   to treat individual RRsets as unsigned.
+
+2.2.3.1  Coexistence and migration
+
+   Old and new NSEC RDATA interpretation or known and unknown Signatures
+   can NOT coexist in a zone since signatures cover complete (NSEC)
+   RRSets.
+
+2.2.3.2  Limitations
+
+   Validating resolvers agnostic of new interpretation will treat the
+   NSEC RRset as "not signed".  This affects wildcard and non-existence
+   proof, as well as proof for (un)secured delegations.  Also, all
+   positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
+   insecure/bogus to an old validator.
+
+   The algorithm version space is split for each future version of
+   DNSSEC.  Violation of the 'modular components' concept.  We use the
+   'validator' to protect the 'resolver' from unknown interpretations.
+
+2.2.3.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.3.4  Cons
+
+   The algorithm field was not designed for this purpose.  This is a
+   straightforward hack.
+
+2.2.3.5  Pros
+
+   No amendments/changes to current DNSSEC-bis docset needed.
+
+3.  Recommendation
+
+   The authors recommend that the working group commits to and starts
+   work on a partial TCR, allowing graceful transition towards a future
+   version of NSEC.  Meanwhile, to accomodate the need for an
+   immediately, temporary, solution against zone-traversal, we recommend
+   On-Demand NSEC synthesis.
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 12]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   This approach does not require any mandatory changes to DNSSEC-bis,
+   does not violate the protocol and fulfills the requirements.  As a
+   side effect, it moves the cost of implementation and deployment to
+   the users (zone owners) of this mechanism.
+
+4.  Acknowledgements
+
+   The authors would like to thank Sam Weiler and Mark Andrews for their
+   input and constructive comments.
+
+5.  References
+
+5.1  Normative References
+
+   [I-D.ietf-dnsext-dnssec-intro]
+              Arends, R., Austein, R., Massey, D., Larson, M. and S.
+              Rose, "DNS Security Introduction and Requirements",
+              Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
+              2004.
+
+   [I-D.ietf-dnsext-dnssec-protocol]
+              Arends, R., "Protocol Modifications for the DNS Security
+              Extensions",
+              Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
+              October 2004.
+
+   [I-D.ietf-dnsext-dnssec-records]
+              Arends, R., "Resource Records for the DNS Security
+              Extensions",
+              Internet-Draft draft-ietf-dnsext-dnssec-records-11,
+              October 2004.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
+              SIG(0)s)", RFC 2931, September 2000.
+
+5.2  Informative References
+
+   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
+              With Widely Deployed DNS Software", RFC 1535, October
+              1993.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 13]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+              RFC 2535, March 1999.
+
+   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+              June 1999.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   Enschede  7523 XC
+   The Netherlands
+
+   Phone: +31 53 4850485
+   Email: roy.arends@telin.nl
+
+
+   Peter Koch
+   DENIC eG
+   Wiesenh"uttenplatz 26
+   Frankfurt  60329
+   Germany
+
+   Phone: +49 69 27235 0
+   Email: pk@DENIC.DE
+
+
+   Jakob Schlyter
+   NIC-SE
+   Box 5774
+   Stockholm  SE-114 87
+   Sweden
+
+   Email: jakob@nic.se
+   URI:   http://www.nic.se/
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 14]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 15]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
new file mode 100644
index 0000000..2460cb6
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
@@ -0,0 +1,504 @@
+
+
+
+Network Working Group                                        W. Hardaker
+Internet-Draft                                                    Sparta
+Expires: August 25, 2006                               February 21, 2006
+
+
+ Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
+                   draft-ietf-dnsext-ds-sha256-05.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 25, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document specifies how to use the SHA-256 digest type in DNS
+   Delegation Signer (DS) Resource Records (RRs).  DS records, when
+   stored in a parent zone, point to key signing DNSKEY key(s) in a
+   child zone.
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 1]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Implementing the SHA-256 algorithm for DS record support  . . . 3
+     2.1.  DS record field values  . . . . . . . . . . . . . . . . . . 3
+     2.2.  DS Record with SHA-256 Wire Format  . . . . . . . . . . . . 3
+     2.3.  Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
+   3.  Implementation Requirements . . . . . . . . . . . . . . . . . . 4
+   4.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+     6.1.  Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
+     6.2.  SHA-1 vs SHA-256 Considerations for DS Records  . . . . . . 6
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 2]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+1.  Introduction
+
+   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
+   zones to distribute a cryptographic digest of a child's Key Signing
+   Key (KSK) DNSKEY RR.  The DS RRset is signed by at least one of the
+   parent zone's private zone data signing keys for each algorithm in
+   use by the parent.  Each signature is published in an RRSIG resource
+   record, owned by the same domain as the DS RRset and with a type
+   covered of DS.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+2.  Implementing the SHA-256 algorithm for DS record support
+
+   This document specifies that the digest type code [XXX: To be
+   assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
+   [SHA256CODE] for use within DS records.  The results of the digest
+   algorithm MUST NOT be truncated and the entire 32 byte digest result
+   is to be published in the DS record.
+
+2.1.  DS record field values
+
+   Using the SHA-256 digest algorithm within a DS record will make use
+   of the following DS-record fields:
+
+   Digest type: [XXX: To be assigned by IANA; likely 2]
+
+   Digest: A SHA-256 bit digest value calculated by using the following
+      formula ("|" denotes concatenation).  The resulting value is not
+      truncated and the entire 32 byte result is to used in the
+      resulting DS record and related calculations.
+
+        digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
+
+      where DNSKEY RDATA is defined by [RFC4034] as:
+
+        DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
+
+   The Key Tag field and Algorithm fields remain unchanged by this
+   document and are specified in the [RFC4034] specification.
+
+2.2.  DS Record with SHA-256 Wire Format
+
+   The resulting on-the-wire format for the resulting DS record will be
+   [XXX: IANA assignment should replace the 2 below]:
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 3]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Key Tag             |  Algorithm    | DigestType=2  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /            Digest  (length for SHA-256 is 32 bytes)           /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+2.3.  Example DS Record Using SHA-256
+
+   The following is an example DNSKEY and matching DS record.  This
+   DNSKEY record comes from the example DNSKEY/DS records found in
+   section 5.4 of [RFC4034].
+
+   The DNSKEY record:
+
+   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+                                                fwJr1AYtsmx3TGkJaNXVbfi/
+                                                2pHm822aJ5iI9BMzNXxeYCmZ
+                                                DRD99WYwYqUSdjMmmAphXdvx
+                                                egXd/M5+X7OrzKBaMbCVdFLU
+                                                Uh6DhweJBjEVv5f2wwjM9Xzc
+                                                nOf+EPbtG9DMBmADjFDc2w/r
+                                                ljwvFw==
+                                                ) ;  key id = 60485
+
+   The resulting DS record covering the above DNSKEY record using a SHA-
+   256 digest: [RFC Editor: please replace XXX with the assigned digest
+   type (likely 2):]
+
+   dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
+                                                CEB1E3E0614B93C4F9E99B83
+                                                83F6A1E4469DA50A )
+
+
+3.  Implementation Requirements
+
+   Implementations MUST support the use of the SHA-256 algorithm in DS
+   RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
+   digests if DS RRs with SHA-256 digests are present in the DS RRset.
+
+
+4.  Deployment Considerations
+
+   If a validator does not support the SHA-256 digest type and no other
+   DS RR exists in a zone's DS RRset with a supported digest type, then
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 4]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+   the validator has no supported authentication path leading from the
+   parent to the child.  The resolver should treat this case as it would
+   the case of an authenticated NSEC RRset proving that no DS RRset
+   exists, as described in [RFC4035], section 5.2.
+
+   Because zone administrators can not control the deployment speed of
+   support for SHA-256 in validators that may be referencing any of
+   their zones, zone operators should consider deploying both SHA-1 and
+   SHA-256 based DS records.  This should be done for every DNSKEY for
+   which DS records are being generated.  Whether to make use of both
+   digest types and for how long is a policy decision that extends
+   beyond the scope of this document.
+
+
+5.  IANA Considerations
+
+   Only one IANA action is required by this document:
+
+   The Digest Type to be used for supporting SHA-256 within DS records
+   needs to be assigned by IANA.  This document requests that the Digest
+   Type value of 2 be assigned to the SHA-256 digest algorithm.
+
+   At the time of this writing, the current digest types assigned for
+   use in DS records are as follows:
+
+      VALUE     Digest Type          Status
+        0       Reserved                -
+        1       SHA-1                MANDATORY
+        2       SHA-256              MANDATORY
+      3-255    Unassigned               -
+
+
+6.  Security Considerations
+
+6.1.  Potential Digest Type Downgrade Attacks
+
+   A downgrade attack from a stronger digest type to a weaker one is
+   possible if all of the following are true:
+
+   o  A zone includes multiple DS records for a given child's DNSKEY,
+      each of which use a different digest type.
+
+   o  A validator accepts a weaker digest even if a stronger one is
+      present but invalid.
+
+   For example, if the following conditions are all true:
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 5]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+   o  Both SHA-1 and SHA-256 based digests are published in DS records
+      within a parent zone for a given child zone's DNSKEY.
+
+   o  The DS record with the SHA-1 digest matches the digest computed
+      using the child zone's DNSKEY.
+
+   o  The DS record with the SHA-256 digest fails to match the digest
+      computed using the child zone's DNSKEY.
+
+   Then if the validator accepts the above situation as secure then this
+   can be used as a downgrade attack since the stronger SHA-256 digest
+   is ignored.
+
+6.2.  SHA-1 vs SHA-256 Considerations for DS Records
+
+   Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
+   implementations allow for it.  SHA-256 is widely believed to be more
+   resilient to attack than SHA-1, and confidence in SHA-1's strength is
+   being eroded by recently-announced attacks.  Regardless of whether or
+   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
+   time of this writing) that SHA-256 is the better choice for use in DS
+   records.
+
+   At the time of this publication, the SHA-256 digest algorithm is
+   considered sufficiently strong for the immediate future.  It is also
+   considered sufficient for use in DNSSEC DS RRs for the immediate
+   future.  However, future published attacks may weaken the usability
+   of this algorithm within the DS RRs.  It is beyond the scope of this
+   document to speculate extensively on the cryptographic strength of
+   the SHA-256 digest algorithm.
+
+   Likewise, it is also beyond the scope of this document to specify
+   whether or for how long SHA-1 based DS records should be
+   simultaneously published alongside SHA-256 based DS records.
+
+
+7.  Acknowledgments
+
+   This document is a minor extension to the existing DNSSEC documents
+   and those authors are gratefully appreciated for the hard work that
+   went into the base documents.
+
+   The following people contributed to portions of this document in some
+   fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
+   Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
+   Weiler.
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 6]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [SHA256]   National Institute of Standards and Technology, "Secure
+              Hash Algorithm. NIST FIPS 180-2", August 2002.
+
+8.2.  Informative References
+
+   [SHA256CODE]
+              Eastlake, D., "US Secure Hash Algorithms (SHA)",
+              June 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 7]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Author's Address
+
+   Wes Hardaker
+   Sparta
+   P.O. Box 382
+   Davis, CA  95617
+   US
+
+   Email: hardaker@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 8]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 9]
+
diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
new file mode 100644
index 0000000..2cdcdb1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
@@ -0,0 +1,928 @@
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+Expires: January 2006                                          July 2005
+
+
+
+                     Elliptic Curve KEYs in the DNS
+                     -------- ----- ---- -- --- ---
+                   <draft-ietf-dnsext-ecc-key-07.txt>
+
+                         Richard C. Schroeppel
+                          Donald Eastlake 3rd
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   This draft is intended to be become a Proposed Standard RFC.
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS mailing list <namedroppers@ops.ietf.org>.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   The standard method for storing elliptic curve cryptographic keys and
+   signatures in the Domain Name System is specified.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 1]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+Acknowledgement
+
+   The assistance of Hilarie K. Orman in the production of this document
+   is greatfully acknowledged.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Acknowledgement............................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. Elliptic Curve Data in Resource Records.................3
+      3. The Elliptic Curve Equation.............................9
+      4. How do I Compute Q, G, and Y?..........................10
+      5. Elliptic Curve SIG Resource Records....................11
+      6. Performance Considerations.............................13
+      7. Security Considerations................................13
+      8. IANA Considerations....................................13
+      Copyright and Disclaimer..................................14
+
+      Informational References..................................15
+      Normative Refrences.......................................15
+
+      Author's Addresses........................................16
+      Expiration and File Name..................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 2]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. The DNS has been extended to include digital
+   signatures and cryptographic keys as described in [RFC 4033, 4034,
+   4035].
+
+   This document describes how to store elliptic curve cryptographic
+   (ECC) keys and signatures in the DNS so they can be used for a
+   variety of security purposes.  Familiarity with ECC cryptography is
+   assumed [Menezes].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+2. Elliptic Curve Data in Resource Records
+
+   Elliptic curve public keys are stored in the DNS within the RDATA
+   portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
+   structure shown below.
+
+   The research world continues to work on the issue of which is the
+   best elliptic curve system, which finite field to use, and how to
+   best represent elements in the field.  So, representations are
+   defined for every type of finite field, and every type of elliptic
+   curve.  The reader should be aware that there is a unique finite
+   field with a particular number of elements, but many possible
+   representations of that field and its elements.  If two different
+   representations of a field are given, they are interconvertible with
+   a tedious but practical precomputation, followed by a fast
+   computation for each field element to be converted.  It is perfectly
+   reasonable for an algorithm to work internally with one field
+   representation, and convert to and from a different external
+   representation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 3]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |S M -FMT- A B Z|
+       +-+-+-+-+-+-+-+-+
+       |       LP      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        P (length determined from LP)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LF      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        F (length determined from LF)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEG               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEGH              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEGI              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             DEGJ              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             TRDV              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |S|     LH      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        H (length determined from LH)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |S|     LK      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        K (length determined from LK)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LQ      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        Q (length determined from LQ)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LA      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        A (length determined from LA)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |             ALTA              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LB      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        B (length determined from LB)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LC      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        C (length determined from LC)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LG      |
+
+
+R. Schroeppel, et al                                            [Page 4]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        G (length determined from LG)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       LY      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                        Y (length determined from LY)       .../
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   SMFMTABZ is a flags octet as follows:
+
+        S = 1 indicates that the remaining 7 bits of the octet selects
+           one of 128 predefined choices of finite field, element
+           representation, elliptic curve, and signature parameters.
+           MFMTABZ are omitted, as are all parameters from LP through G.
+           LY and Y are retained.
+
+        If S = 0, the remaining parameters are as in the picture and
+           described below.
+
+        M determines the type of field underlying the elliptic curve.
+
+        M = 0 if the field is a GF[2^N] field;
+
+        M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
+
+        FMT is a three bit field describing the format of the field
+           representation.
+
+        FMT = 0  for a (mod P) field.
+            > 0  for an extension field, either GF[2^D] or GF[P^D].
+                The degree D of the extension, and the field polynomial
+                must be specified.  The field polynomial is always monic
+                (leading coefficient 1.)
+
+        FMT = 1  The field polynomial is given explicitly; D is implied.
+
+        If FMT >=2, the degree D is given explicitly.
+
+           = 2  The field polynomial is implicit.
+           = 3  The field polynomial is a binomial.  P>2.
+           = 4  The field polynomial is a trinomial.
+           = 5  The field polynomial is the quotient of a trinomial by a
+                short polynomial.  P=2.
+           = 6  The field polynomial is a pentanomial.  P=2.
+
+        Flags A and B apply to the elliptic curve parameters.
+
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 5]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+        A = 1 When P>=5, the curve parameter A is negated.  If P=2, then
+              A=1 indicates that the A parameter is special.  See the
+              ALTA parameter below, following A.  The combination A=1,
+              P=3 is forbidden.
+
+        B = 1 When P>=5, the curve parameter B is negated.  If P=2 or 3,
+              then B=1 indicates an alternate elliptic curve equation is
+              used.  When P=2 and B=1, an additional curve parameter C
+              is present.
+
+        The Z bit SHOULD be set to zero on creation of an RR and MUST be
+           ignored when processing an RR (when S=0).
+
+   Most of the remaining parameters are present in some formats and
+   absent in others.  The presence or absence of a parameter is
+   determined entirely by the flags.  When a parameter occurs, it is in
+   the order defined by the picture.
+
+   Of the remaining parameters, PFHKQABCGY are variable length.  When
+   present, each is preceded by a one-octet length field as shown in the
+   diagram above.  The length field does not include itself.  The length
+   field may have values from 0 through 110.  The parameter length in
+   octets is determined by a conditional formula: If LL<=64, the
+   parameter length is LL.  If LL>64, the parameter length is 16 times
+   (LL-60).  In some cases, a parameter value of 0 is sensible, and MAY
+   be represented by an LL value of 0, with the data field omitted.  A
+   length value of 0 represents a parameter value of 0, not an absent
+   parameter.  (The data portion occupies 0 space.)  There is no
+   requirement that a parameter be represented in the minimum number of
+   octets; high-order 0 octets are allowed at the front end.  Parameters
+   are always right adjusted, in a field of length defined by LL.  The
+   octet-order is always most-significant first, least-significant last.
+   The parameters H and K may have an optional sign bit stored in the
+   unused high-order bit of their length fields.
+
+   LP defines the length of the prime P.  P must be an odd prime.  The
+   parameters LP,P are present if and only if the flag M=1.  If M=0, the
+   prime is 2.
+
+   LF,F define an explicit field polynomial.  This parameter pair is
+   present only when FMT = 1.  The length of a polynomial coefficient is
+   ceiling(log2 P) bits.  Coefficients are in the numerical range
+   [0,P-1].  The coefficients are packed into fixed-width fields, from
+   higher order to lower order.  All coefficients must be present,
+   including any 0s and also the leading coefficient (which is required
+   to be 1).  The coefficients are right justified into the octet string
+   of length specified by LF, with the low-order "constant" coefficient
+   at the right end.  As a concession to storage efficiency, the higher
+   order bits of the leading coefficient may be elided, discarding high-
+   order 0 octets and reducing LF.  The degree is calculated by
+
+
+R. Schroeppel, et al                                            [Page 6]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   determining the bit position of the left most 1-bit in the F data
+   (counting the right most bit as position 0), and dividing by
+   ceiling(log2 P).  The division must be exact, with no remainder.  In
+   this format, all of the other degree and field parameters are
+   omitted.  The next parameters will be LQ,Q.
+
+   If FMT>=2, the degree of the field extension is specified explicitly,
+   usually along with other parameters to define the field polynomial.
+
+   DEG is a two octet field that defines the degree of the field
+   extension.  The finite field will have P^DEG elements.  DEG is
+   present when FMT>=2.
+
+   When FMT=2, the field polynomial is specified implicitly.  No other
+   parameters are required to define the field; the next parameters
+   present will be the LQ,Q pair.  The implicit field poynomial is the
+   lexicographically smallest irreducible (mod P) polynomial of the
+   correct degree.  The ordering of polynomials is by highest-degree
+   coefficients first -- the leading coefficient 1 is most important,
+   and the constant term is least important.  Coefficients are ordered
+   by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ...  The first polynomial of
+   degree D is X^D (which is not irreducible).  The next is X^D+1, which
+   is sometimes irreducible, followed by X^D-1, which isn't.  Assuming
+   odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
+   X, X^D + X + 1, X^D + X - 1, etc.
+
+   When FMT=3, the field polynomial is a binomial, X^DEG + K.  P must be
+   odd.  The polynomial is determined by the degree and the low order
+   term K.  Of all the field parameters, only the LK,K parameters are
+   present.  The high-order bit of the LK octet stores on optional sign
+   for K; if the sign bit is present, the field polynomial is X^DEG - K.
+
+   When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
+   K.  When P=2, the H and K parameters are implicitly 1, and are
+   omitted from the representation.  Only DEG and DEGH are present; the
+   next parameters are LQ,Q.  When P>2, then LH,H and LK,K are
+   specified.  Either or both of LH, LK may contain a sign bit for its
+   parameter.
+
+   When FMT=5, then P=2 (only).  The field polynomial is the exact
+   quotient of a trinomial divided by a small polynomial, the trinomial
+   divisor.  The small polynomial is right-adjusted in the two octet
+   field TRDV.  DEG specifies the degree of the field.  The degree of
+   TRDV is calculated from the position of the high-order 1 bit.  The
+   trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1.  If
+   DEGH is 0, the middle term is omitted from the trinomial.  The
+   quotient must be exact, with no remainder.
+
+   When FMT=6, then P=2 (only).  The field polynomial is a pentanomial,
+   with the degrees of the middle terms given by the three 2-octet
+
+
+R. Schroeppel, et al                                            [Page 7]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   values DEGH, DEGI, DEGJ.  The polynomial is X^DEG + X^DEGH + X^DEGI +
+   X^DEGJ + 1.  The values must satisfy the inequality DEG > DEGH > DEGI
+   > DEGJ > 0.
+
+        DEGH, DEGI, DEGJ  are two-octet fields that define the degree of
+           a term in a field polynomial.   DEGH is present when FMT = 4,
+           5, or 6.  DEGI and DEGJ are present only when FMT = 6.
+
+        TRDV is a two-octet right-adjusted binary polynomial of degree <
+           16.  It is present only for FMT=5.
+
+        LH and H define the H parameter, present only when FMT=4 and P
+           is odd.  The high bit of LH is an optional sign bit for H.
+
+        LK and K define the K parameter, present when FMT = 3 or 4, and
+           P is odd.  The high bit of LK is an optional sign bit for K.
+
+   The remaining parameters are concerned with the elliptic curve and
+   the signature algorithm.
+
+        LQ defines the length of the prime Q.  Q is a prime > 2^159.
+
+   In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
+   member of the pair is an element from the finite field defined
+   earlier.  The length field defines a long octet string.  Field
+   elements are represented as (mod P) polynomials of degree < DEG, with
+   DEG or fewer coefficients.  The coefficients are stored from left to
+   right, higher degree to lower, with the constant term last.  The
+   coefficients are represented as integers in the range [0,P-1].  Each
+   coefficient is allocated an area of ceiling(log2 P) bits.  The field
+   representation is right-justified; the "constant term" of the field
+   element ends at the right most bit.  The coefficients are fitted
+   adjacently without regard for octet boundaries.  (Example: if P=5,
+   three bits are used for each coefficient.  If the field is GF[5^75],
+   then 225 bits are required for the coefficients, and as many as 29
+   octets may be needed in the data area.  Fewer octets may be used if
+   some high-order coefficients are 0.)  If a flag requires a field
+   element to be negated, each non-zero coefficient K is replaced with
+   P-K.  To save space, 0 bits may be removed from the left end of the
+   element representation, and the length field reduced appropriately.
+   This would normally only happen with A,B,C, because the designer
+   chose curve parameters with some high-order 0 coefficients or bits.
+
+   If the finite field is simply (mod P), then the field elements are
+   simply numbers (mod P), in the usual right-justified notation.  If
+   the finite field is GF[2^D], the field elements are the usual right-
+   justified polynomial basis representation.
+
+
+
+
+
+R. Schroeppel, et al                                            [Page 8]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+        LA,A is the first parameter of the elliptic curve equation.
+           When P>=5, the flag A = 1 indicates A should be negated (mod
+           P).  When P=2 (indicated by the flag M=0), the flag A = 1
+           indicates that the parameter pair LA,A is replaced by the two
+           octet parameter ALTA.  In this case, the parameter A in the
+           curve equation is x^ALTA, where x is the field generator.
+           Parameter A often has the value 0, which may be indicated by
+           LA=0 (with no A data field), and sometimes A is 1, which may
+           be represented with LA=1 and a data field of 1, or by setting
+           the A flag and using an ALTA value of 0.
+
+        LB,B is the second parameter of the elliptic curve equation.
+           When P>=5, the flag B = 1 indicates B should be negated (mod
+           P).  When P=2 or 3, the flag B selects an alternate curve
+           equation.
+
+        LC,C is the third parameter of the elliptic curve equation,
+           present only when P=2 (indicated by flag M=0) and flag B=1.
+
+        LG,G defines a point on the curve, of order Q.  The W-coordinate
+           of the curve point is given explicitly; the Z-coordinate is
+           implicit.
+
+        LY,Y is the user's public signing key, another curve point of
+           order Q.  The W-coordinate is given explicitly; the Z-
+           coordinate is implicit.  The LY,Y parameter pair is always
+           present.
+
+
+
+3. The Elliptic Curve Equation
+
+   (The coordinates of an elliptic curve point are named W,Z instead of
+   the more usual X,Y to avoid confusion with the Y parameter of the
+   signing key.)
+
+   The elliptic curve equation is determined by the flag octet, together
+   with information about the prime P.  The primes 2 and 3 are special;
+   all other primes are treated identically.
+
+   If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+   + A*W + B.  Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
+   If A and/or B is negative (i.e., in the range from P/2 to P), and
+   P>=5, space may be saved by putting the sign bit(s) in the A and B
+   bits of the flags octet, and the magnitude(s) in the parameter
+   fields.
+
+   If M=1 and P=3, the B flag has a different meaning: it specifies an
+   alternate curve equation, Z^2 = W^3 + A*W^2 + B.  The middle term of
+   the right-hand-side is different.  When P=3, this equation is more
+
+
+R. Schroeppel, et al                                            [Page 9]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   commonly used.
+
+   If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
+   A*W^2 + B.  Z,W,A,B are all elements of the field GF[2^N].  The A
+   parameter can often be 0 or 1, or be chosen as a single-1-bit value.
+   The flag B is used to select an alternate curve equation, Z^2 + C*Z =
+   W^3 + A*W + B.  This is the only time that the C parameter is used.
+
+
+
+4. How do I Compute Q, G, and Y?
+
+   The number of points on the curve is the number of solutions to the
+   curve equation, + 1 (for the "point at infinity").  The prime Q must
+   divide the number of points.  Usually the curve is chosen first, then
+   the number of points is determined with Schoof's algorithm.  This
+   number is factored, and if it has a large prime divisor, that number
+   is taken as Q.
+
+   G must be a point of order Q on the curve, satisfying the equation
+
+        Q * G  =  the point at infinity (on the elliptic curve)
+
+   G may be chosen by selecting a random [RFC 1750] curve point, and
+   multiplying it by (number-of-points-on-curve/Q).  G must not itself
+   be the "point at infinity"; in this astronomically unlikely event, a
+   new random curve point is recalculated.
+
+   G is specified by giving its W-coordinate.  The Z-coordinate is
+   calculated from the curve equation.  In general, there will be two
+   possible Z values.  The rule is to choose the "positive" value.
+
+   In the (mod P) case, the two possible Z values sum to P.  The smaller
+   value is less than P/2; it is used in subsequent calculations.  In
+   GF[P^D] fields, the highest-degree non-zero coefficient of the field
+   element Z is used; it is chosen to be less than P/2.
+
+   In the GF[2^N] case, the two possible Z values xor to W (or to the
+   parameter C with the alternate curve equation).  The numerically
+   smaller Z value (the one which does not contain the highest-order 1
+   bit of W (or C)) is used in subsequent calculations.
+
+   Y is specified by giving the W-coordinate of the user's public
+   signature key.  The Z-coordinate value is determined from the curve
+   equation.  As with G, there are two possible Z values; the same rule
+   is followed for choosing which Z to use.
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 10]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+   During the key generation process, a random [RFC 1750] number X must
+   be generated such that 1 <= X <= Q-1.  X is the private key and is
+   used in the final step of public key generation where Y is computed
+   as
+
+        Y = X * G (as points on the elliptic curve)
+
+   If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
+   in the (mod P) case, or the high-order non-zero coefficient of Z >
+   P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
+   GF[2^N] case), then X must be replaced with Q-X.  This will
+   correspond to the correct Z-coordinate.
+
+
+
+5. Elliptic Curve SIG Resource Records
+
+   The signature portion of an RR RDATA area when using the EC
+   algorithm, for example in the RRSIG and SIG [RFC records] RRs is
+   shown below.
+
+                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   R, (length determined from LQ)           .../
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   S, (length determined from LQ)           .../
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   R and S are integers (mod Q).  Their length is specified by the LQ
+   field of the corresponding KEY RR and can also be calculated from the
+   SIG RR's RDLENGTH. They are right justified, high-order-octet first.
+   The same conditional formula for calculating the length from LQ is
+   used as for all the other length fields above.
+
+   The data signed is determined as specified in [RFC 2535].  Then the
+   following steps are taken where Q, P, G, and Y are as specified in
+   the public key [Schneier]:
+
+     hash = SHA-1 ( data )
+
+     Generate random [RFC 4086] K such that 0 < K < Q.  (Never sign two
+          different messages with the same K.  K should be chosen from a
+          very large space: If an opponent learns a K value for a single
+          signature, the user's signing key is compromised, and a forger
+          can sign arbitrary messages. There is no harm in signing the
+          same message multiple times with the same key or different
+          keys.)
+
+     R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
+
+
+R. Schroeppel, et al                                           [Page 11]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+          as an integer, and reduced (mod Q).  (R must not be 0.  In
+          this astronomically unlikely event, generate a new random K
+          and recalculate R.)
+
+     S = ( K^(-1) * (hash + X*R) ) mod Q.
+
+     S must not be 0.  In this astronomically unlikely event, generate a
+          new random K and recalculate R and S.
+
+     If S > Q/2, set S = Q - S.
+
+     The pair (R,S) is the signature.
+
+     Another party verifies the signature as follows:
+
+          Check that 0 < R < Q and 0 < S < Q/2.  If not, it can not be a
+               valid EC sigature.
+
+          hash = SHA-1 ( data )
+
+          Sinv = S^(-1) mod Q.
+
+          U1 = (hash * Sinv) mod Q.
+
+          U2 = (R * Sinv) mod Q.
+
+          (U1 * G + U2 * Y) is computed on the elliptic curve.
+
+          V = (the W-coordinate of this point) interpreted as an integer
+               and reduced (mod Q).
+
+          The signature is valid if V = R.
+
+     The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
+     (R,Q-S) would be valid signatures for the same data.  Note that a
+     signature that is valid for hash(data) is also valid for
+     hash(data)+Q or hash(data)-Q, if these happen to fall in the range
+     [0,2^160-1].  It's believed to be computationally infeasible to
+     find data that hashes to an assigned value, so this is only a
+     cosmetic blemish.  The blemish can be eliminated by using Q >
+     2^160, at the cost of having slightly longer signatures, 42 octets
+     instead of 40.
+
+     We must specify how a field-element E ("the W-coordinate") is to be
+     interpreted as an integer.  The field-element E is regarded as a
+     radix-P integer, with the digits being the coefficients in the
+     polynomial basis representation of E.  The digits are in the ragne
+     [0,P-1].  In the two most common cases, this reduces to "the
+     obvious thing".  In the (mod P) case, E is simply a residue mod P,
+     and is taken as an integer in the range [0,P-1].  In the GF[2^D]
+
+
+R. Schroeppel, et al                                           [Page 12]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+     case, E is in the D-bit polynomial basis representation, and is
+     simply taken as an integer in the range [0,(2^D)-1].  For other
+     fields GF[P^D], it's necessary to do some radix conversion
+     arithmetic.
+
+
+
+  6. Performance Considerations
+
+     Elliptic curve signatures use smaller moduli or field sizes than
+     RSA and DSA.  Creation of a curve is slow, but not done very often.
+     Key generation is faster than RSA or DSA.
+
+     DNS implementations have been optimized for small transfers,
+     typically less than 512 octets including DNS overhead. Larger
+     transfers will perform correctly and and extensions have been
+     standardized to make larger transfers more efficient [RFC 2671].
+     However, it is still advisable at this time to make reasonable
+     efforts to minimize the size of RR sets stored within the DNS
+     consistent with adequate security.
+
+
+
+  7. Security Considerations
+
+     Keys retrieved from the DNS should not be trusted unless (1) they
+     have been securely obtained from a secure resolver or independently
+     verified by the user and (2) this secure resolver and secure
+     obtainment or independent verification conform to security policies
+     acceptable to the user.  As with all cryptographic algorithms,
+     evaluating the necessary strength of the key is essential and
+     dependent on local policy.
+
+     Some specific key generation considerations are given in the body
+     of this document.
+
+
+
+  8. IANA Considerations
+
+     The key and signature data structures defined herein correspond to
+     the value 4 in the Algorithm number field of the IANA registry
+
+     Assignment of meaning to the remaining ECC data flag bits or to
+     values of ECC fields outside the ranges for which meaning in
+     defined in this document requires an IETF consensus as defined in
+     [RFC 2434].
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 13]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+  Copyright and Disclaimer
+
+     Copyright (C) The Internet Society 2005.  This document is subject
+     to the rights, licenses and restrictions contained in BCP 78, and
+     except as set forth therein, the authors retain all their rights.
+
+
+     This document and the information contained herein are provided on
+     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
+     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
+     THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
+     ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+     PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 14]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+  Informational References
+
+     [RFC 1034] - P. Mockapetris, "Domain names - concepts and
+     facilities", 11/01/1987.
+
+     [RFC 1035] - P. Mockapetris, "Domain names - implementation and
+     specification", 11/01/1987.
+
+     [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
+     August 1999.
+
+     [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
+     S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
+     March 2005.
+
+     [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
+     S. Rose, "Protocol Modifications for the DNS Security Extensions",
+     RFC 4035, March 2005.
+
+     [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+     "Randomness Requirements for Security", BCP 106, RFC 4086, June
+     2005.
+
+     [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
+     Algorithms, and Source Code in C", 1996, John Wiley and Sons
+
+     [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
+     Cryptosystems", 1993 Kluwer.
+
+     [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
+     Curves", 1986, Springer Graduate Texts in mathematics #106.
+
+
+
+  Normative Refrences
+
+     [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
+     Requirement Levels", March 1997.
+
+     [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
+     IANA Considerations Section in RFCs", October 1998.
+
+     [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
+     S. Rose, "Resource Records for the DNS Security Extensions", RFC
+     4034, March 2005.
+
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 15]
+
+
+INTERNET-DRAFT                                       ECC Keys in the DNS
+
+
+  Author's Addresses
+
+     Rich Schroeppel
+     500 S. Maple Drive
+     Woodland Hills, UT 84653 USA
+
+     Telephone:   +1-505-844-9079(w)
+     Email:       rschroe@sandia.gov
+
+
+     Donald E. Eastlake 3rd
+     Motorola Laboratories
+     155 Beaver Street
+     Milford, MA 01757 USA
+
+     Telephone:   +1 508-786-7554 (w)
+     EMail:       Donald.Eastlake@motorola.com
+
+
+
+  Expiration and File Name
+
+     This draft expires in January 2006.
+
+     Its file name is draft-ietf-dnsext-ecc-key-07.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al                                           [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
new file mode 100644
index 0000000..160afc3
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
@@ -0,0 +1,334 @@
+DNS Extensions Working Group                                 J. Schlyter
+Internet-Draft                                              May 19, 2005
+Expires: November 20, 2005
+
+
+                     RFC 3597 Interoperability Report
+                   draft-ietf-dnsext-interop3597-02.txt
+
+Status of this Memo
+
+    By submitting this Internet-Draft, each author represents that any
+    applicable patent or other IPR claims of which he or she is aware
+    have been or will be disclosed, and any of which he or she becomes
+    aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+    Internet-Drafts are working documents of the Internet Engineering
+    Task Force (IETF), its areas, and its working groups.  Note that
+    other groups may also distribute working documents as Internet-
+    Drafts.
+
+    Internet-Drafts are draft documents valid for a maximum of six months
+    and may be updated, replaced, or obsoleted by other documents at any
+    time.  It is inappropriate to use Internet-Drafts as reference
+    material or to cite them other than as "work in progress."
+
+    The list of current Internet-Drafts can be accessed at
+    http://www.ietf.org/ietf/1id-abstracts.txt.
+
+    The list of Internet-Draft Shadow Directories can be accessed at
+    http://www.ietf.org/shadow.html.
+
+    This Internet-Draft will expire on November 20, 2005.
+
+Copyright Notice
+
+    Copyright (C) The Internet Society (2005).
+
+Abstract
+
+    This memo documents the result from the RFC 3597 (Handling of Unknown
+    DNS Resource Record Types) interoperability testing.
+
+
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 1]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+Table of Contents
+
+    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+    2.  Implementations  . . . . . . . . . . . . . . . . . . . . . . .  3
+    3.  Tests  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+      3.1   Authoritative Primary Name Server  . . . . . . . . . . . .  3
+      3.2   Authoritative Secondary Name Server  . . . . . . . . . . .  3
+      3.3   Full Recursive Resolver  . . . . . . . . . . . . . . . . .  4
+      3.4   Stub Resolver  . . . . . . . . . . . . . . . . . . . . . .  4
+      3.5   DNSSEC Signer  . . . . . . . . . . . . . . . . . . . . . .  4
+    4.  Problems found . . . . . . . . . . . . . . . . . . . . . . . .  4
+    5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+    6.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
+        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
+    A.  Test zone data . . . . . . . . . . . . . . . . . . . . . . . .  5
+        Intellectual Property and Copyright Statements . . . . . . . .  6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 2]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+1.  Introduction
+
+    This memo documents the result from the RFC 3597 (Handling of Unknown
+    DNS Resource Record Types) interoperability testing.  The test was
+    performed during June and July 2004 by request of the IETF DNS
+    Extensions Working Group.
+
+2.  Implementations
+
+    The following is a list, in alphabetic order, of implementations
+    tested for compliance with RFC 3597:
+
+       DNSJava 1.6.4
+       ISC BIND 8.4.5
+       ISC BIND 9.3.0
+       NSD 2.1.1
+       Net::DNS 0.47 patchlevel 1
+       Nominum ANS 2.2.1.0.d
+
+    These implementations covers the following functions (number of
+    implementations tested for each function in paranthesis):
+
+       Authoritative Name Servers (4)
+       Full Recursive Resolver (2)
+       Stub Resolver (4)
+       DNSSEC Zone Signers (2)
+
+    All listed implementations are genetically different.
+
+3.  Tests
+
+    The following tests was been performed to validate compliance with
+    RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
+    and 5 ("Text Representation").
+
+3.1  Authoritative Primary Name Server
+
+    The test zone data (Appendix A) was loaded into the name server
+    implementation and the server was queried for the loaded information.
+
+3.2  Authoritative Secondary Name Server
+
+    The test zone data (Appendix A) was transferred using AXFR from
+    another name server implementation and the server was queried for the
+    transferred information.
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 3]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+3.3  Full Recursive Resolver
+
+    A recursive resolver was queried for resource records from a domain
+    with the test zone data (Appendix A).
+
+3.4  Stub Resolver
+
+    A stub resolver was used to query resource records from a domain with
+    the test zone data (Appendix A).
+
+3.5  DNSSEC Signer
+
+    A DNSSEC signer was used to sign a zone with test zone data
+    (Appendix A).
+
+4.  Problems found
+
+    Two implementations had problems with text presentation of zero
+    length RDATA.
+
+    One implementation had problems with text presentation of RR type
+    code and classes >= 4096.
+
+    Bug reports were filed for problems found.
+
+5.  Summary
+
+    Unknown type codes works in the tested authoritative servers,
+    recursive resolvers and stub clients.
+
+    No changes are needed to advance RFC 3597 to draft standard.
+
+6.  Normative References
+
+    [1]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+         Types", RFC 3597, September 2003.
+
+
+Author's Address
+
+    Jakob Schlyter
+
+    Email: jakob@rfc.se
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 4]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+Appendix A.  Test zone data
+
+    ; A-record encoded as TYPE1
+    a  TYPE1  \# 4 7f000001
+    a  TYPE1  192.0.2.1
+    a  A      \# 4 7f000002
+
+    ; draft-ietf-secsh-dns-05.txt
+    sshfp  TYPE44  \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
+
+    ; bogus test record (from RFC 3597)
+    type731    TYPE731    \# 6 abcd (
+                               ef 01 23 45 )
+
+    ; zero length RDATA (from RFC 3597)
+    type62347  TYPE62347  \# 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 5]
+
+Internet-Draft      RFC 3597 Interoperability Report            May 2005
+
+
+Intellectual Property Statement
+
+    The IETF takes no position regarding the validity or scope of any
+    Intellectual Property Rights or other rights that might be claimed to
+    pertain to the implementation or use of the technology described in
+    this document or the extent to which any license under such rights
+    might or might not be available; nor does it represent that it has
+    made any independent effort to identify any such rights.  Information
+    on the procedures with respect to rights in RFC documents can be
+    found in BCP 78 and BCP 79.
+
+    Copies of IPR disclosures made to the IETF Secretariat and any
+    assurances of licenses to be made available, or the result of an
+    attempt made to obtain a general license or permission for the use of
+    such proprietary rights by implementers or users of this
+    specification can be obtained from the IETF on-line IPR repository at
+    http://www.ietf.org/ipr.
+
+    The IETF invites any interested party to bring to its attention any
+    copyrights, patents or patent applications, or other proprietary
+    rights that may cover technology that may be required to implement
+    this standard.  Please address the information to the IETF at
+    ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+    This document and the information contained herein are provided on an
+    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+    Copyright (C) The Internet Society (2005).  This document is subject
+    to the rights, licenses and restrictions contained in BCP 78, and
+    except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+    Funding for the RFC Editor function is currently provided by the
+    Internet Society.
+
+
+
+
+Schlyter                Expires November 20, 2005               [Page 6]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
new file mode 100644
index 0000000..6bffb70
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
@@ -0,0 +1,560 @@
+
+DNS Extensions                                                O. Kolkman
+Internet-Draft                                                  RIPE NCC
+Expires: June 17, 2004                                       J. Schlyter
+
+                                                                E. Lewis
+                                                                    ARIN
+                                                       December 18, 2003
+
+
+                   DNSKEY RR Secure Entry Point Flag
+              draft-ietf-dnsext-keyrr-key-signing-flag-12
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that other
+   groups may also distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on June 17, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+   With the Delegation Signer (DS) resource record the concept of a
+   public key acting as a secure entry point has been introduced. During
+   exchanges of public keys with the parent there is a need to
+   differentiate secure entry point keys from other public keys in the
+   DNSKEY resource record (RR) set.  A flag bit in the DNSKEY RR is
+   defined to indicate that DNSKEY is to be used as a secure entry
+   point. The flag bit is intended to assist in operational procedures
+   to correctly generate DS resource records, or to indicate what
+   DNSKEYs are intended for static configuration. The flag bit is not to
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 1]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   be used in the DNS verification protocol. This document updates RFC
+   2535 and RFC 3445.
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2. The Secure Entry Point (SEP) Flag  . . . . . . . . . . . . . . . 4
+   3. DNSSEC Protocol Changes  . . . . . . . . . . . . . . . . . . . . 5
+   4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
+   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
+   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
+   7. Internationalization Considerations  . . . . . . . . . . . . . . 6
+   8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
+      Informative References . . . . . . . . . . . . . . . . . . . . . 7
+      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
+      Intellectual Property and Copyright Statements . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 2]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+1. Introduction
+
+   "All keys are equal but some keys are more equal than others" [6]
+
+   With the definition of the Delegation Signer Resource Record (DS RR)
+   [5] it has become important to differentiate between the keys in the
+   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
+   other keys in the DNSKEY RR set.  We refer to these public keys as
+   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
+   DS RR or is distributed to resolvers that use the key as the root of
+   a trusted subtree[3].
+
+   In early deployment tests, the use of two (kinds of) key pairs for
+   each zone has been prevalent.  For one kind of key pair the private
+   key is used to sign just the zone's DNSKEY resource record (RR) set.
+   Its public key is intended to be referenced by a DS RR at the parent
+   or configured statically in a resolver.  The private key of the other
+   kind of key pair is used to sign the rest of the zone's data sets.
+   The former key pair is called a key-signing key (KSK) and the latter
+   is called a zone-signing key (ZSK).  In practice there have been
+   usually one of each kind of key pair, but there will be multiples of
+   each at times.
+
+   It should be noted that division of keys pairs into KSK's and ZSK's
+   is not mandatory in any definition of DNSSEC, not even with the
+   introduction of the DS RR.  But, in testing, this distinction has
+   been helpful when designing key roll over (key super-cession)
+   schemes.  Given that the distinction has proven helpful, the labels
+   KSK and ZSK have begun to stick.
+
+   There is a need to differentiate the public keys for the key pairs
+   that are used for key signing from keys that are not used key signing
+   (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
+   be sent for generating DS RRs, which DNSKEYs are to be distributed to
+   resolvers, and which keys are fed to the signer application at the
+   appropriate time.
+
+   In other words, the SEP bit provides an in-band method to communicate
+   a DNSKEY RR's intended use to third parties. As an example we present
+   3 use cases in which the bit is useful:
+
+      The parent is a registry, the parent and the child use secured DNS
+      queries and responses, with a preexisting trust-relation, or plain
+      DNS over a secured channel to exchange the child's  DNSKEY RR
+      sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
+      the SEP bit can be used to isolate the DNSKEYs for which a DS RR
+      needs to be created.
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 3]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+      An administrator has configured a DNSKEY as root for a trusted
+      subtree into security aware resolver. Using a special purpose tool
+      that queries for the KEY RRs from that domain's apex, the
+      administrator will be able to notice the roll over of the trusted
+      anchor by a change of the subset of KEY RRs with the DS flag set.
+
+      A signer might use the SEP bit on the public key to determine
+      which private key to use to exclusively sign the DNSKEY RRset and
+      which private key to use to sign the other RRsets in the zone.
+
+   As demonstrated in the above examples it is important to be able to
+   differentiate the SEP keys from the other keys in a DNSKEY RR set in
+   the flow between signer and (parental) key-collector and in the flow
+   between the signer and the resolver configuration. The SEP flag is to
+   be of no interest to the flow between the verifier and the
+   authoritative data store.
+
+   The reason for the term "SEP" is a result of the observation that the
+   distinction between KSK and ZSK key pairs is made by the signer, a
+   key pair could be used as both a KSK and a ZSK at the same time. To
+   be clear, the term SEP was coined to lessen the confusion caused by
+   the overlap. ( Once this label was applied, it had the side effect of
+   removing the temptation to have both a KSK flag bit and a ZSK flag
+   bit.)
+
+   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+   interpreted as described in RFC2119 [1].
+
+2. The Secure Entry Point (SEP) Flag
+
+
+                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              flags          |S|   protocol    |   algorithm   |
+      |                             |E|               |               |
+      |                             |P|               |               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                        public key                             /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                DNSKEY RR Format
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 4]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   This document assigns the 15'th bit in the flags field as the secure
+   entry point (SEP) bit.  If the the bit is set to 1 the key is
+   intended to be used as secure entry point key.  One SHOULD NOT assign
+   special meaning to the key if the bit is set to 0.  Operators can
+   recognize the secure entry point key by the even or odd-ness of the
+   decimal representation of the flag field.
+
+3. DNSSEC Protocol Changes
+
+   The bit MUST NOT be used during the resolving and verification
+   process. The SEP flag is only used to provide a hint about the
+   different administrative properties of the key and therefore the use
+   of the SEP flag does not change the DNS resolution protocol or the
+   resolution process.
+
+4. Operational Guidelines
+
+   The SEP bit is set by the key-pair-generator and MAY be used by the
+   zone signer to decide whether the public part of the key pair is to
+   be prepared for input to a DS RR generation function.  The SEP bit is
+   recommended to be set (to 1) whenever the public key of the key pair
+   will be distributed to the parent zone to build the authentication
+   chain or if the public key is to be distributed for static
+   configuration in verifiers.
+
+   When a key pair is created, the operator needs to indicate whether
+   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
+   the data that is used to compute the 'key tag field' in the SIG RR,
+   changing the SEP bit will change the identity of the key within DNS.
+   In other words, once a key is used to generate signatures, the
+   setting of the SEP bit is to remain constant. If not, a verifier will
+   not be able to find the relevant KEY RR.
+
+   When signing a zone, it is intended that the key(s) with the SEP bit
+   set (if such keys exist) are used to sign the KEY RR set of the zone.
+   The same key can be used to sign the rest of the zone data too.  It
+   is conceivable that not all keys with a SEP bit set will sign the
+   DNSKEY RR set, such keys might be pending retirement or not yet in
+   use.
+
+   When verifying a RR set, the SEP bit is not intended to play a role.
+   How the key is used by the verifier is not intended to be a
+   consideration at key creation time.
+
+   Although the SEP flag provides a hint on which public key is to be
+   used as trusted root, administrators can choose to ignore the fact
+   that a DNSKEY has its SEP bit set or not when configuring a trusted
+   root for their resolvers.
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 5]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   Using the SEP flag a key roll over can be automated. The parent can
+   use an existing trust relation to verify DNSKEY RR sets in which a
+   new DNSKEY RR with the SEP flag appears.
+
+5. Security Considerations
+
+   As stated in Section 3 the flag is not to be used in the resolution
+   protocol or to determine the security status of a key. The flag is to
+   be used for administrative purposes only.
+
+   No trust in a key should be inferred from this flag - trust MUST be
+   inferred from an existing chain of trust or an out-of-band exchange.
+
+   Since this flag might be used for automating public key exchanges, we
+   think the following consideration is in place.
+
+   Automated mechanisms for roll over of the DS RR might be vulnerable
+   to a class of replay attacks.  This might happen after a public key
+   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
+   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
+   RR set with the existing trust relation and creates the new DS RR
+   from the DNSKEY RR that the current DS RR is not pointing to.  This
+   key exchange might be replayed. Parents are encouraged to implement a
+   replay defense. A simple defense can be based on a registry of keys
+   that have been used to generate DS RRs during the most recent roll
+   over. These same considerations apply to entities that configure keys
+   in resolvers.
+
+6. IANA Considerations
+
+   The flag bits  in the DNSKEY RR are assigned by IETF consensus and
+   registered in the DNSKEY Flags registry (created by [4]). This
+   document assigns the 15th bit in the DNSKEY RR as the Secure Entry
+   Point (SEP) bit.
+
+7. Internationalization Considerations
+
+   Although SEP is a popular acronym in many different languages, there
+   are no internationalization considerations.
+
+8. Acknowledgments
+
+   The ideas documented in this document are inspired by communications
+   we had with numerous people and ideas published by other folk. Among
+   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
+   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
+   have contributed ideas and provided feedback.
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 6]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   This document saw the light during a workshop on DNSSEC operations
+   hosted by USC/ISI in August 2002.
+
+Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
+        Status", RFC 3090, March 2001.
+
+   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+        Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
+        in progress), October 2003.
+
+Informative References
+
+   [5]  Gudmundsson, O., "Delegation Signer Resource Record",
+        draft-ietf-dnsext-delegation-signer-15 (work in progress), June
+        2003.
+
+   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
+
+
+Authors' Addresses
+
+   Olaf M. Kolkman
+   RIPE NCC
+   Singel 256
+   Amsterdam  1016 AB
+   NL
+
+   Phone: +31 20 535 4444
+   EMail: olaf@ripe.net
+   URI:   http://www.ripe.net/
+
+
+   Jakob Schlyter
+   Karl Gustavsgatan 15
+   Goteborg  SE-411 25
+   Sweden
+
+   EMail: jakob@schlyter.se
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 7]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   Edward P. Lewis
+   ARIN
+   3635 Concorde Parkway Suite 200
+   Chantilly, VA  20151
+   US
+
+   Phone: +1 703 227 9854
+   EMail: edlewis@arin.net
+   URI:   http://www.arin.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 8]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works. However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 9]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                 [Page 10]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-mdns-43.txt b/doc/draft/draft-ietf-dnsext-mdns-43.txt
new file mode 100644
index 0000000..5de6e85
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-mdns-43.txt
@@ -0,0 +1,1740 @@
+
+
+
+
+
+
+DNSEXT Working Group                                       Bernard Aboba
+INTERNET-DRAFT                                               Dave Thaler
+Category: Standards Track                                   Levon Esibov
+<draft-ietf-dnsext-mdns-43.txt>                    Microsoft Corporation
+29 August 2005
+
+              Linklocal Multicast Name Resolution (LLMNR)
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2005.
+
+Abstract
+
+   The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
+   name resolution in scenarios in which conventional DNS name
+   resolution is not possible.  LLMNR supports all current and future
+   DNS formats, types and classes, while operating on a separate port
+   from DNS, and with a distinct resolver cache.  Since LLMNR only
+   operates on the local link, it cannot be considered a substitute for
+   DNS.
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 1]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+Table of Contents
+
+1.     Introduction ..........................................    3
+   1.1       Requirements ....................................    4
+   1.2       Terminology .....................................    4
+2.     Name Resolution Using LLMNR ...........................    4
+   2.1       LLMNR Packet Format .............................    6
+   2.2       Sender Behavior .................................    9
+   2.3       Responder Behavior ..............................   10
+   2.4       Unicast Queries and Responses ...................   12
+   2.5       Off-link Detection ..............................   13
+   2.6       Responder Responsibilities ......................   13
+   2.7       Retransmission and Jitter .......................   14
+   2.8       DNS TTL .........................................   15
+   2.9       Use of the Authority and Additional Sections ....   15
+3.     Usage model ...........................................   16
+   3.1       LLMNR Configuration .............................   17
+4.     Conflict Resolution ...................................   18
+   4.1       Uniqueness Verification .........................   19
+   4.2       Conflict Detection and Defense ..................   20
+   4.3       Considerations for Multiple Interfaces ..........   21
+   4.4       API issues ......................................   22
+5.     Security Considerations ...............................   22
+   5.1       Denial of Service ...............................   23
+   5.2       Spoofing ...............,........................   23
+   5.3       Authentication ..................................   24
+   5.4       Cache and Port Separation .......................   25
+6.     IANA considerations ...................................   25
+7.     Constants .............................................   25
+8.     References ............................................   25
+   8.1       Normative References ............................   25
+   8.2       Informative References ..........................   26
+Acknowledgments ..............................................   27
+Authors' Addresses ...........................................   28
+Intellectual Property Statement ..............................   28
+Disclaimer of Validity .......................................   29
+Copyright Statement ..........................................   29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 2]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+1.  Introduction
+
+   This document discusses Link Local Multicast Name Resolution (LLMNR),
+   which is based on the DNS packet format and supports all current and
+   future DNS formats, types and classes.  LLMNR operates on a separate
+   port from the Domain Name System (DNS), with a distinct resolver
+   cache.
+
+   The goal of LLMNR is to enable name resolution in scenarios in which
+   conventional DNS name resolution is not possible.  Usage scenarios
+   (discussed in more detail in Section 3.1) include situations in which
+   hosts are not configured with the address of a DNS server; where the
+   DNS server is unavailable or unreachable; where there is no DNS
+   server authoritative for the name of a host, or where the
+   authoritative DNS server does not have the desired RRs, as described
+   in Section 2.
+
+   Since LLMNR only operates on the local link, it cannot be considered
+   a substitute for DNS.  Link-scope multicast addresses are used to
+   prevent propagation of LLMNR traffic across routers, potentially
+   flooding the network.  LLMNR queries can also be sent to a unicast
+   address, as described in Section 2.4.
+
+   Propagation of LLMNR packets on the local link is considered
+   sufficient to enable name resolution in small networks.  In such
+   networks, if a network has a gateway, then typically the network is
+   able to provide DNS server configuration.  Configuration issues are
+   discussed in Section 3.1.
+
+   In the future, it may be desirable to consider use of multicast name
+   resolution with multicast scopes beyond the link-scope.  This could
+   occur if LLMNR deployment is successful, the need arises for
+   multicast name resolution beyond the link-scope, or multicast routing
+   becomes ubiquitous.  For example, expanded support for multicast name
+   resolution might be required for mobile ad-hoc networks.
+
+   Once we have experience in LLMNR deployment in terms of
+   administrative issues, usability and impact on the network, it will
+   be possible to reevaluate which multicast scopes are appropriate for
+   use with multicast name resolution.  IPv4 administratively scoped
+   multicast usage is specified in "Administratively Scoped IP
+   Multicast" [RFC2365].
+
+   Service discovery in general, as well as discovery of DNS servers
+   using LLMNR in particular, is outside of the scope of this document,
+   as is name resolution over non-multicast capable media.
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 3]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+1.1.  Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
+   and "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+1.2.  Terminology
+
+   This document assumes familiarity with DNS terminology defined in
+   [RFC1035].  Other terminology used in this document includes:
+
+Positively Resolved
+     Responses with RCODE set to zero are referred to in this document
+     as "positively resolved".
+
+Routable Address
+     An address other than a Link-Local address.  This includes globally
+     routable addresses, as well as private addresses.
+
+Reachable
+     An LLMNR responder considers one of its addresses reachable over a
+     link if it will respond to an ARP or Neighbor Discovery query for
+     that address received on that link.
+
+Responder
+     A host that listens to LLMNR queries, and responds to those for
+     which it is authoritative.
+
+Sender
+     A host that sends an LLMNR query.
+
+UNIQUE
+     There are some scenarios when multiple responders may respond to
+     the same query.  There are other scenarios when only one responder
+     may respond to a query.  Names for which only a single responder is
+     anticipated are referred to as UNIQUE.  Name uniqueness is
+     configured on the responder, and therefore uniqueness verification
+     is the responder's responsibility.
+
+2.  Name Resolution Using LLMNR
+
+   LLMNR is a peer-to-peer name resolution protocol that is not intended
+   as a replacement for DNS.  LLMNR queries are sent to and received on
+   port 5355.  The IPv4 link-scope multicast address a given responder
+   listens to, and to which a sender sends queries, is 224.0.0.252.  The
+   IPv6 link-scope multicast address a given responder listens to, and
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 4]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
+
+   Typically a host is configured as both an LLMNR sender and a
+   responder.  A host MAY be configured as a sender, but not a
+   responder.  However, a host configured as a responder MUST act as a
+   sender, if only to verify the uniqueness of names as described in
+   Section 4.  This document does not specify how names are chosen or
+   configured.  This may occur via any mechanism, including DHCPv4
+   [RFC2131] or DHCPv6 [RFC3315].
+
+   LLMNR usage MAY be configured manually or automatically on a per
+   interface basis.  By default, LLMNR responders SHOULD be enabled on
+   all interfaces, at all times.  Enabling LLMNR for use in situations
+   where a DNS server has been configured will result in a change in
+   default behavior without a simultaneous update to configuration
+   information.  Where this is considered undesirable, LLMNR SHOULD NOT
+   be enabled by default, so that hosts will neither listen on the link-
+   scope multicast address, nor will they send queries to that address.
+
+   By default, LLMNR queries MAY be sent only when one of the following
+   conditions are met:
+
+   [1] No manual or automatic DNS configuration has been performed.
+       If DNS server address(es) have been configured, then LLMNR
+       SHOULD NOT be used as the primary name resolution mechanism,
+       although it MAY be used as a secondary name resolution
+       mechanism.  A dual stack host SHOULD attempt to reach DNS
+       servers overall protocols on which DNS server address(es) are
+       configured, prior to sending LLMNR queries.  For dual stack
+       hosts configured with DNS server address(es) for one protocol
+       but not another, this inplies that DNS queries SHOULD be sent
+       over the protocol configured with a DNS server, prior to
+       sending LLMNR queries.
+
+   [2] All attempts to resolve the name via DNS on all interfaces
+       have failed after exhausting the searchlist.  This can occur
+       because DNS servers did not respond, or because they
+       responded to DNS queries with RCODE=3 (Authoritative Name
+       Error) or RCODE=0, and an empty answer section.  Where a
+       single resolver call generates DNS queries for A and AAAA RRs,
+       an implementation MAY choose not to send LLMNR queries if any
+       of the DNS queries is successful.  An LLMNR query SHOULD only
+       be sent for the originally requested name;  a searchlist
+       is not used to form additional LLMNR queries.
+
+   While these conditions are necessary for sending an LLMNR query, they
+   are not sufficient.  While an LLMNR sender MAY send a query for any
+   name, it also MAY impose additional conditions on sending LLMNR
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 5]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   queries.  For example, a sender configured with a DNS server MAY send
+   LLMNR queries only for unqualified names and for fully qualified
+   domain names within configured zones.
+
+   A typical sequence of events for LLMNR usage is as follows:
+
+   [a]  DNS servers are not configured or attempts to resolve the
+        name via DNS have failed, after exhausting the searchlist.
+        Also, the name to be queried satisfies the restrictions
+        imposed by the implementation.
+
+   [b]  An LLMNR sender sends an LLMNR query to the link-scope
+        multicast address(es), unless a unicast query is indicated,
+        as specified in Section 2.4.
+
+   [c]  A responder responds to this query only if it is authoritative
+        for the domain name in the query.  A responder responds to a
+        multicast query by sending a unicast UDP response to the sender.
+        Unicast queries are responded to as indicated in Section 2.4.
+
+   [d]  Upon reception of the response, the sender processes it.
+
+   The sections that follow provide further details on sender and
+   responder behavior.
+
+2.1.  LLMNR Packet Format
+
+   LLMNR is based on the DNS packet format defined in [RFC1035] Section
+   4 for both queries and responses.  LLMNR implementations SHOULD send
+   UDP queries and responses only as large as are known to be
+   permissible without causing fragmentation.  When in doubt a maximum
+   packet size of 512 octets SHOULD be used.  LLMNR implementations MUST
+   accept UDP queries and responses as large as the smaller of the link
+   MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
+   octets for the header, VLAN tag and CRC).
+
+2.1.1.  LLMNR Header Format
+
+   LLMNR queries and responses utilize the DNS header format defined in
+   [RFC1035] with exceptions noted below:
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 6]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+                                   1  1  1  1  1  1
+     0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                      ID                       |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |QR|   Opcode  | C|TC| T| Z| Z| Z| Z|   RCODE   |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    QDCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    ANCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    NSCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   |                    ARCOUNT                    |
+   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+ID   A 16 bit identifier assigned by the program that generates any kind
+     of query.  This identifier is copied from the query to the response
+     and can be used by the sender to match responses to outstanding
+     queries. The ID field in a query SHOULD be set to a pseudo-random
+     value.  For advice on generation of pseudo-random values, please
+     consult [RFC1750].
+
+QR   Query/Response.  A one bit field, which if set indicates that the
+     message is an LLMNR response; if clear then the message is an LLMNR
+     query.
+
+OPCODE
+     A four bit field that specifies the kind of query in this message.
+     This value is set by the originator of a query and copied into the
+     response.  This specification defines the behavior of standard
+     queries and responses (opcode value of zero).  Future
+     specifications may define the use of other opcodes with LLMNR.
+     LLMNR senders and responders MUST support standard queries (opcode
+     value of zero).  LLMNR queries with unsupported OPCODE values MUST
+     be silently discarded by responders.
+
+C    Conflict.  When set within a request, the 'C'onflict bit indicates
+     that a sender has received multiple LLMNR responses to this query.
+     In an LLMNR response, if the name is considered UNIQUE, then the
+     'C' bit is clear, otherwise it is set.  LLMNR senders do not
+     retransmit queries with the 'C' bit set.  Responders MUST NOT
+     respond to LLMNR queries with the 'C' bit set, but may start the
+     uniqueness verification process, as described in Section 4.2.
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 7]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+TC   TrunCation - specifies that this message was truncated due to
+     length greater than that permitted on the transmission channel.
+     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
+     by an LLMNR responder.  If the TC bit is set in an LLMNR response,
+     then the sender SHOULD discard the response and resend the LLMNR
+     query over TCP using the unicast address of the responder as the
+     destination address.  See  [RFC2181] and Section 2.4 of this
+     specification for further discussion of the TC bit.
+
+T    Tentative.  The 'T'entative bit is set in a response if the
+     responder is authoritative for the name, but has not yet verified
+     the uniqueness of the name.  A responder MUST ignore the 'T' bit in
+     a query, if set.  A response with the 'T' bit set is silently
+     discarded by the sender, except if it is a uniqueness query, in
+     which case a conflict has been detected and a responder MUST
+     resolve the conflict as described in Section 4.1.
+
+Z    Reserved for future use.  Implementations of this specification
+     MUST set these bits to zero in both queries and responses.  If
+     these bits are set in a LLMNR query or response, implementations of
+     this specification MUST ignore them.  Since reserved bits could
+     conceivably be used for different purposes than in DNS,
+     implementors are advised not to enable processing of these bits in
+     an LLMNR implementation starting from a DNS code base.
+
+RCODE
+     Response code -- this 4 bit field is set as part of LLMNR
+     responses.  In an LLMNR query, the sender MUST set RCODE to zero;
+     the responder ignores the RCODE and assumes it to be zero.  The
+     response to a multicast LLMNR query MUST have RCODE set to zero.  A
+     sender MUST silently discard an LLMNR response with a non-zero
+     RCODE sent in response to a multicast query.
+
+     If an LLMNR responder is authoritative for the name in a multicast
+     query, but an error is encountered, the responder SHOULD send an
+     LLMNR response with an RCODE of zero, no RRs in the answer section,
+     and the TC bit set.  This will cause the query to be resent using
+     TCP, and allow the inclusion of a non-zero RCODE in the response to
+     the TCP query.  Responding with the TC bit set is preferable to not
+     sending a response, since it enables errors to be diagnosed.
+     Errors include those defined in [RFC2845], such as BADSIG(16),
+     BADKEY(17) and BADTIME(18).
+
+     Since LLMNR responders only respond to LLMNR queries for names for
+     which they are authoritative, LLMNR responders MUST NOT respond
+     with an RCODE of 3; instead, they should not respond at all.
+
+     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 8]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+     RCODE values.
+
+QDCOUNT
+     An unsigned 16 bit integer specifying the number of entries in the
+     question section.  A sender MUST place only one question into the
+     question section of an LLMNR query.  LLMNR responders MUST silently
+     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
+     MUST silently discard LLMNR responses with QDCOUNT not equal to
+     one.
+
+ANCOUNT
+     An unsigned 16 bit integer specifying the number of resource
+     records in the answer section.  LLMNR responders MUST silently
+     discard LLMNR queries with ANCOUNT not equal to zero.
+
+NSCOUNT
+     An unsigned 16 bit integer specifying the number of name server
+     resource records in the authority records section.  Authority
+     record section processing is described in Section 2.9.  LLMNR
+     responders MUST silently discard LLMNR queries with NSCOUNT not
+     equal to zero.
+
+ARCOUNT
+     An unsigned 16 bit integer specifying the number of resource
+     records in the additional records section.  Additional record
+     section processing is described in Section 2.9.
+
+2.2.  Sender Behavior
+
+   A sender MAY send an LLMNR query for any legal resource record  type
+   (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
+   As described in Section 2.4, a sender MAY also send a unicast query.
+
+   The sender MUST anticipate receiving no replies to some LLMNR
+   queries, in the event that no responders are available within the
+   link-scope.  If no response is received, a resolver treats it as a
+   response that the name does not exist (RCODE=3 is returned).  A
+   sender can handle duplicate responses by discarding responses with a
+   source IP address and ID field that duplicate a response already
+   received.
+
+   When multiple valid LLMNR responses are received with the 'C' bit
+   set, they SHOULD be concatenated and treated in the same manner that
+   multiple RRs received from the same DNS server would be.  However,
+   responses with the 'C' bit set SHOULD NOT be concatenated with
+   responses with the 'C' bit clear; instead, only the responses with
+   the 'C' bit set SHOULD be returned.  If valid LLMNR response(s) are
+   received along with error response(s), then the error responses are
+
+
+
+Aboba, Thaler & Esibov       Standards Track                    [Page 9]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   silently discarded.
+
+   If error responses are received from both DNS and LLMNR, then the
+   lowest RCODE value should be returned. For example, if either DNS or
+   LLMNR receives a response with RCODE=0, then this should returned to
+   the caller.
+
+   Since the responder may order the RRs in the response so as to
+   indicate preference, the sender SHOULD preserve ordering in the
+   response to the querying application.
+
+2.3.  Responder Behavior
+
+   An LLMNR response MUST be sent to the sender via unicast.
+
+   Upon configuring an IP address, responders typically will synthesize
+   corresponding A, AAAA and PTR RRs so as to be able to respond to
+   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
+   responder has another RR in addition to the SOA RR;  the SOA RR MUST
+   NOT be the only RR that a responder has.  However, in general whether
+   RRs are manually or automatically created is an implementation
+   decision.
+
+   For example, a host configured to have computer name "host1" and to
+   be a member of the "example.com" domain, and with IPv4 address
+   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
+   authoritative for the following records:
+
+   host1. IN A 192.0.2.1
+          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+   host1.example.com. IN A 192.0.2.1
+          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+   1.2.0.192.in-addr.arpa. IN PTR host1.
+          IN PTR host1.example.com.
+
+   6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
+   ip6.arpa IN PTR host1.  (line split for formatting reasons)
+            IN PTR host1.example.com.
+
+   An LLMNR responder might be further manually configured with the name
+   of a local mail server with an MX RR included in the "host1." and
+   "host1.example.com." records.
+
+   In responding to queries:
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 10]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[a]  Responders MUST listen on UDP port 5355 on the link-scope multicast
+     address(es) defined in Section 2, and on UDP and TCP port 5355 on
+     the unicast address(es) that could be set as the source address(es)
+     when the responder responds to the LLMNR query.
+
+[b]  Responders MUST direct responses to the port from which the query
+     was sent.  When queries are received via TCP this is an inherent
+     part of the transport protocol.  For queries received by UDP the
+     responder MUST take note of the source port and use that as the
+     destination port in the response.  Responses MUST always be sent
+     from the port to which they were directed.
+
+[c]  Responders MUST respond to LLMNR queries for names and addresses
+     they are authoritative for.  This applies to both forward and
+     reverse lookups, with the exception of queries with the 'C' bit
+     set, which do not elicit a response.
+
+[d]  Responders MUST NOT respond to LLMNR queries for names they are not
+     authoritative for.
+
+[e]  Responders MUST NOT respond using data from the LLMNR or DNS
+     resolver cache.
+
+[f]  If a DNS server is running on a host that supports LLMNR, the DNS
+     server MUST respond to LLMNR queries only for the RRSets relating
+     to the host on which the server is running, but MUST NOT respond
+     for other records for which the server is authoritative.  DNS
+     servers also MUST NOT send LLMNR queries in order to resolve DNS
+     queries.
+
+[g]  If a responder is authoritative for a name, it MUST respond with
+     RCODE=0 and an empty answer section, if the type of query does not
+     match a RR that the responder has.
+
+   As an example, a host configured to respond to LLMNR queries for the
+   name "foo.example.com."  is authoritative for the name
+   "foo.example.com.".  On receiving an LLMNR query for an A RR with the
+   name "foo.example.com." the host authoritatively responds with A
+   RR(s) that contain IP address(es) in the RDATA of the resource
+   record.  If the responder has a AAAA RR, but no A RR, and an A RR
+   query is received, the responder would respond with RCODE=0 and an
+   empty answer section.
+
+   In conventional DNS terminology a DNS server authoritative for a zone
+   is authoritative for all the domain names under the zone apex except
+   for the branches delegated into separate zones.  Contrary to
+   conventional DNS terminology, an LLMNR responder is authoritative
+   only for the zone apex.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 11]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   For example the host "foo.example.com." is not authoritative for the
+   name "child.foo.example.com." unless the host is configured with
+   multiple names, including "foo.example.com."  and
+   "child.foo.example.com.".  As a result, "foo.example.com." cannot
+   reply to an LLMNR query for "child.foo.example.com." with RCODE=3
+   (authoritative name error).  The purpose of limiting the name
+   authority scope of a responder is to prevent complications that could
+   be caused by coexistence of two or more hosts with the names
+   representing child and parent (or grandparent) nodes in the DNS tree,
+   for example, "foo.example.com." and "child.foo.example.com.".
+
+   Without the restriction on authority an LLMNR query for an A resource
+   record for the name "child.foo.example.com." would result in two
+   authoritative responses: RCODE=3 (authoritative name error) received
+   from "foo.example.com.", and a requested A record - from
+   "child.foo.example.com.".  To prevent this ambiguity, LLMNR enabled
+   hosts could perform a dynamic update of the parent (or grandparent)
+   zone with a delegation to a child zone;  for example a host
+   "child.foo.example.com." could send a dynamic update for the NS and
+   glue A record to "foo.example.com.".  However, this approach
+   significantly complicates implementation of LLMNR and would not be
+   acceptable for lightweight hosts.
+
+2.4.  Unicast Queries and Responses
+
+   Unicast queries SHOULD be sent when:
+
+   [a] A sender repeats a query after it received a response
+       with the TC bit set to the previous LLMNR multicast query, or
+
+   [b] The sender queries for a PTR RR of a fully formed IP address
+       within the "in-addr.arpa" or "ip6.arpa" zones.
+
+   Unicast LLMNR queries MUST be done using TCP and the responses MUST
+   be sent using the same TCP connection as the query.  Senders MUST
+   support sending TCP queries, and responders MUST support listening
+   for TCP queries. If the sender of a TCP query receives a response to
+   that query not using TCP, the response MUST be silently discarded.
+
+   Unicast UDP queries MUST be silently discarded.
+
+   If TCP connection setup cannot be completed in order to send a
+   unicast TCP query, this is treated as a response that no records of
+   the specified type and class exist for the specified name (it is
+   treated the same as a response with RCODE=0 and an empty answer
+   section).
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 12]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+2.5.  "Off link" Detection
+
+   A sender MUST select a source address for LLMNR queries that is
+   assigned on the interface on which the query is sent.  The
+   destination address of an LLMNR query MUST be a link-scope multicast
+   address or a unicast address.
+
+   A responder MUST select a source address for responses that is
+   assigned on the interface on which the query was received.  The
+   destination address of an LLMNR response MUST be a unicast address.
+
+   On receiving an LLMNR query, the responder MUST check whether it was
+   sent to a LLMNR multicast addresses defined in Section 2.  If it was
+   sent to another multicast address, then the query MUST be silently
+   discarded.
+
+   Section 2.4 discusses use of TCP for LLMNR queries and responses.  In
+   composing an LLMNR query using TCP, the sender MUST set the Hop Limit
+   field in the IPv6 header and the TTL field in the IPv4 header of the
+   response to one (1).  The responder SHOULD set the TTL or Hop Limit
+   settings on the TCP listen socket to one (1) so that SYN-ACK packets
+   will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
+   prevents an incoming connection from off-link since the sender will
+   not receive a SYN-ACK from the responder.
+
+   For UDP queries and responses, the Hop Limit field in the IPv6 header
+   and the TTL field in the IPV4 header MAY be set to any value.
+   However, it is RECOMMENDED that the value 255 be used for
+   compatibility with Apple Bonjour [Bonjour].
+
+   Implementation note:
+
+      In the sockets API for IPv4 [POSIX], the IP_TTL and
+      IP_MULTICAST_TTL socket options are used to set the TTL of
+      outgoing unicast and multicast packets. The IP_RECVTTL socket
+      option is available on some platforms to retrieve the IPv4 TTL of
+      received packets with recvmsg().  [RFC2292] specifies similar
+      options for setting and retrieving the IPv6 Hop Limit.
+
+2.6.  Responder Responsibilities
+
+   It is the responsibility of the responder to ensure that RRs returned
+   in LLMNR responses MUST only include values that are valid on the
+   local interface, such as IPv4 or IPv6 addresses valid on the local
+   link or names defended using the mechanism described in Section 4.
+   IPv4 Link-Local addresses are defined in [RFC3927].  IPv6 Link-Local
+   addresses are defined in [RFC2373].  In particular:
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 13]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   [a] If a link-scope IPv6 address is returned in a AAAA RR,
+       that address MUST be valid on the local link over which
+       LLMNR is used.
+
+   [b] If an IPv4 address is returned, it MUST be reachable
+       through the link over which LLMNR is used.
+
+   [c] If a name is returned (for example in a CNAME, MX
+       or SRV RR), the name MUST be resolvable on the local
+       link over which LLMNR is used.
+
+   Where multiple addresses represent valid responses to a query, the
+   order in which the addresses are returned is as follows:
+
+   [d] If the source address of the query is a link-scope address,
+       then the responder SHOULD include a link-scope address first
+       in the response, if available.
+
+   [e] If the source address of the query is a routable address,
+       then the responder MUST include a routable address first
+       in the response, if available.
+
+2.7.  Retransmission and Jitter
+
+   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
+   when to retransmit an LLMNR query.  An LLMNR sender SHOULD either
+   estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
+   high initial timeout.  Suggested constants are described in Section
+   7.
+
+   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
+   then a sender SHOULD repeat the transmission of the query in order to
+   assure that it was received by a host capable of responding to it,
+   while increasing the value of LLMNR_TIMEOUT exponentially.  An LLMNR
+   query SHOULD NOT be sent more than three times.
+
+   Where LLMNR queries are sent using TCP, retransmission is handled by
+   the transport layer.  Queries with the 'C' bit set MUST be sent using
+   multicast UDP and MUST NOT be retransmitted.
+
+   An LLMNR sender cannot know in advance if a query sent using
+   multicast will receive no response, one response, or more than one
+   response.  An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
+   has been received, or if it is necessary to collect all potential
+   responses, such as if a uniqueness verification query is being made.
+   Otherwise an LLMNR sender SHOULD consider a multicast query answered
+   after the first response is received, if that response has the 'C'
+   bit clear.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 14]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   However, if the first response has the 'C' bit set, then the sender
+   SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
+   responses.  When multiple valid answers are received, they may first
+   be concatenated, and then treated in the same manner that multiple
+   RRs received from the same DNS server would.  A unicast query sender
+   considers the query answered after the first response is received, so
+   that it only waits for LLMNR_TIMEOUT if no response has been
+   received.
+
+   Since it is possible for a response with the 'C' bit clear to be
+   followed by a response with the 'C' bit set, an LLMNR sender SHOULD
+   be prepared to process additional responses for the purposes of
+   conflict detection and LLMNR_TIMEOUT estimation, even after it has
+   considered a query answered.
+
+   In order to avoid synchronization, the transmission of each LLMNR
+   query and response SHOULD delayed by a time randomly selected from
+   the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
+   responders responding with names which they have previously
+   determined to be UNIQUE (see Section 4 for details).
+
+2.8.  DNS TTL
+
+   The responder should insert a pre-configured TTL value in the records
+   returned in an LLMNR response.  A default value of 30 seconds is
+   RECOMMENDED.  In highly dynamic environments (such as mobile ad-hoc
+   networks), the TTL value may need to be reduced.
+
+   Due to the TTL minimalization necessary when caching an RRset, all
+   TTLs in an RRset MUST be set to the same value.
+
+2.9.  Use of the Authority and Additional Sections
+
+   Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
+   concept of delegation.  In LLMNR, the NS resource record type may be
+   stored and queried for like any other type, but it has no special
+   delegation semantics as it does in the DNS.  Responders MAY have NS
+   records associated with the names for which they are authoritative,
+   but they SHOULD NOT include these NS records in the authority
+   sections of responses.
+
+   Responders SHOULD insert an SOA record into the authority section of
+   a negative response, to facilitate negative caching as specified in
+   [RFC2308]. The TTL of this record is set from the minimum of the
+   MINIMUM field of the SOA record and the TTL of the SOA itself, and
+   indicates how long a resolver may cache the negative answer.  The
+   owner name of the SOA record (MNAME) MUST be set to the query name.
+   The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 15]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   by senders.  Negative responses without SOA records SHOULD NOT be
+   cached.
+
+   In LLMNR, the additional section is primarily intended for use by
+   EDNS0, TSIG and SIG(0).  As a result, unless the 'C' bit is set,
+   senders MAY only include pseudo RR-types in the additional section of
+   a query; unless the 'C' bit is set, responders MUST ignore the
+   additional section of queries containing other RR types.
+
+   In queries where the 'C' bit is set, the sender SHOULD include the
+   conflicting RRs in the additional section.  Since conflict
+   notifications are advisory, responders SHOULD log information from
+   the additional section, but otherwise MUST ignore the additional
+   section.
+
+   Senders MUST NOT cache RRs from the authority or additional section
+   of a response as answers, though they may be used for other purposes
+   such as negative caching.
+
+3.  Usage Model
+
+   Since LLMNR is a secondary name resolution mechanism, its usage is in
+   part determined by the behavior of DNS implementations.  This
+   document does not specify any changes to DNS resolver behavior, such
+   as searchlist processing or retransmission/failover policy.  However,
+   robust DNS resolver implementations are more likely to avoid
+   unnecessary LLMNR queries.
+
+   As noted in [DNSPerf], even when DNS servers are configured, a
+   significant fraction of DNS queries do not receive a response, or
+   result in negative responses due to missing inverse mappings or NS
+   records that point to nonexistent or inappropriate hosts.  This has
+   the potential to result in a large number of unnecessary LLMNR
+   queries.
+
+   [RFC1536] describes common DNS implementation errors and fixes.  If
+   the proposed fixes are implemented, unnecessary LLMNR queries will be
+   reduced substantially, and so implementation of [RFC1536] is
+   recommended.
+
+   For example, [RFC1536] Section 1 describes issues with retransmission
+   and recommends implementation of a retransmission policy based on
+   round trip estimates, with exponential backoff.  [RFC1536] Section 4
+   describes issues with failover, and recommends that resolvers try
+   another server when they don't receive a response to a query.  These
+   policies are likely to avoid unnecessary LLMNR queries.
+
+   [RFC1536] Section 3 describes zero answer bugs, which if addressed
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 16]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   will also reduce unnecessary LLMNR queries.
+
+   [RFC1536] Section 6 describes name error bugs and recommended
+   searchlist processing that will reduce unnecessary RCODE=3
+   (authoritative name) errors, thereby also reducing unnecessary LLMNR
+   queries.
+
+3.1.  LLMNR Configuration
+
+   Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
+   possible for a dual stack host to be configured with the address of a
+   DNS server over IPv4, while remaining unconfigured with a DNS server
+   suitable for use over IPv6.
+
+   In these situations, a dual stack host will send AAAA queries to the
+   configured DNS server over IPv4.  However, an IPv6-only host
+   unconfigured with a DNS server suitable for use over IPv6 will be
+   unable to resolve names using DNS.  Automatic IPv6 DNS configuration
+   mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
+   deployed, and not all DNS servers support IPv6.  Therefore lack of
+   IPv6 DNS configuration may be a common problem in the short term, and
+   LLMNR may prove useful in enabling link-local name resolution over
+   IPv6.
+
+   Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
+   IPv6-only hosts may not be configured with a DNS server.  Where there
+   is no DNS server authoritative for the name of a host or the
+   authoritative DNS server does not support dynamic client update over
+   IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
+   be able to do DNS dynamic update, and other hosts will not be able to
+   resolve its name.
+
+   For example, if the configured DNS server responds to a AAAA RR query
+   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
+   RCODE=0 and an empty answer section, then a AAAA RR query sent using
+   LLMNR over IPv6 may be successful in resolving the name of an
+   IPv6-only host on the local link.
+
+   Similarly, if a DHCPv4 server is available providing DNS server
+   configuration, and DNS server(s) exist which are authoritative for
+   the A RRs of local hosts and support either dynamic client update
+   over IPv4 or DHCPv4-based dynamic update, then the names of local
+   IPv4 hosts can be resolved over IPv4 without LLMNR.  However,  if no
+   DNS server is authoritative for the names of local hosts, or the
+   authoritative DNS server(s) do not support dynamic update, then LLMNR
+   enables linklocal name resolution over IPv4.
+
+   Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 17]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   configure LLMNR on an interface.  The LLMNR Enable Option, described
+   in [LLMNREnable], can be used to explicitly enable or disable use of
+   LLMNR on an interface.  The LLMNR Enable Option does not determine
+   whether or in which order DNS itself is used for name resolution.
+   The order in which various name resolution mechanisms should be used
+   can be specified using the Name Service Search Option (NSSO) for DHCP
+   [RFC2937], using the LLMNR Enable Option code carried in the NSSO
+   data.
+
+   It is possible that DNS configuration mechanisms will go in and out
+   of service.  In these circumstances, it is possible for hosts within
+   an administrative domain to be inconsistent in their DNS
+   configuration.
+
+   For example, where DHCP is used for configuring DNS servers, one or
+   more DHCP servers can fail.  As a result, hosts configured prior to
+   the outage will be configured with a DNS server, while hosts
+   configured after the outage will not.  Alternatively, it is possible
+   for the DNS configuration mechanism to continue functioning while
+   configured DNS servers fail.
+
+   An outage in the DNS configuration mechanism may result in hosts
+   continuing to use LLMNR even once the outage is repaired.  Since
+   LLMNR only enables linklocal name resolution, this represents a
+   degradation in capabilities.  As a result, hosts without a configured
+   DNS server may wish to periodically attempt to obtain DNS
+   configuration if permitted by the configuration mechanism in use.  In
+   the absence of other guidance, a default retry interval of one (1)
+   minute is RECOMMENDED.
+
+4.  Conflict Resolution
+
+   By default, a responder SHOULD be configured to behave as though its
+   name is UNIQUE on each interface on which LLMNR is enabled.  However,
+   it is also possible to configure multiple responders to be
+   authoritative for the same name.  For example, multiple responders
+   MAY respond to a query for an A or AAAA type record for a cluster
+   name (assigned to multiple hosts in the cluster).
+
+   To detect duplicate use of a name, an administrator can use a name
+   resolution utility which employs LLMNR and lists both responses and
+   responders.  This would allow an administrator to diagnose behavior
+   and potentially to intervene and reconfigure LLMNR responders who
+   should not be configured to respond to the same name.
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 18]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+4.1.  Uniqueness Verification
+
+   Prior to sending an LLMNR response with the 'T' bit clear, a
+   responder configured with a UNIQUE name MUST verify that there is no
+   other host within the scope of LLMNR query propagation that is
+   authoritative for the same name on that interface.
+
+   Once a responder has verified that its name is UNIQUE, if it receives
+   an LLMNR query for that name, with the 'C' bit clear, it MUST
+   respond, with the 'T' bit clear. Prior to verifying that its name is
+   UNIQUE, a responder MUST set the 'T' bit in responses.
+
+   Uniqueness verification is carried out when the host:
+
+     - starts up or is rebooted
+     - wakes from sleep (if the network interface was inactive
+       during sleep)
+     - is configured to respond to LLMNR queries on an interface
+       enabled for transmission and reception of IP traffic
+     - is configured to respond to LLMNR queries using additional
+       UNIQUE resource records
+     - verifies the acquisition of a new IP address and configuration
+       on an interface
+
+   To verify uniqueness, a responder MUST send an LLMNR query with the
+   'C' bit clear, over all protocols on which it responds to LLMNR
+   queries (IPv4 and/or IPv6).  It is RECOMMENDED that responders verify
+   uniqueness of a name by sending a query for the name with type='ANY'.
+
+   If no response is received, the sender retransmits the query, as
+   specified in Section 2.7.  If a response is received, the sender MUST
+   check if the source address matches the address of any of its
+   interfaces; if so, then the response is not considered a conflict,
+   since it originates from the sender.  To avoid triggering conflict
+   detection, a responder that detects that it is connected to the same
+   link on multiple interfaces SHOULD set the 'C' bit in responses.
+
+   If a response is received with the 'T' bit clear, the responder MUST
+   NOT use the name in response to LLMNR queries received over any
+   protocol (IPv4 or IPv6).  If a response is received with the 'T' bit
+   set, the responder MUST check if the source IP address in the
+   response, interpreted as an unsigned integer, is less than the source
+   IP address in the query.  If so, the responder MUST NOT use the name
+   in response to LLMNR queries received over any protocol (IPv4 or
+   IPv6).  For the purpose of uniqueness verification, the contents of
+   the answer section in a response is irrelevant.
+
+   Periodically carrying out uniqueness verification in an attempt to
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 19]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   detect name conflicts is not necessary, wastes network bandwidth, and
+   may actually be detrimental.  For example, if network links are
+   joined only briefly, and are separated again before any new
+   communication is initiated, temporary conflicts are benign and no
+   forced reconfiguration is required.  LLMNR responders SHOULD NOT
+   periodically attempt uniqueness verification.
+
+4.2.  Conflict Detection and Defense
+
+   Hosts on disjoint network links may configure the same name for use
+   with LLMNR.  If these separate network links are later joined or
+   bridged together, then there may be multiple hosts which are now on
+   the same link, trying to use the same name.
+
+   In order to enable ongoing detection of name conflicts, when an LLMNR
+   sender receives multiple LLMNR responses to a query, it MUST check if
+   the 'C' bit is clear in any of the responses.  If so, the sender
+   SHOULD send another query for the same name, type and class, this
+   time with the 'C' bit set, with the potentially conflicting resource
+   records included in the additional section.
+
+   Queries with the 'C' bit set are considered advisory and responders
+   MUST verify the existence of a conflict before acting on it.  A
+   responder receiving a query with the 'C' bit set MUST NOT respond.
+
+   If the query is for a UNIQUE name, then the responder MUST send its
+   own query for the same name, type and class, with the 'C' bit clear.
+   If a response is received, the sender MUST check if the source
+   address matches the address of any of its interfaces; if so, then the
+   response is not considered a conflict, since it originates from the
+   sender.  To avoid triggering conflict detection, a responder that
+   detects that it is connected to the same link on multiple interfaces
+   SHOULD set the 'C' bit in responses.
+
+   An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
+   log them.  Upon detecting a conflict, an LLMNR responder MUST
+   immediately stop using the conflicting name in response to LLMNR
+   queries received over any supported protocol, if the source IP
+   address in the response, interpreted as an unsigned integer, is less
+   than the source IP address in the uniqueness verification query.
+
+   After stopping the use of a name, the responder MAY elect to
+   configure a new name.  However, since name reconfiguration may be
+   disruptive, this is not required, and a responder may have been
+   configured to respond to multiple names so that alternative names may
+   already be available.  A host that has stopped the use of a name may
+   attempt uniqueness verification again after the expiration of the TTL
+   of the conflicting response.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 20]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+4.3.  Considerations for Multiple Interfaces
+
+   A multi-homed host may elect to configure LLMNR on only one of its
+   active interfaces.  In many situations this will be adequate.
+   However, should a host need to configure LLMNR on more than one of
+   its active interfaces, there are some additional precautions it MUST
+   take.  Implementers who are not planning to support LLMNR on multiple
+   interfaces simultaneously may skip this section.
+
+   Where a host is configured to issue LLMNR queries on more than one
+   interface, each interface maintains its own independent LLMNR
+   resolver cache, containing the responses to LLMNR queries.
+
+   A multi-homed host checks the uniqueness of UNIQUE records as
+   described in Section 4.  The situation is illustrated in figure 1.
+
+        ----------  ----------
+         |      |    |      |
+        [A]    [myhost]   [myhost]
+
+      Figure 1.  Link-scope name conflict
+
+   In this situation, the multi-homed myhost will probe for, and defend,
+   its host name on both interfaces.  A conflict will be detected on one
+   interface, but not the other.  The multi-homed myhost will not be
+   able to respond with a host RR for "myhost" on the interface on the
+   right (see Figure 1).  The multi-homed host may, however, be
+   configured to use the "myhost" name on the interface on the left.
+
+   Since names are only unique per-link, hosts on different links could
+   be using the same name.  If an LLMNR client sends requests over
+   multiple interfaces, and receives replies from more than one, the
+   result returned to the client is defined by the implementation.  The
+   situation is illustrated in figure 2.
+
+        ----------  ----------
+         |      |    |     |
+        [A]    [myhost]   [A]
+
+
+      Figure 2.  Off-segment name conflict
+
+   If host myhost is configured to use LLMNR on both interfaces, it will
+   send LLMNR queries on both interfaces.  When host myhost sends a
+   query for the host RR for name "A" it will receive a response from
+   hosts on both interfaces.
+
+   Host myhost cannot distinguish between the situation shown in Figure
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 21]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   2, and that shown in Figure 3 where no conflict exists.
+
+                [A]
+               |   |
+           -----   -----
+               |   |
+              [myhost]
+
+      Figure 3.  Multiple paths to same host
+
+   This illustrates that the proposed name conflict resolution mechanism
+   does not support detection or resolution of conflicts between hosts
+   on different links.  This problem can also occur with DNS when a
+   multi-homed host is connected to two different networks with
+   separated name spaces.  It is not the intent of this document to
+   address the issue of uniqueness of names within DNS.
+
+4.4.  API Issues
+
+   [RFC2553] provides an API which can partially solve the name
+   ambiguity problem for applications written to use this API, since the
+   sockaddr_in6 structure exposes the scope within which each scoped
+   address exists, and this structure can be used for both IPv4 (using
+   v4-mapped IPv6 addresses) and IPv6 addresses.
+
+   Following the example in Figure 2, an application on 'myhost' issues
+   the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
+   ai_flags=AI_ALL|AI_V4MAPPED.  LLMNR requests will be sent from both
+   interfaces and the resolver library will return a list containing
+   multiple addrinfo structures, each with an associated sockaddr_in6
+   structure.  This list will thus contain the IPv4 and IPv6 addresses
+   of both hosts responding to the name 'A'.  Link-local addresses will
+   have a sin6_scope_id value that disambiguates which interface is used
+   to reach the address.  Of course, to the application, Figures 2 and 3
+   are still indistinguishable, but this API allows the application to
+   communicate successfully with any address in the list.
+
+5.  Security Considerations
+
+   LLMNR is a peer-to-peer name resolution protocol designed for use on
+   the local link.  While LLMNR limits the vulnerability of responders
+   to off-link senders, it is possible for an off-link responder to
+   reach a sender.
+
+   In scenarios such as public "hotspots" attackers can be present on
+   the same link.  These threats are most serious in wireless networks
+   such as 802.11, since attackers on a wired network will require
+   physical access to the network, while wireless attackers may mount
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 22]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   attacks from a distance.  Link-layer security such as [IEEE-802.11i]
+   can be of assistance against these threats if it is available.
+
+   This section details security measures available to mitigate threats
+   from on and off-link attackers.
+
+5.1.  Denial of Service
+
+   Attackers may take advantage of LLMNR conflict detection by
+   allocating the same name, denying service to other LLMNR responders
+   and possibly allowing an attacker to receive packets destined for
+   other hosts.  By logging conflicts, LLMNR responders can provide
+   forensic evidence of these attacks.
+
+   An attacker may spoof LLMNR queries from a victim's address in order
+   to mount a denial of service attack.  Responders setting the IPv6 Hop
+   Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
+   response may be able to reach the victim across the Internet.
+
+   While LLMNR responders only respond to queries for which they are
+   authoritative and LLMNR does not provide wildcard query support, an
+   LLMNR response may be larger than the query, and an attacker can
+   generate multiple responses to a query for a name used by multiple
+   responders.  A sender may protect itself against unsolicited
+   responses by silently discarding them as rapidly as possible.
+
+5.2.  Spoofing
+
+   LLMNR is designed to prevent reception of queries sent by an off-link
+   attacker.  LLMNR requires that responders receiving UDP queries check
+   that they are sent to a link-scope multicast address.  However, it is
+   possible that some routers may not properly implement link-scope
+   multicast, or that link-scope multicast addresses may leak into the
+   multicast routing system.  To prevent successful setup of TCP
+   connections by an off-link sender, responders receiving a TCP SYN
+   reply with a TCP SYN-ACK with TTL set to one (1).
+
+   While it is difficult for an off-link attacker to send an LLMNR query
+   to a responder,  it is possible for an off-link attacker to spoof a
+   response to a query (such as an A or AAAA query for a popular
+   Internet host), and by using a TTL or Hop Limit field larger than one
+   (1), for the forged response to reach the LLMNR sender.  Since the
+   forged response will only be accepted if it contains a matching ID
+   field, choosing a pseudo-random ID field within queries provides some
+   protection against off-link responders.
+
+   Since LLMNR queries can be sent when DNS server(s) do not respond, an
+   attacker can execute a denial of service attack on the DNS server(s)
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 23]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   and then poison the LLMNR cache by responding to an LLMNR query with
+   incorrect information.  As noted in "Threat Analysis of the Domain
+   Name System (DNS)" [RFC3833] these threats also exist with DNS, since
+   DNS response spoofing tools are available that can allow an attacker
+   to respond to a query more quickly than a distant DNS server.
+   However, while switched networks or link layer security may make it
+   difficult for an on-link attacker to snoop unicast DNS queries,
+   multicast LLMNR queries are propagated to all hosts on the link,
+   making it possible for an on-link attacker to spoof LLMNR responses
+   without having to guess the value of the ID field in the query.
+
+   Since LLMNR queries are sent and responded to on the local-link, an
+   attacker will need to respond more quickly to provide its own
+   response prior to arrival of the response from a legitimate
+   responder.   If an LLMNR query is sent for an off-link host, spoofing
+   a response in a timely way is not difficult, since a legitimate
+   response will never be received.
+
+   Limiting the situations in which LLMNR queries are sent, as described
+   in Section 2, is the best protection against these attacks.  If LLMNR
+   is given higher priority than DNS among the enabled name resolution
+   mechanisms, a denial of service attack on the DNS server would not be
+   necessary in order to poison the LLMNR cache, since LLMNR queries
+   would be sent even when the DNS server is available.  In addition,
+   the LLMNR cache, once poisoned, would take precedence over the DNS
+   cache, eliminating the benefits of cache separation.  As a result,
+   LLMNR is only used as a name resolution mechanism of last resort.
+
+5.3.  Authentication
+
+   LLMNR is a peer-to-peer name resolution protocol, and as a result,
+   it is often deployed in situations where no trust model can be
+   assumed.  This makes it difficult to apply existing DNS security
+   mechanisms to LLMNR.
+
+   LLMNR does not support "delegated trust" (CD or AD bits).  As a
+   result, unless LLMNR senders are DNSSEC aware, it is not feasible to
+   use DNSSEC [RFC4033] with LLMNR.
+
+   If authentication is desired, and a pre-arranged security
+   configuration is possible, then the following security mechanisms may
+   be used:
+
+[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
+     [RFC2931] security mechanisms. "DNS Name Service based on Secure
+     Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
+     the use of TSIG to secure LLMNR responses, based on group keys.
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 24]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
+     LLMNR queries and responses or LLMNR responses to multicast
+     queries.  In a small network without a certificate authority, this
+     can be most easily accomplished through configuration of a group
+     pre-shared key for trusted hosts.
+
+   Where these mechanisms cannot be supported, responses to LLMNR
+   queries may be unauthenticated.
+
+5.4.  Cache and Port Separation
+
+   In order to prevent responses to LLMNR queries from polluting the DNS
+   cache, LLMNR implementations MUST use a distinct, isolated cache for
+   LLMNR on each interface.  The use of separate caches is most
+   effective when LLMNR is used as a name resolution mechanism of last
+   resort, since this minimizes the opportunities for poisoning the
+   LLMNR cache, and decreases reliance on it.
+
+   LLMNR operates on a separate port from DNS, reducing the likelihood
+   that a DNS server will unintentionally respond to an LLMNR query.
+
+6.  IANA Considerations
+
+   This specification creates one new name space:  the reserved bits in
+   the LLMNR header.  These are allocated by IETF Consensus, in
+   accordance with BCP 26 [RFC2434].
+
+   LLMNR requires allocation of port 5355 for both TCP and UDP.
+
+   LLMNR requires allocation of link-scope multicast IPv4 address
+   224.0.0.252, as well as link-scope multicast IPv6 address
+   FF02:0:0:0:0:0:1:3.
+
+7.  Constants
+
+   The following timing constants are used in this protocol; they are
+   not intended to be user configurable.
+
+      JITTER_INTERVAL      100 ms
+      LLMNR_TIMEOUT        1 second (if set statically on all interfaces)
+                           100 ms (IEEE 802 media, including IEEE 802.11)
+
+8.  References
+
+8.1.  Normative References
+
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and
+          Specification", RFC 1035, November 1987.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 25]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+          Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+          Specification", RFC 2181, July 1997.
+
+[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+          RFC 2308, March 1998.
+
+[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+          Architecture", RFC 2373, July 1998.
+
+[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+          Considerations Section in RFCs", BCP 26, RFC 2434, October
+          1998.
+
+[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+          August 1999.
+
+[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+          "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+          2845, May 2000.
+
+[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+          (SIG(0)s)", RFC 2931, September 2000.
+
+8.2.  Informative References
+
+[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
+          (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
+          June 2005.
+
+[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
+          Caching", IEEE/ACM Transactions on Networking, Volume 10,
+          Number 5, pp. 589, October 2002.
+
+[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
+          unicast addresses to communicate with recursive DNS servers",
+          Internet draft (work in progress), draft-ietf-ipv6-dns-
+          discovery-07.txt, October 2002.
+
+[IEEE-802.11i]
+          Institute of Electrical and Electronics Engineers, "Supplement
+          to Standard for Telecommunications and Information Exchange
+          Between Systems - LAN/MAN Specific Requirements - Part 11:
+          Wireless LAN Medium Access Control (MAC) and Physical Layer
+          (PHY) Specifications: Specification for Enhanced Security",
+          IEEE 802.11i, July 2004.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 26]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+[LLMNREnable]
+          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
+          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
+
+[LLMNRSec]
+          Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
+          Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
+          2004, Phoenix Park, Korea, February 9-11, 2004.
+
+[POSIX]   IEEE Std. 1003.1-2001 Standard for Information Technology --
+          Portable Operating System Interface (POSIX). Open Group
+          Technical Standard: Base Specifications, Issue 6, December
+          2001.  ISO/IEC 9945:2002.  http://www.opengroup.org/austin
+
+[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
+          Fixes", RFC 1536, October 1993.
+
+[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+          Recommendations for Security", RFC 1750, December 1994.
+
+[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+          March 1997.
+
+[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
+          RFC 2292, February 1998.
+
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
+          2365, July 1998.
+
+[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
+          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
+
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
+          2937, September 2000.
+
+[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
+          IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+          System (DNS)", RFC 3833, August 2004.
+
+[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
+          of Link-Local IPv4 Addresses", RFC 3927, October 2004.
+
+[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+          "DNS Security Introduction and Requirement", RFC 4033, March
+          2005.
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 27]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+Acknowledgments
+
+   This work builds upon original work done on multicast DNS by Bill
+   Manning and Bill Woodcock.  Bill Manning's work was funded under
+   DARPA grant #F30602-99-1-0523.  The authors gratefully acknowledge
+   their contribution to the current specification.  Constructive input
+   has also been received from Mark Andrews, Rob Austein, Randy Bush,
+   Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
+   Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
+   Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
+   Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
+   St. Johns, Sander Van-Valkenburg, and Brian Zill.
+
+Authors' Addresses
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 706 6605
+   EMail: bernarda@microsoft.com
+
+   Dave Thaler
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 703 8835
+   EMail: dthaler@microsoft.com
+
+   Levon Esibov
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   EMail: levone@microsoft.com
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 28]
+
+
+
+
+
+INTERNET-DRAFT                    LLMNR                   29 August 2005
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+Open Issues
+
+   Open issues with this specification are tracked on the following web
+   site:
+
+   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov       Standards Track                   [Page 29]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
new file mode 100644
index 0000000..8c6c5b1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
@@ -0,0 +1,2352 @@
+
+
+
+Network Working Group                                          B. Laurie
+Internet-Draft                                                 G. Sisson
+Expires: August 5, 2006                                        R. Arends
+                                                                 Nominet
+                                                           February 2006
+
+
+             DNSSEC Hash Authenticated Denial of Existence
+                       draft-ietf-dnsext-nsec3-04
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 5, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The DNS Security Extensions introduces the NSEC resource record for
+   authenticated denial of existence.  This document introduces a new
+   resource record as an alternative to NSEC that provides measures
+   against zone enumeration and allows for gradual expansion of
+   delegation-centric zones.
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 1]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
+     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  NSEC versus NSEC3  . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
+     3.1.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  6
+       3.1.1.  The Hash Function Field  . . . . . . . . . . . . . . .  6
+       3.1.2.  The Opt-In Flag Field  . . . . . . . . . . . . . . . .  7
+       3.1.3.  The Iterations Field . . . . . . . . . . . . . . . . .  8
+       3.1.4.  The Salt Length Field  . . . . . . . . . . . . . . . .  8
+       3.1.5.  The Salt Field . . . . . . . . . . . . . . . . . . . .  8
+       3.1.6.  The Next Hashed Ownername Field  . . . . . . . . . . .  9
+       3.1.7.  The Type Bit Maps Field  . . . . . . . . . . . . . . .  9
+     3.2.  The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
+   4.  Creating Additional NSEC3 RRs for Empty Non-Terminals  . . . . 11
+   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 11
+   6.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 11
+   7.  Responding to NSEC3 Queries  . . . . . . . . . . . . . . . . . 12
+   8.  Special Considerations . . . . . . . . . . . . . . . . . . . . 13
+     8.1.  Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
+     8.2.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     8.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
+     8.4.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
+       8.4.1.  Avoiding Hash Collisions during generation . . . . . . 16
+       8.4.2.  Second Preimage Requirement Analysis . . . . . . . . . 16
+       8.4.3.  Possible Hash Value Truncation Method  . . . . . . . . 17
+       8.4.4.  Server Response to a Run-time Collision  . . . . . . . 17
+       8.4.5.  Parameters that Cover the Zone . . . . . . . . . . . . 18
+   9.  Performance Considerations . . . . . . . . . . . . . . . . . . 18
+   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
+   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
+   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 22
+   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 27
+     B.1.  answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+       B.1.1.  Authenticating the Example DNSKEY RRset  . . . . . . . 29
+     B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
+     B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 32
+       B.3.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 33
+     B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . . 34
+     B.5.  Referral to Unsigned Zone using the Opt-In Flag  . . . . . 35
+     B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 2]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+     B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
+     B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 39
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
+   Intellectual Property and Copyright Statements . . . . . . . . . . 42
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 3]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+1.  Introduction
+
+1.1.  Rationale
+
+   The DNS Security Extensions included the NSEC RR to provide
+   authenticated denial of existence.  Though the NSEC RR meets the
+   requirements for authenticated denial of existence, it introduced a
+   side-effect in that the contents of a zone can be enumerated.  This
+   property introduces undesired policy issues.
+
+   An enumerated zone can be used either directly as a source of
+   probable e-mail addresses for spam, or indirectly as a key for
+   multiple WHOIS queries to reveal registrant data which many
+   registries may be under strict legal obligations to protect.  Many
+   registries therefore prohibit copying of their zone file; however the
+   use of NSEC RRs renders these policies unenforceable.
+
+   A second problem was the requirement that the existence of all record
+   types in a zone - including unsigned delegation points - must be
+   accounted for, despite the fact that unsigned delegation point
+   records are not signed.  This requirement has a side-effect that the
+   overhead of signed zones is not related to the increase in security
+   of subzones.  This requirement does not allow the zones' size to grow
+   in relation to the growth of signed subzones.
+
+   In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
+   proposed as a measure against these side effects but at the time were
+   regarded as secondary over the need to have a stable DNSSEC
+   specification.  With (draft-vixie-dnssec-ter) [14] a graceful
+   transition path to future enhancements is introduced, while current
+   DNSSEC deployment can continue.  This document presents the NSEC3
+   Resource Record which mitigates these issues with the NSEC RR.
+
+   The reader is assumed to be familiar with the basic DNS and DNSSEC
+   concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
+   4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
+   [6], RFC2181 [7] and RFC2308 [8].
+
+1.2.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [9].
+
+1.3.  Terminology
+
+   The practice of discovering the contents of a zone, i.e. enumerating
+   the domains within a zone, is known as "zone enumeration".  Zone
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 4]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   enumeration was not practical prior to the introduction of DNSSEC.
+
+   In this document the term "original ownername" refers to a standard
+   ownername.  Because this proposal uses the result of a hash function
+   over the original (unmodified) ownername, this result is referred to
+   as "hashed ownername".
+
+   "Hash order" means the order in which hashed ownernames are arranged
+   according to their numerical value, treating the leftmost (lowest
+   numbered) octet as the most significant octet.  Note that this is the
+   same as the canonical ordering specified in RFC 4034 [4].
+
+   An "empty non-terminal" is a domain name that owns no resource
+   records but has subdomains that do.
+
+   The "closest encloser" of a (nonexistent) domain name is the longest
+   domain name, including empty non-terminals, that matches the
+   rightmost part of the nonexistent domain name.
+
+   "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
+   specified in RFC 3548bis [15].
+
+
+2.  NSEC versus NSEC3
+
+   This document does NOT obsolete the NSEC record, but gives an
+   alternative for authenticated denial of existence.  NSEC and NSEC3
+   RRs can not co-exist in a zone.  See draft-vixie-dnssec-ter [14] for
+   a signaling mechanism to allow for graceful transition towards NSEC3.
+
+
+3.  The NSEC3 Resource Record
+
+   The NSEC3 RR provides Authenticated Denial of Existence for DNS
+   Resource Record Sets.
+
+   The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
+   RR's original ownername.  It includes the next hashed ownername in
+   the hash order of the zone.  The complete set of NSEC3 RRs in a zone
+   indicates which RRsets exist for the original ownername of the RRset
+   and form a chain of hashed ownernames in the zone.  This information
+   is used to provide authenticated denial of existence for DNS data, as
+   described in RFC 4035 [5].  To provide protection against zone
+   enumeration, the ownernames used in the NSEC3 RR are cryptographic
+   hashes of the original ownername prepended to the name of the zone.
+   The NSEC3 RR indicates which hash function is used to construct the
+   hash, which salt is used, and how many iterations of the hash
+   function are performed over the original ownername.  The hashing
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 5]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   technique is described fully in Section 5.
+
+   Hashed ownernames of unsigned delegations may be excluded from the
+   chain.  An NSEC3 record which span covers the hash of an unsigned
+   delegation's ownername is referred to as an Opt-In NSEC3 record and
+   is indicated by the presence of a flag.
+
+   The ownername for the NSEC3 RR is the base32 encoding of the hashed
+   ownername prepended to the name of the zone..
+
+   The type value for the NSEC3 RR is XX.
+
+   The NSEC3 RR RDATA format is class independent and is described
+   below.
+
+   The class MUST be the same as the original ownername's class.
+
+   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching [8].
+
+3.1.  NSEC3 RDATA Wire Format
+
+   The RDATA of the NSEC3 RR is as shown below:
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Hash Function |O|                Iterations                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Salt Length  |                     Salt                      /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                     Next Hashed Ownername                     /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                         Type Bit Maps                         /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   "O" is the Opt-In Flag field.
+
+3.1.1.  The Hash Function Field
+
+   The Hash Function field identifies the cryptographic hash function
+   used to construct the hash-value.
+
+   The values are as defined for the DS record (see RFC 3658 [10]).
+
+   On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
+   function value.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 6]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+3.1.2.  The Opt-In Flag Field
+
+   The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
+   delegations.
+
+   In DNSSEC, NS RRsets at delegation points are not signed, and may be
+   accompanied by a DS record.  The security status of the subzone is
+   determined by the presence or absence of the DS RRset,
+   cryptographically proven by the NSEC record or the signed DS RRset.
+   The presence of the Opt-In flag expands this definition by allowing
+   insecure delegations to exist within an otherwise signed zone without
+   the corresponding NSEC3 record at the delegation's (hashed) owner
+   name.  These delegations are proven insecure by using a covering
+   NSEC3 record.
+
+   Resolvers must be able to distinguish between NSEC3 records and
+   Opt-In NSEC3 records.  This is accomplished by setting the Opt-In
+   flag of the NSEC3 records that cover (or potentially cover) insecure
+   delegation nodes.
+
+   An Opt-In NSEC3 record does not assert the existence or non-existence
+   of the insecure delegations that it covers.  This allows for the
+   addition or removal of these delegations without recalculating or
+   resigning records in the NSEC3 chain.  However, Opt-In NSEC3 records
+   do assert the (non)existence of other, authoritative RRsets.
+
+   An Opt-In NSEC3 record MAY have the same original owner name as an
+   insecure delegation.  In this case, the delegation is proven insecure
+   by the lack of a DS bit in type map and the signed NSEC3 record does
+   assert the existence of the delegation.
+
+   Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
+   non-Opt-In NSEC3 records.  If an NSEC3 record is not Opt-In, there
+   MUST NOT be any hashed ownernames of insecure delegations (nor any
+   other records) between it and the RRsets indicated by the 'Next
+   Hashed Ownername' in the NSEC3 RDATA.  If it is Opt-In, there MUST
+   only be hashed ownernames of insecure delegations between it and the
+   next node indicated by the 'Next Hashed Ownername' in the NSEC3
+   RDATA.
+
+   In summary,
+   o  An Opt-In NSEC3 type is identified by an Opt-In Flag field value
+      of 1.
+   o  A non Opt-In NSEC3 type is identified by an Opt-In Flag field
+      value of 0.
+   and,
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 7]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   o  An Opt-In NSEC3 record does not assert the non-existence of a hash
+      ownername between its ownername and next hashed ownername,
+      although it does assert that any hashed name in this span MUST be
+      of an insecure delegation.
+   o  An Opt-In NSEC3 record does assert the (non)existence of RRsets
+      with the same hashed owner name.
+
+3.1.3.  The Iterations Field
+
+   The Iterations field defines the number of times the hash has been
+   iterated.  More iterations results in greater resiliency of the hash
+   value against dictionary attacks, but at a higher cost for both the
+   server and resolver.  See Section 5 for details of this field's use.
+
+   Iterations make an attack more costly by making the hash computation
+   more computationally intensive, e.g. by iterating the hash function a
+   number of times.
+
+   When generating a few hashes this performance loss will not be a
+   problem, as a validator can handle a delay of a few milliseconds.
+   But when doing a dictionary attack it will also multiply the attack
+   workload by a factor, which is a problem for the attacker.
+
+3.1.4.  The Salt Length Field
+
+   The salt length field defines the length of the salt in octets.
+
+3.1.5.  The Salt Field
+
+   The Salt field is not present when the Salt Length Field has a value
+   of 0.
+
+   The Salt field is appended to the original ownername before hashing
+   in order to defend against precalculated dictionary attacks.  See
+   Section 5 for details on how the salt is used.
+
+   Salt is used to make dictionary attacks using precomputation more
+   costly.  A dictionary can only be computed after the attacker has the
+   salt, hence a new salt means that the dictionary has to be
+   regenerated with the new salt.
+
+   There MUST be a complete set of NSEC3 records covering the entire
+   zone that use the same salt value.  The requirement exists so that,
+   given any qname within a zone, at least one covering NSEC3 RRset may
+   be found.  While it may be theoretically possible to produce a set of
+   NSEC3s that use different salts that cover the entire zone, it is
+   computationally infeasible to generate such a set.  See Section 8.2
+   for further discussion.
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 8]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   The salt value SHOULD be changed from time to time - this is to
+   prevent the use of a precomputed dictionary to reduce the cost of
+   enumeration.
+
+3.1.6.  The Next Hashed Ownername Field
+
+   The Next Hashed Ownername field contains the next hashed ownername in
+   hash order.  That is, given the set of all hashed owernames, the Next
+   Hashed Ownername contains the hash value that immediately follows the
+   owner hash value for the given NSEC3 record.  The value of the Next
+   Hashed Ownername Field in the last NSEC3 record in the zone is the
+   same as the ownername of the first NSEC3 RR in the zone in hash
+   order.
+
+   Hashed ownernames of glue RRsets MUST NOT be listed in the Next
+   Hashed Ownername unless at least one authoritative RRset exists at
+   the same ownername.  Hashed ownernames of delegation NS RRsets MUST
+   be listed if the Opt-In bit is clear.
+
+   Note that the Next Hashed Ownername field is not encoded, unlike the
+   NSEC3 RR's ownername.  It is the unmodified binary hash value.  It
+   does not include the name of the containing zone.
+
+   The length of this field is the length of the hash value produced by
+   the hash function selected by the Hash Function field.
+
+3.1.7.  The Type Bit Maps Field
+
+   The Type Bit Maps field identifies the RRset types which exist at the
+   NSEC3 RR's original ownername.
+
+   The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
+   generation, and MUST be ignored during processing.
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Blocks are present in the NSEC3 RR RDATA in increasing numerical
+   order.
+
+   "|" denotes concatenation
+
+   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                 [Page 9]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
+   1, it indicates that an RRset of that type is present for the NSEC3
+   RR's ownername.  If a bit is set to 0, it indicates that no RRset of
+   that type is present for the NSEC3 RR's ownername.
+
+   Since bit 0 in window block 0 refers to the non-existing RR type 0,
+   it MUST be set to 0.  After verification, the validator MUST ignore
+   the value of bit 0 in window block 0.
+
+   Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
+   (section 3.1) or within the range reserved for assignment only to
+   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
+   zone data.  If encountered, they must be ignored upon reading.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value, within that block, among the set of RR types present at the
+   NSEC3 RR's actual ownername.  Trailing zero octets not specified MUST
+   be interpreted as zero octets.
+
+3.2.  The NSEC3 RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Opt-In Flag Field is represented as an unsigned decimal integer.
+   The value is either 0 or 1.
+
+   The Hash field is presented as a mnemonic of the hash or as an
+   unsigned decimal integer.  The value has a maximum of 127.
+
+   The Iterations field is presented as an unsigned decimal integer.
+
+   The Salt Length field is not presented.
+
+   The Salt field is represented as a sequence of case-insensitive
+   hexadecimal digits.  Whitespace is not allowed within the sequence.
+   The Salt Field is represented as "-" (without the quotes) when the
+   Salt Length field has value 0.
+
+   The Next Hashed Ownername field is represented as a sequence of case-
+   insensitive base32 digits, without whitespace.
+
+   The Type Bit Maps Field is represented as a sequence of RR type
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 10]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   mnemonics.  When the mnemonic is not known, the TYPE representation
+   as described in RFC 3597 [12] (section 5) MUST be used.
+
+
+4.  Creating Additional NSEC3 RRs for Empty Non-Terminals
+
+   In order to prove the non-existence of a record that might be covered
+   by a wildcard, it is necessary to prove the existence of its closest
+   encloser.  A closest encloser might be an empty non-terminal.
+
+   Additional NSEC3 RRs are generated for empty non-terminals.  These
+   additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
+   existing RRs in the zone except that their type-maps only indicated
+   the existence of an NSEC3 RRset and an RRSIG RRset.
+
+   This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
+   not appear at names that did not exist before the zone was signed.
+   [Comment.1]
+
+
+5.  Calculation of the Hash
+
+   Define H(x) to be the hash of x using the hash function selected by
+   the NSEC3 record and || to indicate concatenation.  Then define:
+
+   IH(salt,x,0)=H(x || salt)
+
+   IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
+
+   Then the calculated hash of an ownername is
+   IH(salt,ownername,iterations-1), where the ownername is the canonical
+   form.
+
+   The canonical form of the ownername is the wire format of the
+   ownername where:
+   1.  The ownername is fully expanded (no DNS name compression) and
+       fully qualified;
+   2.  All uppercase US-ASCII letters are replaced by the corresponding
+       lowercase US-ASCII letters;
+   3.  If the ownername is a wildcard name, the ownername is in its
+       original unexpanded form, including the "*" label (no wildcard
+       substitution);
+   This form is as defined in section 6.2 of RFC 4034 ([4]).
+
+
+6.  Including NSEC3 RRs in a Zone
+
+   Each ownername within the zone that owns authoritative RRsets MUST
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 11]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   have a corresponding NSEC3 RR.  Ownernames that correspond to
+   unsigned delegations MAY have a corresponding NSEC3 RR, however, if
+   there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
+   set to 1.  Other non-authoritative RRs are not included in the set of
+   NSEC3 RRs.
+
+   Each empty non-terminal MUST have an NSEC3 record.
+
+   The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
+   value field in the zone SOA RR.
+
+   The type bitmap of every NSEC3 resource record in a signed zone MUST
+   indicate the presence of both the NSEC3 RR type itself and its
+   corresponding RRSIG RR type.
+
+   The following steps describe the proper construction of NSEC3
+   records.  [Comment.2]
+   1.  For each unique original ownername in the zone, add an NSEC3
+       RRset.  If Opt-In is being used, ownernames of unsigned
+       delegations may be excluded, but must be considered for empty-
+       non-terminals.  The ownername of the NSEC3 RR is the hashed
+       equivalent of the original owner name, prepended to the zone
+       name.  The Next Hashed Ownername field is left blank for the
+       moment.  If Opt-In is being used, set the Opt-In bit to one.
+   2.  For each RRset at the original owner name, set the corresponding
+       bit in the type bit map.
+   3.  If the difference in number of labels between the apex and the
+       original ownername is greater then 1, additional NSEC3s need to
+       be added for every empty non-terminal between the apex and the
+       original ownername.  This process may generate NSEC3 RRs with
+       duplicate hashed ownernames.
+   4.  Sort the set of NSEC3 RRs into hash order.  Hash order is the
+       ascending numerical order of the non-encoded hash values.
+   5.  Combine NSEC3 RRs with identical hashed ownernames by replacing
+       with a single NSEC3 RR with the type map consisting of the union
+       of the types represented by the set of NSEC3 RRs.
+   6.  In each NSEC3 RR, insert the Next Hashed Ownername by using the
+       value of the next NSEC3 RR in hash order.  The Next Hashed
+       Ownername of the last NSEC3 in the zone contains the value of the
+       hashed ownername of the first NSEC3 in the hash order.
+
+
+7.  Responding to NSEC3 Queries
+
+   Since NSEC3 ownernames are not represented in the NSEC3 chain like
+   other zone ownernames, direct queries for NSEC3 ownernames present a
+   special case.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 12]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   The special case arises when the following are all true:
+   o  The QNAME equals an existing NSEC3 ownername, and
+   o  There are no other record types that exist at QNAME, and
+   o  The QTYPE does not equal NSEC3.
+   These conditions describe a particular case: the answer should be a
+   NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
+   include in the authority section.
+
+   However, the NSEC3 RRset with ownername equal to QNAME is able to
+   prove its own existence.  Thus, when answering this query, the
+   authoritative server MUST include the NSEC3 RRset whose ownername
+   equals QNAME.  This RRset proves that QNAME is an existing name with
+   types NSEC3 and RRSIG.  The authoritative server MUST also include
+   the NSEC3 RRset that covers the hash of QNAME.  This RRset proves
+   that no other types exist.
+
+   When validating a NOERROR/NODATA response, validators MUST check for
+   a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
+   (validated) NSEC3 RRset as proof that QNAME exists.  The validator
+   MUST also check for an NSEC3 RRset that covers the hash of QNAME as
+   proof that QTYPE doesn't exist.
+
+   Other cases where the QNAME equals an existing NSEC3 ownername may be
+   answered normally.
+
+
+8.  Special Considerations
+
+   The following paragraphs clarify specific behaviour explain special
+   considerations for implementations.
+
+8.1.  Proving Nonexistence
+
+   If a wildcard resource record appears in a zone, its asterisk label
+   is treated as a literal symbol and is treated in the same way as any
+   other ownername for purposes of generating NSEC3 RRs.  RFC 4035 [5]
+   describes the impact of wildcards on authenticated denial of
+   existence.
+
+   In order to prove there exist no RRs for a domain, as well as no
+   source of synthesis, an RR must be shown for the closest encloser,
+   and non-existence must be shown for all closer labels and for the
+   wildcard at the closest encloser.
+
+   This can be done as follows.  If the QNAME in the query is
+   omega.alfa.beta.example, and the closest encloser is beta.example
+   (the nearest ancestor to omega.alfa.beta.example), then the server
+   should return an NSEC3 that demonstrates the nonexistence of
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 13]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
+   *.beta.example, and an NSEC3 that demonstrates the existence of
+   beta.example.  This takes between one and three NSEC3 records, since
+   a single record can, by chance, prove more than one of these facts.
+
+   When a verifier checks this response, then the existence of
+   beta.example together with the non-existence of alfa.beta.example
+   proves that the closest encloser is indeed beta.example.  The non-
+   existence of *.beta.example shows that there is no wildcard at the
+   closest encloser, and so no source of synthesis for
+   omega.alfa.beta.example.  These two facts are sufficient to satisfy
+   the resolver that the QNAME cannot be resolved.
+
+   In practice, since the NSEC3 owner and next names are hashed, if the
+   server responds with an NSEC3 for beta.example, the resolver will
+   have to try successively longer names, starting with example, moving
+   to beta.example, alfa.beta.example, and so on, until one of them
+   hashes to a value that matches the interval (but not the ownername
+   nor next owner name) of one of the returned NSEC3s (this name will be
+   alfa.beta.example).  Once it has done this, it knows the closest
+   encloser (i.e. beta.example), and can then easily check the other two
+   required proofs.
+
+   Note that it is not possible for one of the shorter names tried by
+   the resolver to be denied by one of the returned NSEC3s, since, by
+   definition, all these names exist and so cannot appear within the
+   range covered by an NSEC3.  Note, however, that the first name that
+   the resolver tries MUST be the apex of the zone, since names above
+   the apex could be denied by one of the returned NSEC3s.
+
+8.2.  Salting
+
+   Augmenting original ownernames with salt before hashing increases the
+   cost of a dictionary of pre-generated hash-values.  For every bit of
+   salt, the cost of a precomputed dictionary doubles (because there
+   must be an entry for each word combined with each possible salt
+   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
+   salt, multiplying the cost by 2^2040.  This means that an attacker
+   must, in practice, recompute the dictionary each time the salt is
+   changed.
+
+   There MUST be at least one complete set of NSEC3s for the zone using
+   the same salt value.
+
+   The salt SHOULD be changed periodically to prevent precomputation
+   using a single salt.  It is RECOMMENDED that the salt be changed for
+   every resigning.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 14]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   Note that this could cause a resolver to see records with different
+   salt values for the same zone.  This is harmless, since each record
+   stands alone (that is, it denies the set of ownernames whose hashes,
+   using the salt in the NSEC3 record, fall between the two hashes in
+   the NSEC3 record) - it is only the server that needs a complete set
+   of NSEC3 records with the same salt in order to be able to answer
+   every possible query.
+
+   There is no prohibition with having NSEC3 with different salts within
+   the same zone.  However, in order for authoritative servers to be
+   able to consistently find covering NSEC3 RRs, the authoritative
+   server MUST choose a single set of parameters (algorithm, salt, and
+   iterations) to use when selecting NSEC3s.  In the absence of any
+   other metadata, the server does this by using the parameters from the
+   zone apex NSEC3, recognizable by the presence of the SOA bit in the
+   type map.  If there is more than one NSEC3 record that meets this
+   description, then the server may arbitrarily choose one.  Because of
+   this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
+   of a complete NSEC3 set.  Conversely, if there exists an incomplete
+   set of NSEC3 RRs using the same parameters within a zone, there MUST
+   NOT be an NSEC3 RR using those parameters with the SOA bit set.
+
+8.3.  Iterations
+
+   Setting the number of iterations used allows the zone owner to choose
+   the cost of computing a hash, and so the cost of generating a
+   dictionary.  Note that this is distinct from the effect of salt,
+   which prevents the use of a single precomputed dictionary for all
+   time.
+
+   Obviously the number of iterations also affects the zone owner's cost
+   of signing the zone as well as the verifiers cost of verifying the
+   zone.  We therefore impose an upper limit on the number of
+   iterations.  We base this on the number of iterations that
+   approximately doubles the cost of signing the zone.
+
+   A zone owner MUST NOT use a value higher than shown in the table
+   below for iterations.  A resolver MAY treat a response with a higher
+   value as bogus.
+
+                       +--------------+------------+
+                       | RSA Key Size | Iterations |
+                       +--------------+------------+
+                       | 1024         | 3,000      |
+                       | 2048         | 20,000     |
+                       | 4096         | 150,000    |
+                       +--------------+------------+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 15]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                       +--------------+------------+
+                       | DSA Key Size | Iterations |
+                       +--------------+------------+
+                       | 1024         | 1,500      |
+                       | 2048         | 5,000      |
+                       +--------------+------------+
+
+   This table is based on 150,000 SHA-1's per second, 50 RSA signs per
+   second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
+   sign per second for 4096 bit keys, 100 DSA signs per second for 1024
+   bit keys and 30 signs per second for 2048 bit keys.
+
+   Note that since RSA verifications are 10-100 times faster than
+   signatures (depending on key size), in the case of RSA the legal
+   values of iterations can substantially increase the cost of
+   verification.
+
+8.4.  Hash Collision
+
+   Hash collisions occur when different messages have the same hash
+   value.  The expected number of domain names needed to give a 1 in 2
+   chance of a single collision is about 2^(n/2) for a hash of length n
+   bits (i.e. 2^80 for SHA-1).  Though this probability is extremely
+   low, the following paragraphs deal with avoiding collisions and
+   assessing possible damage in the event of an attack using hash
+   collisions.
+
+8.4.1.  Avoiding Hash Collisions during generation
+
+   During generation of NSEC3 RRs, hash values are supposedly unique.
+   In the (academic) case of a collision occurring, an alternative salt
+   MUST be chosen and all hash values MUST be regenerated.
+
+8.4.2.  Second Preimage Requirement Analysis
+
+   A cryptographic hash function has a second-preimage resistance
+   property.  The second-preimage resistance property means that it is
+   computationally infeasible to find another message with the same hash
+   value as a given message, i.e. given preimage X, to find a second
+   preimage X' != X such that hash(X) = hash(X').  The work factor for
+   finding a second preimage is of the order of 2^160 for SHA-1.  To
+   mount an attack using an existing NSEC3 RR, an adversary needs to
+   find a second preimage.
+
+   Assuming an adversary is capable of mounting such an extreme attack,
+   the actual damage is that a response message can be generated which
+   claims that a certain QNAME (i.e. the second pre-image) does exist,
+   while in reality QNAME does not exist (a false positive), which will
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 16]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   either cause a security aware resolver to re-query for the non-
+   existent name, or to fail the initial query.  Note that the adversary
+   can't mount this attack on an existing name but only on a name that
+   the adversary can't choose and does not yet exist.
+
+8.4.3.  Possible Hash Value Truncation Method
+
+   The previous sections outlined the low probability and low impact of
+   a second-preimage attack.  When impact and probability are low, while
+   space in a DNS message is costly, truncation is tempting.  Truncation
+   might be considered to allow for shorter ownernames and rdata for
+   hashed labels.  In general, if a cryptographic hash is truncated to n
+   bits, then the expected number of domains required to give a 1 in 2
+   probability of a single collision is approximately 2^(n/2) and the
+   work factor to produce a second preimage is 2^n.
+
+   An extreme hash value truncation would be truncating to the shortest
+   possible unique label value.  This would be unwise, since the work
+   factor to produce second preimages would then approximate the size of
+   the zone (sketch of proof: if the zone has k entries, then the length
+   of the names when truncated down to uniqueness should be proportional
+   to log_2(k).  Since the work factor to produce a second pre-image is
+   2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
+   C is some constant), i.e.  C'k - a work factor of k).
+
+   Though the mentioned truncation can be maximized to a certain
+   extreme, the probability of collision increases exponentially for
+   every truncated bit.  Given the low impact of hash value collisions
+   and limited space in DNS messages, the balance between truncation
+   profit and collision damage may be determined by local policy.  Of
+   course, the size of the corresponding RRSIG RR is not reduced, so
+   truncation is of limited benefit.
+
+   Truncation could be signaled simply by reducing the length of the
+   first label in the ownername.  Note that there would have to be a
+   corresponding reduction in the length of the Next Hashed Ownername
+   field.
+
+8.4.4.  Server Response to a Run-time Collision
+
+   In the astronomically unlikely event that a server is unable to prove
+   nonexistence because the hash of the name that does not exist
+   collides with a name that does exist, the server is obviously broken,
+   and should, therefore, return a response with an RCODE of 2 (server
+   failure).
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 17]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+8.4.5.  Parameters that Cover the Zone
+
+   Secondary servers (and perhaps other entities) need to reliably
+   determine which NSEC3 parameters (that is, hash, salt and iterations)
+   are present at every hashed ownername, in order to be able to choose
+   an appropriate set of NSEC3 records for negative responses.  This is
+   indicated by the parameters at the apex: any set of parameters that
+   is used in an NSEC3 record whose original ownername is the apex of
+   the zone MUST be present throughout the zone.
+
+   A method to determine which NSEC3 in a complete chain corresponds to
+   the apex is to look for a NSEC3 RRset which has the SOA bit set in
+   the RDATA bit type maps field.
+
+
+9.  Performance Considerations
+
+   Iterated hashes impose a performance penalty on both authoritative
+   servers and resolvers.  Therefore, the number of iterations should be
+   carefully chosen.  In particular it should be noted that a high value
+   for iterations gives an attacker a very good denial of service
+   attack, since the attacker need not bother to verify the results of
+   their queries, and hence has no performance penalty of his own.
+
+   On the other hand, nameservers with low query rates and limited
+   bandwidth are already subject to a bandwidth based denial of service
+   attack, since responses are typically an order of magnitude larger
+   than queries, and hence these servers may choose a high value of
+   iterations in order to increase the difficulty of offline attempts to
+   enumerate their namespace without significantly increasing their
+   vulnerability to denial of service attacks.
+
+
+10.  IANA Considerations
+
+   IANA needs to allocate a RR type code for NSEC3 from the standard RR
+   type space (type XXX requested).  IANA needs to open a new registry
+   for the NSEC3 Hash Functions.  The range for this registry is 0-127.
+   Defined types are:
+
+      0 is reserved.
+      1 is SHA-1 ([13]).
+      127 is experimental.
+
+
+11.  Security Considerations
+
+   The NSEC3 records are still susceptible to dictionary attacks (i.e.
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 18]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   the attacker retrieves all the NSEC3 records, then calculates the
+   hashes of all likely domain names, comparing against the hashes found
+   in the NSEC3 records, and thus enumerating the zone).  These are
+   substantially more expensive than enumerating the original NSEC
+   records would have been, and in any case, such an attack could also
+   be used directly against the name server itself by performing queries
+   for all likely names, though this would obviously be more detectable.
+   The expense of this off-line attack can be chosen by setting the
+   number of iterations in the NSEC3 RR.
+
+   Domains are also susceptible to a precalculated dictionary attack -
+   that is, a list of hashes for all likely names is computed once, then
+   NSEC3 is scanned periodically and compared against the precomputed
+   hashes.  This attack is prevented by changing the salt on a regular
+   basis.
+
+   Walking the NSEC3 RRs will reveal the total number of records in the
+   zone, and also what types they are.  This could be mitigated by
+   adding dummy entries, but certainly an upper limit can always be
+   found.
+
+   Hash collisions may occur.  If they do, it will be impossible to
+   prove the non-existence of the colliding domain - however, this is
+   fantastically unlikely, and, in any case, DNSSEC already relies on
+   SHA-1 to not collide.
+
+   Responses to queries where QNAME equals an NSEC3 ownername that has
+   no other types may be undetectably changed from a NOERROR/NODATA
+   response to a NAME ERROR response.
+
+   The Opt-In Flag (O) allows for unsigned names, in the form of
+   delegations to unsigned subzones, to exist within an otherwise signed
+   zone.  All unsigned names are, by definition, insecure, and their
+   validity or existence cannot by cryptographically proven.
+
+   In general:
+      Records with unsigned names (whether existing or not) suffer from
+      the same vulnerabilities as records in an unsigned zone.  These
+      vulnerabilities are described in more detail in [16] (note in
+      particular sections 2.3, "Name Games" and 2.6, "Authenticated
+      Denial").
+      Records with signed names have the same security whether or not
+      Opt-In is used.
+
+   Note that with or without Opt-In, an insecure delegation may be
+   undetectably altered by an attacker.  Because of this, the primary
+   difference in security when using Opt-In is the loss of the ability
+   to prove the existence or nonexistence of an insecure delegation
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 19]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   within the span of an Opt-In NSEC3 record.
+
+   In particular, this means that a malicious entity may be able to
+   insert or delete records with unsigned names.  These records are
+   normally NS records, but this also includes signed wildcard
+   expansions (while the wildcard record itself is signed, its expanded
+   name is an unsigned name).
+
+   For example, if a resolver received the following response from the
+   example zone above:
+
+   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
+
+           RCODE=NOERROR
+
+           Answer Section:
+
+           Authority Section:
+           DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
+           EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
+                                          RRSIG DNSKEY
+           abcd...                 RRSIG  NSEC3 ...
+
+           Additional Section:
+
+   The resolver would have no choice but to accept that the referral to
+   NS.FORGED. is valid.  If a wildcard existed that would have been
+   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+   have undetectably removed it and replaced it with the forged
+   delegation.
+
+   Note that being able to add a delegation is functionally equivalent
+   to being able to add any record type: an attacker merely has to forge
+   a delegation to nameserver under his/her control and place whatever
+   records needed at the subzone apex.
+
+   While in particular cases, this issue may not present a significant
+   security problem, in general it should not be lightly dismissed.
+   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+   In particular, zone signing tools SHOULD NOT default to using Opt-In,
+   and MAY choose to not support Opt-In at all.
+
+
+12.  References
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 20]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+12.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions",
+         RFC 4035, March 2005.
+
+   [6]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+         April 1997.
+
+   [7]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+   [8]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+         RFC 2308, March 1998.
+
+   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [10]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+         RFC 3658, December 2003.
+
+   [11]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
+         Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+         September 2000.
+
+   [12]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+         Types", RFC 3597, September 2003.
+
+   [13]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
+         RFC 3174, September 2001.
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 21]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+12.2.  Informative References
+
+   [14]  Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
+         draft-vixie-dnssec-ter-01 (work in progress), June 2004.
+
+   [15]  Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
+         Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
+         October 2005.
+
+   [16]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+Editorial Comments
+
+   [Comment.1]  Although, strictly speaking, the names *did* exist.
+
+   [Comment.2]  Note that this method makes it impossible to detect
+                (extremely unlikely) hash collisions.
+
+
+Appendix A.  Example Zone
+
+   This is a zone showing its NSEC3 records.  They can also be used as
+   test vectors for the hash algorithm.
+
+   The data in the example zone is currently broken, as it uses a
+   different base32 alphabet.  This shall be fixed in the next release.
+
+
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600 )
+                  3600 RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+                  3600 NS     ns1.example.
+                  3600 NS     ns2.example.
+                  3600 RRSIG  NS 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+                              1SH5r/wfjuCg+g== )
+                  3600 MX     1 xx.example.
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 22]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                  3600 RRSIG  MX 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
+                              NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
+                              S/o/g5C8VM6ftQ== )
+                  3600 DNSKEY 257 3 5 (
+                              AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
+                              cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
+                              zsYKWJ7BvR2894hX
+                              ) ; Key ID = 21960
+                  3600 DNSKEY 256 3 5 (
+                              AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
+                              5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
+                              ExXT48OGGdbfIme5
+                              ) ; Key ID = 62699
+                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
+                              xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
+                              mTkunTYzqWJrmQ== )
+                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
+                              20050612112304 21960 example.
+                              SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
+                              ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
+                              3w7ZY2UWyYIvpw== )
+   5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              7nomf47k3vlidh4vxahhpp47l3tgv7a2
+                              NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
+                              Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
+                              sb7KfbaUo/vzAg== )
+   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+                              MX NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+                              MEFQmc/gEuxojA== )
+   a.example.     3600 IN NS  ns1.a.example.
+                  3600 IN NS  ns2.a.example.
+                  3600 DS     58470 5 1 3079F1593EBAD6DC121E202A8B
+                              766A6A4837206C )
+                  3600 RRSIG  DS 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 23]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              20050612112304 62699 example.
+                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+                              0kx7rGKTc3RQDA== )
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+   ai.example.    3600 IN A   192.0.2.9
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+                              ZXW5S+1VjMZYzQ== )
+                  3600 HINFO  "KLH-10" "ITS"
+                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
+                              tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
+                              VGNmbgPnqDVPiA== )
+                  3600 AAAA   2001:db8:0:0:0:0:f00:baa9
+                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+                              l5/UqLCJJ9BDMg== )
+   b.example.     3600 IN NS  ns1.b.example.
+                  3600 IN NS  ns2.b.example.
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              gmnfcccja7wkax3iv26bs75myptje3qk
+                              MX DNSKEY NS SOA NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+                              MOiKMSHozVebqw== )
+   gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
+                              DS NS NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
+                              ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
+                              OwQBGbOegrW/Zw== )
+   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 24]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              kcll7fqfnisuhfekckeeqnmbbd4maanu
+                              NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+                              94Zbq3k8lgdpZA== )
+   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3  1 1 1 (
+                              deadbeaf
+                              n42hbhnjj333xdxeybycax5ufvntux5d
+                              MX NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+                              TOLtc5jPrkL4zQ== )
+   n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              nimwfwcnbeoodmsc6npv3vuaagaevxxu
+                              A NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
+                              91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
+                              xFPFGRIW3wKnrA== )
+   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
+                              HINFO A AAAA NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+                              jL33Wm1p07TBdw== )
+   ns1.example.   3600 A      192.0.2.1
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+                              nWWLepz1PjjShQ== )
+   ns2.example.   3600 A      192.0.2.2
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+                              AkeTJu3J3auUiA== )
+   vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 25]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              wbyijvpnyj33pcpi3i44ecnibnaj7eiw
+                              HINFO A AAAA NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
+                              kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
+                              5SNSHIyfpfsi6A== )
+   *.w.example.   3600 MX     1 ai.example.
+                  3600 RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+                              gQlgxEwhvQDEaQ== )
+   x.w.example.   3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+                              U9VazOa1KEIq1w== )
+   x.y.w.example. 3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 4 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
+                              uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
+                              9VrQvJjwbllAfA== )
+   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+                              A NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+                              oorBv4xkb0flXw== )
+   xx.example.    3600 A      192.0.2.10
+                  3600 RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+                              cxwCXWj82GVGdw== )
+                  3600 HINFO  "KLH-10" "TOPS-20"
+                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
+                              OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
+                              KMf4DgNBDj+dIQ== )
+                  3600 AAAA   2001:db8:0:0:0:0:f00:baaa
+                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 26]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+                              20050612112304 62699 example.
+                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+                              rzKKwb8J04/ILw== )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3  0 1 1 (
+                              deadbeaf
+                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+                              MX NSEC3 RRSIG )
+                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+                              OcFlrPGPMm48/A== )
+
+
+Appendix B.  Example Responses
+
+   The examples in this section show response messages using the signed
+   zone example in Appendix A.
+
+B.1.  answer
+
+   A successful query to an authoritative server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 27]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   x.w.example.        IN MX
+
+   ;; Answer
+   x.w.example.   3600 IN MX  1 xx.example.
+   x.w.example.   3600 IN RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+                              U9VazOa1KEIq1w== )
+
+   ;; Authority
+   example.       3600 IN NS  ns1.example.
+   example.       3600 IN NS  ns2.example.
+   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+                              1SH5r/wfjuCg+g== )
+
+   ;; Additional
+   xx.example.    3600 IN A   192.0.2.10
+   xx.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+                              cxwCXWj82GVGdw== )
+   xx.example.    3600 IN AAAA   2001:db8::f00:baaa
+   xx.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+                              rzKKwb8J04/ILw== )
+   ns1.example.   3600 IN A   192.0.2.1
+   ns1.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+                              nWWLepz1PjjShQ== )
+   ns2.example.   3600 IN A   192.0.2.2
+   ns2.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+                              AkeTJu3J3auUiA== )
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 28]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   The query returned an MX RRset for "x.w.example".  The corresponding
+   RRSIG RR indicates that the MX RRset was signed by an "example"
+   DNSKEY with algorithm 5 and key tag 62699.  The resolver needs the
+   corresponding DNSKEY RR in order to authenticate this answer.  The
+   discussion below describes how a resolver might obtain this DNSKEY
+   RR.
+
+   The RRSIG RR indicates the original TTL of the MX RRset was 3600,
+   and, for the purpose of authentication, the current TTL is replaced
+   by 3600.  The RRSIG RR's labels field value of 3 indicates that the
+   answer was not the result of wildcard expansion.  The "x.w.example"
+   MX RRset is placed in canonical form, and, assuming the current time
+   falls between the signature inception and expiration dates, the
+   signature is authenticated.
+
+B.1.1.  Authenticating the Example DNSKEY RRset
+
+   This example shows the logical authentication process that starts
+   from a configured root DNSKEY RRset (or DS RRset) and moves down the
+   tree to authenticate the desired "example" DNSKEY RRset.  Note that
+   the logical order is presented for clarity.  An implementation may
+   choose to construct the authentication as referrals are received or
+   to construct the authentication chain only after all RRsets have been
+   obtained, or in any other combination it sees fit.  The example here
+   demonstrates only the logical process and does not dictate any
+   implementation rules.
+
+   We assume the resolver starts with a configured DNSKEY RRset for the
+   root zone (or a configured DS RRset for the root zone).  The resolver
+   checks whether this configured DNSKEY RRset is present in the root
+   DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
+   RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
+   root DNSKEY RRset, and whether the signature lifetime is valid.  If
+   all these conditions are met, all keys in the DNSKEY RRset are
+   considered authenticated.  The resolver then uses one (or more) of
+   the root DNSKEY RRs to authenticate the "example" DS RRset.  Note
+   that the resolver may have to query the root zone to obtain the root
+   DNSKEY RRset or "example" DS RRset.
+
+   Once the DS RRset has been authenticated using the root DNSKEY, the
+   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+   RR that matches one of the authenticated "example" DS RRs.  If such a
+   matching "example" DNSKEY is found, the resolver checks whether this
+   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
+   lifetime is valid.  If these conditions are met, all keys in the
+   "example" DNSKEY RRset are considered authenticated.
+
+   Finally, the resolver checks that some DNSKEY RR in the "example"
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 29]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   DNSKEY RRset uses algorithm 5 and has a key tag of 62699.  This
+   DNSKEY is used to authenticate the RRSIG included in the response.
+   If multiple "example" DNSKEY RRs match this algorithm and key tag,
+   then each DNSKEY RR is tried, and the answer is authenticated if any
+   of the matching DNSKEY RRs validate the signature as described above.
+
+B.2.  Name Error
+
+   An authoritative name error.  The NSEC3 RRs prove that the name does
+   not exist and that no covering wildcard exists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 30]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=3
+   ;;
+   ;; Question
+   a.c.x.w.example.         IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+                              MX NSEC3 RRSIG )
+   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+                              MEFQmc/gEuxojA== )
+   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
+                              HINFO A AAAA NSEC3 RRSIG )
+   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+                              jL33Wm1p07TBdw== )
+   ;; Additional
+   ;; (empty)
+
+   The query returned two NSEC3 RRs that prove that the requested data
+   does not exist and no wildcard applies.  The negative reply is
+   authenticated by verifying both NSEC3 RRs.  The NSEC3 RRs are
+   authenticated in a manner identical to that of the MX RRset discussed
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 31]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   above.  At least one of the owner names of the NSEC3 RRs will match
+   the closest encloser.  At least one of the NSEC3 RRs prove that there
+   exists no longer name.  At least one of the NSEC3 RRs prove that
+   there exists no wildcard RRsets that should have been expanded.  The
+   closest encloser can be found by hashing the apex ownername (The SOA
+   RR's ownername, or the ownername of the DNSKEY RRset referred by an
+   RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
+   if that fails, continue by adding labels.  In other words, the
+   resolver first hashes example, checks for a matching NSEC3 ownername,
+   then hashes w.example, checks, and finally hashes w.x.example and
+   checks.
+
+   In the above example, the name 'x.w.example' hashes to
+   '7nomf47k3vlidh4vxahhpp47l3tgv7a2'.  This indicates that this might
+   be the closest encloser.  To prove that 'c.x.w.example' and
+   '*.x.w.example' do not exists, these names are hashed to respectively
+   'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
+   'cvljzyf6nsckjowghch4tt3nohocpdka'.  The two NSEC3 records prove that
+   these hashed ownernames do not exists, since the names are within the
+   given intervals.
+
+B.3.  No Data Error
+
+   A "no data" response.  The NSEC3 RR proves that the name exists and
+   that the requested RR type does not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 32]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   ns1.example.        IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+                              A NSEC3 RRSIG )
+   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+                              oorBv4xkb0flXw== )
+   ;; Additional
+   ;; (empty)
+
+   The query returned an NSEC3 RR that proves that the requested name
+   exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
+   but the requested RR type does not exist (type MX is absent in the
+   type code list of the NSEC RR).  The negative reply is authenticated
+   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
+   identical to that of the MX RRset discussed above.
+
+B.3.1.  No Data Error, Empty Non-Terminal
+
+   A "no data" response because of an empty non-terminal.  The NSEC3 RR
+   proves that the name exists and that the requested RR type does not.
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 33]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   y.w.example.        IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              kcll7fqfnisuhfekckeeqnmbbd4maanu
+                              NSEC3 RRSIG )
+   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+                              94Zbq3k8lgdpZA== )
+
+   The query returned an NSEC3 RR that proves that the requested name
+   exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
+   but the requested RR type does not exist (Type A is absent in the
+   type-bit-maps of the NSEC3 RR).  The negative reply is authenticated
+   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
+   identical to that of the MX RRset discussed above.  Note that, unlike
+   generic empty non terminal proof using NSECs, this is identical to
+   proving a No Data Error.  This example is solely mentioned to be
+   complete.
+
+B.4.  Referral to Signed Zone
+
+   Referral to a signed zone.  The DS RR contains the data which the
+   resolver will need to validate the corresponding DNSKEY RR in the
+   child zone's apex.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 34]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR DO RCODE=0
+   ;;
+
+   ;; Question
+   mc.a.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   a.example.     3600 IN NS  ns1.a.example.
+   a.example.     3600 IN NS  ns2.a.example.
+   a.example.     3600 IN DS  58470 5 1 (
+                              3079F1593EBAD6DC121E202A8B766A6A4837
+                              206C )
+   a.example.     3600 IN RRSIG  DS 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+                              0kx7rGKTc3RQDA== )
+
+   ;; Additional
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+
+   The query returned a referral to the signed "a.example." zone.  The
+   DS RR is authenticated in a manner identical to that of the MX RRset
+   discussed above.  This DS RR is used to authenticate the "a.example"
+   DNSKEY RRset.
+
+   Once the "a.example" DS RRset has been authenticated using the
+   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
+   matching "a.example" DNSKEY is found, the resolver checks whether
+   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
+   the signature lifetime is valid.  If all these conditions are met,
+   all keys in the "a.example" DNSKEY RRset are considered
+   authenticated.
+
+B.5.  Referral to Unsigned Zone using the Opt-In Flag
+
+   The NSEC3 RR proves that nothing for this delegation was signed in
+   the parent zone.  There is no proof that the delegation exists
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 35]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR DO RCODE=0
+   ;;
+   ;; Question
+   mc.b.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   b.example.     3600 IN NS  ns1.b.example.
+   b.example.     3600 IN NS  ns2.b.example.
+   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3  1 1 1 (
+                              deadbeaf
+                              n42hbhnjj333xdxeybycax5ufvntux5d
+                              MX NSEC3 RRSIG )
+   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+                              TOLtc5jPrkL4zQ== )
+
+   ;; Additional
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+
+   The query returned a referral to the unsigned "b.example." zone.  The
+   NSEC3 proves that no authentication leads from "example" to
+   "b.example", since the hash of "b.example"
+   ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
+   the NSEC3 opt-in bit is set.  The NSEC3 RR is authenticated in a
+   manner identical to that of the MX RRset discussed above.
+
+B.6.  Wildcard Expansion
+
+   A successful query that was answered via wildcard expansion.  The
+   label count in the answer's RRSIG RR indicates that a wildcard RRset
+   was expanded to produce this response, and the NSEC3 RR proves that
+   no closer match exists in the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 36]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN MX
+
+   ;; Answer
+   a.z.w.example. 3600 IN MX  1 ai.example.
+   a.z.w.example. 3600 IN RRSIG  MX 5 3 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+                              gQlgxEwhvQDEaQ== )
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+                              1SH5r/wfjuCg+g== )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+                              MX NSEC3 RRSIG )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+                              OcFlrPGPMm48/A== )
+   ;; Additional
+   ai.example.    3600 IN A   192.0.2.9
+   ai.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+                              ZXW5S+1VjMZYzQ== )
+   ai.example.    3600 AAAA   2001:db8::f00:baa9
+   ai.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+                              l5/UqLCJJ9BDMg== )
+
+   The query returned an answer that was produced as a result of
+   wildcard expansion.  The answer section contains a wildcard RRset
+   expanded as it would be in a traditional DNS response, and the
+   corresponding RRSIG indicates that the expanded wildcard MX RRset was
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 37]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
+   The RRSIG indicates that the original TTL of the MX RRset was 3600,
+   and, for the purpose of authentication, the current TTL is replaced
+   by 3600.  The RRSIG labels field value of 2 indicates that the answer
+   is the result of wildcard expansion, as the "a.z.w.example" name
+   contains 4 labels.  The name "a.z.w.example" is replaced by
+   "*.w.example", the MX RRset is placed in canonical form, and,
+   assuming that the current time falls between the signature inception
+   and expiration dates, the signature is authenticated.
+
+   The NSEC3 proves that no closer match (exact or closer wildcard)
+   could have been used to answer this query, and the NSEC3 RR must also
+   be authenticated before the answer is considered valid.
+
+B.7.  Wildcard No Data Error
+
+   A "no data" response for a name covered by a wildcard.  The NSEC3 RRs
+   prove that the matching wildcard name does not have any RRs of the
+   requested type and that no closer match exists in the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 38]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN AAAA
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+                              MX NSEC3 RRSIG )
+   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+                              OcFlrPGPMm48/A== )
+   ;; Additional
+   ;; (empty)
+
+   The query returned NSEC3 RRs that prove that the requested data does
+   not exist and no wildcard applies.  The negative reply is
+   authenticated by verifying both NSEC3 RRs.
+
+B.8.  DS Child Zone No Data Error
+
+   A "no data" response for a QTYPE=DS query that was mistakenly sent to
+   a name server for the child zone.
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 39]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   example.            IN DS
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
+                              20050612112304 62699 example.
+                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+                              qYIt90txzE/4+g== )
+   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3  0 1 1 (
+                              deadbeaf
+                              gmnfcccja7wkax3iv26bs75myptje3qk
+                              MX DNSKEY NS SOA NSEC3 RRSIG )
+   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG  NSEC3 (
+                              5 2 3600 20050712112304
+                              20050612112304 62699 example.
+                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+                              MOiKMSHozVebqw== )
+
+   ;; Additional
+   ;; (empty)
+
+   The query returned NSEC RRs that shows the requested was answered by
+   a child server ("example" server).  The NSEC RR indicates the
+   presence of an SOA RR, showing that the answer is from the child .
+   Queries for the "example" DS RRset should be sent to the parent
+   servers ("root" servers).
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 40]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+Authors' Addresses
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London  W3 7LR
+   England
+
+   Phone: +44 (20) 8735 0686
+   Email: ben@algroup.co.uk
+
+
+   Geoffrey Sisson
+   Nominet
+
+
+   Roy Arends
+   Nominet
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 41]
+
+Internet-Draft                    nsec3                    February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Laurie, et al.           Expires August 5, 2006                [Page 42]
+
diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt
new file mode 100644
index 0000000..90d1a06
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-nsid-01.txt
@@ -0,0 +1,840 @@
+
+
+
+Network Working Group                                         R. Austein
+Internet-Draft                                                       ISC
+Expires: July 15, 2006                                  January 11, 2006
+
+
+                DNS Name Server Identifier Option (NSID)
+                       draft-ietf-dnsext-nsid-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  While existing ad-hoc
+   mechanism allow an operator to send follow-up queries when it is
+   necessary to debug such a configuration, the only completely reliable
+   way to obtain the identity of the name server which responded is to
+   have the name server include this information in the response itself.
+   This note defines a protocol extension to support this functionality.
+
+
+
+Austein                   Expires July 15, 2006                 [Page 1]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  4
+     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
+     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  5
+   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  6
+     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  8
+     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  8
+     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 2]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+1.  Introduction
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.
+
+   Existing ad-hoc mechanisms allow an operator to send follow-up
+   queries when it is necessary to debug such a configuration, but there
+   are situations in which this is not a totally satisfactory solution,
+   since anycast routing may have changed, or the server pool in
+   question may be behind some kind of extremely dynamic load balancing
+   hardware.  Thus, while these ad-hoc mechanisms are certainly better
+   than nothing (and have the advantage of already being deployed), a
+   better solution seems desirable.
+
+   Given that a DNS query is an idempotent operation with no retained
+   state, it would appear that the only completely reliable way to
+   obtain the identity of the name server which responded to a
+   particular query is to have that name server include identifying
+   information in the response itself.  This note defines a protocol
+   enhancement to achieve this.
+
+1.1.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 3]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+2.  Protocol
+
+   This note uses an EDNS [RFC2671] option to signal the resolver's
+   desire for information identifying the name server and to hold the
+   name server's response, if any.
+
+2.1.  Resolver Behavior
+
+   A resolver signals its desire for information identifying a name
+   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
+   pseudo-RR in the query message.
+
+   The resolver MUST NOT include any NSID payload data in the query
+   message.
+
+   The semantics of an NSID request are not transitive.  That is: the
+   presence of an NSID option in a query is a request that the name
+   server which receives the query identify itself.  If the name server
+   side of a recursive name server receives an NSID request, the client
+   is asking the recursive name server to identify itself; if the
+   resolver side of the recursive name server wishes to receive
+   identifying information, it is free to add NSID requests in its own
+   queries, but that is a separate matter.
+
+2.2.  Name Server Behavior
+
+   A name server which understands the NSID option and chooses to honor
+   a particular NSID request responds by including identifying
+   information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
+   in the response message.
+
+   The name server MUST ignore any NSID payload data that might be
+   present in the query message.
+
+   The NSID option is not transitive.  A name server MUST NOT send an
+   NSID option back to a resolver which did not request it.  In
+   particular, while a recursive name server may choose to add an NSID
+   option when sending a query, this has no effect on the presence or
+   absence of the NSID option in the recursive name server's response to
+   the original client.
+
+   As stated in Section 2.1, this mechanism is not restricted to
+   authoritative name servers; the semantics are intended to be equally
+   applicable to recursive name servers.
+
+2.3.  The NSID Option
+
+   The OPTION-CODE for the NSID option is [TBD].
+
+
+
+Austein                   Expires July 15, 2006                 [Page 4]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   The OPTION-DATA for the NSID option is an opaque byte string the
+   semantics of which are deliberately left outside the protocol.  See
+   Section 3.1 for discussion.
+
+2.4.  Presentation Format
+
+   User interfaces MUST read and write the content of the NSID option as
+   a sequence of hexadecimal digits, two digits per payload octet.
+
+   The NSID payload is binary data.  Any comparison between NSID
+   payloads MUST be a comparison of the raw binary data.  Copy
+   operations MUST NOT assume that the raw NSID payload is null-
+   terminated.  Any resemblance between raw NSID payload data and any
+   form of text is purely a convenience, and does not change the
+   underlying nature of the payload data.
+
+   See Section 3.3 for discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 5]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+3.  Discussion
+
+   This section discusses certain aspects of the protocol and explains
+   considerations that led to the chosen design.
+
+3.1.  The NSID Payload
+
+   The syntax and semantics of the content of the NSID option is
+   deliberately left outside the scope of this specification.  This
+   section describe some of the kinds of data that server administrators
+   might choose to provide as the content of the NSID option, and
+   explains the reasoning behind choosing a simple opaque byte string.
+
+   There are several possibilities for the payload of the NSID option:
+
+   o  It could be the "real" name of the specific name server within the
+      name server pool.
+
+   o  It could be the "real" IP address (IPv4 or IPv6) of the name
+      server within the name server pool.
+
+   o  It could be some sort of pseudo-random number generated in a
+      predictable fashion somehow using the server's IP address or name
+      as a seed value.
+
+   o  It could be some sort of probabilisticly unique identifier
+      initially derived from some sort of random number generator then
+      preserved across reboots of the name server.
+
+   o  It could be some sort of dynamicly generated identifier so that
+      only the name server operator could tell whether or not any two
+      queries had been answered by the same server.
+
+   o  It could be a blob of signed data, with a corresponding key which
+      might (or might not) be available via DNS lookups.
+
+   o  It could be a blob of encrypted data, the key for which could be
+      restricted to parties with a need to know (in the opinion of the
+      server operator).
+
+   o  It could be an arbitrary string of octets chosen at the discretion
+      of the name server operator.
+
+   Each of these options has advantages and disadvantages:
+
+   o  Using the "real" name is simple, but the name server may not have
+      a "real" name.
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 6]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   o  Using the "real" address is also simple, and the name server
+      almost certainly does have at least one non-anycast IP address for
+      maintenance operations, but the operator of the name server may
+      not be willing to divulge its non-anycast address.
+
+   o  Given that one common reason for using anycast DNS techniques is
+      an attempt to harden a critical name server against denial of
+      service attacks, some name server operators are likely to want an
+      identifier other than the "real" name or "real" address of the
+      name server instance.
+
+   o  Using a hash or pseudo-random number can provide a fixed length
+      value that the resolver can use to tell two name servers apart
+      without necessarily being able to tell where either one of them
+      "really" is, but makes debugging more difficult if one happens to
+      be in a friendly open environment.  Furthermore, hashing might not
+      add much value, since a hash based on an IPv4 address still only
+      involves a 32-bit search space, and DNS names used for servers
+      that operators might have to debug at 4am tend not to be very
+      random.
+
+   o  Probabilisticly unique identifiers have similar properties to
+      hashed identifiers, but (given a sufficiently good random number
+      generator) are immune to the search space issues.  However, the
+      strength of this approach is also its weakness: there is no
+      algorithmic transformation by which even the server operator can
+      associate name server instances with identifiers while debugging,
+      which might be annoying.  This approach also requires the name
+      server instance to preserve the probabilisticly unique identifier
+      across reboots, but this does not appear to be a serious
+      restriction, since authoritative nameservers almost always have
+      some form of nonvolatile storage in any case, and in the rare case
+      of a name server that does not have any way to store such an
+      identifier, nothing terrible will happen if the name server just
+      generates a new identifier every time it reboots.
+
+   o  Using an arbitrary octet string gives name server operators yet
+      another thing to configure, or mis-configure, or forget to
+      configure.  Having all the nodes in an anycast name server
+      constellation identify themselves as "My Name Server" would not be
+      particularly useful.
+
+   Given all of the issues listed above, there does not appear to be a
+   single solution that will meet all needs.  Section 2.3 therefore
+   defines the NSID payload to be an opaque byte string and leaves the
+   choice up to the implementor and name server operator.  The following
+   guidelines may be useful to implementors and server operators:
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 7]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   o  Operators for whom divulging the unicast address is an issue could
+      use the raw binary representation of a probabilisticly unique
+      random number.  This should probably be the default implementation
+      behavior.
+
+   o  Operators for whom divulging the unicast address is not an issue
+      could just use the raw binary representation of a unicast address
+      for simplicity.  This should only be done via an explicit
+      configuration choice by the operator.
+
+   o  Operators who really need or want the ability to set the NSID
+      payload to an arbitrary value could do so, but this should only be
+      done via an explicit configuration choice by the operator.
+
+   This approach appears to provide enough information for useful
+   debugging without unintentionally leaking the maintenance addresses
+   of anycast name servers to nogoodniks, while also allowing name
+   server operators who do not find such leakage threatening to provide
+   more information at their own discretion.
+
+3.2.  NSID Is Not Transitive
+
+   As specified in Section 2.1 and Section 2.2, the NSID option is not
+   transitive.  This is strictly a hop-by-hop mechanism.
+
+   Most of the discussion of name server identification to date has
+   focused on identifying authoritative name servers, since the best
+   known cases of anycast name servers are a subset of the name servers
+   for the root zone.  However, given that anycast DNS techniques are
+   also applicable to recursive name servers, the mechanism may also be
+   useful with recursive name servers.  The hop-by-hop semantics support
+   this.
+
+   While there might be some utility in having a transitive variant of
+   this mechanism (so that, for example, a stub resolver could ask a
+   recursive server to tell it which authoritative name server provided
+   a particular answer to the recursive name server), the semantics of
+   such a variant would be more complicated, and are left for future
+   work.
+
+3.3.  User Interface Issues
+
+   Given the range of possible payload contents described in
+   Section 3.1, it is not possible to define a single presentation
+   format for the NSID payload that is efficient, convenient,
+   unambiguous, and aesthetically pleasing.  In particular, while it is
+   tempting to use a presentation format that uses some form of textual
+   strings, attempting to support this would significantly complicate
+
+
+
+Austein                   Expires July 15, 2006                 [Page 8]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   what's intended to be a very simple debugging mechanism.
+
+   In some cases the content of the NSID payload may be binary data
+   meaningful only to the name server operator, and may not be
+   meaningful to the user or application, but the user or application
+   must be able to capture the entire content anyway in order for it to
+   be useful.  Thus, the presentation format must support arbitrary
+   binary data.
+
+   In cases where the name server operator derives the NSID payload from
+   textual data, a textual form such as US-ASCII or UTF-8 strings might
+   at first glance seem easier for a user to deal with.  There are,
+   however, a number of complex issues involving internationalized text
+   which, if fully addressed here, would require a set of rules
+   significantly longer than the rest of this specification.  See
+   [RFC2277] for an overview of some of these issues.
+
+   It is much more important for the NSID payload data to be passed
+   unambiguously from server administrator to user and back again than
+   it is for the payload data data to be pretty while in transit.  In
+   particular, it's critical that it be straightforward for a user to
+   cut and paste an exact copy of the NSID payload output by a debugging
+   tool into other formats such as email messages or web forms without
+   distortion.  Hexadecimal strings, while ugly, are also robust.
+
+3.4.  Truncation
+
+   In some cases, adding the NSID option to a response message may
+   trigger message truncation.  This specification does not change the
+   rules for DNS message truncation in any way, but implementors will
+   need to pay attention to this issue.
+
+   Including the NSID option in a response is always optional, so this
+   specification never requires name servers to truncate response
+   messages.
+
+   By definition, a resolver that requests NSID responses also supports
+   EDNS, so a resolver that requests NSID responses can also use the
+   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
+   receive buffer size large enough to make truncation unlikely.
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 9]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+4.  IANA Considerations
+
+   This mechanism requires allocation of one ENDS option code for the
+   NSID option (Section 2.3).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 10]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+5.  Security Considerations
+
+   This document describes a channel signaling mechanism, intended
+   primarily for debugging.  Channel signaling mechanisms are outside
+   the scope of DNSSEC per se.  Applications that require integrity
+   protection for the data being signaled will need to use a channel
+   security mechanism such as TSIG [RFC2845].
+
+   Section 3.1 discusses a number of different kinds of information that
+   a name server operator might choose to provide as the value of the
+   NSID option.  Some of these kinds of information are security
+   sensitive in some environments.  This specification deliberately
+   leaves the syntax and semantics of the NSID option content up to the
+   implementation and the name server operator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 11]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+6.  Acknowledgements
+
+   Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
+   Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
+   Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
+   Suzanne Woolf.  Apologies to anyone inadvertently omitted from the
+   above list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 12]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+7.2.  Informative References
+
+   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
+              Languages", RFC 2277, BCP 18, January 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 13]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Author's Address
+
+   Rob Austein
+   ISC
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   Email: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 14]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 15]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
new file mode 100644
index 0000000..5b6d655
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
@@ -0,0 +1,464 @@
+
+INTERNET-DRAFT                                DSA Information in the DNS
+OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: January 2006                                          July 2005
+
+
+            DSA Keying and Signature Information in the DNS
+            --- ------ --- --------- ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
+                         Donald E. Eastlake 3rd
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   The standard method of encoding US Government Digital Signature
+   Algorithm keying and signature information for use in the Domain Name
+   System is specified.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2005. All Rights Reserved.
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. DSA Keying Information..................................3
+      3. DSA Signature Information...............................4
+      4. Performance Considerations..............................4
+      5. Security Considerations.................................5
+      6. IANA Considerations.....................................5
+      Copyright and Disclaimer...................................5
+
+      Normative References.......................................7
+      Informative References.....................................7
+
+      Authors Address............................................8
+      Expiration and File Name...................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC 4033, 4034, 4035] and additional work is underway which would
+   require the storage of keying and signature information in the DNS.
+
+   This document describes how to encode US Government Digital Signature
+   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
+   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
+
+
+
+2. DSA Keying Information
+
+   When DSA public keys are stored in the DNS, the structure of the
+   relevant part of the RDATA part of the RR being used is the fields
+   listed below in the order given.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+        Field     Size
+        -----     ----
+         T         1  octet
+         Q        20  octets
+         P        64 + T*8  octets
+         G        64 + T*8  octets
+         Y        64 + T*8  octets
+
+   As described in [FIPS 186-2] and [Schneier], T is a key size
+   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
+   is greater than 8 is reserved and the remainder of the data may have
+   a different format in that case.)  Q is a prime number selected at
+   key generation time such that 2**159 < Q < 2**160. Thus Q is always
+   20 octets long and, as with all other fields, is stored in "big-
+   endian" network order.  P, G, and Y are calculated as directed by the
+   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
+   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
+   and Y are quantities modulo P and so can be up to the same length as
+   P and are allocated fixed size fields with the same number of octets
+   as P.
+
+   During the key generation process, a random number X must be
+   generated such that 1 <= X <= Q-1.  X is the private key and is used
+   in the final step of public key generation where Y is computed as
+
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+        Y = G**X mod P
+
+
+
+3. DSA Signature Information
+
+   The portion of the RDATA area used for US Digital Signature Algorithm
+   signature information is shown below with fields in the order they
+   are listed and the contents of each multi-octet field in "big-endian"
+   network order.
+
+        Field     Size
+        -----     ----
+         T         1 octet
+         R        20 octets
+         S        20 octets
+
+   First, the data signed must be determined.  Then the following steps
+   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
+   specified in the public key [Schneier]:
+
+        hash = SHA-1 ( data )
+
+        Generate a random K such that 0 < K < Q.
+
+        R = ( G**K mod P ) mod Q
+
+        S = ( K**(-1) * (hash + X*R) ) mod Q
+
+   For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
+   3174].
+
+   Since Q is 160 bits long, R and S can not be larger than 20 octets,
+   which is the space allocated.
+
+   T is copied from the public key.  It is not logically necessary in
+   the SIG but is present so that values of T > 8 can more conveniently
+   be used as an escape for extended versions of DSA or other algorithms
+   as later standardized.
+
+
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA [RFC
+   3110] and DSA.  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower than
+   RSA when the RSA public exponent is chosen to be small, as is
+   recommended for some applications.
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient, it
+   is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying and/or signature
+   inforamtion consistent with adequate security.
+
+
+
+5. Security Considerations
+
+   Keys retrieved from the DNS should not be trusted unless (1) they
+   have been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
+   current DSA standard may limit the security of DSA.  For particular
+   applications, implementors are encouraged to consider the range of
+   available algorithms and key sizes.
+
+   DSA assumes the ability to frequently generate high quality random
+   numbers.  See [random] for guidance.  DSA is designed so that if
+   biased rather than random numbers are used, high bandwidth covert
+   channels are possible.  See [Schneier] and more recent research.  The
+   leakage of an entire DSA private key in only two DSA signatures has
+   been demonstrated.  DSA provides security only if trusted
+   implementations, including trusted random number generation, are
+   used.
+
+
+
+6. IANA Considerations
+
+   Allocation of meaning to values of the T parameter that are not
+   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
+   is intended that values unallocated herein be used to cover future
+   extensions of the DSS standard.
+
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Normative References
+
+   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
+   Signature Standard, 27 January 2000.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+
+
+Informative References
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+   (DNS)", D.  Eastlake 3rd. May 2001.
+
+   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
+   Jones, September 2001.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+   "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [Schneier] - "Applied Cryptography Second Edition: protocols,
+   algorithms, and source code in C" (second edition), Bruce Schneier,
+   1996, John Wiley and Sons, ISBN 0-471-11709-9.
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Authors Address
+
+   Donald E. Eastlake 3rd
+   Motorola Labortories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554(w)
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in January 2006.
+
+   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
new file mode 100644
index 0000000..2ec9dbe
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
@@ -0,0 +1,840 @@
+
+
+
+Network Working Group                                       S. Josefsson
+Internet-Draft                                           August 30, 2005
+Expires: March 3, 2006
+
+
+          Storing Certificates in the Domain Name System (DNS)
+                    draft-ietf-dnsext-rfc2538bis-04
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 3, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   Cryptographic public keys are frequently published and their
+   authenticity demonstrated by certificates.  A CERT resource record
+   (RR) is defined so that such certificates and related certificate
+   revocation lists can be stored in the Domain Name System (DNS).
+
+   This document obsoletes RFC 2538.
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 1]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  The CERT Resource Record . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Certificate Type Values  . . . . . . . . . . . . . . . . .  4
+     2.2.  Text Representation of CERT RRs  . . . . . . . . . . . . .  5
+     2.3.  X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Appropriate Owner Names for CERT RRs . . . . . . . . . . . . .  6
+     3.1.  Content-based X.509 CERT RR Names  . . . . . . . . . . . .  7
+     3.2.  Purpose-based X.509 CERT RR Names  . . . . . . . . . . . .  8
+     3.3.  Content-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
+     3.4.  Purpose-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
+     3.5.  Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . .  9
+   4.  Performance Considerations . . . . . . . . . . . . . . . . . . 10
+   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
+   Appendix A.  Copying conditions  . . . . . . . . . . . . . . . . . 12
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 2]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+1.  Introduction
+
+   Public keys are frequently published in the form of a certificate and
+   their authenticity is commonly demonstrated by certificates and
+   related certificate revocation lists (CRLs).  A certificate is a
+   binding, through a cryptographic digital signature, of a public key,
+   a validity interval and/or conditions, and identity, authorization,
+   or other information.  A certificate revocation list is a list of
+   certificates that are revoked, and incidental information, all signed
+   by the signer (issuer) of the revoked certificates.  Examples are
+   X.509 certificates/CRLs in the X.500 directory system or OpenPGP
+   certificates/revocations used by OpenPGP software.
+
+   Section 2 below specifies a CERT resource record (RR) for the storage
+   of certificates in the Domain Name System [1] [2].
+
+   Section 3 discusses appropriate owner names for CERT RRs.
+
+   Sections 4, 5, and 6 below cover performance, IANA, and security
+   considerations, respectively.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [3].
+
+
+2.  The CERT Resource Record
+
+   The CERT resource record (RR) has the structure given below.  Its RR
+   type code is 37.
+
+                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             type              |             key tag           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   algorithm   |                                               /
+   +---------------+            certificate or CRL                 /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The type field is the certificate type as defined in section 2.1
+   below.
+
+   The key tag field is the 16 bit value computed for the key embedded
+   in the certificate, using the RRSIG Key Tag algorithm described in
+   Appendix B of [10].  This field is used as an efficiency measure to
+   pick which CERT RRs may be applicable to a particular key.  The key
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 3]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   tag can be calculated for the key in question and then only CERT RRs
+   with the same key tag need be examined.  However, the key must always
+   be transformed to the format it would have as the public key portion
+   of a DNSKEY RR before the key tag is computed.  This is only possible
+   if the key is applicable to an algorithm (and limits such as key size
+   limits) defined for DNS security.  If it is not, the algorithm field
+   MUST BE zero and the tag field is meaningless and SHOULD BE zero.
+
+   The algorithm field has the same meaning as the algorithm field in
+   DNSKEY and RRSIG RRs [10], except that a zero algorithm field
+   indicates the algorithm is unknown to a secure DNS, which may simply
+   be the result of the algorithm not having been standardized for
+   DNSSEC.
+
+2.1.  Certificate Type Values
+
+   The following values are defined or reserved:
+
+       Value  Mnemonic  Certificate Type
+       -----  --------  ----------------
+           0            reserved
+           1  PKIX      X.509 as per PKIX
+           2  SPKI      SPKI certificate
+           3  PGP       OpenPGP packet
+           4  IPKIX     The URL of an X.509 data object
+           5  ISPKI     The URL of an SPKI certificate
+           6  IPGP      The URL of an OpenPGP packet
+       7-252            available for IANA assignment
+         253  URI       URI private
+         254  OID       OID private
+   255-65534            available for IANA assignment
+       65535            reserved
+
+   The PKIX type is reserved to indicate an X.509 certificate conforming
+   to the profile being defined by the IETF PKIX working group.  The
+   certificate section will start with a one-byte unsigned OID length
+   and then an X.500 OID indicating the nature of the remainder of the
+   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
+   not include their X.500 directory type designating OID as a prefix.)
+
+   The SPKI type is reserved to indicate the SPKI certificate format
+   [13], for use when the SPKI documents are moved from experimental
+   status.
+
+   The PGP type indicates an OpenPGP packet as described in [6] and its
+   extensions and successors.  Two uses are to transfer public key
+   material and revocation signatures.  The data is binary, and MUST NOT
+   be encoded into an ASCII armor.  An implementation SHOULD process
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 4]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   transferable public keys as described in section 10.1 of [6], but it
+   MAY handle additional OpenPGP packets.
+
+   The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
+   content that would have been in the "certificate, CRL or URL" field
+   of the corresponding (PKIX, SPKI or PGP) packet types.  These types
+   are known as "indirect".  These packet types MUST be used when the
+   content is too large to fit in the CERT RR, and MAY be used at the
+   implementer's discretion.  They SHOULD NOT be used where the entire
+   UDP packet would have fit in 512 bytes.
+
+   The URI private type indicates a certificate format defined by an
+   absolute URI.  The certificate portion of the CERT RR MUST begin with
+   a null terminated URI [5] and the data after the null is the private
+   format certificate itself.  The URI SHOULD be such that a retrieval
+   from it will lead to documentation on the format of the certificate.
+   Recognition of private certificate types need not be based on URI
+   equality but can use various forms of pattern matching so that, for
+   example, subtype or version information can also be encoded into the
+   URI.
+
+   The OID private type indicates a private format certificate specified
+   by an ISO OID prefix.  The certificate section will start with a one-
+   byte unsigned OID length and then a BER encoded OID indicating the
+   nature of the remainder of the certificate section.  This can be an
+   X.509 certificate format or some other format.  X.509 certificates
+   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
+   type, not the OID private type.  Recognition of private certificate
+   types need not be based on OID equality but can use various forms of
+   pattern matching such as OID prefix.
+
+2.2.  Text Representation of CERT RRs
+
+   The RDATA portion of a CERT RR has the type field as an unsigned
+   decimal integer or as a mnemonic symbol as listed in section 2.1
+   above.
+
+   The key tag field is represented as an unsigned decimal integer.
+
+   The algorithm field is represented as an unsigned decimal integer or
+   a mnemonic symbol as listed in [10].
+
+   The certificate / CRL portion is represented in base 64 [14] and may
+   be divided up into any number of white space separated substrings,
+   down to single base 64 digits, which are concatenated to obtain the
+   full signature.  These substrings can span lines using the standard
+   parenthesis.
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 5]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   Note that the certificate / CRL portion may have internal sub-fields,
+   but these do not appear in the master file representation.  For
+   example, with type 254, there will be an OID size, an OID, and then
+   the certificate / CRL proper.  But only a single logical base 64
+   string will appear in the text representation.
+
+2.3.  X.509 OIDs
+
+   OIDs have been defined in connection with the X.500 directory for
+   user certificates, certification authority certificates, revocations
+   of certification authority, and revocations of user certificates.
+   The following table lists the OIDs, their BER encoding, and their
+   length-prefixed hex format for use in CERT RRs:
+
+       id-at-userCertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
+              == 0x 03 55 04 24
+       id-at-cACertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
+              == 0x 03 55 04 25
+       id-at-authorityRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
+              == 0x 03 55 04 26
+       id-at-certificateRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
+              == 0x 03 55 04 27
+
+
+3.  Appropriate Owner Names for CERT RRs
+
+   It is recommended that certificate CERT RRs be stored under a domain
+   name related to their subject, i.e., the name of the entity intended
+   to control the private key corresponding to the public key being
+   certified.  It is recommended that certificate revocation list CERT
+   RRs be stored under a domain name related to their issuer.
+
+   Following some of the guidelines below may result in the use in DNS
+   names of characters that require DNS quoting which is to use a
+   backslash followed by the octal representation of the ASCII code for
+   the character (e.g., \000 for NULL).
+
+   The choice of name under which CERT RRs are stored is important to
+   clients that perform CERT queries.  In some situations, the clients
+   may not know all information about the CERT RR object it wishes to
+   retrieve.  For example, a client may not know the subject name of an
+   X.509 certificate, or the e-mail address of the owner of an OpenPGP
+   key.  Further, the client might only know the hostname of a service
+   that uses X.509 certificates or the Key ID of an OpenPGP key.
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 6]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   Therefore, two owner name guidelines are defined: content-based owner
+   names and purpose-based owner names.  A content-based owner name is
+   derived from the content of the CERT RR data; for example, the
+   Subject field in an X.509 certificate or the User ID field in OpenPGP
+   keys.  A purpose-based owner name is a name that a client retrieving
+   CERT RRs MUST already know; for example, the host name of an X.509
+   protected service or the Key ID of an OpenPGP key.  The content-based
+   and purpose-based owner name MAY be the same; for example, when a
+   client looks up a key based on the From: address of an incoming
+   e-mail.
+
+   Implementations SHOULD use the purpose-based owner name guidelines
+   described in this document, and MAY use CNAMEs of content-based owner
+   names (or other names), pointing to the purpose-based owner name.
+
+3.1.  Content-based X.509 CERT RR Names
+
+   Some X.509 versions permit multiple names to be associated with
+   subjects and issuers under "Subject Alternate Name" and "Issuer
+   Alternate Name".  For example, X.509v3 has such Alternate Names with
+   an ASN.1 specification as follows:
+
+        GeneralName ::= CHOICE {
+           otherName                  [0] INSTANCE OF OTHER-NAME,
+           rfc822Name                 [1] IA5String,
+           dNSName                    [2] IA5String,
+           x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
+           directoryName              [4] EXPLICIT Name,
+           ediPartyName               [5] EDIPartyName,
+           uniformResourceIdentifier  [6] IA5String,
+           iPAddress                  [7] OCTET STRING,
+           registeredID               [8] OBJECT IDENTIFIER
+        }
+
+   The recommended locations of CERT storage are as follows, in priority
+   order:
+   1.  If a domain name is included in the identification in the
+       certificate or CRL, that should be used.
+   2.  If a domain name is not included but an IP address is included,
+       then the translation of that IP address into the appropriate
+       inverse domain name should be used.
+   3.  If neither of the above is used, but a URI containing a domain
+       name is present, that domain name should be used.
+   4.  If none of the above is included but a character string name is
+       included, then it should be treated as described for OpenPGP
+       names below.
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 7]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   5.  If none of the above apply, then the distinguished name (DN)
+       should be mapped into a domain name as specified in [4].
+
+   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
+   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
+   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
+   uri <https://www.secure.john-doe.com:8080/>.  The storage locations
+   recommended, in priority order, would be
+   1.  john-doe.com,
+   2.  www.secure.john-doe.com, and
+   3.  Doe.com.xy.
+
+   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
+   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
+   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
+   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
+   storage locations recommended, in priority order, would be
+   1.  widget.foo.example,
+   2.  201.13.251.10.in-addr.arpa, and
+   3.  hacker.mail.widget.foo.example.
+
+3.2.  Purpose-based X.509 CERT RR Names
+
+   Due to the difficulty for clients that do not already possess a
+   certificate to reconstruct the content-based owner name, purpose-
+   based owner names are recommended in this section.  Recommendations
+   for purpose-based owner names vary per scenario.  The following table
+   summarizes the purpose-based X.509 CERT RR owner name guidelines for
+   use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
+
+    Scenario             Owner name
+    ------------------   ----------------------------------------------
+    S/MIME Certificate   Standard translation of an RFC 2822 email
+                         address.  Example: An S/MIME certificate for
+                         "postmaster@example.org" will use a standard
+                         hostname translation of the owner name,
+                         "postmaster.example.org".
+
+    TLS Certificate      Hostname of the TLS server.
+
+    IPSEC Certificate    Hostname of the IPSEC machine and/or, for IPv4
+                         or IPv6 addresses, the fully qualified domain
+                         name in the appropriate reverse domain.
+
+   An alternate approach for IPSEC is to store raw public keys [15].
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 8]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+3.3.  Content-based OpenPGP CERT RR Names
+
+   OpenPGP signed keys (certificates) use a general character string
+   User ID [6].  However, it is recommended by OpenPGP that such names
+   include the RFC 2822 [8] email address of the party, as in "Leslie
+   Example <Leslie@host.example>".  If such a format is used, the CERT
+   should be under the standard translation of the email address into a
+   domain name, which would be leslie.host.example in this case.  If no
+   RFC 2822 name can be extracted from the string name, no specific
+   domain name is recommended.
+
+   If a user has more than one email address, the CNAME type can be used
+   to reduce the amount of data stored in the DNS.  Example:
+
+      $ORIGIN example.org.
+      smith        IN CERT PGP 0 0 <OpenPGP binary>
+      john.smith   IN CNAME smith
+      js           IN CNAME smith
+
+3.4.  Purpose-based OpenPGP CERT RR Names
+
+   Applications that receive an OpenPGP packet containing encrypted or
+   signed data but do not know the email address of the sender will have
+   difficulties constructing the correct owner name and cannot use the
+   content-based owner name guidelines.  However, these clients commonly
+   know the key fingerprint or the Key ID.  The key ID is found in
+   OpenPGP packets, and the key fingerprint is commonly found in
+   auxilliary data that may be available.  In this case, use of an owner
+   name identical to the key fingerprint and the key ID expressed in
+   hexadecimal [14] is recommended.  Example:
+
+      $ORIGIN example.org.
+      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
+      F835EDA21E94B565716F                     IN CERT PGP ...
+      B565716F                                 IN CERT PGP ...
+
+   If the same key material is stored for several owner names, the use
+   of CNAME may be used to avoid data duplication.  Note that CNAME is
+   not always applicable, because it maps one owner name to the other
+   for all purposes, which may be sub-optimal when two keys with the
+   same Key ID are stored.
+
+3.5.  Owner names for IPKIX, ISPKI, and IPGP
+
+   These types are stored under the same owner names, both purpose- and
+   content-based, as the PKIX, SPKI and PGP types.
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                 [Page 9]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+4.  Performance Considerations
+
+   Current Domain Name System (DNS) implementations are optimized for
+   small transfers, typically not more than 512 bytes including
+   overhead.  While larger transfers will perform correctly and work is
+   underway to make larger transfers more efficient, it is still
+   advisable at this time to make every reasonable effort to minimize
+   the size of certificates stored within the DNS.  Steps that can be
+   taken may include using the fewest possible optional or extension
+   fields and using short field values for necessary variable length
+   fields.
+
+   The RDATA field in the DNS protocol may only hold data of size 65535
+   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
+   more than 64kb of payload, even if the corresponding certificate or
+   certificate revocation list is larger.  This document addresses this
+   by defining "indirect" data types for each normal type.
+
+
+5.  Contributors
+
+   The majority of this document is copied verbatim from RFC 2538, by
+   Donald Eastlake 3rd and Olafur Gudmundsson.
+
+
+6.  Acknowledgements
+
+   Thanks to David Shaw and Michael Graff for their contributions to
+   earlier works that motivated, and served as inspiration for, this
+   document.
+
+   This document was improved by suggestions and comments from Olivier
+   Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
+   Sloderbeck, Samuel Weiler, and Florian Weimer.  No doubt the list is
+   incomplete.  We apologize to anyone we left out.
+
+
+7.  Security Considerations
+
+   By definition, certificates contain their own authenticating
+   signature.  Thus, it is reasonable to store certificates in non-
+   secure DNS zones or to retrieve certificates from DNS with DNS
+   security checking not implemented or deferred for efficiency.  The
+   results MAY be trusted if the certificate chain is verified back to a
+   known trusted key and this conforms with the user's security policy.
+
+   Alternatively, if certificates are retrieved from a secure DNS zone
+   with DNS security checking enabled and are verified by DNS security,
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 10]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   the key within the retrieved certificate MAY be trusted without
+   verifying the certificate chain if this conforms with the user's
+   security policy.
+
+   If an organization chooses to issue certificates for it's employees,
+   placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
+   is in use, it is possible for someone to enumerate all employees of
+   the organization.  This is usually not considered desirable, for the
+   same reason enterprise phone listings are not often publicly
+   published and are even mark confidential.
+
+   When the URI type is used, it should be understood that it introduces
+   an additional indirection that may allow for a new attack vector.
+   One method to secure that indirection is to include a hash of the
+   certificate in the URI itself.
+
+   CERT RRs are not used by DNSSEC [9], so there are no security
+   considerations related to CERT RRs and securing the DNS itself.
+
+   If DNSSEC is used, then the non-existence of a CERT RR and,
+   consequently, certificates or revocation lists can be securely
+   asserted.  Without DNSSEC, this is not possible.
+
+
+8.  IANA Considerations
+
+   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
+   only be assigned by an IETF standards action [7].  This document
+   assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE.  Certificate
+   types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
+   based on RFC documentation of the certificate type.  The availability
+   of private types under 0x00FD and 0x00FE should satisfy most
+   requirements for proprietary or private types.
+
+   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
+   particular, the CERT RR requires that algorithm number 0 remain
+   reserved, as described in Section 2.  The IANA is directed to
+   reference the CERT RR as a user of this registry and value 0, in
+   particular.
+
+
+9.  Changes since RFC 2538
+
+   1.   Editorial changes to conform with new document requirements,
+        including splitting reference section into two parts and
+        updating the references to point at latest versions, and to add
+        some additional references.
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 11]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
+        to align with RFC 2440.
+   3.   In section 2.1, clarify that OpenPGP public key data are binary,
+        not the ASCII armored format, and reference 10.1 in RFC 2440 on
+        how to deal with OpenPGP keys, and acknowledge that
+        implementations may handle additional packet types.
+   4.   Clarify that integers in the representation format are decimal.
+   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
+        terminology.  Improve reference for Key Tag Algorithm
+        calculations.
+   6.   Add examples that suggest use of CNAME to reduce bandwidth.
+   7.   In section 3, appended the last paragraphs that discuss
+        "content-based" vs "purpose-based" owner names.  Add section 3.2
+        for purpose-based X.509 CERT owner names, and section 3.4 for
+        purpose-based OpenPGP CERT owner names.
+   8.   Added size considerations.
+   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
+        from the experimental status.
+   10.  Added indirect types IPKIX, ISPKI, and IPGP.
+
+
+Appendix A.  Copying conditions
+
+   Regarding the portion of this document that was written by Simon
+   Josefsson ("the author", for the remainder of this section), the
+   author makes no guarantees and is not responsible for any damage
+   resulting from its use.  The author grants irrevocable permission to
+   anyone to use, modify, and distribute it in any way that does not
+   diminish the rights of anyone else to use, modify, and distribute it,
+   provided that redistributed derivative works do not contain
+   misleading author or version information.  Derivative works need not
+   be licensed under similar terms.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 12]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
+         January 1998.
+
+   [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+         Resource Identifiers (URI): Generic Syntax", RFC 2396,
+         August 1998.
+
+   [6]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+         "OpenPGP Message Format", RFC 2440, November 1998.
+
+   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434,
+         October 1998.
+
+   [8]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+10.2.  Informative References
+
+   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+         RFC 2246, January 1999.
+
+   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [13]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
+         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
+         September 1999.
+
+   [14]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+         RFC 3548, July 2003.
+
+   [15]  Richardson, M., "A Method for Storing IPsec Keying Material in
+         DNS", RFC 4025, March 2005.
+
+   [16]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+         (S/MIME) Version 3.1 Message Specification", RFC 3851,
+         July 2004.
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 13]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+Author's Address
+
+   Simon Josefsson
+
+   Email: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 14]
+
+Internet-Draft       Storing Certificates in the DNS         August 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Josefsson                 Expires March 3, 2006                [Page 15]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
new file mode 100644
index 0000000..5e6cb1d
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
@@ -0,0 +1,580 @@
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: January 2006                                          July 2005
+
+
+
+
+        Storage of Diffie-Hellman Keying Information in the DNS
+        ------- -- -------------- ------ ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2539bis-dhk-06.txt>
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   The standard method for encoding Diffie-Hellman keys in the Domain
+   Name System is specified.
+
+
+
+Copyright
+
+   Copyright (C) The Internet Society 2005.
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Acknowledgements
+
+   Part of the format for Diffie-Hellman keys and the description
+   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
+   and Hemma Prafullchandra.  In addition, the following persons
+   provided useful comments that were incorporated into the predecessor
+   of this document: Ran Atkinson, Thomas Narten.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright..................................................1
+
+      Acknowledgements...........................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      1.1 About This Document....................................3
+      1.2 About Diffie-Hellman...................................3
+      2. Encoding Diffie-Hellman Keying Information..............4
+      3. Performance Considerations..............................5
+      4. IANA Considerations.....................................5
+      5. Security Considerations.................................5
+      Copyright and Disclaimer...................................5
+
+      Normative References.......................................7
+      Informative Refences.......................................7
+
+      Author Address.............................................8
+      Expiration and File Name...................................8
+
+      Appendix A: Well known prime/generator pairs...............9
+      A.1. Well-Known Group 1:  A 768 bit prime..................9
+      A.2. Well-Known Group 2:  A 1024 bit prime.................9
+      A.3. Well-Known Group 3:  A 1536 bit prime................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   similar information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC 4033, 4034, 4035] and additonal work is underway which would use
+   the storage of keying information in the DNS.
+
+
+
+1.1 About This Document
+
+   This document describes how to store Diffie-Hellman keys in the DNS.
+   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
+   [Schneier, RFC 2631].
+
+
+
+1.2 About Diffie-Hellman
+
+   Diffie-Hellman requires two parties to interact to derive keying
+   information which can then be used for authentication.  Thus Diffie-
+   Hellman is inherently a key agreement algorithm. As a result, no
+   format is defined for Diffie-Hellman "signature information".  For
+   example, assume that two parties have local secrets "i" and "j".
+   Assume they each respectively calculate X and Y as follows:
+
+        X = g**i ( mod p )
+
+        Y = g**j ( mod p )
+
+   They exchange these quantities and then each calculates a Z as
+   follows:
+
+        Zi = Y**i ( mod p )
+
+        Zj = X**j ( mod p )
+
+   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
+   secret between the two parties that an adversary who does not know i
+   or j will not be able to learn from the exchanged messages (unless
+   the adversary can derive i or j by performing a discrete logarithm
+   mod p which is hard for strong p and g).
+
+   The private key for each party is their secret i (or j).  The public
+   key is the pair p and g, which must be the same for the parties, and
+   their individual X (or Y).
+
+   For further information about Diffie-Hellman and precautions to take
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   in deciding on a p and g, see [RFC 2631].
+
+
+
+2. Encoding Diffie-Hellman Keying Information
+
+   When Diffie-Hellman keys appear within the RDATA portion of a RR,
+   they are encoded as shown below.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |           KEY flags           |    protocol   |  algorithm=2  |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     prime length (or flag)    |  prime (p) (or special)       /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  prime (p)  (variable length) |       generator length        |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | generator (g) (variable length)                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     public value length       | public value (variable length)/
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  public value (g^i mod p)    (variable length)                |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Prime length is the length of the Diffie-Hellman prime (p) in bytes
+   if it is 16 or greater.  Prime contains the binary representation of
+   the Diffie-Hellman prime with most significant byte first (i.e., in
+   network order). If "prime length" field is 1 or 2, then the "prime"
+   field is actually an unsigned index into a table of 65,536
+   prime/generator pairs and the generator length SHOULD be zero.  See
+   Appedix A for defined table entries and Section 4 for information on
+   allocating additional table entries.  The meaning of a zero or 3
+   through 15 value for "prime length" is reserved.
+
+   Generator length is the length of the generator (g) in bytes.
+   Generator is the binary representation of generator with most
+   significant byte first.  PublicValueLen is the Length of the Public
+   Value (g**i (mod p)) in bytes.  PublicValue is the binary
+   representation of the DH public value with most significant byte
+   first.
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+3. Performance Considerations
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient. But
+   it is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying information consistent
+   with adequate security.
+
+
+
+4. IANA Considerations
+
+   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
+   an IETF consensus as defined in [RFC 2434].
+
+   Well known prime/generator pairs number 0x0000 through 0x07FF can
+   only be assigned by an IETF standards action. [RFC 2539], the
+   Proposed Standard predecessor of this document, assigned 0x0001
+   through 0x0002. This document additionally assigns 0x0003.  Pairs
+   number 0s0800 through 0xBFFF can be assigned based on RFC
+   documentation. Pairs number 0xC000 through 0xFFFF are available for
+   private use and are not centrally coordinated. Use of such private
+   pairs outside of a closed environment may result in conflicts and/or
+   security failures.
+
+
+
+5. Security Considerations
+
+   Keying information retrieved from the DNS should not be trusted
+   unless (1) it has been securely obtained from a secure resolver or
+   independently verified by the user and (2) this secure resolver and
+   secure obtainment or independent verification conform to security
+   policies acceptable to the user.  As with all cryptographic
+   algorithms, evaluating the necessary strength of the key is important
+   and dependent on security policy.
+
+   In addition, the usual Diffie-Hellman key strength considerations
+   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
+   should be "large", etc. See [RFC 2631, Schneier].
+
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Normative References
+
+   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
+   1999.
+
+   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
+   in RFCs", T.  Narten, H. Alvestrand, October 1998.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+
+
+Informative Refences
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, November 1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, November 1987.
+
+   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
+   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
+   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
+   and Sons.
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Author Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in January 2006.
+
+   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Appendix A: Well known prime/generator pairs
+
+   These numbers are copied from the IPSEC effort where the derivation of
+   these values is more fully explained and additional information is
+   available.
+   Richard Schroeppel performed all the mathematical and computational
+   work for this appendix.
+
+
+
+A.1. Well-Known Group 1:  A 768 bit prime
+
+   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
+   decimal value is
+          155251809230070893513091813125848175563133404943451431320235
+          119490296623994910210725866945387659164244291000768028886422
+          915080371891804634263272761303128298374438082089019628850917
+          0691316593175367469551763119843371637221007210577919
+
+   Prime modulus: Length (32 bit words): 24, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+A.2. Well-Known Group 2:  A 1024 bit prime
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its decimal value is
+         179769313486231590770839156793787453197860296048756011706444
+         423684197180216158519368947833795864925541502180565485980503
+         646440548199239100050792877003355816639229553136239076508735
+         759914822574862575007425302077447712589550957937778424442426
+         617334727629299387668709205606050270810842907692932019128194
+         467627007
+
+   Prime modulus:  Length (32 bit words): 32, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+            FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+A.3. Well-Known Group 3:  A 1536 bit prime
+
+   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
+   Its decimal value is
+            241031242692103258855207602219756607485695054850245994265411
+            694195810883168261222889009385826134161467322714147790401219
+            650364895705058263194273070680500922306273474534107340669624
+            601458936165977404102716924945320037872943417032584377865919
+            814376319377685986952408894019557734611984354530154704374720
+            774996976375008430892633929555996888245787241299381012913029
+            459299994792636526405928464720973038494721168143446471443848
+            8520940127459844288859336526896320919633919
+
+   Prime modulus Length (32 bit words): 48, Data (hex):
+              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words):  1, Data (hex): 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 10]
+
diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
new file mode 100644
index 0000000..0af13c6
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
@@ -0,0 +1,755 @@
+
+
+Network Working Group                                          B. Laurie
+Internet-Draft                                                   Nominet
+Expires: March 2, 2005                                         R. Loomis
+                                                                    SAIC
+                                                          September 2004
+
+
+
+      Requirements related to DNSSEC Signed Proof of Non-Existence
+         draft-ietf-dnsext-signed-nonexistence-requirements-01
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+   This Internet-Draft will expire on March 2, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+
+   DNSSEC-bis uses the NSEC record to provide authenticated denial of
+   existence of RRsets.  NSEC also has the side-effect of permitting
+   zone enumeration, even if zone transfers have been forbidden.
+   Because some see this as a problem, this document has been assembled
+   to detail the possible requirements for denial of existence A/K/A
+   signed proof of non-existence.
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 1]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+Table of Contents
+
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Non-purposes . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.   Zone Enumeration . . . . . . . . . . . . . . . . . . . . . .   3
+   4.   Zone Enumeration II  . . . . . . . . . . . . . . . . . . . .   4
+   5.   Zone Enumeration III . . . . . . . . . . . . . . . . . . . .   4
+   6.   Exposure of Contents . . . . . . . . . . . . . . . . . . . .   4
+   7.   Zone Size  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   8.   Single Method  . . . . . . . . . . . . . . . . . . . . . . .   5
+   9.   Empty Non-terminals  . . . . . . . . . . . . . . . . . . . .   5
+   10.  Prevention of Precomputed Dictionary Attacks . . . . . . . .   6
+   11.  DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . .   6
+   12.  Non-overlap of denial records with possible zone records . .   7
+   13.  Exposure of Private Keys . . . . . . . . . . . . . . . . . .   7
+   14.  Minimisation of Zone Signing Cost  . . . . . . . . . . . . .   8
+   15.  Minimisation of Asymmetry  . . . . . . . . . . . . . . . . .   8
+   16.  Minimisation of Client Complexity  . . . . . . . . . . . . .   8
+   17.  Completeness . . . . . . . . . . . . . . . . . . . . . . . .   8
+   18.  Purity of Namespace  . . . . . . . . . . . . . . . . . . . .   8
+   19.  Replay Attacks . . . . . . . . . . . . . . . . . . . . . . .   8
+   20.  Compatibility with NSEC  . . . . . . . . . . . . . . . . . .   8
+   21.  Compatibility with NSEC II . . . . . . . . . . . . . . . . .   9
+   22.  Compatibility with NSEC III  . . . . . . . . . . . . . . . .   9
+   23.  Coexistence with NSEC  . . . . . . . . . . . . . . . . . . .   9
+   24.  Coexistence with NSEC II . . . . . . . . . . . . . . . . . .   9
+   25.  Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   9
+   26.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
+   27.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
+   28.  Requirements notation  . . . . . . . . . . . . . . . . . . .   9
+   29.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
+   30.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   30.1   Normative References . . . . . . . . . . . . . . . . . . .  10
+   30.2   Informative References . . . . . . . . . . . . . . . . . .  10
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  10
+        Intellectual Property and Copyright Statements . . . . . . .  11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 2]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+1.  Introduction
+
+
+   NSEC records allow trivial enumeration of zones - a situation that
+   has existed for several years but which has recently been raised as a
+   significant concern for DNSSECbis deployment in several zones.
+   Alternate proposals have been made that make zone enumeration more
+   difficult, and some previous proposals to modify DNSSEC had related
+   requirements/desirements that are relevant to the discussion.  In
+   addition the original designs for NSEC/NXT records were based on
+   working group discussions and the choices made were not always
+   documented with context and requirements-- so some of those choices
+   may need to be restated as requirements.  Overall, the working group
+   needs to better understand the requirements for denial of existence
+   (and certain other requirements related to DNSSECbis deployment) in
+   order to evaluate the proposals that may replace NSEC.
+
+
+   In the remainder of this document, "NSEC++" is used as shorthand for
+   "a denial of existence proof that will replace NSEC".  "NSECbis" has
+   also been used as shorthand for this, but we avoid that usage since
+   NSECbis will not be part of DNSSECbis and therefore there might be
+   some confusion.
+
+
+2.  Non-purposes
+
+
+   This document does not currently document the reasons why zone
+   enumeration might be "bad" from a privacy, security, business, or
+   other perspective--except insofar as those reasons result in
+   requirements.  Once the list of requirements is complete and vaguely
+   coherent, the trade-offs (reducing zone enumeration will have X cost,
+   while providing Y benefit) may be revisited.  The editors of this
+   compendium received inputs on the potential reasons why zone
+   enumeration is bad (and there was significant discussion on the
+   DNSEXT WG mailing list) but that information fell outside the scope
+   of this document.
+
+
+   Note also that this document does not assume that NSEC *must* be
+   replaced with NSEC++, if the requirements can be met through other
+   methods (e.g., "white lies" with the current NSEC).  As is stated
+   above, this document is focused on requirements collection and
+   (ideally) prioritization rather than on the actual implementation.
+
+
+3.  Zone Enumeration
+
+
+   Authenticated denial should not permit trivial zone enumeration.
+
+
+   Additional discussion:  NSEC (and NXT before it) provide a linked
+   list that could be "walked" to trivially enumerate all the signed
+   records in a zone.  This requirement is primarily (though not
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 3]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   exclusively) important for zones that either are delegation-only/
+   -mostly or do not have reverse lookup (PTR) records configured, since
+   enterprises that have PTR records for all A records have already
+   provided a similar capability to enumerate the contents of DNS zones.
+
+
+   Contributor: various
+
+
+4.  Zone Enumeration II
+
+
+   Zone enumeration should be at least as difficult as it would be to
+   effect a dictionary attack using simple DNS queries to do the same in
+   an unsecured zone.
+
+
+   (Editor comment: it is not clear how to measure difficulty in this
+   case.  Some examples could be monetary cost, bandwidth, processing
+   power or some combination of these.  It has also been suggested that
+   the requirement is that the graph of difficulty of enumeration vs.
+   the fraction of the zone enumerated should be approximately the same
+   shape in the two cases)
+
+
+   Contributor: Nominet
+
+
+5.  Zone Enumeration III
+
+
+   Enumeration of a zone with random contents should computationally
+   infeasible.
+
+
+   Editor comment: this is proposed as a way of evaluating the
+   effectiveness of a proposal rather than as a requirement anyone would
+   actually have in practice.
+
+
+   Contributor: Alex Bligh
+
+
+6.  Exposure of Contents
+
+
+   NSEC++ should not expose any of the contents of the zone (apart from
+   the NSEC++ records themselves, of course).
+
+
+   Editor comment: this is a weaker requirement than prevention of
+   enumeration, but certainly any zone that satisfied this requirement
+   would also satisfy the trivial prevention of enumeration requirement.
+
+
+   Contributor: Ed Lewis
+
+
+7.  Zone Size
+
+
+   Requirement:  NSEC++ should make it possible to take precautions
+   against trivial zone size estimates.  Since not all zone owners care
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 4]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   about others estimation of the size of a zone, it is not always
+   necessary to prohibit trivial estimation of the size of the zone but
+   NSEC++ should allow such measures.
+
+
+   Additional Discussion: Even with proposals based on obfuscating names
+   with hashes it is trivial to give very good estimates of the number
+   of domains in a certain zone.  Just send 10 random queries and look
+   at the range between the two hash values returned in each NSEC++.  As
+   hash output can be assumed to follow a rectangular random
+   distribution, using the mean difference between the two values, you
+   can estimate the total number of records.  It is probably sufficient
+   to look at even one NSEC++, since the two hash values should follow a
+   (I believe) Poisson distribution.
+
+
+   The concern is motivated by some wording remembered from NSEC, which
+   stated that NSEC MUST only be present for existing owner names in the
+   zone, and MUST NOT be present for non-existing owner names.  If
+   similar wording were carried over to NSEC++, introducing bogus owner
+   names in the hash chain (an otherwise simple solution to guard
+   against trivial estimates of zone size) wouldn't be allowed.
+
+
+   One simple attempt at solving this is to describe in the
+   specifications how zone signer tools can add a number of random
+   "junk" records.
+
+
+   Editor's comment: it is interesting that obfuscating names might
+   actually make it easier to estimate zone size.
+
+
+   Contributor: Simon Josefsson.
+
+
+8.  Single Method
+
+
+   Requirement:  A single NSEC++ method must be able to carry both
+   old-style denial (i.e.  plain labels) and whatever the new style
+   looks like.  Having two separate denial methods could result in
+   cornercases where one method can deny the other and vice versa.
+
+
+   Additional discussion:  This requirement can help -bis folks to a
+   smooth upgrade to -ter.  First they'd change the method while the
+   content is the same, then they can change content of the method.
+
+
+   Contributor: Roy Arends.
+
+
+9.  Empty Non-terminals
+
+
+   Requirement:  Empty-non-terminals (ENT) should remain empty.  In
+   other words, adding NSEC++ records to an existing DNS structure
+   should not cause the creation of NSEC++ records (or related records)
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 5]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   at points that are otherwise ENT.
+
+
+   Additional discussion:  Currently NSEC complies with ENT requirement:
+   b.example.com NSEC a.c.example.com implies the existence of an ENT
+   with ownername c.example.com.  NSEC2 breaks that requirement, since
+   the ownername is entirely hashed causing the structure to disappear.
+   This is why EXIST was introduced.  But EXIST causes ENT to be
+   non-empty-terminals.  Next to the dissappearance of ENT, it causes
+   (some) overhead since an EXIST record needs a SIG, NSEC2 and
+   SIG(NSEC2).  DNSNR honours this requirement by hashing individual
+   labels instead of ownernames.  However this causes very long labels.
+   Truncation is a measure against very long ownernames, but that is
+   controversial.  There is a fair discussion of the validity of
+   truncation in the DNSNR draft, but that hasn't got proper review yet.
+
+
+   Contributor: Roy Arends.
+
+
+   (Editor comment: it is not clear to us that an EXIST record needs an
+   NSEC2 record, since it is a special purpose record only used for
+   denial of existence)
+
+
+10.  Prevention of Precomputed Dictionary Attacks
+
+
+   Requirement:  NSEC++ needs to provide a method to reduce the
+   effectiveness of precomputed dictionary attacks.
+
+
+   Additional Discussion:  Salt is a measure against dictionary attacks.
+   There are other possible measures (such as iterating hashes in
+   NSEC2).  The salt needs to be communicated in every response, since
+   it is needed in every verification.  Some have suggested to move the
+   salt to a special record instead of the denial record.  I think this
+   is not wise.  Response size has more priority over zone size.  An
+   extra record causes a larger response than a larger existing record.
+
+
+   Contributor: Roy Arends.
+
+
+   (Editor comment: the current version of NSEC2 also has the salt in
+   every NSEC2 record)
+
+
+11.  DNSSEC-Adoption and Zone-Growth Relationship
+
+
+   Background:  Currently with NSEC, when a delegation centric zone
+   deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
+   when the DNSSEC-adoption rate of the subzones remains low--because
+   each delegation point creates at least one NSEC record and
+   corresponding signature in the parent even if the child is not
+   signed.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 6]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Requirements:  A delegation-only (or delegation-mostly) zone that is
+   signed but which has no signed child zones should initially need only
+   to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
+   minimal set of NSEC++ records to cover zone contents.  Further,
+   during the transition of a delegation-only zone from 0% signed
+   children to 100% signed children, the growth in the delegation-only
+   zone should be roughly proportional to the percentage of signed child
+   zones.
+
+
+   Additional Discussion: This is why DNSNR has the Authoritative Only
+   bit.  This is similar to opt-in for delegations only.  This (bit) is
+   currently the only method to help delegation-centric zone cope with
+   zone-growth due to DNSSEC adoption.  As an example, A delegation only
+   zone which deploys DNSSEC with the help of this bit, needs to add
+   SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex.  No
+   more than that.
+
+
+   Contributor: Roy Arends.
+
+
+12.  Non-overlap of denial records with possible zone records
+
+
+   Requirement:  NSEC++ records should in some way be differentiated
+   from regular zone records, so that there is no possibility that a
+   record in the zone could be duplicated by a non-existence proof
+   (NSEC++) record.
+
+
+   Additional discussion:  This requirement is derived from a discussion
+   on the DNSEXT mailing list related to copyrights and domain names.
+   As was outlined there, one solution is to put NSEC++ records in a
+   separate namespace, e.g.: $ORIGIN co.uk.
+   873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
+   delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
+   ; for amazon.co.uk.
+
+
+   Contributor: various
+
+
+   (Editor comment:  One of us still does not see why a conflict
+   matters.  Even if there is an apparent conflict or overlap, the
+   "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
+   other name _never_ appears in NSEC2 records.)
+
+
+13.  Exposure of Private Keys
+
+
+   Private keys associated with the public keys in the DNS should be
+   exposed as little as possible.  It is highly undesirable for private
+   keys to be distributed to nameservers, or to otherwise be available
+   in the run-time environment of nameservers.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 7]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Contributors: Nominet, Olaf Kolkman, Ed Lewis
+
+
+14.  Minimisation of Zone Signing Cost
+
+
+   The additional cost of creating an NSEC++ signed zone should not
+   significantly exceed the cost of creating an ordinary signed zone.
+
+
+   Contributor: Nominet
+
+
+15.  Minimisation of Asymmetry
+
+
+   Nameservers should have to do as little additional work as necessary.
+   More precisely, it is desirable for any increase in cost incurred by
+   the nameservers to be offset by a proportionate increase in cost to
+   DNS `clients', e.g.  stub and/or `full-service' resolvers.
+
+
+   Contributor: Nominet
+
+
+16.  Minimisation of Client Complexity
+
+
+   Caching, wildcards, CNAMEs, DNAMEs should continue to work without
+   adding too much complexity at the client side.
+
+
+   Contributor: Olaf Kolkman
+
+
+17.  Completeness
+
+
+   A proof of nonexistence should be possible for all nonexistent data
+   in the zone.
+
+
+   Contributor: Olaf Kolkman
+
+
+18.  Purity of Namespace
+
+
+   The name space should not be muddied with fake names or data sets.
+
+
+   Contributor: Ed Lewis
+
+
+19.  Replay Attacks
+
+
+   NSEC++ should not allow a replay to be used to deny existence of an
+   RR that actually exists.
+
+
+   Contributor: Ed Lewis
+
+
+20.  Compatibility with NSEC
+
+
+   NSEC++ should not introduce changes incompatible with NSEC.
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 8]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Contributor: Ed Lewis
+
+
+21.  Compatibility with NSEC II
+
+
+   NSEC++ should differ from NSEC in a way that is transparent to the
+   resolver or validator.
+
+
+   Contributor: Ed Lewis
+
+
+22.  Compatibility with NSEC III
+
+
+   NSEC++ should differ from NSEC as little as possible whilst achieving
+   other requirements.
+
+
+   Contributor: Alex Bligh
+
+
+23.  Coexistence with NSEC
+
+
+   NSEC++ should be optional, allowing NSEC to be used instead.
+
+
+   Contributor: Ed Lewis, Alex Bligh
+
+
+24.  Coexistence with NSEC II
+
+
+   NSEC++ should not impose extra work on those content with NSEC.
+
+
+   Contributor: Ed Lewis
+
+
+25.  Protocol Design
+
+
+   A good security protocol would allow signing the nonexistence of some
+   selected names without revealing anything about other names.
+
+
+   Contributor: Dan Bernstein
+
+
+26.  Process
+
+
+   Clearly not all of these requirements can be met.  Therefore the next
+   phase of this document will be to either prioritise them or narrow
+   them down to a non-contradictory set, which should then allow us to
+   judge proposals on the basis of their fit.
+
+
+27.  Acknowledgements
+
+
+28.  Requirements notation
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 9]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   document are to be interpreted as            described in [RFC2119].
+
+
+29.  Security Considerations
+
+
+   There are currently no security considerations called out in this
+   draft.  There will be security considerations in the choice of which
+   requirements will be implemented, but there are no specific security
+   requirements during the requirements collection process.
+
+
+30.  References
+
+
+30.1  Normative References
+
+
+   [dnssecbis-protocol]
+              "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
+              Month 2004.
+
+
+30.2  Informative References
+
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, September 1998.
+
+
+
+Authors' Addresses
+
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London  W3 7LR
+   England
+
+
+   Phone: +44 (20) 8735 0686
+   EMail: ben@algroup.co.uk
+
+
+
+   Rip Loomis
+   Science Applications International Corporation
+   7125 Columbia Gateway Drive, Suite 300
+   Columbia, MD  21046
+   US
+
+
+   EMail: gilbert.r.loomis@saic.com
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                 [Page 10]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                 [Page 11]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
new file mode 100644
index 0000000..9c73c68
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
@@ -0,0 +1,1292 @@
+
+
+
+
+
+DNS Extensions                                              Yuji Kamite
+Internet-Draft                                       NTT Communications
+Expires: April 15, 2005                                 Masaya Nakayama
+                                                The University of Tokyo
+                                                       October 14, 2004
+
+
+
+                      TKEY Secret Key Renewal Mode
+                 draft-ietf-dnsext-tkey-renewal-mode-05
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on April 15, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines a new mode in TKEY and proposes an atomic
+   method for changing secret keys used for TSIG periodically.
+   Originally, TKEY provides methods of setting up shared secrets other
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 1]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   than manual exchange, but it cannot control timing of key renewal
+   very well though it can add or delete shared keys separately. This
+   proposal is a systematical key renewal procedure intended for
+   preventing signing DNS messages with old and non-safe keys
+   permanently.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1   Defined Words  . . . . . . . . . . . . . . . . . . . . . .  3
+     1.2   New Format and Assigned Numbers  . . . . . . . . . . . . .  4
+     1.3   Overview of Secret Key Renewal Mode  . . . . . . . . . . .  4
+   2.  Shared Secret Key Renewal  . . . . . . . . . . . . . . . . . .  5
+     2.1   Key Usage Time Check . . . . . . . . . . . . . . . . . . .  5
+     2.2   Partial Revocation . . . . . . . . . . . . . . . . . . . .  6
+     2.3   Key Renewal Message Exchange . . . . . . . . . . . . . . .  7
+       2.3.1   Query for Key Renewal  . . . . . . . . . . . . . . . .  7
+       2.3.2   Response for Key Renewal . . . . . . . . . . . . . . .  7
+       2.3.3   Attributes of Generated Key  . . . . . . . . . . . . .  8
+       2.3.4   TKEY RR structure  . . . . . . . . . . . . . . . . . .  8
+     2.4   Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
+       2.4.1   Query for Key Adoption . . . . . . . . . . . . . . . . 10
+       2.4.2   Response for Key Adoption  . . . . . . . . . . . . . . 10
+     2.5   Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
+       2.5.1   DH Exchange for Key Renewal  . . . . . . . . . . . . . 11
+       2.5.2   Server Assigned Keying for Key Renewal . . . . . . . . 12
+       2.5.3   Resolver Assigned Keying for Key Renewal . . . . . . . 13
+     2.6   Considerations about Non-compliant Hosts . . . . . . . . . 14
+   3.  Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
+   4.  Compulsory Key Revocation  . . . . . . . . . . . . . . . . . . 15
+     4.1   Compulsory Key Revocation by Server  . . . . . . . . . . . 15
+     4.2   Authentication Methods Considerations  . . . . . . . . . . 15
+   5.  Special Considerations for Two Servers' Case   . . . . . . . . 16
+     5.1   To Cope with Collisions of Renewal Requests  . . . . . . . 16
+   6.  Key Name Considerations  . . . . . . . . . . . . . . . . . . . 17
+   7.  Example Usage of Secret Key Renewal Mode   . . . . . . . . . . 17
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+  10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
+  11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+    11.1   Normative References . . . . . . . . . . . . . . . . . . . 21
+    11.2   Informative References . . . . . . . . . . . . . . . . . . 21
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
+       Intellectual Property and Copyright Statements . . . . . . . . 23
+
+
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 2]
+
+INTERNET-DRAFT                                              October 2004
+
+
+1.  Introduction
+
+   TSIG [RFC2845] provides DNS message integrity and the
+   request/transaction authentication by means of message authentication
+   codes (MAC). TSIG is a practical solution in view of calculation
+   speed and availability. However, TSIG does not have exchanging
+   mechanism of shared secret keys between server and resolver, and
+   administrators might have to exchange secret keys manually. TKEY
+   [RFC2930] is introduced to solve such problem and it can exchange
+   secrets for TSIG via networks.
+
+   In various modes of TKEY, a server and a resolver can add or delete a
+   secret key be means of TKEY message exchange. However, the existing
+   TKEY does not care fully about the management of keys which became
+   too old, or dangerous after long time usage.
+
+   It is ideal that the number of secret which a pair of hosts share
+   should be limited only one, because having too many keys for the same
+   purpose might not only be a burden to resolvers for managing and
+   distinguishing according to servers to query, but also does not seem
+   to be safe in terms of storage and protection against attackers.
+   Moreover, perhaps holding old keys long time might give attackers
+   chances to compromise by scrupulous calculation.
+
+   Therefore, when a new shared secret is established by TKEY, the
+   previous old secret should be revoked immediately. To accomplish
+   this, DNS servers must support a protocol for key renewal. This
+   document specifies procedure to refresh secret keys between two hosts
+   which is defined within the framework of TKEY, and it is called "TKEY
+   Secret Key Renewal Mode".
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+
+1.1.  Defined Words
+
+   * Inception Time: Beginning of the shared secret key lifetime. This
+   value is determined when the key is generated.
+
+   * Expiry Limit: Time limit of the key's validity. This value is
+   determined when a new key is generated. After Expiry Limit, server
+   and client (resolver) must not authenticate TSIG signed with the key.
+   Therefore, Renewal to the next key should be carried out before
+   Expiry Limit.
+
+   * Partial Revocation Time: Time when server judges the key is too old
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 3]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   and must be updated. It must be between Inception Time and Expiry
+   Limit.  This value is determined by server freely following its
+   security policy. e.g., If the time from Inception to Partial
+   Revocation is short, renewal will be carried out more often, which
+   might be safer.
+
+   * Revocation Time: Time when the key becomes invalid and can be
+   removed. This value is not determined in advance because it is the
+   actual time when revocation is completed.
+
+   * Adoption Time: Time when the new key is adopted as the next key
+   formally. After Adoption, the key is valid and server and client can
+   generate or verify TSIG making use of it. Adoption Time also means
+   the time when it becomes possible to remove the previous key, so
+   Revocation and Adoption are usually done at the same time.
+
+
+                  Partial
+    Inception     Revocation    Revocation         Expiry Limit
+     |                |              |             |
+     |----------------|- - - - - - >>|- (revoked) -|
+     |                |              |             |
+    previous key      |      |       |
+                             |- - - -|-------------------->> time
+                             |       |               new key
+                         Inception   Adoption
+
+
+1.2.  New Format and Assigned Numbers
+
+   TSIG
+         ERROR = (PartialRevoke), TBD
+
+   TKEY
+         Mode  = (server assignment for key renewal), TBD
+         Mode  = (Diffie-Hellman exchange for key renewal), TBD
+         Mode  = (resolver assignment for key renewal), TBD
+         Mode  = (key adoption), TBD
+
+
+1.3.  Overview of Secret Key Renewal Mode
+
+   When a server receives a query from a client signed with a TSIG key,
+   It always checks if the present time is within the range of usage
+   duration it considers safe. If it is judged that the key is too old,
+   i.e., after Partial Revocation Time, the server comes to be in
+   Partial Revocation state about the key, and this key is called
+   partially revoked.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 4]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   In this state, if a client sends a normal query (e.g., question about
+   A RR) other than TKEY Renewal request with TSIG signed with the old
+   key, the server returns an error message to notify that the time to
+   renew has come. This is called "PartialRevoke" error message. It is
+   server's choice whether it returns PartialRevoke or not. If and only
+   if the server is ready for changing its own key, it decides to return
+   PartialRevoke.
+
+   The client which got this error is able to notice that it is
+   necessary to refresh the secret. To make a new shared secret, it
+   sends a TKEY Renewal request, in which several keying methods are
+   available. It can make use of TSIG authentication signed with the
+   partially revoked key mentioned above.
+
+   After new secret establishment, the client sends a TKEY Adoption
+   request for renewal confirmation. This can also be authenticated with
+   the partially revoked key. If this is admitted by the server, the new
+   key is formally adopted, and at the same time the corresponding old
+   secret is invalidated. Then the client can send the first query again
+   signed with the new key.
+
+   Key renewal procedure is executed based on two-phase commit
+   mechanism. The first phase is the TKEY Renewal request and its
+   response, which means preparatory confirmation for key update. The
+   second phase is Adoption request and its response. If the server gets
+   request and client receives the response successfully, they can
+   finish renewal process. If any error happens and renewal process
+   fails during these phases, client should roll back to the beginning
+   of the first phase, and send TKEY Renewal request again. This
+   rollback can be done until the Expiry Limit of the key.
+
+
+2.  Shared Secret Key Renewal
+
+   Suppose a server and a client agree to change their TSIG keys
+   periodically. Key renewal procedure is defined between two hosts.
+
+2.1.  Key Usage Time Check
+
+   Whenever a server receives a query with TSIG and can find a key that
+   is used for signing it, the server checks its Inception Time, Partial
+   Revocation Time and Expiry Limit (this information is usually
+   memorized by the server).
+
+   When the present time is before Inception Time, the server MUST NOT
+   verify TSIG with the key, and server acts the same way as when the
+   key used by the client is not recognized. It follows [RFC2845] 4.5.1.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 5]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   When the present time is equal to Inception Time, or between
+   Inception Time and Partial Revocation Time, the behavior of the
+   server is the same as when a valid key is found. It follows [RFC2845]
+   4.5.2 and 4.5.3.
+
+   When the present time is the same as the Partial Revocation Time, or
+   between the Partial Revocation Time and Expiry Limit, the server
+   comes to be in Partial Revocation state about the TSIG key and
+   behaves according to the next section.
+
+   When the present time is the same as the Expiry Time or after it, the
+   server MUST NOT verify TSIG with the key, and returns error messages
+   in the same way as when the key used by the client is not recognized.
+   It follows [RFC2845] 4.5.1.
+
+
+2.2.  Partial Revocation
+
+   In Partial Revocation state, we say the server has partially revoked
+   the key and the key has become a "partially revoked key".
+
+   If server has received a query signed with the partially revoked key
+   for TKEY Renewal request (See section 2.3.) or Key Adoption request
+   (See section 2.4.), then server does proper process following each
+   specification. If it is for TKEY key deletion request ([RFC2930]
+   4.2), server MAY process usual deletion operation defined therein.
+
+   If server receives other types of query signed with the partially
+   revoked key, and both the corresponding MAC and signed TIME are
+   verified, then server begins returning answer whose TSIG error code
+   is "PartialRevoke" (See section 9.). Server MUST randomly but with
+   increasing frequency return PartialRevoke when in the Partial
+   Revocation state.
+
+   Server can decide when it actually sends PartialRevoke, checking if
+   it is appropriate time for renewal. Server MUST NOT return
+   PartialRevoke if this is apart long lived TSIG transaction (such as
+   AXFR) that started before the Partial Revocation Time.
+
+   If the client receives PartialRevoke and understands it, then it MUST
+   retry the query with the old key unless a new key has been adopted.
+   Client SHOULD start the process to renew the TSIG key. For key
+   renewal procedure, see details in Section 2.3 and 2.4.
+
+   PartialRevoke period (i.e., time while server returns PartialRevoke
+   randomely) SHOULD be small, say 2-5% of key lifetime. This is
+   server's choice.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 6]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   Server MUST keep track of clients ignoring PartialRevoke, thus
+   indicating ignorance of this TKEY mode.
+
+   PartialRevoke error messages have the role to inform clients of the
+   keys' partial revocation and urge them to send TKEY Renewal requests.
+   These error responses MUST be signed with those partial revoked keys
+   if the queries are signed with them. They are sent only when the
+   signing keys are found to be partially revoked. If the MAC of TSIG
+   cannot be verified with the partially revoked keys, servers MUST NOT
+   return PartialRevoke error with MAC, but MUST return another error
+   such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
+   words, a server informs its key's partial revocation only when the
+   MAC in the received query is valid.
+
+
+2.3.  Key Renewal Message Exchange
+
+2.3.1.  Query for Key Renewal
+
+   If a client has received a PartialRevoke error and authenticated the
+   response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
+   this document, we call it Renewal request, too.) to the server. The
+   request MUST be signed with TSIG or SIG(0) [RFC2931] for
+   authentication. If TSIG is selected, the client can sign it with the
+   partial revoked key.
+
+   Key Renewal can use one of several keying methods which is indicated
+   in "Mode" field of TKEY RR, and its message structure is dependent on
+   that method.
+
+
+2.3.2.  Response for Key Renewal
+
+   The server which has received Key Renewal request first tries to
+   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
+   verified with the partially revoked key, the request MUST be
+   authenticated.
+
+   After authentication, server must check existing old key's validity.
+   If the partially revoked key indicated in the request TKEY's OldName
+   and OldAlgorithm field (See section 2.3.4.) does not exist at the
+   server, "BADKEY" [RFC2845] is given in Error field for response. If
+   any other error happens, server returns appropriate error messages
+   following the specification described in section 2.5. If there are no
+   errors, server returns a Key Renewal answer. This answer MUST be
+   signed with TSIG or SIG(0) for authentication.
+
+   When this answer is successfully returned and no error is detected by
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 7]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   client, a new shared secret can be established. The details of
+   concrete keying procedure are given in the section 2.5.
+
+   Note:
+      Sometimes Adoption message and new Renewal request will cross on
+      the wire. In this case the newly generated key Adoption message is
+      resent.
+
+
+2.3.3.  Attributes of Generated Key
+
+   As a result of this message exchange, client comes to know the newly
+   generated key's attributes such as key's name, Inception Time and
+   Expiry Limit. They are decided by the server and told to the client;
+   in particular, however, once the server has decided Expiry Limit and
+   returned a response, it should obey the decision as far as it can. In
+   other words, they SHOULD NOT change time values for checking Expiry
+   Limit in the future without any special reason, such as security
+   issue like "Emergency Compulsory Revocation" described in section 8.
+
+   On the other hand, Partial Revocation Time of this generated key is
+   not decided based on the request, and not informed to the client. The
+   server can determine any value as long as it is between Inception
+   Time and Expiry Limit. However, the period from Inception to Partial
+   Revocation SHOULD be fixed as the server side's configuration or be
+   set the same as the corresponding old key's one.
+
+   Note:
+      Even if client sends Key Renewal request though the key described
+      in OldName has not been partially revoked yet, server does renewal
+      processes.  At the moment when the server accepts such requests
+      with valid authentication, it MUST forcibly consider the key is
+      already partially revoked, that is, the key's Partial Revocation
+      Time must be changed into the present time (i.e., the time when
+      the server receives the request).
+
+
+2.3.4.  TKEY RR structure
+
+   TKEY RR for Key Renewal message has the structure given below. In
+   principle, format and definition for each field follows [RFC2930].
+   Note that each keying scheme sometimes needs different interpretation
+   of RDATA field; for detail, see section 2.5.
+
+        Field        Type         Comment
+        -------      ------       -------
+        NAME         domain       used for a new key, see below
+        TYPE         u_int16_t    (defined in [RFC2930])
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 8]
+
+INTERNET-DRAFT                                              October 2004
+
+
+        CLASS        u_int16_t    (defined in [RFC2930])
+        TTL          u_int32_t    (defined in [RFC2930])
+        RDLEN        u_int16_t    (defined in [RFC2930])
+        RDATA:
+         Algorithm:   domain       algorithm for a new key
+         Inception:   u_int32_t    about the keying material
+         Expiration:  u_int32_t    about the keying material
+         Mode:        u_int16_t    scheme for key agreement
+                                   see section 9.
+         Error:       u_int16_t    see description below
+         Key Size:    u_int16_t    see description below
+         Key Data:    octet-stream
+         Other Size:  u_int16_t    (defined in [RFC2930])
+                                   size of other data
+         Other Data:               newly defined: see description below
+
+
+     For "NAME" field, both non-root and root name are allowed. It may
+     be used for a new key's name in the same manner as [RFC2930] 2.1.
+
+     "Algorithm" specifies which algorithm is used for agreed keying
+     material, which is used for identification of the next key.
+
+     "Inception" and "Expiration" are used for the valid period of
+     keying material. The meanings differ somewhat according to whether
+     the message is request or answer, and its keying scheme.
+
+     "Key Data" has different meanings according to keying schemes.
+
+     "Mode" field stores the value in accordance with the keying method,
+     and see section 2.5. Servers and clients supporting TKEY Renewal
+     method MUST implement "Diffie-Hellman exchange for key renewal"
+     scheme. All other modes are OPTIONAL.
+
+     "Error" is an extended RCODE which includes "PartialRevoke" value
+     too. See section 9.
+
+     "Other Data" field has the structure given below.  They describe
+     attributes of the key to be renewed.
+
+        in Other Data filed:
+
+          Field            Type       Comment
+          -------          ------     -------
+          OldNAME          domain     name of the old key
+          OldAlgorithm     domain     algorithm of the old key
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                 [Page 9]
+
+INTERNET-DRAFT                                              October 2004
+
+
+          "OldName" indicates the name of the previous key (usually,
+          this is partially revoked key's name that client noticed by
+          PartialRevoke answer from server), and "OldAlogirthm"
+          indicates its algorithm.
+
+
+2.4.  Key Adoption
+
+2.4.1.  Query for Key Adoption
+
+   After receiving a TKEY Renewal answer, the client gets the same
+   secret as the server. Then, it sends a TKEY Adoption request. The
+   request's question section's QNAME field is the same as the NAME
+   filed of TKEY written below. In additional section, there is one TKEY
+   RR that has the structure and values described below.
+
+     "NAME" field is the new key's name to be adopted which was already
+     generated by Renewal message exchange. "Algorithm" is its
+     algorithm. "Inception" means the key's Inception Time, and
+     "Expiration" means Expiry Limit.
+
+     "Mode" field is the value of "key adoption". See section 9.
+
+     "Other Data" field in Adoption has the same structure as that of
+     Renewal request message. "OldName" means the previous old key, and
+     "OldAlogirthm" means its algorithm.
+
+   Key Adoption request MUST be signed with TSIG or SIG(0) for
+   authentication. The client can sign TSIG with the previous key. Note
+   that until Adoption is finished, the new key is treated as invalid,
+   thus it cannot be used for authentication immediately.
+
+
+2.4.2.  Response for Key Adoption
+
+   The server which has received Adoption request, it verifies TSIG or
+   SIG(0) accompanying it. If the TSIG is signed with the partially
+   revoked key and can be verified, the message MUST be authenticated.
+
+   If the next new key indicated by the request TKEY's "NAME" is not
+   present at the server, BADNAME [RFC2845] is given in Error field and
+   the error message is returned.
+
+   If the next key exists but it has not been adopted formally yet, the
+   server confirms the previous key's existence indicated by the
+   "OldName" and "OldAlgorithm" field. If it succeeds, the server
+   executes Adoption of the next key and Revocation of the previous key.
+   Response message duplicates the request's TKEY RR with NOERROR,
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 10]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   including "OldName" and "OldAlgorithm" that indicate the revoked key.
+
+   If the next key exists but it is already adopted, the server returns
+   a response message regardless of the substance of the request TKEY's
+   "OldName". In this response, Response TKEY RR has the same data as
+   the request's one except as to its "Other Data" that is changed into
+   null (i.e., "Other Size" is zero), which is intended for telling the
+   client that the previous key name was ignored, and the new key is
+   already available.
+
+   Client sometimes has to retry Adoption request. Suppose the client
+   sent request signed with the partially revoked key, but its response
+   did not return successfully (e.g., due to the drop of UDP packet).
+   Client will probably retry Adoption request; however, the request
+   will be refused in the form of TSIG "BADKEY" error because the
+   previous key was already revoked. In this case, client will
+   retransmit Adoption request signed with the next key, and expect a
+   response which has null "Other Data" for confirming the completion of
+   renewal.
+
+
+2.5.  Keying Schemes
+
+   In Renewal message exchanges, there are no limitations as to which
+   keying method is actually used. The specification of keying
+   algorithms is independent of the general procedure of Renewal that is
+   described in section 2.3.
+
+   Now this document specifies three algorithms in this section, but
+   other future documents can make extensions defining other methods.
+
+
+2.5.1.  DH Exchange for Key Renewal
+
+   This scheme is defined as an extended method of [RFC2930] 4.1. This
+   specification only describes the difference from it and special
+   notice; assume that all other points, such as keying material
+   computation, are the exactly same as the specification of [RFC2930]
+   4.1.
+
+   Query
+      In Renewal request for type TKEY with this mode, there is one TKEY
+      RR and one KEY RR in the additional information section. KEY RR is
+      the client's Diffie-Hellman public key [RFC2539].
+
+      QNAME in question section is the same as that of "NAME" field in
+      TKEY RR, i.e., it means the requested new key's name.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 11]
+
+INTERNET-DRAFT                                              October 2004
+
+
+      TKEY "Mode" field stores the value of "DH exchange for key
+      renewal". See section 9.
+
+      TKEY "Inception" and "Expiration" are those requested for the
+      keying material, that is, requested usage period of a new key.
+
+      TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
+
+   Response
+      The server which received this request first verifies the TSIG,
+      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+      old key's existence validity is checked, following section 2.3. If
+      any incompatible DH key is found in the request, "BADKEY"
+      [RFC2845] is given in Error field for response. "FORMERR" is given
+      if the query included no DH KEY.
+
+      If there are no errors, the server processes a response according
+      to Diffie-Hellman algorithm and returns the answer. In this
+      answer, there is one TKEY RR in answer section and KEY RR(s) in
+      additional section.
+
+      As long as no error has occurred, all values of TKEY are equal to
+      that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
+      Inception, Expiration, Key Size and Key Data.
+
+      TKEY "NAME" field in the answer specifies the name of newly
+      produced key which the client MUST use.
+
+      TKEY "Inception" and "Expiration" mean the periods of the produced
+      key usage. "Inception" is set to be the time when the new key is
+      actually generated or the time before it, and it will be regarded
+      as Inception Time. "Expiration" is determined by the server, and
+      it will be regarded as Expiry Limit.
+
+      TKEY "Key Data" is used as an additional nonce, following
+      [RFC2930] 4.1.
+
+      The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
+      the additional section and a server Diffie-Hellman KEY RR will
+      also be present in the answer section, following [RFC2930] 4.1.
+
+
+2.5.2.  Server Assigned Keying for Key Renewal
+
+   This scheme is defined as an extended method of [RFC2930] 4.4. This
+   specification only describes the difference from it and special
+   notice; assume that all other points, such as secret encrypting
+   method, are the exactly same as the specification of [RFC2930] 4.4.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 12]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   Query
+      In Renewal request for type TKEY with this mode, there is one TKEY
+      RR and one KEY RR in the additional information section. KEY RR is
+      used in encrypting the response.
+
+      QNAME in question section is the same as that of "NAME" field in
+      TKEY RR, i.e., it means the requested new key's name.
+
+      TKEY "Mode" field stores the value of "server assignment for key
+      renewal". See section 9.
+
+      TKEY "Inception" and "Expiration" are those requested for the
+      keying material, that is, requested usage period of a new key.
+
+      TKEY "Key Data" is provided following the specification of
+      [RFC2930] 4.4.
+
+   Response
+      The server which received this request first verifies the TSIG,
+      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+      old key's existence validity is checked, following section 2.3.
+      "FORMERR" is given if the query specified no encryption key.
+
+      If there are no errors, the server response contains one TKEY RR
+      in the answer section, and echoes the KEY RR provided in the query
+      in the additional information section.
+
+      TKEY "NAME" field in the answer specifies the name of newly
+      produced key which the client MUST use.
+
+      TKEY "Inception" and "Expiration" mean the periods of the produced
+      key usage. "Inception" is set to be the time when the new key is
+      actually generated or the time before it, and it will be regarded
+      as Inception Time. "Expiration" is determined by the server, and
+      it will be regarded as Expiry Limit.
+
+      TKEY "Key Data" is the assigned keying data encrypted under the
+      public key in the resolver provided KEY RR, which is the same as
+      [RFC2930] 4.4.
+
+
+2.5.3.  Resolver Assigned Keying for Key Renewal
+
+   This scheme is defined as an extended method of [RFC2930] 4.5. This
+   specification only describes the difference from it and special
+   notice; assume that all other points, such as secret encrypting
+   method, are the exactly same as the specification of [RFC2930] 4.5.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 13]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   Query
+      In Renewal request for type TKEY with this mode, there is one TKEY
+      RR and one KEY RR in the additional information section. TKEY RR
+      has the encrypted keying material and KEY RR is the server public
+      key used to encrypt the data.
+
+      QNAME in question section is the same as that of "NAME" field in
+      TKEY RR, i.e., it means the requested new key's name.
+
+      TKEY "Mode" field stores the value of "resolver assignment for key
+      renewal". See section 9.
+
+      TKEY "Inception" and "Expiration" are those requested for the
+      keying material, that is, requested usage period of a new key.
+
+      TKEY "Key Data" is the encrypted keying material.
+
+   Response
+      The server which received this request first verifies the TSIG,
+      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+      old key's existence validity is checked, following section 2.3.
+      "FORMERR" is given if the server does not have the corresponding
+      private key for the KEY RR that was shown sin the request.
+
+      If there are no errors, the server returns a response. The
+      response contains a TKEY RR in the answer section to tell the
+      shared key's name and its usage time values.
+
+      TKEY "NAME" field in the answer specifies the name of newly
+      produced key which the client MUST use.
+
+      TKEY "Inception" and "Expiration" mean the periods of the produced
+      key usage. "Inception" is set to be the time when the new key is
+      actually generated or the time before it, and it will be regarded
+      as Inception Time. "Expiration" is determined by the server, and
+      it will be regarded as Expiry Limit.
+
+
+2.6.  Considerations about Non-compliant Hosts
+
+   Key Renewal requests and responses must be exchanged between hosts
+   which can understand them and do proper processes. PartialRevoke
+   error messages will be only ignored if they should be returned to
+   non-compliant hosts.
+
+   Note that server does not inform actively the necessity of renewal to
+   clients, but inform it as responses invoked by client's query.
+   Server needs not care whether the PartialRevoke errors has reached
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 14]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   client or not. If client has not received yet because of any reasons
+   such as packet drops, it will resend the queries, and finally will be
+   able to get PartialRevoke information.
+
+
+3.  Secret Storage
+
+   Every server keeps all secrets and attached information, e.g.,
+   Inception Time, Expiry Limit, etc. safely to be able to recover from
+   unexpected stop. To accomplish this, formally adopted keys SHOULD be
+   memorized not only on memory, but also be stored in the form of some
+   files. It will become more secure if they are stored in ecrypted
+   form.
+
+
+4.  Compulsory Key Revocation
+
+4.1.  Compulsory Key Revocation by Server
+
+   There is a rare but possible case that although servers have already
+   partially revoked keys, clients do not try to send any Renewal
+   requests. If this state continues, in the future it will become the
+   time of Expiry Limit. After Expiry Limit, the keys will be expired
+   and completely removed, so this is called Compulsory Key Revocation
+   by server.
+
+   If Expiry Limit is too distant from the Partial Revocation Time, then
+   even though very long time passes, clients will be able to refresh
+   secrets only if they add TSIG signed with those old partially revoked
+   keys into requests, which is not safe.
+
+   On the other hand, if Expiry Limit is too close to Partial Revocation
+   Time, perhaps clients might not be able to notice their keys' Partial
+   Revocation by getting "PartialRevoke" errors.
+
+   Therefore, servers should set proper Expiry Limit to their keys,
+   considering both their keys' safety, and enough time for clients to
+   send requests and process renewal.
+
+
+4.2.  Authentication Methods Considerations
+
+   It might be ideal to provide both SIG(0) and TSIG as authentication
+   methods. For example:
+
+     A client and a server start SIG(0) authentication at first, to
+     establish TSIG shared keys by means of "Query for Diffie-Hellman
+     Exchanged Keying" as described in [RFC2930] 4.1. Once they get
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 15]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     shared secret, they keep using TSIG for queries and responses.
+     After a while the server returns a "ParitalRevoke" error and they
+     begin a key renewal process. Both TSIG signed with partially
+     revoked keys and SIG(0) are okay for authentication, but TSIG would
+     be easier to use considering calculation efficiency.
+
+     Suppose now client is halted for long time with some reason.
+     Because server does not execute any renewal process, it will
+     finally do Compulsory Revocation. Even if client restarts and sends
+     a key Renewal request, it will fail because old key is already
+     deleted at server.
+
+     At this moment, however, if client also uses SIG(0) as another
+     authentication method, it can make a new shared key again and
+     recover successfully by sending "Query for Diffie-Hellman Exchanged
+     Keying" with SIG(0).
+
+
+5.  Special Considerations for Two servers' Case
+
+   This section refers to the case where both hosts are DNS servers
+   which can act as full resolvers as well and using one shared key
+   only. If one server (called Server A) wants to refresh a shared key
+   (called "Key A-B"), it will await a TKEY Renewal request from the
+   other server (called Server B). However, perhaps Server A wants to
+   refresh the key right now.
+
+   In this case, Server A is allowed to send a Renewal request to Server
+   B, if Server A knows the Key A-B is too old and wants to renew it
+   immediately.
+
+   Note that the initiative in key renewal belongs to Server A because
+   it can notice the Partial Revocation Time and decide key renewal. If
+   Server B has information about Partial Revocation Time as well, it
+   can also decide for itself to send Renewal request to Server A.
+   However, it is not essential for both two servers have information
+   about key renewal timing.
+
+5.1.  To Cope with Collisions of Renewal Requests
+
+   At least one of two hosts which use Key Renewal must know their key
+   renewal information such as Partial Revocation Time. It is okay that
+   both hosts have it.
+
+   Provided that both two servers know key renewal timing information,
+   there is possibility for them to begin partial revocation and sending
+   Renewal requests to each other at the same time. Such collisions will
+   not happen so often because Renewal requests are usually invoked when
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 16]
+
+INTERNET-DRAFT                                              October 2004
+
+
+   hosts want to send queries, but it is possible.
+
+   When one of two servers tries to send Renewal requests, it MUST
+   protect old secrets that it has partially revoked and prevent it from
+   being refreshed by any requests from the other server (i.e., it must
+   lock the old secret during the process of renewal). While the server
+   is sending Renewal requests and waiting responses, it ignores the
+   other server's Renewal requests.
+
+   Therefore, servers might fail to change secrets by means of their own
+   requests to others. After failure they will try to resend, but they
+   should wait for random delays by the next retries. If they get any
+   Renewal requests from others while they are waiting, their shared
+   keys may be refreshed, then they do not need to send any Renewal
+   requests now for themselves.
+
+
+6.  Key Name Considerations
+
+   Since both servers and clients have only to distinguish new secrets
+   and old ones, keys' names do not need to be specified strictly.
+   However, it is recommended that some serial number or key generation
+   time be added to the name and that the names of keys between the same
+   pair of hosts should have some common labels among their keys. For
+   example, suppose A.example.com. and B.example.com. share the key
+   "<serial number>.A.example.com.B.example.com." such as
+   "10010.A.example.com.B.example.com.". After key renewal, they change
+   their secret and name into "10011.A.example.com.B.example.com."
+
+   Servers and clients must be able to use keys properly for each query.
+   Because TSIG secret keys themselves do not have any particular IDs to
+   be distinguished and would be identified by their names and
+   algorithm, it must be understood correctly what keys are refreshed.
+
+
+7.  Example Usage of Secret Key Renewal Mode
+
+   This is an example of Renewal mode usage where a Server,
+   server.example.com, and a Client, client.exmple.com have an initial
+   shared secret key named "00.client.example.com.server.example.com".
+
+     (1) The time values for key
+     "00.client.example.com.server.example.com" was set as follows:
+     Inception Time is at 1:00, Expiry Limit is at 21:00.
+
+     (2) At Server, renewal time has been set: Partial Revocation Time
+     is at 20:00.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 17]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     (3) Suppose the present time is 19:55. If Client sends a query
+     signed with key "00.client.example.com.server.example.com" to ask
+     the IP address of "www.example.com", finally it will get a proper
+     answer from Server with valid TSIG (NOERROR).
+
+     (4) At 20:05. Client sends a query to ask the IP address of
+     "www2.example.com". It is signed with key
+     "00.client.example.com.server.example.com". Server returns an
+     answer for the IP address. However, server has begun retuning
+     PartialRevoke Error randomely. This answer includes valid TSIG MAC
+     signed with "00.client.example.com.server.example.com", and its
+     Error Code indicates PartialRevoke. Client understands that the
+     current key is partially revoked.
+
+     (5) At 20:06. Client sends a Renewal request to Server. This
+     request is signed with key
+     "00.client.example.com.server.example.com". It includes data such
+     as:
+
+      Question Section:
+         QNAME = 01.client.example.com. (Client can set this freely)
+         TYPE  = TKEY
+
+      Additional Section:
+         01.client.example.com. TKEY
+          Algorithm    = hmac-md5-sig-alg.reg.int.
+          Inception    = (value meaning 20:00)
+          Expiration   = (value meaning next day's 16:00)
+          Mode         = (DH exchange for key renewal)
+          OldName      = 00.client.example.com.server.example.com.
+          OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+      Additional Section also contains a KEY RR for DH and a TSIG RR.
+
+     (6) As soon as Server receives this request, it verifies TSIG. It
+     is signed with the partially revoked key
+     "00.client.example.com.server.example.com". and Server accepts the
+     request. It creates a new key by Diffie-Hellman calculation and
+     returns an answer which includes data such as:
+
+      Answer Section:
+         01.client.example.com.server.example.com. TKEY
+          Algorithm    = hmac-md5-sig-alg.reg.int.
+          Inception    = (value meaning 20:00)
+          Expiration   = (value meaning next day's 16:00)
+          Mode         = (DH exchange for key renewal)
+          OldName      = 00.client.example.com.server.example.com.
+          OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 18]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     Answer Section also contains KEY RRs for DH.
+
+      Additional Section also contains a TSIG RR.
+     This response is signed with key
+     "00.client.example.com.server.example.com" without error.
+
+     At the same time, Server decides to set the Partial Revocation Time
+     of this new key "01.client.example.com.server.example.com." as next
+     day's 15:00.
+
+     (7) Client gets the response and checks TSIG MAC, and calculates
+     Diffie-Hellman. It will get a new key, and it has been named
+     "01.client.example.com.server.example.com" by Server.
+
+     (8) At 20:07. Client sends an Adoption request to Server. This
+     request is signed with the previous key
+     "00.client.example.com.server.example.com". It includes:
+
+      Question Section:
+         QNAME = 01.client.example.com.server.example.com.
+         TYPE  = TKEY
+
+      Additional Section:
+         01.client.example.com.server.example.com. TKEY
+          Algorithm    = hmac-md5-sig-alg.reg.int.
+          Inception    = (value meaning 20:00)
+          Expiration   = (value meaning next day's 16:00)
+          Mode         = (key adoption)
+          OldName      = 00.client.example.com.server.example.com.
+          OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+     Additional Section also contains a TSIG RR.
+
+     (9) Server verifies the query's TSIG. It is signed with the
+     previous key and authenticated. It returns a response whose TKEY RR
+     is the same as the request's one. The response is signed with key
+     "00.client.example.com.server.example.com.". As soon as the
+     response is sent, Server revokes and removes the previous key. At
+     the same time, key "01.client.example.com.server.example.com." is
+     validated.
+
+     (10) Client acknowledges the success of Adoption by receiving the
+     response.  Then, it retries to send an original question about
+     "www2.example.com". It is signed with the adopted key
+     "01.client.example.com.server.example.com", so Server authenticates
+     it and returns an answer.
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 19]
+
+INTERNET-DRAFT                                              October 2004
+
+
+     (11) This key is used until next day's 15:00. After that, it will
+     be partially revoked again.
+
+
+8.  Security Considerations
+
+   This document considers about how to refresh shared secret. Secret
+   changed by this method is used at servers in support of TSIG
+   [RFC2845].
+
+   [RFC2104] says that current attacks to HMAC do not indicate a
+   specific recommended frequency for key changes but periodic key
+   refreshment is a fundamental security practice that helps against
+   potential weaknesses of the function and keys, and limits the damage
+   of an exposed key. TKEY Secret Key Renewal provides the method of
+   periodical key refreshment.
+
+   In TKEY Secret Key Renewal, clients need to send two requests
+   (Renewal and Adoption) and spend time to finish their key renewal
+   processes. Thus the usage period of secrets should be considered
+   carefully based on both TKEY processing performance and security.
+
+   This document specifies the procedure of periodical key renewal, but
+   actually there is possibility for servers to have no choice other
+   than revoking their secret keys immediately especially when the keys
+   are found to be compromised by attackers. This is called "Emergency
+   Compulsory Revocation". For example, suppose the original Expiry
+   Limit was set at 21:00, Partial Revocation Time at 20:00 and
+   Inception Time at 1:00.  if at 11:00 the key is found to be
+   compromised, the server sets Expiry Limit forcibly to be 11:00 or
+   before it.
+
+   Consequently, once Compulsory Revocation (See section 4.) is carried
+   out, normal renewal process described in this document cannot be done
+   any more as far as the key is concerned. However, after such
+   accidents happened, the two hosts are able to establish secret keys
+   and begin renewal procedure only if they have other (non-compromised)
+   shared TSIG keys or safe SIG(0) keys for the authentication of
+   initial secret establishment such as Diffie-Hellman Exchanged Keying.
+
+
+9.  IANA Considerations
+
+   IANA needs to allocate a value for "DH exchange for key renewal",
+   "server assignment for key renewal", "resolver assignment for key
+   renewal" and "key adoption" in the mode filed of TKEY. It also needs
+   to allocate a value for "PartialRevoke" from the extended RCODE
+   space.
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 20]
+
+INTERNET-DRAFT                                              October 2004
+
+
+10.  Acknowledgements
+
+   The authors would like to thank Olafur Gudmundsson, whose helpful
+   input and comments contributed greatly to this document.
+
+
+11.  References
+
+11.1.  Normative References
+
+[RFC2119]
+     Bradner, S., "Key words for use in RFCs to Indicate Requirement
+     Levels", RFC 2119, March 1997.
+
+[RFC2539]
+     D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
+     System (DNS)", RFC 2539, March 1999.
+
+[RFC2845]
+     Vixie, P., Gudmundsson, O., Eastlake, D. and B.  Wellington,
+     "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
+     May 2000.
+
+[RFC2930]
+     D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
+     RFC 2930, September 2000.
+
+[RFC2931]
+     D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
+     )", RFC 2931, September 2000.
+
+11.2.  Informative References
+
+[RFC2104]
+     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
+     Authentication", RFC2104, February 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 21]
+
+INTERNET-DRAFT                                              October 2004
+
+
+Authors' Addresses
+
+   Yuji Kamite
+   NTT Communications Corporation
+   Tokyo Opera City Tower
+   3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
+   163-1421, Japan
+   EMail: y.kamite@ntt.com
+
+
+   Masaya Nakayama
+   Information Technology Center, The University of Tokyo
+   2-11-16 Yayoi, Bunkyo-ku, Tokyo
+   113-8658, Japan
+   EMail: nakayama@nc.u-tokyo.ac.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 22]
+
+INTERNET-DRAFT                                              October 2004
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Kamite, et. al.          Expires April 15, 2005                [Page 23]
+
+
+
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
new file mode 100644
index 0000000..a598826
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
@@ -0,0 +1,1501 @@
+Network Working Group                                           J. Ihren
+Internet-Draft                                             Autonomica AB
+Expires: April 18, 2005                                       O. Kolkman
+                                                                RIPE NCC
+                                                              B. Manning
+                                                                  EP.net
+                                                        October 18, 2004
+
+
+
+  An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
+                         DNSSEC Trust Anchors.
+               draft-ietf-dnsext-trustupdate-threshold-00
+
+
+Status of this Memo
+
+
+   By submitting this Internet-Draft, I certify that any applicable
+   patent or other IPR claims of which I am aware have been disclosed,
+   and any of which I become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+   This Internet-Draft will expire on April 18, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+
+Abstract
+
+
+   The DNS Security Extensions (DNSSEC) works by validating so called
+   chains of authority.  The start of these chains of authority are
+   usually public keys that are anchored in the DNS clients.  These keys
+   are known as the so called trust anchors.
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 1]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   This memo describes a method how these client trust anchors can be
+   replaced using the DNS validation and querying mechanisms (in-band)
+   when the key pairs used for signing by zone owner are rolled.
+
+
+   This memo also describes a method to establish the validity of trust
+   anchors for initial configuration, or priming, using out of band
+   mechanisms.
+
+
+Table of Contents
+
+
+   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1   Key Signing Keys, Zone Signing Keys and Secure Entry
+           Points . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Introduction and Background  . . . . . . . . . . . . . . . . .  5
+     2.1   Dangers of Stale Trust Anchors . . . . . . . . . . . . . .  5
+   3.  Threshold-based Trust Anchor Rollover  . . . . . . . . . . . .  7
+     3.1   The Rollover . . . . . . . . . . . . . . . . . . . . . . .  7
+     3.2   Threshold-based Trust Update . . . . . . . . . . . . . . .  8
+     3.3   Possible Trust Update States . . . . . . . . . . . . . . .  9
+     3.4   Implementation notes . . . . . . . . . . . . . . . . . . . 10
+     3.5   Possible transactions  . . . . . . . . . . . . . . . . . . 11
+       3.5.1   Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
+       3.5.2   Addition of a new DNSKEY (no removal)  . . . . . . . . 12
+       3.5.3   Removal of old DNSKEY (no addition)  . . . . . . . . . 12
+       3.5.4   Multiple DNSKEYs replaced  . . . . . . . . . . . . . . 12
+     3.6   Removal of trust anchors for a trust point . . . . . . . . 12
+     3.7   No need for resolver-side overlap of old and new keys  . . 13
+   4.  Bootstrapping automatic rollovers  . . . . . . . . . . . . . . 14
+     4.1   Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
+       4.1.1   Bootstrapping trust anchors using a priming key  . . . 14
+       4.1.2   Distribution of priming keys . . . . . . . . . . . . . 15
+   5.  The Threshold Rollover Mechanism vs Priming  . . . . . . . . . 16
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
+     6.1   Threshold-based Trust Update Security Considerations . . . 17
+     6.2   Priming Key Security Considerations  . . . . . . . . . . . 17
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 20
+   8.2   Informative References . . . . . . . . . . . . . . . . . . . 20
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
+   B.  Document History . . . . . . . . . . . . . . . . . . . . . . . 23
+     B.1   prior to version 00  . . . . . . . . . . . . . . . . . . . 23
+     B.2   version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
+       Intellectual Property and Copyright Statements . . . . . . . . 24
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 2]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+1.  Terminology
+
+
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+   and "MAY" in this document are to be interpreted as described in
+   RFC2119 [1].
+
+
+   The term "zone" refers to the unit of administrative control in the
+   Domain Name System.  In this document "name server" denotes a DNS
+   name server that is authoritative (i.e.  knows all there is to know)
+   for a DNS zone.  A "zone owner" is the entity responsible for signing
+   and publishing a zone on a name server.  The terms "authentication
+   chain", "bogus", "trust anchors" and "Island of Security" are defined
+   in [4].  Throughout this document we use the term "resolver" to mean
+   "Validating Stub Resolvers" as defined in [4].
+
+
+   We use the term "security apex" as the zone for which a trust anchor
+   has been configured (by validating clients) and which is therefore,
+   by definition, at the root of an island of security.  The
+   configuration of trust anchors is a client side issue.  Therefore a
+   zone owner may not always know if their zone has become a security
+   apex.
+
+
+   A "stale anchor" is a trust anchor (a public key) that relates to a
+   key that is not used for signing.  Since trust anchors indicate that
+   a zone is supposed to be secure a validator will mark the all data in
+   an island of security as bogus when all trust anchors become stale.
+
+
+   It is assumed that the reader is familiar with public key
+   cryptography concepts [REF: Schneier Applied Cryptography] and is
+   able to distinguish between the private and public parts of a key
+   based on the context in which we use the term "key".  If there is a
+   possible ambiguity we will explicitly mention if a private or a
+   public part of a key is used.
+
+
+   The term "administrator" is used loosely throughout the text.  In
+   some cases an administrator is meant to be a person, in other cases
+   the administrator may be a process that has been delegated certain
+   responsibilities.
+
+
+1.1  Key Signing Keys, Zone Signing Keys and Secure Entry Points
+
+
+   Although the DNSSEC protocol does not make a distinction between
+   different keys the operational practice is that a distinction is made
+   between zone signing keys and key signing keys.  A key signing key is
+   used to exclusively sign the DNSKEY Resource Record (RR) set at the
+   apex of a zone and the zone signing keys sign all the data in the
+   zone (including the DNSKEY RRset at the apex).
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 3]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   Keys that are intended to be used as the start of the authentication
+   chain for a particular zone, either because they are pointed to by a
+   parental DS RR or because they are configured as a trust anchor, are
+   called Secure Entry Point (SEP) keys.  In practice these SEP keys
+   will be key signing keys.
+
+
+   In order for the mechanism described herein to work the keys that are
+   intended to be used as secure entry points MUST have the SEP [2] flag
+   set.  In the examples it is assumed that keys with the SEP flag set
+   are used as key signing keys and thus exclusively sign the DNSKEY
+   RRset published at the apex of the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 4]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+2.  Introduction and Background
+
+
+   When DNSSEC signatures are validated the resolver constructs a chain
+   of authority from a pre-configured trust anchor to the DNSKEY
+   Resource Record (RR), which contains the public key that validates
+   the signature stored in an RRSIG RR.  DNSSEC is designed so that the
+   administrator of a resolver can validate data in multiple islands of
+   security by configuring multiple trust anchors.
+
+
+   It is expected that resolvers will have more than one trust anchor
+   configured.  Although there is no deployment experience it is not
+   unreasonable to expect resolvers to be configured with a number of
+   trust anchors that varies between order 1 and order 1000.  Because
+   zone owners are expected to roll their keys, trust anchors will have
+   to be maintained (in the resolver end) in order not to become stale.
+
+
+   Since there is no global key maintenance policy for zone owners and
+   there are no mechanisms in the DNS to signal the key maintenance
+   policy it may be very hard for resolvers administrators to keep their
+   set of trust anchors up to date.  For instance, if there is only one
+   trust anchor configured and the key maintenance policy is clearly
+   published, through some out of band trusted channel, then a resolver
+   administrator can probably keep track of key rollovers and update the
+   trust anchor manually.  However, with an increasing number of trust
+   anchors all rolled according to individual policies that are all
+   published through different channels this soon becomes an
+   unmanageable problem.
+
+
+2.1  Dangers of Stale Trust Anchors
+
+
+   Whenever a SEP key at a security apex is rolled there exists a danger
+   that "stale anchors" are created.  A stale anchor is a trust anchor
+   (i.e.  a public key configured in a validating resolver) that relates
+   to a private key that is no longer used for signing.
+
+
+   The problem with a stale anchors is that they will (from the
+   validating resolvers point of view) prove data to be false even
+   though it is actually correct.  This is because the data is either
+   signed by a new key or is no longer signed and the resolver expects
+   data to be signed by the old (now stale) key.
+
+
+   This situation is arguably worse than not having a trusted key
+   configured for the secure entry point, since with a stale key no
+   lookup is typically possible (presuming that the default
+   configuration of a validating recursive nameserver is to not give out
+   data that is signed but failed to verify.
+
+
+   The danger of making configured trust anchors become stale anchors
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 5]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   may be a reason for zone owners not to roll their keys.  If a
+   resolver is configured with many trust anchors that need manual
+   maintenance it may be easy to not notice a key rollover at a security
+   apex, resulting in a stale anchor.
+
+
+   In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
+   track key rollovers and modify the configured trust anchors
+   accordingly.  The mechanism is stateless and does not need protocol
+   extensions.  The proposed design is that this mechanism is
+   implemented as a "trust updating machine" that is run entirely
+   separate from the validating resolver except that the trust updater
+   will have influence over the trust anchors used by the latter.
+
+
+   In Section 4 we describe a method [Editors note: for now only the
+   frame work and a set of requirements] to install trust anchors.  This
+   method can be used at first configuration or when the trust anchors
+   became stale (typically due to a failure to track several rollover
+   events).
+
+
+   The choice for which domains trust anchors are to be configured is a
+   local policy issue.  So is the choice which trust anchors has
+   prevalence if there are multiple chains of trust to a given piece of
+   DNS data (e.g.  when a parent zone and its child both have trust
+   anchors configured).  Both issues are out of the scope of this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 6]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+3.  Threshold-based Trust Anchor Rollover
+
+
+3.1  The Rollover
+
+
+   When a key pair is replaced all signatures (in DNSSEC these are the
+   RRSIG records) created with the old key will be replaced by new
+   signatures created by the new key.  Access to the new public key is
+   needed to verify these signatures.
+
+
+   Since zone signing keys are in "the middle" of a chain of authority
+   they can be verified using the signature made by a key signing key.
+   Rollover of zone signing keys is therefore transparent to validators
+   and requires no action in the validator end.
+
+
+   But if a key signing key is rolled a resolver can determine its
+   authenticity by either following the authorization chain from the
+   parents DS record, an out-of-DNS authentication mechanism or by
+   relying on other trust anchors known for the zone in which the key is
+   rolled.
+
+
+   The threshold trust anchor rollover mechanism (or trust update),
+   described below, is based on using existing trust anchors to verify a
+   subset of the available signatures.  This is then used as the basis
+   for a decision to accept the new keys as valid trust anchors.
+
+
+   Our example pseudo zone below contains a number of key signing keys
+   numbered 1 through Y and two zone signing keys A and B.  During a key
+   rollover key 2 is replaced by key Y+1.  The zone content changes
+   from:
+
+
+          example.com.  DNSKEY key1
+          example.com.  DNSKEY key2
+          example.com.  DNSKEY key3
+          ...
+          example.com.  DNSKEY keyY
+
+
+          example.com.  DNSKEY keyA
+          example.com.  DNSKEY keyB
+
+
+          example.com.  RRSIG DNSKEY ... (key1)
+          example.com.  RRSIG DNSKEY ... (key2)
+          example.com.  RRSIG DNSKEY ... (key3)
+          ...
+          example.com.  RRSIG DNSKEY ... (keyY)
+          example.com.  RRSIG DNSKEY ... (keyA)
+          example.com.  RRSIG DNSKEY ... (keyB)
+
+
+    to:
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 7]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+          example.com.  DNSKEY key1
+          example.com.  DNSKEY key3
+          ...
+          example.com.  DNSKEY keyY
+          example.com.  DNSKEY keyY+1
+
+
+          example.com.  RRSIG DNSKEY ... (key1)
+          example.com.  RRSIG DNSKEY ... (key3)
+          ...
+          example.com.  RRSIG DNSKEY ... (keyY)
+          example.com.  RRSIG DNSKEY ... (keyY+1)
+          example.com.  RRSIG DNSKEY ... (keyA)
+          example.com.  RRSIG DNSKEY ... (keyB)
+
+
+   When the rollover becomes visible to the verifying stub resolver it
+   will be able to verify the RRSIGs associated with key1, key3 ...
+   keyY.  There will be no RRSIG by key2 and the RRSIG by keyY+1 will
+   not be used for validation, since that key is previously unknown and
+   therefore not trusted.
+
+
+   Note that this example is simplified.  Because of operational
+   considerations described in [5] having a period during which the two
+   key signing keys are both available is necessary.
+
+
+3.2  Threshold-based Trust Update
+
+
+   The threshold-based trust update algorithm applies as follows.  If
+   for a particular secure entry point
+   o  if the DNSKEY RRset in the zone has been replaced by a more recent
+      one (as determined by comparing the RRSIG inception dates)
+   and
+   o  if at least M configured trust anchors directly verify the related
+      RRSIGs over the new DNSKEY RRset
+   and
+   o  the number of configured trust anchors that verify the related
+      RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
+      number that should be greater than one
+   then all the trust anchors for the particular secure entry point are
+   replaced by the set of keys from the zones DNSKEY RRset that have the
+   SEP flag set.
+
+
+   The choices for the rollover acceptance policy parameter M is left to
+   the administrator of the resolver.  To be certain that a rollover is
+   accepted up by resolvers using this mechanism zone owners should roll
+   as few SEP keys at a time as possible (preferably just one).  That
+   way they comply to the most strict rollover acceptance policy of
+   M=N-1.
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 8]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   The value of M has an upper bound, limited by the number of of SEP
+   keys a zone owner publishes (i.e.  N).  But there is also a lower
+   bound, since it will not be safe to base the trust in too few
+   signatures.  The corner case is M=1 when any validating RRSIG will be
+   sufficient for a complete replacement of the trust anchors for that
+   secure entry point.  This is not a recommended configuration, since
+   that will allow an attacker to initiate rollover of the trust anchors
+   himself given access to just one compromised key.  Hence M should in
+   be strictly larger than 1 as shown by the third requirement above.
+
+
+   If the rollover acceptance policy is M=1 then the result for the
+   rollover in our example above should be that the local database of
+   trust anchors is updated by removing key "key2" from and adding key
+   "keyY+1" to the key store.
+
+
+3.3  Possible Trust Update States
+
+
+   We define five states for trust anchor configuration at the client
+   side.
+   PRIMING: There are no trust anchors configured.  There may be priming
+      keys available for initial priming of trust anchors.
+   IN-SYNC: The set of trust anchors configured exactly matches the set
+      of SEP keys used by the zone owner to sign the zone.
+   OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
+      set of SEP keys used by the zone owner to sign the zone but there
+      are enough SEP key in use by the zone owner that is also in the
+      trust anchor configuration.
+   UNSYNCABLE: There is not enough overlap between the configured trust
+      anchors and the set of SEP keys used to sign the zone for the new
+      set to be accepted by the validator (i.e.  the number of
+      signatures that verify is not sufficient).
+   STALE: There is no overlap between the configured trust anchors and
+      the set of SEP keys used to sign the zone.  Here validation of
+      data is no longer possible and hence we are in a situation where
+      the trust anchors are stale.
+
+
+   Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
+   the automatic trust update mechanism.  The PRIMING state is where a
+   validator is located before acquiring an up-to-date set of trust
+   anchors.  The transition from PRIMING to IN-SYNC is manual (see
+   Section 4 below).
+
+
+   Example: assume a secure entry point with four SEP keys and a
+   validator with the policy that it will accept any update to the set
+   of trust anchors as long as no more than two signatures fail to
+   validate (i.e.  M >= N-2) and at least two signature does validate
+   (i.e.  M >= 2).  In this case the rollover of a single key will move
+   the validator from IN-SYNC to OUT-OF-SYNC.  When the trust update
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                 [Page 9]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   state machine updates the trust anchors it returns to state IN-SYNC.
+
+
+   If if for some reason it fails to update the trust anchors then the
+   next rollover (of a different key) will move the validator from
+   OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
+   that are configured as trust anchors and that is sufficient to accpt
+   an automatic update of the trust anchors.
+
+
+   The UNSYNCABLE state is where a validator is located if it for some
+   reason fails to incorporate enough updates to the trust anchors to be
+   able to accept new updates according to its local policy.  In this
+   example (i.e.  with the policy specified above) this will either be
+   because M < N-2 or M < 2, which does not suffice to authenticate a
+   successful update of trust anchors.
+
+
+   Continuing with the previous example where two of the four SEP keys
+   have already rolled, but the validator has failed to update the set
+   of trust anchors.  When the third key rolls over there will only be
+   one trust anchor left that can do successful validation.  This is not
+   sufficient to enable automatic update of the trust anchors, hence the
+   new state is UNSYNCABLE.  Note, however, that the remaining
+   up-to-date trust anchor is still enough to do successful validation
+   so the validator is still "working" from a DNSSEC point of view.
+
+
+   The STALE state, finally, is where a validator ends up when it has
+   zero remaining current trust anchors.  This is a dangerous state,
+   since the stale trust anchors will cause all validation to fail.  The
+   escape is to remove the stale trust anchors and thereby revert to the
+   PRIMING state.
+
+
+3.4  Implementation notes
+
+
+   The DNSSEC protocol specification ordains that a DNSKEY to which a DS
+   record points should be self-signed.  Since the keys that serve as
+   trust anchors and the keys that are pointed to by DS records serve
+   the same purpose, they are both secure entry points, we RECOMMEND
+   that zone owners who want to facilitate the automated rollover scheme
+   documented herein self-sign DNSKEYs with the SEP bit set and that
+   implementation check that DNSKEYs with the SEP bit set are
+   self-signed.
+
+
+   In order to maintain a uniform way of determining that a keyset in
+   the zone has been replaced by a more recent set the automatic trust
+   update machine SHOULD only accept new DNSKEY RRsets if the
+   accompanying RRSIGs show a more recent inception date than the
+   present set of trust anchors.  This is also needed as a safe guard
+   against possible replay attacks where old updates are replayed
+   "backwards" (i.e.  one change at a time, but going in the wrong
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 10]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   direction, thereby luring the validator into the UNSYNCABLE and
+   finally STALE states).
+
+
+   In order to be resilient against failures the implementation should
+   collect the DNSKEY RRsets from (other) authoritative servers if
+   verification of the self signatures fails.
+
+
+   The threshold-based trust update mechanism SHOULD only be applied to
+   algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
+   [3], that the resolver is aware of.  In other words the SEP keys of
+   unknown algorithms should not be used when counting the number of
+   available signatures (the N constant) and the SEP keys of unknown
+   algorithm should not be entered as trust anchors.
+
+
+   When in state UNSYNCABLE or STALE manual intervention will be needed
+   to return to the IN-SYNC state.  These states should be flagged.  The
+   most appropriate action is human audit possibly followed by
+   re-priming (Section 4) the keyset (i.e.  manual transfer to the
+   PRIMING state through removal of the configured trust anchors).
+
+
+   An implementation should regularly probe the the authoritative
+   nameservers for new keys.  Since there is no mechanism to publish
+   rollover frequencies this document RECOMMENDS zone owners not to roll
+   their key signing keys more often than once per month and resolver
+   administrators to probe for key rollsovers (and apply the threshold
+   criterion for acceptance of trust update) not less often than once
+   per month.  If the rollover frequency is higher than the probing
+   frequency then trust anchors may become stale.  The exact relation
+   between the frequencies depends on the number of SEP keys rolled by
+   the zone owner and the value M configured by the resolver
+   administrator.
+
+
+   In all the cases below a transaction where the threshold criterion is
+   not satisfied should be considered bad (i.e.  possibly spoofed or
+   otherwise corrupted data).  The most appropriate action is human
+   audit.
+
+
+   There is one case where a "bad" state may be escaped from in an
+   automated fashion.  This is when entering the STALE state where all
+   DNSSEC validation starts to fail.  If this happens it is concievable
+   that it is better to completely discard the stale trust anchors
+   (thereby reverting to the PRIMING state where validation is not
+   possible).  A local policy that automates removal of stale trust
+   anchors is therefore suggested.
+
+
+3.5  Possible transactions
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 11]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+3.5.1  Single DNSKEY replaced
+
+
+   This is probably the most typical transaction on the zone owners
+   part.  The result should be that if the threshold criterion is
+   satisfied then the key store is updated by removal of the old trust
+   anchor and addition of the new key as a new trust anchor.  Note that
+   if the DNSKEY RRset contains exactly M keys replacement of keys is
+   not possible, i.e.  for automatic rollover to work M must be stricly
+   less than N.
+
+
+3.5.2  Addition of a new DNSKEY (no removal)
+
+
+   If the threshold criterion is satisfied then the new key is added as
+   a configured trust anchor.  Not more than N-M keys can be added at
+   once, since otherwise the algorithm will fail.
+
+
+3.5.3  Removal of old DNSKEY (no addition)
+
+
+   If the threshold criterion is satisfied then the old key is removed
+   from being a configured trust anchor.  Note that it is not possible
+   to reduce the size of the DNSKEY RRset to a size smaller than the
+   minimum required value for M.
+
+
+3.5.4  Multiple DNSKEYs replaced
+
+
+   Arguably it is not a good idea for the zone administrator to replace
+   several keys at the same time, but from the resolver point of view
+   this is exactly what will happen if the validating resolver for some
+   reason failed to notice a previous rollover event.
+
+
+   Not more than N-M keys can be replaced at one time or the threshold
+   criterion will not be satisfied.  Or, expressed another way: as long
+   as the number of changed keys is less than or equal to N-M the
+   validator is in state OUT-OF-SYNC.  When the number of changed keys
+   becomes greater than N-M the state changes to UNSYNCABLE and manual
+   action is needed.
+
+
+3.6  Removal of trust anchors for a trust point
+
+
+   If the parent of a secure entry point gets signed and it's trusted
+   keys get configured in the key store of the validating resolver then
+   the configured trust anchors for the child should be removed entirely
+   unless explicitly configured (in the utility configuration) to be an
+   exception.
+
+
+   The reason for such a configuration would be that the resolver has a
+   local policy that requires maintenance of trusted keys further down
+   the tree hierarchy than strictly needed from the point of view.
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 12]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   The default action when the parent zone changes from unsigned to
+   signed should be to remove the configured trust anchors for the
+   child.  This form of "garbage collect" will ensure that the automatic
+   rollover machinery scales as DNSSEC deployment progresses.
+
+
+3.7  No need for resolver-side overlap of old and new keys
+
+
+   It is worth pointing out that there is no need for the resolver to
+   keep state about old keys versus new keys, beyond the requirement of
+   tracking signature inception time for the covering RRSIGs as
+   described in Section 3.4.
+
+
+   From the resolver point of view there are only trusted and not
+   trusted keys.  The reason is that the zone owner needs to do proper
+   maintenance of RRSIGs regardless of the resolver rollover mechanism
+   and hence must ensure that no key rolled out out the DNSKEY set until
+   there cannot be any RRSIGs created by this key still legally cached.
+
+
+   Hence the rollover mechanism is entirely stateless with regard to the
+   keys involved: as soon as the resolver (or in this case the rollover
+   tracking utility) detects a change in the DNSKEY RRset (i.e.  it is
+   now in the state OUT-OF-SYNC) with a sufficient number of matching
+   RRSIGs the configured trust anchors are immediately updated (and
+   thereby the machine return to state IN-SYNC).  I.e.  the rollover
+   machine changes states (mostly oscillating between IN-SYNC and
+   OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 13]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+4.  Bootstrapping automatic rollovers
+
+
+   It is expected that with the ability to automatically roll trust
+   anchors at trust points will follow a diminished unwillingness to
+   roll these keys, since the risks associated with stale keys are
+   minimized.
+
+
+   The problem of "priming" the trust anchors, or bringing them into
+   sync (which could happen if a resolver is off line for a long period
+   in which a set of SEP keys in a zone 'evolve' away from its trust
+   anchor configuration) remains.
+
+
+   For (re)priming we can rely on out of band technology and we propose
+   the following framework.
+
+
+4.1  Priming Keys
+
+
+   If all the trust anchors roll somewhat frequently (on the order of
+   months or at most about a year) then it will not be possible to
+   design a device, or a software distribution that includes trust
+   anchors, that after being manufactured is put on a shelf for several
+   key rollover periods before being brought into use (since no trust
+   anchors that were known at the time of manufacture remain active).
+
+
+   To alleviate this we propose the concept of "priming keys".  Priming
+   keys are ordinary DNSSEC Key Signing Keys with the characteristic
+   that
+   o  The private part of a priming key signs the DNSKEY RRset at the
+      security apex, i.e.  at least one RRSIG DNSKEY is created by a
+      priming key rather than by an "ordinary" trust anchor
+   o  the public parts of priming keys are not included in the DNSKEY
+      RRset.  Instead the public parts of priming keys are only
+      available out-of-band.
+   o  The public parts of the priming keys have a validity period.
+      Within this period they can be used to obtain trust anchors.
+   o  The priming key pairs are long lived (relative to the key rollover
+      period.)
+
+
+4.1.1  Bootstrapping trust anchors using a priming key
+
+
+   To install the trust anchors for a particular security apex an
+   administrator of a validating resolver will need to:
+   o  query for the DNSKEY RRset of the zone at the security apex;
+   o  verify the self signatures of all DNSKEYs in the RRset;
+   o  verify the signature of the RRSIG made with a priming key --
+      verification using one of the public priming keys that is valid at
+      that moment is sufficient;
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 14]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   o  create the trust anchors by extracting the DNSKEY RRs with the SEP
+      flag set.
+   The SEP keys with algorithms unknown to the validating resolver
+   SHOULD be ignored during the creation of the trust anchors.
+
+
+4.1.2  Distribution of priming keys
+
+
+   The public parts of the priming keys SHOULD be distributed
+   exclusively through out-of-DNS mechanisms.  The requirements for a
+   distribution mechanism are:
+   o  it can carry the "validity" period for the priming keys;
+   o  it can carry the self-signature of the priming keys;
+   o  and it allows for verification using trust relations outside the
+      DNS.
+   A distribution mechanism would benefit from:
+   o  the availability of revocation lists;
+   o  the ability of carrying zone owners policy information such as
+      recommended values for "M" and "N" and a rollover frequency;
+   o  and the technology on which is based is readily available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 15]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+5.  The Threshold Rollover Mechanism vs Priming
+
+
+   There is overlap between the threshold-based trust updater and the
+   Priming method.  One could exclusively use the Priming method for
+   maintaining the trust anchors.  However the priming method probably
+   relies on "non-DNS' technology and may therefore not be available for
+   all devices that have a resolver.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 16]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+6.  Security Considerations
+
+
+6.1  Threshold-based Trust Update Security Considerations
+
+
+   A clear issue for resolvers will be how to ensure that they track all
+   rollover events for the zones they have configure trust anchors for.
+   Because of temporary outages validating resolvers may have missed a
+   rollover of a KSK.  The parameters that determine the robustness
+   against failures are: the length of the period between rollovers
+   during which the KSK set is stable and validating resolvers can
+   actually notice the change; the number of available KSKs (i.e.  N)
+   and the number of signatures that may fail to validate (i.e.  N-M).
+
+
+   With a large N (i.e.  many KSKs) and a small value of M this
+   operation becomes more robust since losing one key, for whatever
+   reason, will not be crucial.  Unfortunately the choice for the number
+   of KSKs is a local policy issue for the zone owner while the choice
+   for the parameter M is a local policy issue for the resolver
+   administrator.
+
+
+   Higher values of M increase the resilience against attacks somewhat;
+   more signatures need to verify for a rollover to be approved.  On the
+   other hand the number of rollover events that may pass unnoticed
+   before the resolver reaches the UNSYNCABLE state goes down.
+
+
+   The threshold-based trust update intentionally does not provide a
+   revocation mechanism.  In the case that a sufficient number of
+   private keys of a zone owner are simultaneously compromised the the
+   attacker may use these private keys to roll the trust anchors of (a
+   subset of) the resolvers.  This is obviously a bad situation but it
+   is not different from most other public keys systems.
+
+
+   However, it is important to point out that since any reasonable trust
+   anchor rollover policy (in validating resolvers) will require more
+   than one RRSIG to validate this proposal does provide security
+   concious zone administrators with the option of not storing the
+   individual private keys in the same location and thereby decreasing
+   the likelihood of simultaneous compromise.
+
+
+6.2  Priming Key Security Considerations
+
+
+   Since priming keys are not included in the DNSKEY RR set they are
+   less sensitive to packet size constraints and can be chosen
+   relatively large.  The private parts are only needed to sign the
+   DNSKEY RR set during the validity period of the particular priming
+   key pair.  Note that the private part of the priming key is used each
+   time when a DNSKEY RRset has to be resigned.  In practice there is
+   therefore little difference between the usage pattern of the private
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 17]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   part of key signing keys and priming keys.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 18]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+7.  IANA Considerations
+
+
+   NONE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 19]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+8.  References
+
+
+8.1  Normative References
+
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+
+   [3]  Arends, R., "Resource Records for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-records-10 (work in progress),
+        September 2004.
+
+
+8.2  Informative References
+
+
+   [4]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
+        "DNS Security Introduction and Requirements",
+        draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
+        2004.
+
+
+   [5]  Kolkman, O., "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practices-01 (work in
+        progress), May 2004.
+
+
+   [6]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
+        Public Key Infrastructure Certificate and CRL Profile", RFC
+        2459, January 1999.
+
+
+
+Authors' Addresses
+
+
+   Johan Ihren
+   Autonomica AB
+   Bellmansgatan 30
+   Stockholm  SE-118 47
+   Sweden
+
+
+   EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 20]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+   Olaf M. Kolkman
+   RIPE NCC
+   Singel 256
+   Amsterdam  1016 AB
+   NL
+
+
+   Phone: +31 20 535 4444
+   EMail: olaf@ripe.net
+   URI:   http://www.ripe.net/
+
+
+
+   Bill Manning
+   EP.net
+   Marina del Rey, CA  90295
+   USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 21]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+Appendix A.  Acknowledgments
+
+
+   The present design for in-band automatic rollovers of DNSSEC trust
+   anchors is the result of many conversations and it is no longer
+   possible to remember exactly who contributed what.
+
+
+   In addition we've also had appreciated help from (in no particular
+   order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
+   Larson and Mark Kosters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 22]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+Appendix B.  Document History
+
+
+   This appendix will be removed if and when the document is submitted
+   to the RFC editor.
+
+
+   The version you are reading is tagged as $Revision: 1.1.230.1 $.
+
+
+   Text between square brackets, other than references, are editorial
+   comments and will be removed.
+
+
+B.1  prior to version 00
+
+
+   This draft was initially published as a personal submission under the
+   name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
+
+
+   Kolkman documented the ideas provided by Ihren and Manning.  In the
+   process of documenting (and prototyping) Kolkman changed some of the
+   details of the M-N algorithms working.  Ihren did not have a chance
+   to review the draft before Kolkman posted;
+
+
+   Kolkman takes responsibilities for omissions, fuzzy definitions and
+   mistakes.
+
+
+B.2  version 00
+   o  The name of the draft was changed as a result of the draft being
+      adopted as a working group document.
+   o  A small section on the concept of stale trust anchors was added.
+   o  The different possible states are more clearly defined, including
+      examples of transitions between states.
+   o  The terminology is changed throughout the document.  The old term
+      "M-N" is replaced by "threshold" (more or less).  Also the
+      interpretation of the constants M and N is significantly
+      simplified to bring the usage more in line with "standard"
+      threshold terminlogy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 23]
+Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Ihren, et al.            Expires April 18, 2005                [Page 24] 
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
new file mode 100644
index 0000000..7cb9063
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
@@ -0,0 +1,730 @@
+
+
+
+
+Network Working Group                                         M. StJohns
+Internet-Draft                                             Nominum, Inc.
+Expires: July 14, 2006                                  January 10, 2006
+
+
+               Automated Updates of DNSSEC Trust Anchors
+                draft-ietf-dnsext-trustupdate-timers-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 14, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a means for automated, authenticated and
+   authorized updating of DNSSEC "trust anchors".  The method provides
+   protection against single key compromise of a key in the trust point
+   key set.  Based on the trust established by the presence of a current
+   anchor, other anchors may be added at the same place in the
+   hierarchy, and, ultimately, supplant the existing anchor.
+
+   This mechanism, if adopted, will require changes to resolver
+   management behavior (but not resolver resolution behavior), and the
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 1]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   addition of a single flag bit to the DNSKEY record.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
+     1.2.  Changes since -00  . . . . . . . . . . . . . . . . . . . .  3
+   2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Remove Hold-down . . . . . . . . . . . . . . . . . . . . .  5
+     2.4.  Active Refresh . . . . . . . . . . . . . . . . . . . . . .  6
+     2.5.  Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
+       2.5.1.  Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
+       2.5.2.  Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
+       2.5.3.  Minimum Trust Anchors per Trust Point  . . . . . . . .  6
+   3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
+   4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.2.  States . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     4.3.  Trust Point Deletion . . . . . . . . . . . . . . . . . . .  8
+   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     5.1.  Adding A Trust Anchor  . . . . . . . . . . . . . . . . . .  9
+     5.2.  Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
+     5.3.  Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . .  9
+     5.4.  Active Key Compromised . . . . . . . . . . . . . . . . . .  9
+     5.5.  Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+     7.1.  Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
+     7.2.  Multiple Key Compromise  . . . . . . . . . . . . . . . . . 10
+     7.3.  Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
+   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 2]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+1.  Introduction
+
+   As part of the reality of fielding DNSSEC (Domain Name System
+   Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
+   community has come to the realization that there will not be one
+   signed name space, but rather islands of signed name space each
+   originating from specific points (i.e. 'trust points') in the DNS
+   tree.  Each of those islands will be identified by the trust point
+   name, and validated by at least one associated public key.  For the
+   purpose of this document we'll call the association of that name and
+   a particular key a 'trust anchor'.  A particular trust point can have
+   more than one key designated as a trust anchor.
+
+   For a DNSSEC-aware resolver to validate information in a DNSSEC
+   protected branch of the hierarchy, it must have knowledge of a trust
+   anchor applicable to that branch.  It may also have more than one
+   trust anchor for any given trust point.  Under current rules, a chain
+   of trust for DNSSEC-protected data that chains its way back to ANY
+   known trust anchor is considered 'secure'.
+
+   Because of the probable balkanization of the DNSSEC tree due to
+   signing voids at key locations, a resolver may need to know literally
+   thousands of trust anchors to perform its duties. (e.g.  Consider an
+   unsigned ".COM".)  Requiring the owner of the resolver to manually
+   manage this many relationships is problematic.  It's even more
+   problematic when considering the eventual requirement for key
+   replacement/update for a given trust anchor.  The mechanism described
+   herein won't help with the initial configuration of the trust anchors
+   in the resolvers, but should make trust point key replacement/
+   rollover more viable.
+
+   As mentioned above, this document describes a mechanism whereby a
+   resolver can update the trust anchors for a given trust point, mainly
+   without human intervention at the resolver.  There are some corner
+   cases discussed (e.g. multiple key compromise) that may require
+   manual intervention, but they should be few and far between.  This
+   document DOES NOT discuss the general problem of the initial
+   configuration of trust anchors for the resolver.
+
+1.1.  Compliance Nomenclature
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, [RFC2119].
+
+1.2.  Changes since -00
+
+   Added the concept of timer triggered resolver queries to refresh the
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 3]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   resolvers view of the trust anchor key RRSet.
+
+   Re-submitted expired draft as -01.  Updated DNSSEC RFC References.
+
+   Draft -02.  Added the IANA Considerations section.  Added text to
+   describe what happens if all trust anchors at a trust point are
+   deleted.
+
+
+2.  Theory of Operation
+
+   The general concept of this mechanism is that existing trust anchors
+   can be used to authenticate new trust anchors at the same point in
+   the DNS hierarchy.  When a new SEP key is added to a trust point
+   DNSKEY RRSet, and when that RRSet is validated by an existing trust
+   anchor, then the new key can be added to the set of trust anchors.
+
+   There are some issues with this approach which need to be mitigated.
+   For example, a compromise of one of the existing keys could allow an
+   attacker to add their own 'valid' data.  This implies a need for a
+   method to revoke an existing key regardless of whether or not that
+   key is compromised.  As another example assuming a single key
+   compromise, an attacker could add a new key and revoke all the other
+   old keys.
+
+2.1.  Revocation
+
+   Assume two trust anchor keys A and B. Assume that B has been
+   compromised.  Without a specific revocation bit, B could invalidate A
+   simply by sending out a signed trust point key set which didn't
+   contain A. To fix this, we add a mechanism which requires knowledge
+   of the private key of a DNSKEY to revoke that DNSKEY.
+
+   A key is considered revoked when the resolver sees the key in a self-
+   signed RRSet and the key has the REVOKE bit (see Section 6 below) set
+   to '1'.  Once the resolver sees the REVOKE bit, it MUST NOT use this
+   key as a trust anchor or for any other purposes except validating the
+   RRSIG over the DNSKEY RRSet specifically for the purpose of
+   validating the revocation.  Unlike the 'Add' operation below,
+   revocation is immediate and permanent upon receipt of a valid
+   revocation at the resolver.
+
+   N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
+   than one without the bit set.  This affects the matching of a DNSKEY
+   to DS records in the parent, or the fingerprint stored at a resolver
+   used to configure a trust point. [msj3]
+
+   In the given example, the attacker could revoke B because it has
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 4]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   knowledge of B's private key, but could not revoke A.
+
+2.2.  Add Hold-Down
+
+   Assume two trust point keys A and B. Assume that B has been
+   compromised.  An attacker could generate and add a new trust anchor
+   key - C (by adding C to the DNSKEY RRSet and signing it with B), and
+   then invalidate the compromised key.  This would result in the both
+   the attacker and owner being able to sign data in the zone and have
+   it accepted as valid by resolvers.
+
+   To mitigate, but not completely solve, this problem, we add a hold-
+   down time to the addition of the trust anchor.  When the resolver
+   sees a new SEP key in a validated trust point DNSKEY RRSet, the
+   resolver starts an acceptance timer, and remembers all the keys that
+   validated the RRSet.  If the resolver ever sees the DNSKEY RRSet
+   without the new key but validly signed, it stops the acceptance
+   process and resets the acceptance timer.  If all of the keys which
+   were originally used to validate this key are revoked prior to the
+   timer expiring, the resolver stops the acceptance process and resets
+   the timer.
+
+   Once the timer expires, the new key will be added as a trust anchor
+   the next time the validated RRSet with the new key is seen at the
+   resolver.  The resolver MUST NOT treat the new key as a trust anchor
+   until the hold down time expires AND it has retrieved and validated a
+   DNSKEY RRSet after the hold down time which contains the new key.
+
+   N.B.: Once the resolver has accepted a key as a trust anchor, the key
+   MUST be considered a valid trust anchor by that resolver until
+   explictly revoked as described above.
+
+   In the given example, the zone owner can recover from a compromise by
+   revoking B and adding a new key D and signing the DNSKEY RRSet with
+   both A and B.
+
+   The reason this does not completely solve the problem has to do with
+   the distributed nature of DNS.  The resolver only knows what it sees.
+   A determined attacker who holds one compromised key could keep a
+   single resolver from realizing that key had been compromised by
+   intercepting 'real' data from the originating zone and substituting
+   their own (e.g. using the example, signed only by B).  This is no
+   worse than the current situation assuming a compromised key.
+
+2.3.  Remove Hold-down
+
+   A new key which has been seen by the resolver, but hasn't reached
+   it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 5]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   zone owner.  If the resolver sees a validated DNSKEY RRSet without
+   this key, it waits for the remove hold-down time and then, if the key
+   hasn't reappeared, SHOULD discard any information about the key.
+
+2.4.  Active Refresh
+
+   A resolver which has been configured for automatic update of keys
+   from a particular trust point MUST query that trust point (e.g. do a
+   lookup for the DNSKEY RRSet and related RRSIG records) no less often
+   than the lesser of 15 days or half the original TTL for the DNSKEY
+   RRSet or half the RRSIG expiration interval.  The expiration interval
+   is the amount of time from when the RRSIG was last retrieved until
+   the expiration time in the RRSIG.
+
+   If the query fails, the resolver MUST repeat the query until
+   satisfied no more often than once an hour and no less often than the
+   lesser of 1 day or 10% of the original TTL or 10% of the original
+   expiration interval.
+
+2.5.  Resolver Parameters
+
+2.5.1.  Add Hold-Down Time
+
+   The add hold-down time is 30 days or the expiration time of the TTL
+   of the first trust point DNSKEY RRSet which contained the key,
+   whichever is greater.  This ensures that at least two validated
+   DNSKEY RRSets which contain the new key MUST be seen by the resolver
+   prior to the key's acceptance.
+
+2.5.2.  Remove Hold-Down Time
+
+   The remove hold-down time is 30 days.
+
+2.5.3.  Minimum Trust Anchors per Trust Point
+
+   A compliant resolver MUST be able to manage at least five SEP keys
+   per trust point.
+
+
+3.  Changes to DNSKEY RDATA Wire Format
+
+   Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
+   flag.  If this bit is set to '1', AND the resolver sees an
+   RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
+   consider this key permanently invalid for all purposes except for
+   validing the revocation.
+
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 6]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+4.  State Table
+
+   The most important thing to understand is the resolver's view of any
+   key at a trust point.  The following state table describes that view
+   at various points in the key's lifetime.  The table is a normative
+   part of this specification.  The initial state of the key is 'Start'.
+   The resolver's view of the state of the key changes as various events
+   occur.
+
+   [msj1] This is the state of a trust point key as seen from the
+   resolver.  The column on the left indicates the current state.  The
+   header at the top shows the next state.  The intersection of the two
+   shows the event that will cause the state to transition from the
+   current state to the next.
+
+                             NEXT STATE
+           --------------------------------------------------
+    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
+   ----------------------------------------------------------
+   Start   |       |NewKey  |       |       |       |       |
+   ----------------------------------------------------------
+   AddPend |KeyRem |        |AddTime|       |       |
+   ----------------------------------------------------------
+   Valid   |       |        |       |KeyRem |Revbit |       |
+   ----------------------------------------------------------
+   Missing |       |        |KeyPres|       |Revbit |       |
+   ----------------------------------------------------------
+   Revoked |       |        |       |       |       |RemTime|
+   ----------------------------------------------------------
+   Removed |       |        |       |       |       |       |
+   ----------------------------------------------------------
+
+4.1.  Events
+   NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
+      That key will become a new trust anchor for the named trust point
+      after its been present in the RRSet for at least 'add time'.
+   KeyPres The key has returned to the valid DNSKEY RRSet.
+   KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
+      this key.
+   AddTime The key has been in every valid DNSKEY RRSet seen for at
+      least the 'add time'.
+   RemTime A revoked key has been missing from the trust point DNSKEY
+      RRSet for sufficient time to be removed from the trust set.
+   RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
+      "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
+      signed by this key.
+
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 7]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+4.2.  States
+   Start The key doesn't yet exist as a trust anchor at the resolver.
+      It may or may not exist at the zone server, but hasn't yet been
+      seen at the resolver.
+   AddPend The key has been seen at the resolver, has its 'SEP' bit set,
+      and has been included in a validated DNSKEY RRSet.  There is a
+      hold-down time for the key before it can be used as a trust
+      anchor.
+   Valid The key has been seen at the resolver and has been included in
+      all validated DNSKEY RRSets from the time it was first seen up
+      through the hold-down time.  It is now valid for verifying RRSets
+      that arrive after the hold down time.  Clarification: The DNSKEY
+      RRSet does not need to be continuously present at the resolver
+      (e.g. its TTL might expire).  If the RRSet is seen, and is
+      validated (i.e. verifies against an existing trust anchor), this
+      key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
+   Missing This is an abnormal state.  The key remains as a valid trust
+      point key, but was not seen at the resolver in the last validated
+      DNSKEY RRSet.  This is an abnormal state because the zone operator
+      should be using the REVOKE bit prior to removal.  [Discussion
+      item: Should a missing key be considered revoked after some period
+      of time?]
+   Revoked This is the state a key moves to once the resolver sees an
+      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
+      this key with its REVOKE bit set to '1'.  Once in this state, this
+      key MUST permanently be considered invalid as a trust anchor.
+   Removed After a fairly long hold-down time, information about this
+      key may be purged from the resolver.  A key in the removed state
+      MUST NOT be considered a valid trust anchor.
+
+4.3.  Trust Point Deletion
+
+   A trust point which has all of its trust anchors revoked is
+   considered deleted and is treated as if the trust point was never
+   configured.  If there are no superior trust points, data at and below
+   the deleted trust point are considered insecure.  If there there ARE
+   superior trust points, data at and below the deleted trust point are
+   evaluated with respect to the superior trust point.
+
+
+5.  Scenarios
+
+   The suggested model for operation is to have one active key and one
+   stand-by key at each trust point.  The active key will be used to
+   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
+   RRSet, but the resolver will accept it as a trust anchor if/when it
+   sees the signature on the trust point DNSKEY RRSet.
+
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 8]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+   Since the stand-by key is not in active signing use, the associated
+   private key may (and SHOULD) be provided with additional protections
+   not normally available to a key that must be used frequently.  E.g.
+   locked in a safe, split among many parties, etc.  Notionally, the
+   stand-by key should be less subject to compromise than an active key,
+   but that will be dependent on operational concerns not addressed
+   here.
+
+5.1.  Adding A Trust Anchor
+
+   Assume an existing trust anchor key 'A'.
+   1.  Generate a new key pair.
+   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
+       Key bits.
+   3.  Add the DNSKEY to the RRSet.
+   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
+       'A'.
+   5.  Wait a while.
+
+5.2.  Deleting a Trust Anchor
+
+   Assume existing trust anchors 'A' and 'B' and that you want to revoke
+   and delete 'A'.
+   1.  Set the revolcation bit on key 'A'.
+   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
+   'A' is now revoked.  The operator SHOULD include the revoked 'A' in
+   the RRSet for at least the remove hold-down time, but then may remove
+   it from the DNSKEY RRSet.
+
+5.3.  Key Roll-Over
+
+   Assume existing keys A and B. 'A' is actively in use (i.e. has been
+   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
+   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
+   used to sign the RRSet.)
+   1.  Generate a new key pair 'C'.
+   2.  Add 'C' to the DNSKEY RRSet.
+   3.  Set the revocation bit on key 'A'.
+   4.  Sign the RRSet with 'A' and 'B'.
+   'A' is now revoked, 'B' is now the active key, and 'C' will be the
+   stand-by key once the hold-down expires.  The operator SHOULD include
+   the revoked 'A' in the RRSet for at least the remove hold-down time,
+   but may then remove it from the DNSKEY RRSet.
+
+5.4.  Active Key Compromised
+
+   This is the same as the mechanism for Key Roll-Over (Section 5.3)
+   above assuming 'A' is the active key.
+
+
+
+StJohns                   Expires July 14, 2006                 [Page 9]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+5.5.  Stand-by Key Compromised
+
+   Using the same assumptions and naming conventions as Key Roll-Over
+   (Section 5.3) above:
+   1.  Generate a new key pair 'C'.
+   2.  Add 'C' to the DNSKEY RRSet.
+   3.  Set the revocation bit on key 'B'.
+   4.  Sign the RRSet with 'A' and 'B'.
+   'B' is now revoked, 'A' remains the active key, and 'C' will be the
+   stand-by key once the hold-down expires.  'B' SHOULD continue to be
+   included in the RRSet for the remove hold-down time.
+
+
+6.  IANA Considerations
+
+   The IANA will need to assign a bit in the DNSKEY flags field (see
+   section 4.3 of [RFC3755]) for the REVOKE bit.  There are no other
+   IANA actions required.
+
+
+7.  Security Considerations
+
+7.1.  Key Ownership vs Acceptance Policy
+
+   The reader should note that, while the zone owner is responsible
+   creating and distributing keys, it's wholly the decision of the
+   resolver owner as to whether to accept such keys for the
+   authentication of the zone information.  This implies the decision
+   update trust anchor keys based on trust for a current trust anchor
+   key is also the resolver owner's decision.
+
+   The resolver owner (and resolver implementers) MAY choose to permit
+   or prevent key status updates based on this mechanism for specific
+   trust points.  If they choose to prevent the automated updates, they
+   will need to establish a mechanism for manual or other out-of-band
+   updates outside the scope of this document.
+
+7.2.  Multiple Key Compromise
+
+   This scheme permits recovery as long as at least one valid trust
+   anchor key remains uncompromised.  E.g. if there are three keys, you
+   can recover if two of them are compromised.  The zone owner should
+   determine their own level of comfort with respect to the number of
+   active valid trust anchors in a zone and should be prepared to
+   implement recovery procedures once they detect a compromise.  A
+   manual or other out-of-band update of all resolvers will be required
+   if all trust anchor keys at a trust point are compromised.
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 10]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+7.3.  Dynamic Updates
+
+   Allowing a resolver to update its trust anchor set based in-band key
+   information is potentially less secure than a manual process.
+   However, given the nature of the DNS, the number of resolvers that
+   would require update if a trust anchor key were compromised, and the
+   lack of a standard management framework for DNS, this approach is no
+   worse than the existing situation.
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+Editorial Comments
+
+   [msj1]  msj: N.B. This table is preliminary and will be revised to
+           match implementation experience.  For example, should there
+           be a state for "Add hold-down expired, but haven't seen the
+           new RRSet"?
+
+   [msj2]  msj: To be assigned.
+
+   [msj3]  msj: For discussion: What's the implementation guidance for
+           resolvers currently with respect to the non-assigned flag
+           bits?  If they consider the flag bit when doing key matching
+           at the trust anchor, they won't be able to match.
+
+
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 11]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+Author's Address
+
+   Michael StJohns
+   Nominum, Inc.
+   2385 Bay Road
+   Redwood City, CA  94063
+   USA
+
+   Phone: +1-301-528-4729
+   Email: Mike.StJohns@nominum.com
+   URI:   www.nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 12]
+
+Internet-Draft             trustanchor-update               January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+StJohns                   Expires July 14, 2006                [Page 13]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
new file mode 100644
index 0000000..00476ae
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
@@ -0,0 +1,522 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+UPDATES RFC 2845                                   Motorola Laboratories
+Expires: July 2006                                          January 2006
+
+                  HMAC SHA TSIG Algorithm Identifiers
+                  ---- --- ---- --------- -----------
+                  <draft-ietf-dnsext-tsig-sha-06.txt>
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   This draft is intended to be become a Proposed Standard RFC.
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   Use of the Domain Name System TSIG resource record requires
+   specification of a cryptographic message authentication code.
+   Currently identifiers have been specified only for the HMAC MD5
+   (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
+   This document standardizes identifiers and implementation
+   requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
+   algorithms and standardizes how to specify and handle the truncation
+   of HMAC values in TSIG.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+
+      2. Algorithms and Identifiers..............................4
+
+      3. Specifying Truncation...................................5
+      3.1 Truncation Specification...............................5
+
+      4. TSIG Truncation Policy and Error Provisions.............6
+
+      5. IANA Considerations.....................................7
+      6. Security Considerations.................................7
+      7. Copyright and Disclaimer................................7
+
+      8. Normative References....................................8
+      9. Informative References..................................8
+
+      Author's Address...........................................9
+      Additional IPR Provisions..................................9
+      Expiration and File Name...................................9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+1. Introduction
+
+   [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
+   authenticate DNS (Domain Name System [STD 13]) queries and responses.
+   This RR contains a domain name syntax data item which names the
+   authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
+   ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
+   algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
+   registered "gss-tsig" as an identifier for TSIG authentication where
+   the cryptographic operations are delegated to the Generic Security
+   Service (GSS) [RFC 3645].
+
+   It should be noted that use of TSIG presumes prior agreement, between
+   the resolver and server involved, as to the algorithm and key to be
+   used.
+
+   In Section 2, this document specifies additional names for TSIG
+   authentication algorithms based on US NIST SHA (United States,
+   National Institute of Science and Technology, Secure Hash Algorithm)
+   algorithms and HMAC and specifies the implementation requirements for
+   those algorithms.
+
+   In Section 3, this document specifies the effect of inequality
+   between the normal output size of the specified hash function and the
+   length of MAC (message authentication code) data given in the TSIG
+   RR. In particular, it specifies that a shorter length field value
+   specifies truncation and a longer length field is an error.
+
+   In Section 4, policy restrictions and implications related to
+   truncation and a new error code to indicate truncation shorter than
+   permitted by policy are described and specified.
+
+   The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
+   defined in [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+2. Algorithms and Identifiers
+
+   TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
+   queries and responses.  They are intended to be efficient symmetric
+   authentication codes based on a shared secret. (Asymmetric signatures
+   can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
+   can be used for transaction signatures.) Used with a strong hash
+   function, HMAC [RFC 2104] provides a way to calculate such symmetric
+   authentication codes. The only specified HMAC based TSIG algorithm
+   identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
+
+   The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
+   compared with the 128 bits for MD5, and additional hash algorithms in
+   the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
+   and 512 bits, may be preferred in some cases particularly since
+   increasingly successful cryptanalytic attacks are being made on the
+   shorter hashes.
+
+   Use of TSIG between a DNS resolver and server is by mutual agreement.
+   That agreement can include the support of additional algorithms and
+   criteria as to which algorithms and truncations are acceptable,
+   subject to the restriction and guidelines in Section 3 and 4 below.
+   Key agreement can be by the TKEY mechanism [RFC 2930] or other
+   mutually agreeable method.
+
+   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
+   included in the table below for convenience.  Implementations which
+   support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
+   implement gss-tsig and the other algorithms listed below.
+
+         Mandatory      HMAC-MD5.SIG-ALG.REG.INT
+         Optional       gss-tsig
+         Mandatory      hmac-sha1
+         Optional       hmac-sha224
+         Mandatory      hmac-sha256
+         Optional       hamc-sha384
+         Optional       hmac-sha512
+
+   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+3. Specifying Truncation
+
+   When space is at a premium and the strength of the full length of an
+   HMAC is not needed, it is reasonable to truncate the HMAC output and
+   use the truncated value for authentication. HMAC SHA-1 truncated to
+   96 bits is an option available in several IETF protocols including
+   IPSEC and TLS.
+
+   The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
+   size of the MAC field in octets. But [RFC 2845] does not specify what
+   to do if this MAC size differs from the length of the output of HMAC
+   for a particular hash function. Truncation is indicated by a MAC size
+   less than the HMAC size as specified below.
+
+
+
+3.1 Truncation Specification
+
+   The specification for TSIG handling is changed as follows:
+
+   1. If "MAC size" field is greater than HMAC output length:
+         This case MUST NOT be generated and if received MUST cause the
+      packet to be dropped and RCODE 1 (FORMERR) to be returned.
+
+   2. If "MAC size" field equals HMAC output length:
+         Operation is as described in [RFC 2845] with the entire output
+      HMAC output present.
+
+   3. "MAC size" field is less than HMAC output length but greater than
+      that specified in case 4 below:
+         This is sent when the signer has truncated the HMAC output to
+      an allowable length, as described in RFC 2104, taking initial
+      octets and discarding trailing octets. TSIG truncation can only be
+      to an integral number of octets. On receipt of a packet with
+      truncation thus indicated, the locally calculated MAC is similarly
+      truncated and only the truncated values compared for
+      authentication. The request MAC used when calculating the TSIG MAC
+      for a reply is the truncated request MAC.
+
+   4. "MAC size" field is less than the larger of 10 (octets) and half
+      the length of the hash function in use:
+         With the exception of certain TSIG error messages described in
+      RFC 2845 section 3.2 where it is permitted that the MAC size be
+      zero, this case MUST NOT be generated and if received MUST cause
+      the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
+      size limit for this case can also, for the hash functions
+      mentioned in this document, be stated as less than half the hash
+      function length for hash functions other than MD5 and less than 10
+      octets for MD5.
+
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+4. TSIG Truncation Policy and Error Provisions
+
+   Use of TSIG is by mutual agreement between a resolver and server.
+   Implicit in such "agreement" are criterion as to acceptable keys and
+   algorithms and, with the extensions in this document, truncations.
+   Note that it is common for implementations to bind the TSIG secret
+   key or keys that may be in place at a resolver and server to
+   particular algorithms. Thus such implementations only permit the use
+   of an algorithm if there is an associated key in place. Receipt of an
+   unknown, unimplemented, or disabled algorithm typically results in a
+   BADKEY error.
+
+      Local policies MAY require the rejection of TSIGs even though they
+   use an algorithm for which implementation is mandatory.
+
+      When a local policy permits acceptance of a TSIG with a particular
+   algorithm and a particular non-zero amount of truncation it SHOULD
+   also permit the use of that algorithm with lesser truncation (a
+   longer MAC) up to the full HMAC output.
+
+      Regardless of a lower acceptable truncated MAC length specified by
+   local policy, a reply SHOULD be sent with a MAC at least as long as
+   that in the corresponding request unless the request specified a MAC
+   length longer than the HMAC output.
+
+      Implementations permitting multiple acceptable algorithms and/or
+   truncations SHOULD permit this list to be ordered by presumed
+   strength and SHOULD allow different truncations for the same
+   algorithm to be treated as separate entities in this list. When so
+   implemented, policies SHOULD accept a presumed stronger algorithm and
+   truncation than the minimum strength required by the policy.
+
+      If a TSIG is received with truncation which is permitted under
+   Section 3 above but the MAC is too short for the local policy in
+   force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+5. IANA Considerations
+
+   This document, on approval for publication as a standards track RFC,
+   (1) registers the new TSIG algorithm identifiers listed in Section 2
+   with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
+   Section 4. [RFC 2845]
+
+
+
+6. Security Considerations
+
+   For all of the message authentication code algorithms listed herein,
+   those producing longer values are believed to be stronger; however,
+   while there have been some arguments that mild truncation can
+   strengthen a MAC by reducing the information available to an
+   attacker, excessive truncation clearly weakens authentication by
+   reducing the number of bits an attacker has to try to break the
+   authentication by brute force [RFC 2104].
+
+   Significant progress has been made recently in cryptanalysis of hash
+   function of the type used herein, all of which ultimately derive from
+   the design of MD4. While the results so far should not effect HMAC,
+   the stronger SHA-1 and SHA-256 algorithms are being made mandatory
+   due to caution.
+
+   See the Security Considerations section of [RFC 2845].  See also the
+   Security Considerations section of [RFC 2104] from which the limits
+   on truncation in this RFC were taken.
+
+
+
+7. Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+8. Normative References
+
+   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
+   Federal Information Processing Standard, with Change Notice 1,
+   February 2004.
+
+   [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
+   1321, April 1992.
+
+   [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+   Hashing for Message Authentication", RFC 2104, February 1997.
+
+   [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+   RFC 2845, May 2000.
+
+   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+   1 (SHA1)", RFC 3174, September 2001.
+
+   [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
+   September 2004,
+
+   [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
+   (SHA)", draft-eastlake-sha2-*.txt, work in progress.
+
+   [STD 13]
+         Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+         Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+
+
+9. Informative References.
+
+   [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
+   (TKEY RR)", RFC 2930, September 2000.
+
+   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
+   Signatures ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
+   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
+   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
+   2003.
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554 (w)
+
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Additional IPR Provisions
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+
+
+Expiration and File Name
+
+   This draft expires in July 2006.
+
+   Its file name is draft-ietf-dnsext-tsig-sha-06.txt
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
new file mode 100644
index 0000000..9cf88a5
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
@@ -0,0 +1,1063 @@
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+DNSEXT Working Group                                          E. Lewis
+INTERNET DRAFT                                                 NeuStar
+Expiration Date: July 9, 2006                          January 9, 2006
+Updates RFC 1034, RFC 2672
+
+                              The Role of Wildcards
+                            in the Domain Name System
+                      draft-ietf-dnsext-wcard-clarify-10.txt
+
+Status of this Memo
+
+      By submitting this Internet-Draft, each author represents that
+      any applicable patent or other IPR claims of which he or she is
+      aware have been or will be disclosed, and any of which he or she
+      becomes aware will be disclosed, in accordance with Section 6 of
+      BCP 79.
+
+      Internet-Drafts are working documents of the Internet Engineering
+      Task Force (IETF), its areas, and its working groups.  Note that
+      other groups may also distribute working documents as Internet-
+      Drafts.
+
+      Internet-Drafts are draft documents valid for a maximum of six
+      months and may be updated, replaced, or obsoleted by other
+      documents at any time.  It is inappropriate to use Internet-Drafts
+      as reference material or to cite them other than as "work in
+      progress."
+
+      The list of current Internet-Drafts can be accessed at
+        http://www.ietf.org/ietf/1id-abstracts.txt
+
+      The list of Internet-Draft Shadow Directories can be accessed at
+        http://www.ietf.org/shadow.html
+
+      This Internet-Draft will expire on July 9, 2006.
+
+Copyright Notice
+
+      Copyright (C) The Internet Society (2006).
+
+Abstract
+
+      This is an update to the wildcard definition of RFC 1034.  The
+      interaction with wildcards and CNAME is changed, an error
+      condition removed, and the words defining some concepts central
+      to wildcards are changed.  The overall goal is not to change
+      wildcards, but to refine the definition of RFC 1034.
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  1]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+Table of Contents
+
+1.    Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  3
+1 1   Motivation                                                     3
+1 2   The Original Definition                                        3
+1 3   Roadmap to This Document                                       4
+1 3 1 New Terms                                                      4
+1.3.2 Changed Text                                                   5
+1.3.3 Considerations with Special Types                              5
+1.4   Standards Terminology                                          5
+2.    Wildcard Syntax   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  6
+2.1   Identifying a Wildcard                                         6
+2.1.1 Wild Card Domain Name and Asterisk Label                       6
+2.1.2 Asterisks and Other Characters                                 6
+2.1.3 Non-terminal Wild Card Domain Names                            6
+2.2   Existence Rules                                                7
+2.2.1 An Example                                                     7
+2.2.2 Empty Non-terminals                                            9
+2.2.3 Yet Another Definition of Existence                           10
+2.3   When is a Wild Card Domain Name Not Special                   10
+3.    Impact of a Wild Card Domain Name On a Response .  .  .  .  . 10
+3.1   Step 2                                                        10
+3.2   Step 3                                                        11
+3.3   Part 'c'                                                      11
+3.3.1 Closest Encloser and the Source of Synthesis                  12
+3.3.2 Closest Encloser and Source of Synthesis Examples             12
+3.3.3 Type Matching                                                 13
+4.    Considerations with Special Types   .  .  .  .  .  .  .  .  . 13
+4.1   SOA RRSet at a Wild Card Domain Name                          13
+4.2   NS RRSet at a Wild Card Domain Name                           14
+4.2.1 Discarded Notions                                             14
+4.3   CNAME RRSet at a Wild Card Domain Name                        15
+4.4   DNAME RRSet at a Wild Card Domain Name                        15
+4.5   SRV RRSet at a Wild Card Domain Name                          16
+4.6   DS RRSet at a Wild Card Domain Name                           16
+4.7   NSEC RRSet at a Wild Card Domain Name                         17
+4.8   RRSIG at a Wild Card Domain Name                              17
+4.9   Empty Non-terminal Wild Card Domain Name                      17
+5.    Security Considerations .  .  .  .  .  .  .  .  .  .  .  .  . 17
+6.    IANA Considerations     .  .  .  .  .  .  .  .  .  .  .  .  . 17
+7.    References              .  .  .  .  .  .  .  .  .  .  .  .  . 17
+8.    Editor                  .  .  .  .  .  .  .  .  .  .  .  .  . 18
+9.    Others Contributing to the Document    .  .  .  .  .  .  .  . 18
+10.   Trailing Boilerplate    .  .  .  .  .  .  .  .  .  .  .  .  . 19
+
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  2]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+1. Introduction
+
+      In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
+      synthesis of answers from special resource records called
+      wildcards.  The definition in RFC 1034 is incomplete and has
+      proven to be confusing.  This document describes the wildcard
+      synthesis by adding to the discussion and making limited
+      modifications.  Modifications are made to close inconsistencies
+      that have led to interoperability issues.  This description
+      does not expand the service intended by the original definition.
+
+      Staying within the spirit and style of the original documents,
+      this document avoids specifying rules for DNS implementations
+      regarding wildcards.  The intention is to only describe what is
+      needed for interoperability, not restrict implementation choices.
+      In addition, consideration is given to minimize any backwards
+      compatibility issues with implementations that comply with RFC
+      1034's definition.
+
+      This document is focused on the concept of wildcards as defined
+      in RFC 1034.  Nothing is implied regarding alternative means of
+      synthesizing resource record sets, nor are alternatives discussed.
+
+1.1 Motivation
+
+      Many DNS implementations diverge, in different ways, from the
+      original definition of wildcards.  Although there is clearly a
+      need to clarify the original documents in light of this alone,
+      the impetus for this document lay in the engineering of the DNS
+      security extensions [RFC4033].  With an unclear definition of
+      wildcards the design of authenticated denial became entangled.
+
+      This document is intended to limit its changes, documenting only
+      those based on implementation experience, and to remain as close
+      to the original document as possible.  To reinforce that this
+      document is meant to clarify and adjust and not redefine wildcards,
+      relevant sections of RFC 1034 are repeated verbatim to facilitate
+      comparison of the old and new text.
+
+1.2 The Original Definition
+
+      The definition of the wildcard concept is comprised by the
+      documentation of the algorithm by which a name server prepares
+      a response (in RFC 1034's section 4.3.2) and the way in which
+      a resource record (set) is identified as being a source of
+      synthetic data (section 4.3.3).
+
+      This is the definition of the term "wildcard" as it appears in
+      RFC 1034, section 4.3.3.
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  3]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+# In the previous algorithm, special treatment was given to RRs with
+# owner names starting with the label "*".  Such RRs are called
+# wildcards. Wildcard RRs can be thought of as instructions for
+# synthesizing RRs.  When the appropriate conditions are met, the name
+# server creates RRs with an owner name equal to the query name and
+# contents taken from the wildcard RRs.
+
+      This passage follows the algorithm in which the term wildcard
+      is first used.   In this definition, wildcard refers to resource
+      records.  In other usage, wildcard has referred to domain names,
+      and it has been used to describe the operational practice of
+      relying on wildcards to generate answers.  It is clear from this
+      that there is a need to define clear and unambiguous terminology
+      in the process of discussing wildcards.
+
+      The mention of the use of wildcards in the preparation of a
+      response is contained in step 3c of RFC 1034's section 4.3.2
+      entitled "Algorithm."  Note that "wildcard" does not appear in
+      the algorithm, instead references are made to the "*" label.
+      The portion of the algorithm relating to wildcards is
+      deconstructed in detail in section 3 of this document, this is
+      the beginning of the relevant portion of the "Algorithm."
+
+#    c. If at some label, a match is impossible (i.e., the
+#       corresponding label does not exist), look to see if [...]
+#       the "*" label exists.
+
+      The scope of this document is the RFC 1034 definition of
+      wildcards and the implications of updates to those documents,
+      such as DNSSEC.  Alternate schemes for synthesizing answers are
+      not considered.  (Note that there is no reference listed.  No
+      document is known to describe any alternate schemes, although
+      there has been some mention of them in mailing lists.)
+
+1.3 Roadmap to This Document
+
+      This document accomplishes these three items.
+      o Defines new terms
+      o Makes minor changes to avoid conflicting concepts
+      o Describes the actions of certain resource records as wildcards
+
+1.3.1 New Terms
+
+      To help in discussing what resource records are wildcards, two
+      terms will be defined - "asterisk label" and "wild card domain
+      name".  These are defined in section 2.1.1.
+
+      To assist in clarifying the role of wildcards in the name server
+      algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
+      encloser" are defined.  These definitions are in section 3.3.2.
+      "Label match" is defined in section 3.2.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  4]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      The new terms are used to make discussions of wildcards clearer.
+      Terminology doesn't directly have an impact on implementations.
+
+1.3.2 Changed Text
+
+      The definition of "existence" is changed superficially.  This
+      change will not be apparent to implementations; it is needed to
+      make descriptions more precise.  The change appears in section
+      2.2.3.
+
+      RFC 1034, section 4.3.3., seems to prohibit having two asterisk
+      labels in a wildcard owner name.  With this document the
+      restriction is removed entirely.  This change and its implications
+      are in section 2.1.3.
+
+      The actions when a source of synthesis owns a CNAME RR are
+      changed to mirror the actions if an exact match name owns a
+      CNAME RR.  This is an addition to the words in RFC 1034,
+      section 4.3.2, step 3, part c.  The discussion of this is in
+      section 3.3.3.
+
+      Only the latter change represents an impact to implementations.
+      The definition of existence is not a protocol impact.  The change
+      to the restriction on names is unlikely to have an impact, as
+      RFC 1034 contained no specification on when and how to enforce the
+      restriction.
+
+1.3.3 Considerations with Special Types
+
+      This document describes semantics of wildcard RRSets for
+      "interesting" types as well as empty non-terminal wildcards.
+      Understanding these situations in the context of wildcards has
+      been clouded because these types incur special processing if
+      they are the result of an exact match.  This discussion is in
+      section 4.
+
+      These discussions do not have an implementation impact, they cover
+      existing knowledge of the types, but to a greater level of detail.
+
+1.4 Standards Terminology
+
+      This document does not use terms as defined in "Key words for use
+      in RFCs to Indicate Requirement Levels." [RFC2119]
+
+      Quotations of RFC 1034 are denoted by a '#' in the leftmost
+      column.  References to section "4.3.2" are assumed to refer
+      to RFC 1034's section 4.3.2, simply titled "Algorithm."
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  5]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+2. Wildcard Syntax
+
+      The syntax of a wildcard is the same as any other DNS resource
+      record, across all classes and types.  The only significant
+      feature is the owner name.
+
+      Because wildcards are encoded as resource records with special
+      names, they are included in zone transfers and incremental zone
+      transfers[RFC1995] just as non-wildcard resource records are.
+      This feature has been under appreciated until discussions on
+      alternative approaches to wildcards appeared on mailing lists.
+
+2.1 Identifying a Wildcard
+
+      To provide a more accurate description of wildcards, the
+      definition has to start with a discussion of the domain names
+      that appear as owners.  Two new terms are needed, "Asterisk
+      Label" and "Wild Card Domain Name."
+
+2.1.1 Wild Card Domain Name and Asterisk Label
+
+      A "wild card domain name" is defined by having its initial
+      (i.e., left-most or least significant) label be, in binary format:
+
+           0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
+
+      The first octet is the normal label type and length for a 1 octet
+      long label, the second octet is the ASCII representation [RFC20]
+      for the '*' character.
+
+      A descriptive name of a label equaling that value is an "asterisk
+      label."
+
+      RFC 1034's definition of wildcard would be "a resource record
+      owned by a wild card domain name."
+
+2.1.2 Asterisks and Other Characters
+
+      No label values other than that in section 2.1.1 are asterisk
+      labels, hence names beginning with other labels are never wild
+      card domain names.  Labels such as 'the*' and '**' are not
+      asterisk labels so these labels do not start wild card domain
+      names.
+
+2.1.3 Non-terminal Wild Card Domain Names
+
+      In section 4.3.3, the following is stated:
+
+# ..........................  The owner name of the wildcard RRs is of
+# the form "*.<anydomain>", where <anydomain> is any domain name.
+# <anydomain> should not contain other * labels......................
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  6]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      The restriction is now removed.  The original documentation of it
+      is incomplete and the restriction does not serve any purpose
+      given years of operational experience.
+
+      There are three possible reasons for putting the restriction in
+      place, but none of the three has held up over time.  One is
+      that the restriction meant that there would never be subdomains
+      of wild card domain names, but the restriciton as stated still
+      permits "example.*.example." for instance.  Another is that
+      wild card domain names are not intended to be empty non-terminals,
+      but this situation does not disrupt the algorithm in 4.3.2.
+      Finally, "nested" wild card domain names are not ambiguous once
+      the concept of the closest encloser had been documented.
+
+      A wild card domain name can have subdomains.  There is no need
+      to inspect the subdomains to see if there is another asterisk
+      label in any subdomain.
+
+      A wild card domain name can be an empty non-terminal.  (See the
+      upcoming sections on empty non-terminals.)  In this case, any
+      lookup encountering it will terminate as would any empty
+      non-terminal match.
+
+2.2 Existence Rules
+
+      The notion that a domain name 'exists' is mentioned in the
+      definition of wildcards.  In section 4.3.3 of RFC 1034:
+
+# Wildcard RRs do not apply:
+#
+...
+#   - When the query name or a name between the wildcard domain and
+#     the query name is know[n] to exist.  For example, if a wildcard
+
+      "Existence" is therefore an important concept in the understanding
+      of wildcards.  Unfortunately, the definition of what exists, in RFC
+      1034, is unclear.  So, in sections 2.2.2. and 2.2.3, another look is
+      taken at the definition of existence.
+
+2.2.1 An Example
+
+      To illustrate what is meant by existence consider this complete
+      zone:
+
+
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  7]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+        $ORIGIN example.
+        example.                 3600 IN  SOA   <SOA RDATA>
+        example.                 3600     NS    ns.example.com.
+        example.                 3600     NS    ns.example.net.
+        *.example.               3600     TXT   "this is a wild card"
+        *.example.               3600     MX    10 host1.example.
+        sub.*.example.           3600     TXT   "this is not a wild card"
+        host1.example.           3600     A     192.0.4.1
+        _ssh._tcp.host1.example. 3600     SRV  <SRV RDATA>
+        _ssh._tcp.host2.example. 3600     SRV  <SRV RDATA>
+        subdel.example.          3600     NS   ns.example.com.
+        subdel.example.          3600     NS   ns.example.net.
+
+      A look at the domain names in a tree structure is helpful:
+
+                                    |
+                    -------------example------------
+                   /           /         \          \
+                  /           /           \          \
+                 /           /             \          \
+                *          host1          host2      subdel
+                |            |             |
+                |            |             |
+               sub         _tcp          _tcp
+                             |             |
+                             |             |
+                           _ssh          _ssh
+
+      The following responses would be synthesized from one of the
+      wildcards in the zone:
+
+          QNAME=host3.example. QTYPE=MX, QCLASS=IN
+               the answer will be a "host3.example. IN MX ..."
+
+          QNAME=host3.example. QTYPE=A, QCLASS=IN
+               the answer will reflect "no error, but no data"
+               because there is no A RR set at '*.example.'
+
+          QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
+               the answer will be "foo.bar.example. IN TXT ..."
+               because bar.example. does not exist, but the wildcard
+               does.
+
+      The following responses would not be synthesized from any of the
+      wildcards in the zone:
+
+          QNAME=host1.example., QTYPE=MX, QCLASS=IN
+               because host1.example. exists
+
+          QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
+               because sub.*.example. exists
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  8]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+          QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
+               because _tcp.host1.example. exists (without data)
+
+          QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
+               because subdel.example. exists (and is a zone cut)
+
+          QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
+               because *.example. exists
+
+      The final example highlights one common misconception about
+      wildcards.  A wildcard "blocks itself" in the sense that a
+      wildcard does not match its own subdomains.  I.e. "*.example."
+      does not match all names in the "example." zone, it fails to
+      match the names below "*.example." To cover names under
+      "*.example.", another wild card domain name is needed -
+      "*.*.example." - which covers all but it's own subdomains.
+
+2.2.2 Empty Non-terminals
+
+      Empty non-terminals [RFC2136, Section 7.16] are domain names
+      that own no resource records but have subdomains that do.  In
+      section 2.2.1, "_tcp.host1.example." is an example of a empty
+      non-terminal name.  Empty non-terminals are introduced by this
+      text in section 3.1 of RFC 1034:
+
+# The domain name space is a tree structure.  Each node and leaf on
+# the tree corresponds to a resource set (which may be empty).  The
+# domain system makes no distinctions between the uses of the
+# interior nodes and leaves, and this memo uses the term "node" to
+# refer to both.
+
+      The parenthesized "which may be empty" specifies that empty non-
+      terminals are explicitly recognized, and that empty non-terminals
+      "exist."
+
+      Pedantically reading the above paragraph can lead to an
+      interpretation that all possible domains exist - up to the
+      suggested limit of 255 octets for a domain name [RFC1035].
+      For example, www.example. may have an A RR, and as far as is
+      practically concerned, is a leaf of the domain tree.  But the
+      definition can be taken to mean that sub.www.example. also
+      exists, albeit with no data.  By extension, all possible domains
+      exist, from the root on down.
+
+      As RFC 1034 also defines "an authoritative name error indicating
+      that the name does not exist" in section 4.3.1, so this apparently
+      is not the intent of the original definition, justifying the
+      need for an updated definition in the next section.
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page  9]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+2.2.3 Yet Another Definition of Existence
+
+      RFC1034's wording is fixed by the following paragraph:
+
+      The domain name space is a tree structure.  Nodes in the tree
+      either own at least one RRSet and/or have descendants that
+      collectively own at least one RRSet.  A node may exist with no
+      RRSets only if it has descendents that do, this node is an empty
+      non-terminal.
+
+      A node with no descendants is a leaf node.  Empty leaf nodes do
+      not exist.
+
+      Note that at a zone boundary, the domain name owns data,
+      including the NS RR set.  In the delegating zone, the NS RR
+      set is not authoritative, but that is of no consequence here.
+      The domain name owns data, therefore, it exists.
+
+2.3 When is a Wild Card Domain Name Not Special
+
+      When a wild card domain name appears in a message's query section,
+      no special processing occurs.  An asterisk label in a query name
+      only matches a single, corresponding asterisk label in the
+      existing zone tree when the 4.3.2 algorithm is being followed.
+
+      When a wild card domain name appears in the resource data of a
+      record, no special processing occurs.  An asterisk label in that
+      context literally means just an asterisk.
+
+3. Impact of a Wild Card Domain Name On a Response
+
+      RFC 1034's description of how wildcards impact response
+      generation is in its section 4.3.2.  That passage contains the
+      algorithm followed by a server in constructing a response.
+      Within that algorithm, step 3, part 'c' defines the behavior of
+      the wildcard.
+
+      The algorithm in section 4.3.2. is not intended to be pseudo-code,
+      i.e., its steps are not intended to be followed in strict order.
+      The "algorithm" is a suggested means of implementing the
+      requirements.  As such, in step 3, parts a, b, and c, do not have
+      to be implemented in that order, provided that the result of the
+      implemented code is compliant with the protocol's specification.
+
+3.1 Step 2
+
+      Step 2 of section 4.3.2 reads:
+
+#   2. Search the available zones for the zone which is the nearest
+#      ancestor to QNAME.  If such a zone is found, go to step 3,
+#      otherwise step 4.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 10]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      In this step, the most appropriate zone for the response is
+      chosen.  The significance of this step is that it means all of
+      step 3 is being performed within one zone.  This has significance
+      when considering whether or not an SOA RR can be ever be used for
+      synthesis.
+
+3.2 Step 3
+
+      Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
+      But the beginning of the step is important and needs explanation.
+
+#   3. Start matching down, label by label, in the zone.  The
+#      matching process can terminate several ways:
+
+      The word 'matching' refers to label matching.  The concept
+      is based in the view of the zone as the tree of existing names.
+      The query name is considered to be an ordered sequence of
+      labels - as if the name were a path from the root to the owner
+      of the desired data.  (Which it is - 3rd paragraph of RFC 1034,
+      section 3.1.)
+
+      The process of label matching a query name ends in exactly one of
+      three choices, the parts 'a', 'b', and 'c'.  Either the name is
+      found, the name is below a cut point, or the name is not found.
+
+      Once one of the parts is chosen, the other parts are not
+      considered.  (E.g., do not execute part 'c' and then change
+      the execution path to finish in part 'b'.)  The process of label
+      matching is also done independent of the query type (QTYPE).
+
+      Parts 'a' and 'b' are not an issue for this clarification as they
+      do not relate to record synthesis.  Part 'a' is an exact match
+      that results in an answer, part 'b' is a referral.
+
+3.3 Part 'c'
+
+      The context of part 'c' is that the process of label matching the
+      labels of the query name has resulted in a situation in which
+      there is no corresponding label in the tree.  It is as if the
+      lookup has "fallen off the tree."
+
+#     c. If at some label, a match is impossible (i.e., the
+#        corresponding label does not exist), look to see if [...]
+#        the "*" label exists.
+
+      To help describe the process of looking 'to see if [...] the "*"
+      label exists' a term has been coined to describe the last domain
+      (node) matched.  The term is "closest encloser."
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 11]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+3.3.1 Closest Encloser and the Source of Synthesis
+
+      The closest encloser is the node in the zone's tree of existing
+      domain names that has the most labels matching the query name
+      (consecutively, counting from the root label downward). Each match
+      is a "label match" and the order of the labels is the same.
+
+      The closest encloser is, by definition, an existing name in the
+      zone.  The closest encloser might be an empty non-terminal or even
+      be a wild card domain name itself.  In no circumstances is the
+      closest encloser to be used to synthesize records for the current
+      query.
+
+      The source of synthesis is defined in the context of a query
+      process as that wild card domain name immediately descending
+      from the closest encloser, provided that this wild card domain
+      name exists.  "Immediately descending" means that the source
+      of synthesis has a name of the form:
+            <asterisk label>.<closest encloser>.
+      A source of synthesis does not guarantee having a RRSet to use
+      for synthesis.  The source of synthesis could be an empty
+      non-terminal.
+
+      If the source of synthesis does not exist (not on the domain
+      tree), there will be no wildcard synthesis.  There is no search
+      for an alternate.
+
+      The important concept is that for any given lookup process, there
+      is at most one place at which wildcard synthetic records can be
+      obtained.  If the source of synthesis does not exist, the lookup
+      terminates, the lookup does not look for other wildcard records.
+
+3.3.2 Closest Encloser and Source of Synthesis Examples
+
+      To illustrate, using the example zone in section 2.2.1 of this
+      document, the following chart shows QNAMEs and the closest
+      enclosers.
+
+      QNAME                       Closest Encloser    Source of Synthesis
+      host3.example.              example.            *.example.
+      _telnet._tcp.host1.example. _tcp.host1.example. no source
+      _telnet._tcp.host2.example. host2.example.      no source
+      _telnet._tcp.host3.example. example.            *.example.
+      _chat._udp.host3.example.   example.            *.example.
+      foobar.*.example.           *.example.          no source
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 12]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+3.3.3 Type Matching
+
+       RFC 1034 concludes part 'c' with this:
+
+#            If the "*" label does not exist, check whether the name
+#            we are looking for is the original QNAME in the query
+#            or a name we have followed due to a CNAME.  If the name
+#            is original, set an authoritative name error in the
+#            response and exit.  Otherwise just exit.
+#
+#            If the "*" label does exist, match RRs at that node
+#            against QTYPE.  If any match, copy them into the answer
+#            section, but set the owner of the RR to be QNAME, and
+#            not the node with the "*" label.  Go to step 6.
+
+      The final paragraph covers the role of the QTYPE in the lookup
+      process.
+
+      Based on implementation feedback and similarities between step
+      'a' and step 'c' a change to this passage has been made.
+
+      The change is to add the following text to step 'c' prior to the
+      instructions to "go to step 6":
+
+               If the data at the source of synthesis is a CNAME, and
+               QTYPE doesn't match CNAME, copy the CNAME RR into the
+               answer section of the response changing the owner name
+               to the QNAME, change QNAME to the canonical name in the
+               CNAME RR, and go back to step 1.
+
+      This is essentially the same text in step a covering the
+      processing of CNAME RRSets.
+
+4. Considerations with Special Types
+
+      Sections 2 and 3 of this document discuss wildcard synthesis
+      with respect to names in the domain tree and ignore the impact
+      of types.  In this section, the implication of wildcards of
+      specific types are discussed.  The types covered are those
+      that have proven to be the most difficult to understand.  The
+      types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
+      "none," i.e., empty non-terminal wild card domain names.
+
+4.1 SOA RRSet at a Wild Card Domain Name
+
+      A wild card domain name owning an SOA RRSet means that the
+      domain is at the root of the zone (apex).  The domain can not
+      be a source of synthesis because that is, by definition, a
+      descendent node (of the closest encloser) and a zone apex is
+      at the top of the zone.
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 13]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      Although a wild card domain name owning an SOA RRSet can never
+      be a source of synthesis, there is no reason to forbid the
+      ownership of an SOA RRSet.
+
+      E.g., given this zone:
+             $ORIGIN *.example.
+             @                 3600 IN  SOA   <SOA RDATA>
+                               3600     NS    ns1.example.com.
+                               3600     NS    ns1.example.net.
+             www               3600     TXT   "the www txt record"
+
+      A query for www.*.example.'s TXT record would still find the
+      "the www txt record" answer.  The asterisk label only becomes
+      significant when section 4.3.2, step 3 part 'c' is in effect.
+
+      Of course, there would need to be a delegation in the parent
+      zone, "example." for this to work too.  This is covered in the
+      next section.
+
+4.2 NS RRSet at a Wild Card Domain Name
+
+      With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
+      in place, the semantics of a wild card domain name owning an
+      NS RRSet has come to be poorly defined.  The dilemma relates to
+      a conflict between the rules for synthesis in part 'c' and the
+      fact that the resulting synthesis generates a record for which
+      the zone is not authoritative.  In a DNSSEC signed zone, the
+      mechanics of signature management (generation and inclusion
+      in a message) have become unclear.
+
+      Salient points of the working group discussion on this topic is
+      summarized in section 4.2.1.
+
+      As a result of these discussion, there is no definition given for
+      wild card domain names owning an NS RRSet.  The semantics are
+      left undefined until there is a clear need to have a set defined,
+      and until there is a clear direction to proceed.  Operationally,
+      inclusion of wild card NS RRSets in a zone is discouraged, but
+      not barred.
+
+4.2.1 Discarded Notions
+
+      Prior to DNSSEC, a wild card domain name owning a NS RRSet
+      appeared to be workable, and there are some instances in which
+      it is found in deployments using implementations that support
+      this.  Continuing to allow this in the specification is not
+      tenable with DNSSEC.  The reason is that the synthesis of the
+      NS RRSet is being done in a zone that has delegated away the
+      responsibility for the name.  This "unauthorized" synthesis is
+      not a problem for the base DNS protocol, but DNSSEC, in affirming
+      the authorization model for DNS exposes the problem.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 14]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      Outright banning of wildcards of type NS is also untenable as
+      the DNS protocol does not define how to handle "illegal" data.
+      Implementations may choose not to load a zone, but there is no
+      protocol definition.  The lack of the definition is complicated
+      by having to cover dynamic update [RFC 2136], zone transfers,
+      as well as loading at the master server.  The case of a client
+      (resolver, caching server) getting a wildcard of type NS in
+      a reply would also have to be considered.
+
+      Given the daunting challenge of a complete definition of how to
+      ban such records, dealing with existing implementations that
+      permit the records today is a further complication.  There are
+      uses of wild card domain name owning NS RRSets.
+
+      One compromise proposed would have redefined wildcards of type
+      NS to not be used in synthesis, this compromise fell apart
+      because it would have required significant edits to the DNSSEC
+      signing and validation work.  (Again, DNSSEC catches
+      unauthorized data.)
+
+      With no clear consensus forming on the solution to this dilemma,
+      and the realization that wildcards of type NS are a rarity in
+      operations, the best course of action is to leave this open-ended
+      until "it matters."
+
+4.3 CNAME RRSet at a Wild Card Domain Name
+
+      The issue of a CNAME RRSet owned by a wild card domain name has
+      prompted a suggested change to the last paragraph of step 3c of
+      the algorithm in 4.3.2.  The changed text appears in section
+      3.3.3 of this document.
+
+4.4 DNAME RRSet at a Wild Card Domain Name
+
+      Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
+      represents a threat to the coherency of the DNS and is to be
+      avoided or outright rejected.  Such a DNAME RRSet represents
+      non-deterministic synthesis of rules fed to different caches.
+      As caches are fed the different rules (in an unpredictable
+      manner) the caches will cease to be coherent.  ("As caches
+      are fed" refers to the storage in a cache of records obtained
+      in responses by recursive or iterative servers.)
+
+      For example, assume one cache, responding to a recursive
+      request, obtains the record:
+         "a.b.example. DNAME foo.bar.example.net."
+      and another cache obtains:
+         "b.example.  DNAME foo.bar.example.net."
+      both generated from the record:
+         "*.example. DNAME foo.bar.example.net."
+      by an authoritative server.
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 15]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      The DNAME specification is not clear on whether DNAME records
+      in a cache are used to rewrite queries.  In some interpretations,
+      the rewrite occurs, in some, it is not.  Allowing for the
+      occurrence of rewriting, queries for "sub.a.b.example. A" may
+      be rewritten as "sub.foo.bar.tld. A" by the former caching
+      server and may be rewritten as "sub.a.foo.bar.tld. A" by the
+      latter.  Coherency is lost, an operational nightmare ensues.
+
+      Another justification for banning or avoiding wildcard DNAME
+      records is the observation that such a record could synthesize
+      a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
+      There is a restriction in the DNAME definition that no domain
+      exist below a DNAME-owning domain, hence, the wildcard DNAME
+      is not to be permitted.
+
+4.5 SRV RRSet at a Wild Card Domain Name
+
+      The definition of the SRV RRset is RFC 2782 [RFC2782].  In the
+      definition of the record, there is some confusion over the term
+      "Name."  The definition reads as follows:
+
+# The format of the SRV RR
+...
+#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
+...
+#  Name
+#   The domain this RR refers to.  The SRV RR is unique in that the
+#   name one searches for is not this name; the example near the end
+#   shows this clearly.
+
+      Do not confuse the definition "Name" with the owner name.  I.e.,
+      once removing the _Service and _Proto labels from the owner name
+      of the SRV RRSet, what remains could be a wild card domain name
+      but this is immaterial to the SRV RRSet.
+
+      E.g.,  If an SRV record is:
+         _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
+
+      *.example is a wild card domain name and although it is the Name
+      of the SRV RR, it is not the owner (domain name).  The owner
+      domain name is "_foo._udp.*.example." which is not a wild card
+      domain name.
+
+      The confusion is likely based on the mixture of the specification
+      of the SRV RR and the description of a "use case."
+
+4.6 DS RRSet at a Wild Card Domain Name
+
+      A DS RRSet owned by a wild card domain name is meaningless and
+      harmless.  This statement is made in the context that an NS RRSet
+      at a wild card domain name is undefined.  At a non-delegation
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 16]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      point, a DS RRSet has no value (no corresponding DNSKEY RRSet
+      will be used in DNSSEC validation).  If there is a synthesized
+      DS RRSet, it alone will not be very useful as it exists in the
+      context of a delegation point.
+
+4.7 NSEC RRSet at a Wild Card Domain Name
+
+      Wild card domain names in DNSSEC signed zones will have an NSEC
+      RRSet.  Synthesis of these records will only occur when the
+      query exactly matches the record.  Synthesized NSEC RR's will not
+      be harmful as they will never be used in negative caching or to
+      generate a negative response.  [RFC2308]
+
+4.8 RRSIG at a Wild Card Domain Name
+
+      RRSIG records will be present at a wild card domain name in a
+      signed zone, and will be synthesized along with data sought in a
+      query.  The fact that the owner name is synthesized is not a
+      problem as the label count in the RRSIG will instruct the
+      verifying code to ignore it.
+
+4.9 Empty Non-terminal Wild Card Domain Name
+
+      If a source of synthesis is an empty non-terminal, then the
+      response will be one of no error in the return code and no RRSet
+      in the answer section.
+
+5. Security Considerations
+
+      This document is refining the specifications to make it more
+      likely that security can be added to DNS.  No functional
+      additions are being made, just refining what is considered
+      proper to allow the DNS, security of the DNS, and extending
+      the DNS to be more predictable.
+
+6. IANA Considerations
+
+       None.
+
+7. References
+
+      Normative References
+
+      [RFC20]   ASCII Format for Network Interchange, V.G. Cerf,
+                Oct-16-1969
+
+      [RFC1034] Domain Names - Concepts and Facilities,
+                P.V. Mockapetris, Nov-01-1987
+
+      [RFC1035] Domain Names - Implementation and Specification, P.V
+                Mockapetris, Nov-01-1987
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 17]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+      [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
+
+      [RFC2119] Key Words for Use in RFCs to Indicate Requirement
+                Levels, S Bradner, March 1997
+
+      [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
+                M. Andrews, March 1998
+
+      [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
+                August 1999.
+
+      [RFC2782] A DNS RR for specifying the location of services (DNS
+                SRV), A. Gulbrandsen, et.al., February 2000
+
+      [RFC4033] DNS Security Introduction and Requirements, R. Arends,
+                et.al., March 2005
+
+      [RFC4034] Resource Records for the DNS Security Extensions,
+                R. Arends, et.al., March 2005
+
+      [RFC4035] Protocol Modifications for the DNS Security Extensions,
+                R. Arends, et.al., March 2005
+
+      Informative References
+
+      [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
+                P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
+                April 1997
+
+8. Editor
+
+           Name:         Edward Lewis
+           Affiliation:  NeuStar
+           Address:      46000 Center Oak Plaza, Sterling, VA, 20166, US
+           Phone:        +1-571-434-5468
+           Email:        ed.lewis@neustar.biz
+
+      Comments on this document can be sent to the editor or the mailing
+      list for the DNSEXT WG, namedroppers@ops.ietf.org.
+
+9. Others Contributing to the Document
+
+      This document represents the work of a large working group.  The
+      editor merely recorded the collective wisdom of the working group.
+
+
+
+
+
+
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 17]
+
+Internet-Draft                  dnsext-wcard           January 9, 2006
+
+10. Trailing Boilerplate
+
+      Copyright (C) The Internet Society (2006).
+
+      This document is subject to the rights, licenses and restrictions
+      contained in BCP 78, and except as set forth therein, the authors
+      retain all their rights.
+
+      This document and the information contained herein are provided
+      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
+      HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
+      SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
+      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
+      ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
+      INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+      MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+      The IETF takes no position regarding the validity or scope of
+      any Intellectual Property Rights or other rights that might
+      be claimed to pertain to the implementation or use of the
+      technology described in this document or the extent to which
+      any license under such rights might or might not be available;
+      nor does it represent that it has made any independent effort
+      to identify any such rights.  Information on the procedures
+      with respect to rights in RFC documents can be found in BCP 78
+      and BCP 79.
+
+      Copies of IPR disclosures made to the IETF Secretariat and any
+      assurances of licenses to be made available, or the result of an
+      attempt made to obtain a general license or permission for the
+      use of such proprietary rights by implementers or users of this
+      specification can be obtained from the IETF on-line IPR
+      repository at http://www.ietf.org/ipr.  The IETF invites any
+      interested party to bring to its attention any copyrights,
+      patents or patent applications, or other proprietary rights
+      that may cover technology that may be required to implement
+      this standard.  Please address the information to the IETF at
+      ietf-ipr@ietf.org.
+
+Acknowledgement
+
+      Funding for the RFC Editor function is currently provided by the
+      Internet Society.
+
+Expiration
+
+      This document expires on or about July 9, 2006.
+
+
+
+DNSEXT Working Group        Expires July 9, 2006             [Page 19]
diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
new file mode 100644
index 0000000..0855ba3
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
@@ -0,0 +1,1232 @@
+
+
+
+DNS Operations                                                 M. Larson
+Internet-Draft                                                 P. Barber
+Expires: August 14, 2006                                        VeriSign
+                                                       February 10, 2006
+
+
+                  Observed DNS Resolution Misbehavior
+                    draft-ietf-dnsop-bad-dns-res-05
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 14, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memo describes DNS iterative resolver behavior that results in a
+   significant query volume sent to the root and top-level domain (TLD)
+   name servers.  We offer implementation advice to iterative resolver
+   developers to alleviate these unnecessary queries.  The
+   recommendations made in this document are a direct byproduct of
+   observation and analysis of abnormal query traffic patterns seen at
+   two of the thirteen root name servers and all thirteen com/net TLD
+   name servers.
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 1]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  A note about terminology in this memo  . . . . . . . . . .  3
+   2.  Observed iterative resolver misbehavior  . . . . . . . . . . .  5
+     2.1.  Aggressive requerying for delegation information . . . . .  5
+       2.1.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  6
+     2.2.  Repeated queries to lame servers . . . . . . . . . . . . .  7
+       2.2.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  7
+     2.3.  Inability to follow multiple levels of indirection . . . .  8
+       2.3.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  9
+     2.4.  Aggressive retransmission when fetching glue . . . . . . .  9
+       2.4.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 10
+     2.5.  Aggressive retransmission behind firewalls . . . . . . . . 10
+       2.5.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 11
+     2.6.  Misconfigured NS records . . . . . . . . . . . . . . . . . 11
+       2.6.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 12
+     2.7.  Name server records with zero TTL  . . . . . . . . . . . . 12
+       2.7.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 13
+     2.8.  Unnecessary dynamic update messages  . . . . . . . . . . . 13
+       2.8.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
+     2.9.  Queries for domain names resembling IPv4 addresses . . . . 14
+       2.9.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
+     2.10. Misdirected recursive queries  . . . . . . . . . . . . . . 15
+       2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
+     2.11. Suboptimal name server selection algorithm . . . . . . . . 15
+       2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
+   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
+   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 18
+   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 19
+   6.  Internationalization considerations  . . . . . . . . . . . . . 20
+   7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
+   Intellectual Property and Copyright Statements . . . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 2]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+1.  Introduction
+
+   Observation of query traffic received by two root name servers and
+   the thirteen com/net TLD name servers has revealed that a large
+   proportion of the total traffic often consists of "requeries".  A
+   requery is the same question (<QNAME, QTYPE, QCLASS>) asked
+   repeatedly at an unexpectedly high rate.  We have observed requeries
+   from both a single IP address and multiple IP addresses (i.e., the
+   same query received simultaneously from multiple IP addresses).
+
+   By analyzing requery events we have found that the cause of the
+   duplicate traffic is almost always a deficient iterative resolver,
+   stub resolver or application implementation combined with an
+   operational anomaly.  The implementation deficiencies we have
+   identified to date include well-intentioned recovery attempts gone
+   awry, insufficient caching of failures, early abort when multiple
+   levels of indirection must be followed, and aggressive retry by stub
+   resolvers or applications.  Anomalies that we have seen trigger
+   requery events include lame delegations, unusual glue records, and
+   anything that makes all authoritative name servers for a zone
+   unreachable (DoS attacks, crashes, maintenance, routing failures,
+   congestion, etc.).
+
+   In the following sections, we provide a detailed explanation of the
+   observed behavior and recommend changes that will reduce the requery
+   rate.  None of the changes recommended affects the core DNS protocol
+   specification; instead, this document consists of guidelines to
+   implementors of iterative resolvers.
+
+1.1.  A note about terminology in this memo
+
+   To recast an old saying about standards, the nice thing about DNS
+   terms is that there are so many of them to choose from.  Writing or
+   talking about DNS can be difficult and cause confusion resulting from
+   a lack of agreed-upon terms for its various components.  Further
+   complicating matters are implementations that combine multiple roles
+   into one piece of software, which makes naming the result
+   problematic.  An example is the entity that accepts recursive
+   queries, issues iterative queries as necessary to resolve the initial
+   recursive query, caches responses it receives, and which is also able
+   to answer questions about certain zones authoritatively.  This entity
+   is an iterative resolver combined with an authoritative name server
+   and is often called a "recursive name server" or a "caching name
+   server".
+
+   This memo is concerned principally with the behavior of iterative
+   resolvers, which are typically found as part of a recursive name
+   server.  This memo uses the more precise term "iterative resolver",
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 3]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   because the focus is usually on that component.  In instances where
+   the name server role of this entity requires mentioning, this memo
+   uses the term "recursive name server".  As an example of the
+   difference, the name server component of a recursive name server
+   receives DNS queries and the iterative resolver component sends
+   queries.
+
+   The advent of IPv6 requires mentioning AAAA records as well as A
+   records when discussing glue.  To avoid continuous repetition and
+   qualification, this memo uses the general term "address record" to
+   encompass both A and AAAA records when a particular situation is
+   relevant to both types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 4]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+2.  Observed iterative resolver misbehavior
+
+2.1.  Aggressive requerying for delegation information
+
+   There can be times when every name server in a zone's NS RRset is
+   unreachable (e.g., during a network outage), unavailable (e.g., the
+   name server process is not running on the server host) or
+   misconfigured (e.g., the name server is not authoritative for the
+   given zone, also known as "lame").  Consider an iterative resolver
+   that attempts to resolve a query for a domain name in such a zone and
+   discovers that none of the zone's name servers can provide an answer.
+   We have observed a recursive name server implementation whose
+   iterative resolver then verifies the zone's NS RRset in its cache by
+   querying for the zone's delegation information: it sends a query for
+   the zone's NS RRset to one of the parent zone's name servers.  (Note
+   that queries with QTYPE=NS are not required by the standard
+   resolution algorithm described in section 4.3.2 of RFC 1034 [2].
+   These NS queries represent this implementation's addition to that
+   algorithm.)
+
+   For example, suppose that "example.com" has the following NS RRset:
+
+     example.com.   IN   NS   ns1.example.com.
+     example.com.   IN   NS   ns2.example.com.
+
+   Upon receipt of a query for "www.example.com" and assuming that
+   neither "ns1.example.com" nor "ns2.example.com" can provide an
+   answer, this iterative resolver implementation immediately queries a
+   "com" zone name server for the "example.com" NS RRset to verify it
+   has the proper delegation information.  This implementation performs
+   this query to a zone's parent zone for each recursive query it
+   receives that fails because of a completely unresponsive set of name
+   servers for the target zone.  Consider the effect when a popular zone
+   experiences a catastrophic failure of all its name servers: now every
+   recursive query for domain names in that zone sent to this recursive
+   name server implementation results in a query to the failed zone's
+   parent name servers.  On one occasion when several dozen popular
+   zones became unreachable, the query load on the com/net name servers
+   increased by 50%.
+
+   We believe this verification query is not reasonable.  Consider the
+   circumstances: When an iterative resolver is resolving a query for a
+   domain name in a zone it has not previously searched, it uses the
+   list of name servers in the referral from the target zone's parent.
+   If on its first attempt to search the target zone, none of the name
+   servers in the referral is reachable, a verification query to the
+   parent would be pointless: this query to the parent would come so
+   quickly on the heels of the referral that it would be almost certain
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 5]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   to contain the same list of name servers.  The chance of discovering
+   any new information is slim.
+
+   The other possibility is that the iterative resolver successfully
+   contacts one of the target zone's name servers and then caches the NS
+   RRset from the authority section of a response, the proper behavior
+   according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
+   the target zone is more trustworthy than delegation information from
+   the parent zone.  If, while processing a subsequent recursive query,
+   the iterative resolver discovers that none of the name servers
+   specified in the cached NS RRset is available or authoritative,
+   querying the parent would be wrong.  An NS RRset from the parent zone
+   would now be less trustworthy than data already in the cache.
+
+   For this query of the parent zone to be useful, the target zone's
+   entire set of name servers would have to change AND the former set of
+   name servers would have to be deconfigured or decommissioned AND the
+   delegation information in the parent zone would have to be updated
+   with the new set of name servers, all within the TTL of the target
+   zone's NS RRset.  We believe this scenario is uncommon:
+   administrative best practices dictate that changes to a zone's set of
+   name servers happen gradually when at all possible, with servers
+   removed from the NS RRset left authoritative for the zone as long as
+   possible.  The scenarios that we can envision that would benefit from
+   the parent requery behavior do not outweigh its damaging effects.
+
+   This section should not be understood to claim that all queries to a
+   zone's parent are bad.  In some cases, such queries are not only
+   reasonable but required.  Consider the situation when required
+   information, such as the address of a name server (i.e., the address
+   record corresponding to the RDATA of an NS record), has timed out of
+   an iterative resolver's cache before the corresponding NS record.  If
+   the name of the name server is below the apex of the zone, then the
+   name server's address record is only available as glue in the parent
+   zone.  For example, consider this NS record:
+
+     example.com.        IN   NS   ns.example.com.
+
+   If a cache has this NS record but not the address record for
+   "ns.example.com", it is unable to contact the "example.com" zone
+   directly and must query the "com" zone to obtain the address record.
+   Note, however, that such a query would not have QTYPE=NS according to
+   the standard resolution algorithm.
+
+2.1.1.  Recommendation
+
+   An iterative resolver MUST NOT send a query for the NS RRset of a
+   non-responsive zone to any of the name servers for that zone's parent
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 6]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   zone.  For the purposes of this injunction, a non-responsive zone is
+   defined as a zone for which every name server listed in the zone's NS
+   RRset:
+
+   1.  is not authoritative for the zone (i.e., lame), or,
+
+   2.  returns a server failure response (RCODE=2), or,
+
+   3.  is dead or unreachable according to section 7.2 of RFC 2308 [4].
+
+2.2.  Repeated queries to lame servers
+
+   Section 2.1 describes a catastrophic failure: when every name server
+   for a zone is unable to provide an answer for one reason or another.
+   A more common occurrence is when a subset of a zone's name servers
+   are unavailable or misconfigured.  Different failure modes have
+   different expected durations.  Some symptoms indicate problems that
+   are potentially transient; for example, various types of ICMP
+   unreachable messages because a name server process is not running or
+   a host or network is unreachable, or a complete lack of a response to
+   a query.  Such responses could be the result of a host rebooting or
+   temporary outages; these events don't necessarily require any human
+   intervention and can be reasonably expected to be temporary.
+
+   Other symptoms clearly indicate a condition requiring human
+   intervention, such as lame server: if a name server is misconfigured
+   and not authoritative for a zone delegated to it, it is reasonable to
+   assume that this condition has potential to last longer than
+   unreachability or unresponsiveness.  Consequently, repeated queries
+   to known lame servers are not useful.  In this case of a condition
+   with potential to persist for a long time, a better practice would be
+   to maintain a list of known lame servers and avoid querying them
+   repeatedly in a short interval.
+
+   It should also be noted, however, that some authoritative name server
+   implementations appear to be lame only for queries of certain types
+   as described in RFC 4074 [5].  In this case, it makes sense to retry
+   the "lame" servers for other types of queries, particularly when all
+   known authoritative name servers appear to be "lame".
+
+2.2.1.  Recommendation
+
+   Iterative resolvers SHOULD cache name servers that they discover are
+   not authoritative for zones delegated to them (i.e. lame servers).
+   If this caching is performed, lame servers MUST be cached against the
+   specific query tuple <zone name, class, server IP address>.  Zone
+   name can be derived from the owner name of the NS record that was
+   referenced to query the name server that was discovered to be lame.
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 7]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   Implementations that perform lame server caching MUST refrain from
+   sending queries to known lame servers based on a time interval from
+   when the server is discovered to be lame.  A minimum interval of
+   thirty minutes is RECOMMENDED.
+
+   An exception to this recommendation occurs if all name servers for a
+   zone are marked lame.  In that case, the iterative resolver SHOULD
+   temporarily ignore the servers' lameness status and query one or more
+   servers.  This behavior is a workaround for the type-specific
+   lameness issue described in the previous section.
+
+   Implementors should take care not to make lame server avoidance logic
+   overly broad: note that a name server could be lame for a parent zone
+   but not a child zone, e.g., lame for "example.com" but properly
+   authoritative for "sub.example.com".  Therefore a name server should
+   not be automatically considered lame for subzones.  In the case
+   above, even if a name server is known to be lame for "example.com",
+   it should be queried for QNAMEs at or below "sub.example.com" if an
+   NS record indicates it should be authoritative for that zone.
+
+2.3.  Inability to follow multiple levels of indirection
+
+   Some iterative resolver implementations are unable to follow
+   sufficient levels of indirection.  For example, consider the
+   following delegations:
+
+     foo.example.        IN   NS   ns1.example.com.
+     foo.example.        IN   NS   ns2.example.com.
+
+     example.com.        IN   NS   ns1.test.example.net.
+     example.com.        IN   NS   ns2.test.example.net.
+
+     test.example.net.   IN   NS   ns1.test.example.net.
+     test.example.net.   IN   NS   ns2.test.example.net.
+
+   An iterative resolver resolving the name "www.foo.example" must
+   follow two levels of indirection, first obtaining address records for
+   "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
+   address records for "ns1.example.com" or "ns2.example.com" in order
+   to query those name servers for the address records of
+   "www.foo.example".  While this situation may appear contrived, we
+   have seen multiple similar occurrences and expect more as new generic
+   top-level domains (gTLDs) become active.  We anticipate many zones in
+   new gTLDs will use name servers in existing gTLDs, increasing the
+   number of delegations using out-of-zone name servers.
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 8]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+2.3.1.  Recommendation
+
+   Clearly constructing a delegation that relies on multiple levels of
+   indirection is not a good administrative practice.  However, the
+   practice is widespread enough to require that iterative resolvers be
+   able to cope with it.  Iterative resolvers SHOULD be able to handle
+   arbitrary levels of indirection resulting from out-of-zone name
+   servers.  Iterative resolvers SHOULD implement a level-of-effort
+   counter to avoid loops or otherwise performing too much work in
+   resolving pathological cases.
+
+   A best practice that avoids this entire issue of indirection is to
+   name one or more of a zone's name servers in the zone itself.  For
+   example, if the zone is named "example.com", consider naming some of
+   the name servers "ns{1,2,...}.example.com" (or similar).
+
+2.4.  Aggressive retransmission when fetching glue
+
+   When an authoritative name server responds with a referral, it
+   includes NS records in the authority section of the response.
+   According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
+   server should also "put whatever addresses are available into the
+   additional section, using glue RRs if the addresses are not available
+   from authoritative data or the cache."  Some name server
+   implementations take this address inclusion a step further with a
+   feature called "glue fetching".  A name server that implements glue
+   fetching attempts to include address records for every NS record in
+   the authority section.  If necessary, the name server issues multiple
+   queries of its own to obtain any missing address records.
+
+   Problems with glue fetching can arise in the context of
+   "authoritative-only" name servers, which only serve authoritative
+   data and ignore requests for recursion.  Such an entity will not
+   normally generate any queries of its own.  Instead it answers non-
+   recursive queries from iterative resolvers looking for information in
+   zones it serves.  With glue fetching enabled, however, an
+   authoritative server invokes an iterative resolver to look up an
+   unknown address record to complete the additional section of a
+   response.
+
+   We have observed situations where the iterative resolver of a glue-
+   fetching name server can send queries that reach other name servers,
+   but is apparently prevented from receiving the responses.  For
+   example, perhaps the name server is authoritative-only and therefore
+   its administrators expect it to receive only queries and not
+   responses.  Perhaps unaware of glue fetching and presuming that the
+   name server's iterative resolver will generate no queries, its
+   administrators place the name server behind a network device that
+
+
+
+Larson & Barber          Expires August 14, 2006                [Page 9]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   prevents it from receiving responses.  If this is the case, all glue-
+   fetching queries will go answered.
+
+   We have observed name server implementations whose iterative
+   resolvers retry excessively when glue-fetching queries are
+   unanswered.  A single com/net name server has received hundreds of
+   queries per second from a single such source.  Judging from the
+   specific queries received and based on additional analysis, we
+   believe these queries result from overly aggressive glue fetching.
+
+2.4.1.  Recommendation
+
+   Implementers whose name servers support glue fetching SHOULD take
+   care to avoid sending queries at excessive rates.  Implementations
+   SHOULD support throttling logic to detect when queries are sent but
+   no responses are received.
+
+2.5.  Aggressive retransmission behind firewalls
+
+   A common occurrence and one of the largest sources of repeated
+   queries at the com/net and root name servers appears to result from
+   resolvers behind misconfigured firewalls.  In this situation, an
+   iterative resolver is apparently allowed to send queries through a
+   firewall to other name servers, but not receive the responses.  The
+   result is more queries than necessary because of retransmission, all
+   of which are useless because the responses are never received.  Just
+   as with the glue-fetching scenario described in Section 2.4, the
+   queries are sometimes sent at excessive rates.  To make matters
+   worse, sometimes the responses, sent in reply to legitimate queries,
+   trigger an alarm on the originator's intrusion detection system.  We
+   are frequently contacted by administrators responding to such alarms
+   who believe our name servers are attacking their systems.
+
+   Not only do some resolvers in this situation retransmit queries at an
+   excessive rate, but they continue to do so for days or even weeks.
+   This scenario could result from an organization with multiple
+   recursive name servers, only a subset of whose iterative resolvers'
+   traffic is improperly filtered in this manner.  Stub resolvers in the
+   organization could be configured to query multiple recursive name
+   servers.  Consider the case where a stub resolver queries a filtered
+   recursive name server first.  The iterative resolver of this
+   recursive name server sends one or more queries whose replies are
+   filtered, so it can't respond to the stub resolver, which times out.
+   Then the stub resolver retransmits to a recursive name server that is
+   able to provide an answer.  Since resolution ultimately succeeds the
+   underlying problem might not be recognized or corrected.  A popular
+   stub resolver implementation has a very aggressive retransmission
+   schedule, including simultaneous queries to multiple recursive name
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 10]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   servers, which could explain how such a situation could persist
+   without being detected.
+
+2.5.1.  Recommendation
+
+   The most obvious recommendation is that administrators SHOULD take
+   care not to place iterative resolvers behind a firewall that allows
+   queries to pass through but not the resulting replies.
+
+   Iterative resolvers SHOULD take care to avoid sending queries at
+   excessive rates.  Implementations SHOULD support throttling logic to
+   detect when queries are sent but no responses are received.
+
+2.6.  Misconfigured NS records
+
+   Sometimes a zone administrator forgets to add the trailing dot on the
+   domain names in the RDATA of a zone's NS records.  Consider this
+   fragment of the zone file for "example.com":
+
+     $ORIGIN example.com.
+     example.com.      3600   IN   NS   ns1.example.com  ; Note missing
+     example.com.      3600   IN   NS   ns2.example.com  ; trailing dots
+
+   The zone's authoritative servers will parse the NS RDATA as
+   "ns1.example.com.example.com" and "ns2.example.com.example.com" and
+   return NS records with this incorrect RDATA in responses, including
+   typically the authority section of every response containing records
+   from the "example.com" zone.
+
+   Now consider a typical sequence of queries.  An iterative resolver
+   attempting to resolve address records for "www.example.com" with no
+   cached information for this zone will query a "com" authoritative
+   server.  The "com" server responds with a referral to the
+   "example.com" zone, consisting of NS records with valid RDATA and
+   associated glue records.  (This example assumes that the
+   "example.com" zone delegation information is correct in the "com"
+   zone.)  The iterative resolver caches the NS RRset from the "com"
+   server and follows the referral by querying one of the "example.com"
+   authoritative servers.  This server responds with the
+   "www.example.com" address record in the answer section and,
+   typically, the "example.com" NS records in the authority section and,
+   if space in the message remains, glue address records in the
+   additional section.  According to Section 5.4 of RFC 2181 [3], NS
+   records in the authority section of an authoritative answer are more
+   trustworthy than NS records from the authority section of a non-
+   authoritative answer.  Thus the "example.com" NS RRset just received
+   from the "example.com" authoritative server overrides the
+   "example.com" NS RRset received moments ago from the "com"
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 11]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   authoritative server.
+
+   But the "example.com" zone contains the erroneous NS RRset as shown
+   in the example above.  Subsequent queries for names in "example.com"
+   will cause the iterative resolver to attempt to use the incorrect NS
+   records and so it will try to resolve the nonexistent names
+   "ns1.example.com.example.com" and "ns2.example.com.example.com".  In
+   this example, since all of the zone's name servers are named in the
+   zone itself (i.e., "ns1.example.com.example.com" and
+   "ns2.example.com.example.com" both end in "example.com") and all are
+   bogus, the iterative resolver cannot reach any "example.com" name
+   servers.  Therefore attempts to resolve these names result in address
+   record queries to the "com" authoritative servers.  Queries for such
+   obviously bogus glue address records occur frequently at the com/net
+   name servers.
+
+2.6.1.  Recommendation
+
+   An authoritative server can detect this situation.  A trailing dot
+   missing from an NS record's RDATA always results by definition in a
+   name server name that exists somewhere under the apex of the zone the
+   NS record appears in.  Note that further levels of delegation are
+   possible, so a missing trailing dot could inadvertently create a name
+   server name that actually exists in a subzone.
+
+   An authoritative name server SHOULD issue a warning when one of a
+   zone's NS records references a name server below the zone's apex when
+   a corresponding address record does not exist in the zone AND there
+   are no delegated subzones where the address record could exist.
+
+2.7.  Name server records with zero TTL
+
+   Sometimes a popular com/net subdomain's zone is configured with a TTL
+   of zero on the zone's NS records, which prohibits these records from
+   being cached and will result in a higher query volume to the zone's
+   authoritative servers.  The zone's administrator should understand
+   the consequences of such a configuration and provision resources
+   accordingly.  A zero TTL on the zone's NS RRset, however, carries
+   additional consequences beyond the zone itself: if an iterative
+   resolver cannot cache a zone's NS records because of a zero TTL, it
+   will be forced to query that zone's parent's name servers each time
+   it resolves a name in the zone.  The com/net authoritative servers do
+   see an increased query load when a popular com/net subdomain's zone
+   is configured with a TTL of zero on the zone's NS records.
+
+   A zero TTL on an RRset expected to change frequently is extreme but
+   permissible.  A zone's NS RRset is a special case, however, because
+   changes to it must be coordinated with the zone's parent.  In most
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 12]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   zone parent/child relationships we are aware of, there is typically
+   some delay involved in effecting changes.  Further, changes to the
+   set of a zone's authoritative name servers (and therefore to the
+   zone's NS RRset) are typically relatively rare: providing reliable
+   authoritative service requires a reasonably stable set of servers.
+   Therefore an extremely low or zero TTL on a zone's NS RRset rarely
+   makes sense, except in anticipation of an upcoming change.  In this
+   case, when the zone's administrator has planned a change and does not
+   want iterative resolvers throughout the Internet to cache the NS
+   RRset for a long period of time, a low TTL is reasonable.
+
+2.7.1.  Recommendation
+
+   Because of the additional load placed on a zone's parent's
+   authoritative servers resulting from a zero TTL on a zone's NS RRset,
+   under such circumstances authoritative name servers SHOULD issue a
+   warning when loading a zone.
+
+2.8.  Unnecessary dynamic update messages
+
+   The UPDATE message specified in RFC 2136 [6] allows an authorized
+   agent to update a zone's data on an authoritative name server using a
+   DNS message sent over the network.  Consider the case of an agent
+   desiring to add a particular resource record.  Because of zone cuts,
+   the agent does not necessarily know the proper zone to which the
+   record should be added.  The dynamic update process requires that the
+   agent determine the appropriate zone so the UPDATE message can be
+   sent to one of the zone's authoritative servers (typically the
+   primary master as specified in the zone's SOA MNAME field).
+
+   The appropriate zone to update is the closest enclosing zone, which
+   cannot be determined only by inspecting the domain name of the record
+   to be updated, since zone cuts can occur anywhere.  One way to
+   determine the closest enclosing zone entails walking up the name
+   space tree by sending repeated UPDATE messages until success.  For
+   example, consider an agent attempting to add an address record with
+   the name "foo.bar.example.com".  The agent could first attempt to
+   update the "foo.bar.example.com" zone.  If the attempt failed, the
+   update could be directed to the "bar.example.com" zone, then the
+   "example.com" zone, then the "com" zone, and finally the root zone.
+
+   A popular dynamic agent follows this algorithm.  The result is many
+   UPDATE messages received by the root name servers, the com/net
+   authoritative servers, and presumably other TLD authoritative
+   servers.  A valid question is why the algorithm proceeds to send
+   updates all the way to TLD and root name servers.  This behavior is
+   not entirely unreasonable: in enterprise DNS architectures with an
+   "internal root" design, there could conceivably be private, non-
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 13]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   public TLD or root zones that would be the appropriate targets for a
+   dynamic update.
+
+   A significant deficiency with this algorithm is that knowledge of a
+   given UPDATE message's failure is not helpful in directing future
+   UPDATE messages to the appropriate servers.  A better algorithm would
+   be to find the closest enclosing zone by walking up the name space
+   with queries for SOA or NS rather than "probing" with UPDATE
+   messages.  Once the appropriate zone is found, an UPDATE message can
+   be sent.  In addition, the results of these queries can be cached to
+   aid in determining closest enclosing zones for future updates.  Once
+   the closest enclosing zone is determined with this method, the update
+   will either succeed or fail and there is no need to send further
+   updates to higher-level zones.  The important point is that walking
+   up the tree with queries yields cacheable information, whereas
+   walking up the tree by sending UPDATE messages does not.
+
+2.8.1.  Recommendation
+
+   Dynamic update agents SHOULD send SOA or NS queries to progressively
+   higher-level names to find the closest enclosing zone for a given
+   name to update.  Only after the appropriate zone is found should the
+   client send an UPDATE message to one of the zone's authoritative
+   servers.  Update clients SHOULD NOT "probe" using UPDATE messages by
+   walking up the tree to progressively higher-level zones.
+
+2.9.  Queries for domain names resembling IPv4 addresses
+
+   The root name servers receive a significant number of A record
+   queries where the QNAME looks like an IPv4 address.  The source of
+   these queries is unknown.  It could be attributed to situations where
+   a user believes an application will accept either a domain name or an
+   IP address in a given configuration option.  The user enters an IP
+   address, but the application assumes any input is a domain name and
+   attempts to resolve it, resulting in an A record lookup.  There could
+   also be applications that produce such queries in a misguided attempt
+   to reverse map IP addresses.
+
+   These queries result in Name Error (RCODE=3) responses.  An iterative
+   resolver can negatively cache such responses, but each response
+   requires a separate cache entry, i.e., a negative cache entry for the
+   domain name "192.0.2.1" does not prevent a subsequent query for the
+   domain name "192.0.2.2".
+
+2.9.1.  Recommendation
+
+   It would be desirable for the root name servers not to have to answer
+   these queries: they unnecessarily consume CPU resources and network
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 14]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   bandwidth.  A possible solution is to delegate these numeric TLDs
+   from the root zone to a separate set of servers to absorb the
+   traffic.  The "black hole servers" used by the AS 112 Project [8],
+   which are currently delegated the in-addr.arpa zones corresponding to
+   RFC 1918 [7] private use address space, would be a possible choice to
+   receive these delegations.  Of course, the proper and usual root zone
+   change procedures would have to be followed to make such a change to
+   the root zone.
+
+2.10.  Misdirected recursive queries
+
+   The root name servers receive a significant number of recursive
+   queries (i.e., queries with the RD bit set in the header).  Since
+   none of the root servers offers recursion, the servers' response in
+   such a situation ignores the request for recursion and the response
+   probably does not contain the data the querier anticipated.  Some of
+   these queries result from users configuring stub resolvers to query a
+   root server.  (This situation is not hypothetical: we have received
+   complaints from users when this configuration does not work as
+   hoped.)  Of course, users should not direct stub resolvers to use
+   name servers that do not offer recursion, but we are not aware of any
+   stub resolver implementation that offers any feedback to the user
+   when so configured, aside from simply "not working".
+
+2.10.1.  Recommendation
+
+   When the IP address of a name server that supposedly offers recursion
+   is configured in a stub resolver using an interactive user interface,
+   the resolver could send a test query to verify that the server indeed
+   supports recursion (i.e., verify that the response has the RA bit set
+   in the header).  The user could be immediately notified if the server
+   is non-recursive.
+
+   The stub resolver could also report an error, either through a user
+   interface or in a log file, if the queried server does not support
+   recursion.  Error reporting SHOULD be throttled to avoid a
+   notification or log message for every response from a non-recursive
+   server.
+
+2.11.  Suboptimal name server selection algorithm
+
+   An entire document could be devoted to the topic of problems with
+   different implementations of the recursive resolution algorithm.  The
+   entire process of recursion is woefully under specified, requiring
+   each implementor to design an algorithm.  Sometimes implementors make
+   poor design choices that could be avoided if a suggested algorithm
+   and best practices were documented, but that is a topic for another
+   document.
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 15]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+   Some deficiencies cause significant operational impact and are
+   therefore worth mentioning here.  One of these is name server
+   selection by an iterative resolver.  When an iterative resolver wants
+   to contact one of a zone's authoritative name servers, how does it
+   choose from the NS records listed in the zone's NS RRset?  If the
+   selection mechanism is suboptimal, queries are not spread evenly
+   among a zone's authoritative servers.  The details of the selection
+   mechanism are up to the implementor, but we offer some suggestions.
+
+2.11.1.  Recommendation
+
+   This list is not conclusive, but reflects the changes that would
+   produce the most impact in terms of reducing disproportionate query
+   load among a zone's authoritative servers.  I.e., these changes would
+   help spread the query load evenly.
+
+   o  Do not make assumptions based on NS RRset order: all NS RRs SHOULD
+      be treated equally.  (In the case of the "com" zone, for example,
+      most of the root servers return the NS record for "a.gtld-
+      servers.net" first in the authority section of referrals.
+      Apparently as a result, this server receives disproportionately
+      more traffic than the other 12 authoritative servers for "com".)
+
+   o  Use all NS records in an RRset.  (For example, we are aware of
+      implementations that hard-coded information for a subset of the
+      root servers.)
+
+   o  Maintain state and favor the best-performing of a zone's
+      authoritative servers.  A good definition of performance is
+      response time.  Non-responsive servers can be penalized with an
+      extremely high response time.
+
+   o  Do not lock onto the best-performing of a zone's name servers.  An
+      iterative resolver SHOULD periodically check the performance of
+      all of a zone's name servers to adjust its determination of the
+      best-performing one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 16]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+3.  Acknowledgments
+
+   The authors would like to thank the following people for their
+   comments that improved this document: Andras Salamon, Dave Meyer,
+   Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
+   Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein.  We
+   apologize if we have omitted anyone; any oversight was unintentional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 17]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+4.  IANA considerations
+
+   There are no new IANA considerations introduced by this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 18]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+5.  Security considerations
+
+   The iterative resolver misbehavior discussed in this document exposes
+   the root and TLD name servers to increased risk of both intentional
+   and unintentional denial of service attacks.
+
+   We believe that implementation of the recommendations offered in this
+   document will reduce the amount of unnecessary traffic seen at root
+   and TLD name servers, thus reducing the opportunity for an attacker
+   to use such queries to his or her advantage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 19]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+6.  Internationalization considerations
+
+   There are no new internationalization considerations introduced by
+   this memo.
+
+7.  Informative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Mockapetris, P., "Domain names - concepts and facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [3]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+        RFC 2181, July 1997.
+
+   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+        RFC 2308, March 1998.
+
+   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
+        Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+   [6]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+        Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+        April 1997.
+
+   [7]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
+        Lear, "Address Allocation for Private Internets", BCP 5,
+        RFC 1918, February 1996.
+
+   [8]  <http://www.as112.net>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 20]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+Authors' Addresses
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   Email: mlarson@verisign.com
+
+
+   Piet Barber
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   Email: pbarber@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 21]
+
+Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Larson & Barber          Expires August 14, 2006               [Page 22]
+
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
new file mode 100644
index 0000000..8ca68a8
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
@@ -0,0 +1,2016 @@
+
+
+
+DNSOP                                                         O. Kolkman
+Internet-Draft                                                 R. Gieben
+Obsoletes: 2541 (if approved)                                 NLnet Labs
+Expires: September 7, 2006                                 March 6, 2006
+
+
+                      DNSSEC Operational Practices
+          draft-ietf-dnsop-dnssec-operational-practices-08.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 7, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a set of practices for operating the DNS with
+   security extensions (DNSSEC).  The target audience is zone
+   administrators deploying DNSSEC.
+
+   The document discusses operational aspects of using keys and
+   signatures in the DNS.  It discusses issues as key generation, key
+   storage, signature generation, key rollover and related policies.
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 1]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   This document obsoletes RFC 2541, as it covers more operational
+   ground and gives more up to date requirements with respect to key
+   sizes and the new DNSSEC specification.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  The Use of the Term 'key'  . . . . . . . . . . . . . . . .  4
+     1.2.  Time Definitions . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Keeping the Chain of Trust Intact  . . . . . . . . . . . . . .  5
+   3.  Keys Generation and Storage  . . . . . . . . . . . . . . . . .  6
+     3.1.  Zone and Key Signing Keys  . . . . . . . . . . . . . . . .  6
+       3.1.1.  Motivations for the KSK and ZSK Separation . . . . . .  7
+       3.1.2.  KSKs for High Level Zones  . . . . . . . . . . . . . .  8
+     3.2.  Key Generation . . . . . . . . . . . . . . . . . . . . . .  8
+     3.3.  Key Effectivity Period . . . . . . . . . . . . . . . . . .  9
+     3.4.  Key Algorithm  . . . . . . . . . . . . . . . . . . . . . .  9
+     3.5.  Key Sizes  . . . . . . . . . . . . . . . . . . . . . . . . 10
+     3.6.  Private Key Storage  . . . . . . . . . . . . . . . . . . . 12
+   4.  Signature generation, Key Rollover and Related Policies  . . . 12
+     4.1.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
+       4.1.1.  Time Considerations  . . . . . . . . . . . . . . . . . 13
+     4.2.  Key Rollovers  . . . . . . . . . . . . . . . . . . . . . . 14
+       4.2.1.  Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
+       4.2.2.  Key Signing Key Rollovers  . . . . . . . . . . . . . . 19
+       4.2.3.  Difference Between ZSK and KSK Rollovers . . . . . . . 20
+       4.2.4.  Automated Key Rollovers  . . . . . . . . . . . . . . . 21
+     4.3.  Planning for Emergency Key Rollover  . . . . . . . . . . . 22
+       4.3.1.  KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
+       4.3.2.  ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
+       4.3.3.  Compromises of Keys Anchored in Resolvers  . . . . . . 24
+     4.4.  Parental Policies  . . . . . . . . . . . . . . . . . . . . 24
+       4.4.1.  Initial Key Exchanges and Parental Policies
+               Considerations . . . . . . . . . . . . . . . . . . . . 24
+       4.4.2.  Storing Keys or Hashes?  . . . . . . . . . . . . . . . 25
+       4.4.3.  Security Lameness  . . . . . . . . . . . . . . . . . . 25
+       4.4.4.  DS Signature Validity Period . . . . . . . . . . . . . 26
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
+   Appendix A.  Terminology . . . . . . . . . . . . . . . . . . . . . 29
+   Appendix B.  Zone Signing Key Rollover Howto . . . . . . . . . . . 30
+   Appendix C.  Typographic Conventions . . . . . . . . . . . . . . . 31
+   Appendix D.  Document Details and Changes  . . . . . . . . . . . . 33
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 2]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+     D.1.  draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
+     D.2.  draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
+     D.3.  draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
+     D.4.  draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
+     D.5.  draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
+     D.6.  draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
+     D.7.  draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
+     D.8.  draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
+     D.9.  draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
+   Intellectual Property and Copyright Statements . . . . . . . . . . 36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 3]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+1.  Introduction
+
+   This document describes how to run a DNSSEC (DNS SECure) enabled
+   environment.  It is intended for operators who have knowledge of the
+   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC.  See
+   RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
+   newly introduced Resource Records and finally RFC 4035 [6] for the
+   protocol changes.
+
+   During workshops and early operational deployment tests, operators
+   and system administrators have gained experience about operating the
+   DNS with security extensions (DNSSEC).  This document translates
+   these experiences into a set of practices for zone administrators.
+   At the time of writing, there exists very little experience with
+   DNSSEC in production environments; this document should therefore
+   explicitly not be seen as representing 'Best Current Practices'.
+
+   The procedures herein are focused on the maintenance of signed zones
+   (i.e. signing and publishing zones on authoritative servers).  It is
+   intended that maintenance of zones such as re-signing or key
+   rollovers be transparent to any verifying clients on the Internet.
+
+   The structure of this document is as follows.  In Section 2 we
+   discuss the importance of keeping the "chain of trust" intact.
+   Aspects of key generation and storage of private keys are discussed
+   in Section 3; the focus in this section is mainly on the private part
+   of the key(s).  Section 4 describes considerations concerning the
+   public part of the keys.  Since these public keys appear in the DNS
+   one has to take into account all kinds of timing issues, which are
+   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
+   rollover, or supercession, of keys.  Finally Section 4.4 discusses
+   considerations on how parents deal with their children's public keys
+   in order to maintain chains of trust.
+
+   The typographic conventions used in this document are explained in
+   Appendix C.
+
+   Since this is a document with operational suggestions and there are
+   no protocol specifications, the RFC 2119 [9] language does not apply.
+
+   This document obsoletes RFC 2541 [12].
+
+1.1.  The Use of the Term 'key'
+
+   It is assumed that the reader is familiar with the concept of
+   asymmetric keys on which DNSSEC is based (Public Key Cryptography
+   [18]).  Therefore, this document will use the term 'key' rather
+   loosely.  Where it is written that 'a key is used to sign data' it is
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 4]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   assumed that the reader understands that it is the private part of
+   the key pair that is used for signing.  It is also assumed that the
+   reader understands that the public part of the key pair is published
+   in the DNSKEY resource record and that it is the public part that is
+   used in key exchanges.
+
+1.2.  Time Definitions
+
+   In this document we will be using a number of time related terms.
+   The following definitions apply:
+   o  "Signature validity period"
+         The period that a signature is valid.  It starts at the time
+         specified in the signature inception field of the RRSIG RR and
+         ends at the time specified in the expiration field of the RRSIG
+         RR.
+   o  "Signature publication period"
+         Time after which a signature (made with a specific key) is
+         replaced with a new signature (made with the same key).  This
+         replacement takes place by publishing the relevant RRSIG in the
+         master zone file.
+         After one stops publishing an RRSIG in a zone it may take a
+         while before the RRSIG has expired from caches and has actually
+         been removed from the DNS.
+   o  "Key effectivity period"
+         The period during which a key pair is expected to be effective.
+         This period is defined as the time between the first inception
+         time stamp and the last expiration date of any signature made
+         with this key, regardless of any discontinuity in the use of
+         the key.
+         The key effectivity period can span multiple signature validity
+         periods.
+   o  "Maximum/Minimum Zone Time to Live (TTL)"
+         The maximum or minimum value of the TTLs from the complete set
+         of RRs in a zone.  Note that the minimum TTL is not the same as
+         the MINIMUM field in the SOA RR.  See [11] for more
+         information.
+
+
+2.  Keeping the Chain of Trust Intact
+
+   Maintaining a valid chain of trust is important because broken chains
+   of trust will result in data being marked as Bogus (as defined in [4]
+   section 5), which may cause entire (sub)domains to become invisible
+   to verifying clients.  The administrators of secured zones have to
+   realize that their zone is, to verifying clients, part of a chain of
+   trust.
+
+   As mentioned in the introduction, the procedures herein are intended
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 5]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   to ensure that maintenance of zones, such as re-signing or key
+   rollovers, will be transparent to the verifying clients on the
+   Internet.
+
+   Administrators of secured zones will have to keep in mind that data
+   published on an authoritative primary server will not be immediately
+   seen by verifying clients; it may take some time for the data to be
+   transferred to other secondary authoritative nameservers and clients
+   may be fetching data from caching non-authoritative servers.  In this
+   light it is good to note that the time for a zone transfer from
+   master to slave is negligible when using NOTIFY [8] and IXFR [7],
+   increasing by reliance on AXFR, and more if you rely on the SOA
+   timing parameters for zone refresh.
+
+   For the verifying clients it is important that data from secured
+   zones can be used to build chains of trust regardless of whether the
+   data came directly from an authoritative server, a caching nameserver
+   or some middle box.  Only by carefully using the available timing
+   parameters can a zone administrator assure that the data necessary
+   for verification can be obtained.
+
+   The responsibility for maintaining the chain of trust is shared by
+   administrators of secured zones in the chain of trust.  This is most
+   obvious in the case of a 'key compromise' when a trade off between
+   maintaining a valid chain of trust and replacing the compromised keys
+   as soon as possible must be made.  Then zone administrators will have
+   to make a trade off, between keeping the chain of trust intact -
+   thereby allowing for attacks with the compromised key - or to
+   deliberately break the chain of trust and making secured sub domains
+   invisible to security aware resolvers.  Also see Section 4.3.
+
+
+3.  Keys Generation and Storage
+
+   This section describes a number of considerations with respect to the
+   security of keys.  It deals with the generation, effectivity period,
+   size and storage of private keys.
+
+3.1.  Zone and Key Signing Keys
+
+   The DNSSEC validation protocol does not distinguish between different
+   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
+   practice operators use Key Signing and Zone Signing Keys and use the
+   so-called (Secure Entry Point) SEP [3] flag to distinguish between
+   them during operations.  The dynamics and considerations are
+   discussed below.
+
+   To make zone re-signing and key rollover procedures easier to
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 6]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   implement, it is possible to use one or more keys as Key Signing Keys
+   (KSK).  These keys will only sign the apex DNSKEY RRSet in a zone.
+   Other keys can be used to sign all the RRSets in a zone and are
+   referred to as Zone Signing Keys (ZSK).  In this document we assume
+   that KSKs are the subset of keys that are used for key exchanges with
+   the parent and potentially for configuration as trusted anchors - the
+   SEP keys.  In this document we assume a one-to-one mapping between
+   KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
+
+3.1.1.  Motivations for the KSK and ZSK Separation
+
+   Differentiating between the KSK and ZSK functions has several
+   advantages:
+
+   o  No parent/child interaction is required when ZSKs are updated.
+   o  The KSK can be made stronger (i.e. using more bits in the key
+      material).  This has little operational impact since it is only
+      used to sign a small fraction of the zone data.  Also the KSK is
+      only used to verify the zone's key set, not for other RRSets in
+      the zone.
+   o  As the KSK is only used to sign a key set, which is most probably
+      updated less frequently than other data in the zone, it can be
+      stored separately from and in a safer location than the ZSK.
+   o  A KSK can have a longer key effectivity period.
+
+   For almost any method of key management and zone signing the KSK is
+   used less frequently than the ZSK.  Once a key set is signed with the
+   KSK all the keys in the key set can be used as ZSK.  If a ZSK is
+   compromised, it can be simply dropped from the key set.  The new key
+   set is then re-signed with the KSK.
+
+   Given the assumption that for KSKs the SEP flag is set, the KSK can
+   be distinguished from a ZSK by examining the flag field in the DNSKEY
+   RR.  If the flag field is an odd number it is a KSK.  If it is an
+   even number it is a ZSK.
+
+   The zone signing key can be used to sign all the data in a zone on a
+   regular basis.  When a zone signing key is to be rolled, no
+   interaction with the parent is needed.  This allows for "Signature
+   Validity Periods" on the order of days.
+
+   The key signing key is only to be used to sign the DNSKEY RRs in a
+   zone.  If a key signing key is to be rolled over, there will be
+   interactions with parties other than the zone administrator.  These
+   can include the registry of the parent zone or administrators of
+   verifying resolvers that have the particular key configured as secure
+   entry points.  Hence, the key effectivity period of these keys can
+   and should be made much longer.  Although, given a long enough key,
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 7]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   the Key Effectivity Period can be on the order of years we suggest
+   planning for a key effectivity of the order of a few months so that a
+   key rollover remains an operational routine.
+
+3.1.2.  KSKs for High Level Zones
+
+   Higher level zones are generally more sensitive than lower level
+   zones.  Anyone controlling or breaking the security of a zone thereby
+   obtains authority over all of its sub domains (except in the case of
+   resolvers that have locally configured the public key of a sub
+   domain, in which case this, and only this, sub domain wouldn't be
+   affected by the compromise of the parent zone).  Therefore, extra
+   care should be taken with high level zones and strong keys should
+   used.
+
+   The root zone is the most critical of all zones.  Someone controlling
+   or compromising the security of the root zone would control the
+   entire DNS name space of all resolvers using that root zone (except
+   in the case of resolvers that have locally configured the public key
+   of a sub domain).  Therefore, the utmost care must be taken in the
+   securing of the root zone.  The strongest and most carefully handled
+   keys should be used.  The root zone private key should always be kept
+   off line.
+
+   Many resolvers will start at a root server for their access to and
+   authentication of DNS data.  Securely updating the trust anchors in
+   an enormous population of resolvers around the world will be
+   extremely difficult.
+
+3.2.  Key Generation
+
+   Careful generation of all keys is a sometimes overlooked but
+   absolutely essential element in any cryptographically secure system.
+   The strongest algorithms used with the longest keys are still of no
+   use if an adversary can guess enough to lower the size of the likely
+   key space so that it can be exhaustively searched.  Technical
+   suggestions for the generation of random keys will be found in RFC
+   4086 [15].  One should carefully assess if the random number
+   generator used during key generation adheres to these suggestions.
+
+   Keys with a long effectivity period are particularly sensitive as
+   they will represent a more valuable target and be subject to attack
+   for a longer time than short period keys.  It is strongly recommended
+   that long term key generation occur off-line in a manner isolated
+   from the network via an air gap or, at a minimum, high level secure
+   hardware.
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 8]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+3.3.  Key Effectivity Period
+
+   For various reasons keys in DNSSEC need to be changed once in a
+   while.  The longer a key is in use, the greater the probability that
+   it will have been compromised through carelessness, accident,
+   espionage, or cryptanalysis.  Furthermore when key rollovers are too
+   rare an event, they will not become part of the operational habit and
+   there is risk that nobody on-site will remember the procedure for
+   rollover when the need is there.
+
+   From a purely operational perspective a reasonable key effectivity
+   period for Key Signing Keys is 13 months, with the intent to replace
+   them after 12 months.  An intended key effectivity period of a month
+   is reasonable for Zone Signing Keys.
+
+   For key sizes that matches these effectivity periods see Section 3.5.
+
+   As argued in Section 3.1.2 securely updating trust anchors will be
+   extremely difficult.  On the other hand the "operational habit"
+   argument does also apply to trust anchor reconfiguration.  If a short
+   key-effectivity period is used and the trust anchor configuration has
+   to be revisited on a regular basis the odds that the configuration
+   tends to be forgotten is smaller.  The trade-off is against a system
+   that is so dynamic that administrators of the validating clients will
+   not be able to follow the modifications.
+
+   Key effectivity periods can be made very short, as in the order of a
+   few minutes.  But when replacing keys one has to take the
+   considerations from Section 4.1 and Section 4.2 into account.
+
+3.4.  Key Algorithm
+
+   There are currently three different types of algorithms that can be
+   used in DNSSEC: RSA, DSA and elliptic curve cryptography.  The latter
+   is fairly new and has yet to be standardized for usage in DNSSEC.
+
+   RSA has been developed in an open and transparent manner.  As the
+   patent on RSA expired in 2000, its use is now also free.
+
+   DSA has been developed by NIST.  The creation of signatures takes
+   roughly the same time as with RSA, but is 10 to 40 times as slow for
+   verification [18].
+
+   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
+   key.  The current known attacks on RSA can be defeated by making your
+   key longer.  As the MD5 hashing algorithm is showing (theoretical)
+   cracks, we recommend the usage of SHA-1.
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006               [Page 9]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   At the time of publication it is known that the SHA-1 hash has
+   cryptanalysis issues.  There is work in progress on addressing these
+   issues.  We recommend the use of public key algorithms based on
+   hashes stronger than SHA-1, e.g.  SHA-256, as soon as these
+   algorithms are available in protocol specifications (See [20] and
+   [21] ) and implementations.
+
+3.5.  Key Sizes
+
+   When choosing key sizes, zone administrators will need to take into
+   account how long a key will be used, how much data will be signed
+   during the key publication period (See Section 8.10 of [18]) and,
+   optionally, how large the key size of the parent is.  As the chain of
+   trust really is "a chain", there is not much sense in making one of
+   the keys in the chain several times larger then the others.  As
+   always, it's the weakest link that defines the strength of the entire
+   chain.  Also see Section 3.1.1 for a discussion of how keys serving
+   different roles (ZSK v.  KSK) may need different key sizes.
+
+   Generating a key of the correct size is a difficult problem, RFC 3766
+   [14] tries to deal with that problem.  The first part of the
+   selection procedure in Section 1 of the RFC states:
+
+      1. Determine the attack resistance necessary to satisfy the
+         security requirements of the application.  Do this by
+         estimating the minimum number of computer operations that
+         the attacker will be forced to do in order to compromise
+         the security of the system and then take the logarithm base
+         two of that number.  Call that logarithm value "n".
+
+         A 1996 report recommended 90 bits as a good all-around choice
+         for system security.  The 90 bit number should be increased
+         by about 2/3 bit/year, or about 96 bits in 2005.
+
+   [14] goes on to explain how this number "n" can be used to calculate
+   the key sizes in public key cryptography.  This culminated in the
+   table given below (slightly modified for our purpose):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 10]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+      +-------------+-----------+--------------+
+      | System      |           |              |
+      | requirement | Symmetric | RSA or DSA   |
+      | for attack  | key size  | modulus size |
+      | resistance  | (bits)    | (bits)       |
+      | (bits)      |           |              |
+      +-------------+-----------+--------------+
+      |     70      |     70    |      947     |
+      |     80      |     80    |     1228     |
+      |     90      |     90    |     1553     |
+      |    100      |    100    |     1926     |
+      |    150      |    150    |     4575     |
+      |    200      |    200    |     8719     |
+      |    250      |    250    |    14596     |
+      +-------------+-----------+--------------+
+
+   The key sizes given are rather large.  This is because these keys are
+   resilient against a trillionaire attacker.  Assuming this rich
+   attacker will not attack your key and that the key is rolled over
+   once a year, we come to the following recommendations about KSK
+   sizes; 1024 bits low value domains, 1300 for medium value and 2048
+   for the high value domains.
+
+   Whether a domain is of low, medium, high value depends solely on the
+   views of the zone owner.  One could for instance view leaf nodes in
+   the DNS as of low value and TLDs or the root zone of high value.  The
+   suggested key sizes should be safe for the next 5 years.
+
+   As ZSKs can be rolled over more easily (and thus more often) the key
+   sizes can be made smaller.  But as said in the introduction of this
+   paragraph, making the ZSKs' key sizes too small (in relation to the
+   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
+   size to about 100 bits.
+
+   Note that nobody can see into the future, and that these key sizes
+   are only provided here as a guide.  Further information can be found
+   in [17] and Section 7.5 of [18].  It should be noted though that [17]
+   is already considered overly optimistic about what key sizes are
+   considered safe.
+
+   One final note concerning key sizes.  Larger keys will increase the
+   sizes of the RRSIG and DNSKEY records and will therefore increase the
+   chance of DNS UDP packet overflow.  Also the time it takes to
+   validate and create RRSIGs increases with larger keys, so don't
+   needlessly double your key sizes.
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 11]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+3.6.  Private Key Storage
+
+   It is recommended that, where possible, zone private keys and the
+   zone file master copy that is to be signed, be kept and used in off-
+   line, non-network connected, physically secure machines only.
+   Periodically an application can be run to add authentication to a
+   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
+   transferred.
+
+   When relying on dynamic update to manage a signed zone [10], be aware
+   that at least one private key of the zone will have to reside on the
+   master server.  This key is only as secure as the amount of exposure
+   the server receives to unknown clients and the security of the host.
+   Although not mandatory one could administer the DNS in the following
+   way.  The master that processes the dynamic updates is unavailable
+   from generic hosts on the Internet, it is not listed in the NS RR
+   set, although its name appears in the SOA RRs MNAME field.  The
+   nameservers in the NS RR set are able to receive zone updates through
+   NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism.  This
+   approach is known as the "hidden master" setup.
+
+   The ideal situation is to have a one way information flow to the
+   network to avoid the possibility of tampering from the network.
+   Keeping the zone master file on-line on the network and simply
+   cycling it through an off-line signer does not do this.  The on-line
+   version could still be tampered with if the host it resides on is
+   compromised.  For maximum security, the master copy of the zone file
+   should be off net and should not be updated based on an unsecured
+   network mediated communication.
+
+   In general keeping a zone-file off-line will not be practical and the
+   machines on which zone files are maintained will be connected to a
+   network.  Operators are advised to take security measures to shield
+   unauthorized access to the master copy.
+
+   For dynamically updated secured zones [10] both the master copy and
+   the private key that is used to update signatures on updated RRs will
+   need to be on-line.
+
+
+4.  Signature generation, Key Rollover and Related Policies
+
+4.1.  Time in DNSSEC
+
+   Without DNSSEC all times in DNS are relative.  The SOA fields
+   REFRESH, RETRY and EXPIRATION are timers used to determine the time
+   elapsed after a slave server synchronized with a master server.  The
+   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 12]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   are used to determine how long a forwarder should cache data after it
+   has been fetched from an authoritative server.  By using a signature
+   validity period, DNSSEC introduces the notion of an absolute time in
+   the DNS.  Signatures in DNSSEC have an expiration date after which
+   the signature is marked as invalid and the signed data is to be
+   considered Bogus.
+
+4.1.1.  Time Considerations
+
+   Because of the expiration of signatures, one should consider the
+   following:
+   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
+      of your signature validity period.
+         If the TTL would be of similar order as the signature validity
+         period, then all RRSets fetched during the validity period
+         would be cached until the signature expiration time.  Section
+         7.1 of [4] suggests that "the resolver may use the time
+         remaining before expiration of the signature validity period of
+         a signed RRSet as an upper bound for the TTL".  As a result
+         query load on authoritative servers would peak at signature
+         expiration time, as this is also the time at which records
+         simultaneously expire from caches.
+         To avoid query load peaks we suggest the TTL on all the RRs in
+         your zone to be at least a few times smaller than your
+         signature validity period.
+   o  We suggest the Signature Publication Period to end at least one
+      Maximum Zone TTL duration before the end of the Signature Validity
+      Period.
+         Re-signing a zone shortly before the end of the signature
+         validity period may cause simultaneous expiration of data from
+         caches.  This in turn may lead to peaks in the load on
+         authoritative servers.
+   o  We suggest the minimum zone TTL to be long enough to both fetch
+      and verify all the RRs in the trust chain.  In workshop
+      environments it has been demonstrated [19] that a low TTL (under 5
+      to 10 minutes) caused disruptions because of the following two
+      problems:
+         1.  During validation, some data may expire before the
+         validation is complete.  The validator should be able to keep
+         all data, until is completed.  This applies to all RRs needed
+         to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
+         final answers i.e. the RRSet that is returned for the initial
+         query.
+         2.  Frequent verification causes load on recursive nameservers.
+         Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
+         caching.  The TTL on those should be relatively long.
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 13]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   o  Slave servers will need to be able to fetch newly signed zones
+      well before the RRSIGs in the zone served by the slave server pass
+      their signature expiration time.
+         When a slave server is out of sync with its master and data in
+         a zone is signed by expired signatures it may be better for the
+         slave server not to give out any answer.
+         Normally a slave server that is not able to contact a master
+         server for an extended period will expire a zone.  When that
+         happens the server will respond differently to queries for that
+         zone.  Some servers issue SERVFAIL while others turn off the
+         'AA' bit in the answers.  The time of expiration is set in the
+         SOA record and is relative to the last successful refresh
+         between the master and the slave server.  There exists no
+         coupling between the signature expiration of RRSIGs in the zone
+         and the expire parameter in the SOA.
+         If the server serves a DNSSEC zone then it may well happen that
+         the signatures expire well before the SOA expiration timer
+         counts down to zero.  It is not possible to completely prevent
+         this from happening by tweaking the SOA parameters.
+         However, the effects can be minimized where the SOA expiration
+         time is equal or shorter than the signature validity period.
+         The consequence of an authoritative server not being able to
+         update a zone, whilst that zone includes expired signatures, is
+         that non-secure resolvers will continue to be able to resolve
+         data served by the particular slave servers while security
+         aware resolvers will experience problems because of answers
+         being marked as Bogus.
+         We suggest the SOA expiration timer being approximately one
+         third or one fourth of the signature validity period.  It will
+         allow problems with transfers from the master server to be
+         noticed before the actual signature times out.
+         We also suggest that operators of nameservers that supply
+         secondary services develop 'watch dogs' to spot upcoming
+         signature expirations in zones they slave, and take appropriate
+         action.
+         When determining the value for the expiration parameter one has
+         to take the following into account: What are the chances that
+         all my secondaries expire the zone; How quickly can I reach an
+         administrator of secondary servers to load a valid zone?  All
+         these arguments are not DNSSEC specific but may influence the
+         choice of your signature validity intervals.
+
+4.2.  Key Rollovers
+
+   A DNSSEC key cannot be used forever (see Section 3.3).  So key
+   rollovers -- or supercessions, as they are sometimes called -- are a
+   fact of life when using DNSSEC.  Zone administrators who are in the
+   process of rolling their keys have to take into account that data
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 14]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   published in previous versions of their zone still lives in caches.
+   When deploying DNSSEC, this becomes an important consideration;
+   ignoring data that may be in caches may lead to loss of service for
+   clients.
+
+   The most pressing example of this occurs when zone material signed
+   with an old key is being validated by a resolver which does not have
+   the old zone key cached.  If the old key is no longer present in the
+   current zone, this validation fails, marking the data Bogus.
+   Alternatively, an attempt could be made to validate data which is
+   signed with a new key against an old key that lives in a local cache,
+   also resulting in data being marked Bogus.
+
+4.2.1.  Zone Signing Key Rollovers
+
+   For zone signing key rollovers there are two ways to make sure that
+   during the rollover data still cached can be verified with the new
+   key sets or newly generated signatures can be verified with the keys
+   still in caches.  One schema, described in Section 4.2.1.2, uses
+   double signatures; the other uses key pre-publication
+   (Section 4.2.1.1).  The pros, cons and recommendations are described
+   in Section 4.2.1.3.
+
+4.2.1.1.  Pre-publish Key Rollover
+
+   This section shows how to perform a ZSK rollover without the need to
+   sign all the data in a zone twice - the so-called "pre-publish
+   rollover".This method has advantages in the case of a key compromise.
+   If the old key is compromised, the new key has already been
+   distributed in the DNS.  The zone administrator is then able to
+   quickly switch to the new key and remove the compromised key from the
+   zone.  Another major advantage is that the zone size does not double,
+   as is the case with the double signature ZSK rollover.  A small
+   "HOWTO" for this kind of rollover can be found in Appendix B.
+
+   Pre-publish Key Rollover involves four stages as follows:
+
+    initial         new DNSKEY       new RRSIGs      DNSKEY removal
+
+    SOA0            SOA1             SOA2            SOA3
+    RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
+
+    DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
+    DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
+                    DNSKEY11         DNSKEY11
+    RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
+    RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 15]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   initial: Initial version of the zone: DNSKEY 1 is the key signing
+      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
+      signing key.
+   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
+      signatures are generated with this key yet, but this does not
+      secure against brute force attacks on the public key.  The minimum
+      duration of this pre-roll phase is the time it takes for the data
+      to propagate to the authoritative servers plus TTL value of the
+      key set.
+   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is
+      used to sign the data in the zone exclusively (i.e. all the
+      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
+      remains published in the key set.  This way data that was loaded
+      into caches from version 1 of the zone can still be verified with
+      key sets fetched from version 2 of the zone.
+      The minimum time that the key set including DNSKEY 10 is to be
+      published is the time that it takes for zone data from the
+      previous version of the zone to expire from old caches i.e. the
+      time it takes for this zone to propagate to all authoritative
+      servers plus the Maximum Zone TTL value of any of the data in the
+      previous version of the zone.
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
+      only containing DNSKEY 1 and DNSKEY 11 is re-signed with the
+      DNSKEY 1.
+
+   The above scheme can be simplified by always publishing the "future"
+   key immediately after the rollover.  The scheme would look as follows
+   (we show two rollovers); the future key is introduced in "new DNSKEY"
+   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
+   (II)":
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 16]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+       initial             new RRSIGs          new DNSKEY
+
+       SOA0                SOA1                SOA2
+       RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
+
+       DNSKEY1             DNSKEY1             DNSKEY1
+       DNSKEY10            DNSKEY10            DNSKEY11
+       DNSKEY11            DNSKEY11            DNSKEY12
+       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
+       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
+
+
+       new RRSIGs (II)     new DNSKEY (II)
+
+       SOA3                SOA4
+       RRSIG12(SOA3)       RRSIG12(SOA4)
+
+       DNSKEY1             DNSKEY1
+       DNSKEY11            DNSKEY12
+       DNSKEY12            DNSKEY13
+       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
+       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
+
+
+   Pre-Publish Key Rollover, showing two rollovers.
+
+   Note that the key introduced in the "new DNSKEY" phase is not used
+   for production yet; the private key can thus be stored in a
+   physically secure manner and does not need to be 'fetched' every time
+   a zone needs to be signed.
+
+4.2.1.2.  Double Signature Zone Signing Key Rollover
+
+   This section shows how to perform a ZSK key rollover using the double
+   zone data signature scheme, aptly named "double sig rollover".
+
+   During the "new DNSKEY" stage the new version of the zone file will
+   need to propagate to all authoritative servers and the data that
+   exists in (distant) caches will need to expire, requiring at least
+   the maximum Zone TTL.
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 17]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   Double Signature Zone Signing Key Rollover involves three stages as
+   follows:
+
+       initial             new DNSKEY         DNSKEY removal
+
+       SOA0                SOA1               SOA2
+       RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
+                           RRSIG11(SOA1)
+
+       DNSKEY1             DNSKEY1            DNSKEY1
+       DNSKEY10            DNSKEY10           DNSKEY11
+                           DNSKEY11
+       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
+       RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
+                           RRSIG11(DNSKEY)
+
+   initial: Initial Version of the zone: DNSKEY 1 is the key signing
+      key.  DNSKEY 10 is used to sign all the data of the zone, the zone
+      signing key.
+   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
+      introduced into the key set and all the data in the zone is signed
+      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
+      continue until all data from version 0 of the zone has expired
+      from remote caches.  This will take at least the maximum Zone TTL
+      of version 0 of the zone.
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
+      signatures from DNSKEY 10 are removed from the zone.  The key set,
+      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
+
+   At every instance, RRSIGs from the previous version of the zone can
+   be verified with the DNSKEY RRSet from the current version and the
+   other way around.  The data from the current version can be verified
+   with the data from the previous version of the zone.  The duration of
+   the "new DNSKEY" phase and the period between rollovers should be at
+   least the Maximum Zone TTL.
+
+   Making sure that the "new DNSKEY" phase lasts until the signature
+   expiration time of the data in initial version of the zone is
+   recommended.  This way all caches are cleared of the old signatures.
+   However, this duration could be considerably longer than the Maximum
+   Zone TTL, making the rollover a lengthy procedure.
+
+   Note that in this example we assumed that the zone was not modified
+   during the rollover.  New data can be introduced in the zone as long
+   as it is signed with both keys.
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 18]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+4.2.1.3.  Pros and Cons of the Schemes
+
+   Pre-publish Key Rollover: This rollover does not involve signing the
+      zone data twice.  Instead, before the actual rollover, the new key
+      is published in the key set and thus available for cryptanalysis
+      attacks.  A small disadvantage is that this process requires four
+      steps.  Also the pre-publish scheme involves more parental work
+      when used for KSK rollovers as explained in Section 4.2.3.
+   Double Signature Zone-signing Key Rollover: The drawback of this
+      signing scheme is that during the rollover the number of
+      signatures in your zone doubles, this may be prohibitive if you
+      have very big zones.  An advantage is that it only requires three
+      steps.
+
+4.2.2.  Key Signing Key Rollovers
+
+   For the rollover of a key signing key the same considerations as for
+   the rollover of a zone signing key apply.  However we can use a
+   double signature scheme to guarantee that old data (only the apex key
+   set) in caches can be verified with a new key set and vice versa.
+   Since only the key set is signed with a KSK, zone size considerations
+   do not apply.
+
+
+       initial        new DNSKEY        DS change       DNSKEY removal
+     Parent:
+       SOA0           -------->         SOA1            -------->
+       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
+       DS1            -------->         DS2             -------->
+       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
+
+
+     Child:
+       SOA0            SOA1             -------->       SOA2
+       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
+                                        -------->
+       DNSKEY1         DNSKEY1          -------->       DNSKEY2
+                       DNSKEY2          -------->
+       DNSKEY10        DNSKEY10         -------->       DNSKEY10
+       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
+                       RRSIG2 (DNSKEY)  -------->
+       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
+
+   Stages of Deployment for Key Signing Key Rollover.
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 19]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   initial: Initial version of the zone.  The parental DS points to
+      DNSKEY1.  Before the rollover starts the child will have to verify
+      what the TTL is of the DS RR that points to DNSKEY1 - it is needed
+      during the rollover and we refer to the value as TTL_DS.
+   new DNSKEY: During the "new DNSKEY" phase the zone administrator
+      generates a second KSK, DNSKEY2.  The key is provided to the
+      parent and the child will have to wait until a new DS RR has been
+      generated that points to DNSKEY2.  After that DS RR has been
+      published on all servers authoritative for the parent's zone, the
+      zone administrator has to wait at least TTL_DS to make sure that
+      the old DS RR has expired from caches.
+   DS change: The parent replaces DS1 with DS2.
+   DNSKEY removal: DNSKEY1 has been removed.
+
+   The scenario above puts the responsibility for maintaining a valid
+   chain of trust with the child.  It also is based on the premises that
+   the parent only has one DS RR (per algorithm) per zone.  An
+   alternative mechanism has been considered.  Using an established
+   trust relation, the interaction can be performed in-band, and the
+   removal of the keys by the child can possibly be signaled by the
+   parent.  In this mechanism there are periods where there are two DS
+   RRs at the parent.  Since at the moment of writing the protocol for
+   this interaction has not been developed, further discussion is out of
+   scope for this document.
+
+4.2.3.  Difference Between ZSK and KSK Rollovers
+
+   Note that KSK rollovers and ZSK rollovers are different in the sense
+   that a KSK rollover requires interaction with the parent (and
+   possibly replacing of trust anchors) and the ensuing delay while
+   waiting for it.
+
+   A zone key rollover can be handled in two different ways: pre-publish
+   (Section Section 4.2.1.1) and double signature (Section
+   Section 4.2.1.2).
+
+   As the KSK is used to validate the key set and because the KSK is not
+   changed during a ZSK rollover, a cache is able to validate the new
+   key set of the zone.  The pre-publish method would also work for a
+   KSK rollover.  The records that are to be pre-published are the
+   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
+   We first describe the rollover scheme and then indicate these
+   drawbacks.
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 20]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+     initial         new DS           new DNSKEY      DS/DNSKEY removal
+   Parent:
+     SOA0            SOA1             -------->       SOA2
+     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
+     DS1             DS1              -------->       DS2
+                     DS2              -------->
+     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
+
+
+
+   Child:
+     SOA0            -------->        SOA1            SOA1
+     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
+                     -------->
+     DNSKEY1         -------->        DNSKEY2         DNSKEY2
+                     -------->
+     DNSKEY10        -------->        DNSKEY10        DNSKEY10
+     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
+     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+
+   Stages of Deployment for a Pre-publish Key Signing Key rollover.
+
+   When the child zone wants to roll it notifies the parent during the
+   "new DS" phase and submits the new key (or the corresponding DS) to
+   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
+   and DNSKEY2 respectively.  During the rollover ("new DNSKEY" phase),
+   which can take place as soon as the new DS set propagated through the
+   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
+   ("DS/DNSKEY removal" phase) it can notify the parent that the old DS
+   record can be deleted.
+
+   The drawbacks of this scheme are that during the "new DS" phase the
+   parent cannot verify the match between the DS2 RR and DNSKEY2 using
+   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
+   "security lame" key (See Section 4.4.3).  Finally the child-parent
+   interaction consists of two steps.  The "double signature" method
+   only needs one interaction.
+
+4.2.4.  Automated Key Rollovers
+
+   As keys must be renewed periodically, there is some motivation to
+   automate the rollover process.  Consider that:
+
+   o  ZSK rollovers are easy to automate as only the child zone is
+      involved.
+   o  A KSK rollover needs interaction between parent and child.  Data
+      exchange is needed to provide the new keys to the parent,
+      consequently, this data must be authenticated and integrity must
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 21]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+      be guaranteed in order to avoid attacks on the rollover.
+
+4.3.  Planning for Emergency Key Rollover
+
+   This section deals with preparation for a possible key compromise.
+   Our advice is to have a documented procedure ready for when a key
+   compromise is suspected or confirmed.
+
+   When the private material of one of your keys is compromised it can
+   be used for as long as a valid trust chain exists.  A trust chain
+   remains intact for:
+   o  as long as a signature over the compromised key in the trust chain
+      is valid,
+   o  as long as a parental DS RR (and signature) points to the
+      compromised key,
+   o  as long as the key is anchored in a resolver and is used as a
+      starting point for validation (this is generally the hardest to
+      update).
+
+   While a trust chain to your compromised key exists, your name-space
+   is vulnerable to abuse by anyone who has obtained illegitimate
+   possession of the key.  Zone operators have to make a trade off if
+   the abuse of the compromised key is worse than having data in caches
+   that cannot be validated.  If the zone operator chooses to break the
+   trust chain to the compromised key, data in caches signed with this
+   key cannot be validated.  However, if the zone administrator chooses
+   to take the path of a regular roll-over, the malicious key holder can
+   spoof data so that it appears to be valid.
+
+4.3.1.  KSK Compromise
+
+   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
+   as long as the compromised KSK is configured as trust anchor or a
+   parental DS points to it.
+
+   A compromised KSK can be used to sign the key set of an attacker's
+   zone.  That zone could be used to poison the DNS.
+
+   Therefore when the KSK has been compromised, the trust anchor or the
+   parental DS, should be replaced as soon as possible.  It is local
+   policy whether to break the trust chain during the emergency
+   rollover.  The trust chain would be broken when the compromised KSK
+   is removed from the child's zone while the parent still has a DS
+   pointing to the compromised KSK (the assumption is that there is only
+   one DS at the parent.  If there are multiple DSs this does not apply
+   -- however the chain of trust of this particular key is broken).
+
+   Note that an attacker's zone still uses the compromised KSK and the
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 22]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   presence of a parental DS would cause the data in this zone to appear
+   as valid.  Removing the compromised key would cause the attacker's
+   zone to appear as valid and the child's zone as Bogus.  Therefore we
+   advise not to remove the KSK before the parent has a DS to a new KSK
+   in place.
+
+4.3.1.1.  Keeping the Chain of Trust Intact
+
+   If we follow this advice the timing of the replacement of the KSK is
+   somewhat critical.  The goal is to remove the compromised KSK as soon
+   as the new DS RR is available at the parent.  And also make sure that
+   the signature made with a new KSK over the key set with the
+   compromised KSK in it expires just after the new DS appears at the
+   parent.  Thus removing the old cruft in one swoop.
+
+   The procedure is as follows:
+   1.  Introduce a new KSK into the key set, keep the compromised KSK in
+       the key set.
+   2.  Sign the key set, with a short validity period.  The validity
+       period should expire shortly after the DS is expected to appear
+       in the parent and the old DSs have expired from caches.
+   3.  Upload the DS for this new key to the parent.
+   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
+       to appear in the authoritative servers and then wait as long as
+       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
+       and modify/extend the expiration time.
+   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
+       key set using your "normal" validity interval.
+
+   An additional danger of a key compromise is that the compromised key
+   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
+   nameserver changes at the parent.  When that happens the domain may
+   be in dispute.  An authenticated out-of-band and secure notify
+   mechanism to contact a parent is needed in this case.
+
+   Note that this is only a problem when the DNSKEY and or DS records
+   are used for authentication at the parent.
+
+4.3.1.2.  Breaking the Chain of Trust
+
+   There are two methods to break the chain of trust.  The first method
+   causes the child zone to appear as 'Bogus' to validating resolvers.
+   The other causes the the child zone to appear as 'insecure'.  These
+   are described below.
+
+   In the method that causes the child zone to appear as 'Bogus' to
+   validating resolvers, the child zone replaces the current KSK with a
+   new one and resigns the key set.  Next it sends the DS of the new key
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 23]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   to the parent.  Only after the parent has placed the new DS in the
+   zone, the child's chain of trust is repaired.
+
+   An alternative method of breaking the chain of trust is by removing
+   the DS RRs from the parent zone altogether.  As a result the child
+   zone would become insecure.
+
+4.3.2.  ZSK Compromise
+
+   Primarily because there is no parental interaction required when a
+   ZSK is compromised, the situation is less severe than with a KSK
+   compromise.  The zone must still be re-signed with a new ZSK as soon
+   as possible.  As this is a local operation and requires no
+   communication between the parent and child this can be achieved
+   fairly quickly.  However, one has to take into account that just as
+   with a normal rollover the immediate disappearance of the old
+   compromised key may lead to verification problems.  Also note that as
+   long as the RRSIG over the compromised ZSK is not expired the zone
+   may be still at risk.
+
+4.3.3.  Compromises of Keys Anchored in Resolvers
+
+   A key can also be pre-configured in resolvers.  For instance, if
+   DNSSEC is successfully deployed the root key may be pre-configured in
+   most security aware resolvers.
+
+   If trust-anchor keys are compromised, the resolvers using these keys
+   should be notified of this fact.  Zone administrators may consider
+   setting up a mailing list to communicate the fact that a SEP key is
+   about to be rolled over.  This communication will of course need to
+   be authenticated e.g. by using digital signatures.
+
+   End-users faced with the task of updating an anchored key should
+   always validate the new key.  New keys should be authenticated out-
+   of-band, for example, looking them up on an SSL secured announcement
+   website.
+
+4.4.  Parental Policies
+
+4.4.1.  Initial Key Exchanges and Parental Policies Considerations
+
+   The initial key exchange is always subject to the policies set by the
+   parent.  When designing a key exchange policy one should take into
+   account that the authentication and authorization mechanisms used
+   during a key exchange should be as strong as the authentication and
+   authorization mechanisms used for the exchange of delegation
+   information between parent and child.  I.e. there is no implicit need
+   in DNSSEC to make the authentication process stronger than it was in
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 24]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   DNS.
+
+   Using the DNS itself as the source for the actual DNSKEY material,
+   with an out-of-band check on the validity of the DNSKEY, has the
+   benefit that it reduces the chances of user error.  A DNSKEY query
+   tool can make use of the SEP bit [3] to select the proper key from a
+   DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
+   sent.  It can validate the self-signature over a key; thereby
+   verifying the ownership of the private key material.  Fetching the
+   DNSKEY from the DNS ensures that the chain of trust remains intact
+   once the parent publishes the DS RR indicating the child is secure.
+
+   Note: the out-of-band verification is still needed when the key-
+   material is fetched via the DNS.  The parent can never be sure
+   whether the DNSKEY RRs have been spoofed or not.
+
+4.4.2.  Storing Keys or Hashes?
+
+   When designing a registry system one should consider which of the
+   DNSKEYs and/or the corresponding DSs to store.  Since a child zone
+   might wish to have a DS published using a message digest algorithm
+   not yet understood by the registry, the registry can't count on being
+   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
+   that registry systems at least support storing DS records.
+
+   It may also be useful to store DNSKEYs, since having them may help
+   during troubleshooting and, as long as the child's chosen message
+   digest is supported, the overhead of generating DS records from them
+   is minimal.  Having an out-of-band mechanism, such as a registry
+   directory (e.g.  Whois), to find out which keys are used to generate
+   DS Resource Records for specific owners and/or zones may also help
+   with troubleshooting.
+
+   The storage considerations also relate to the design of the customer
+   interface and the method by which data is transferred between
+   registrant and registry; Will the child zone administrator be able to
+   upload DS RRs with unknown hash algorithms or does the interface only
+   allow DNSKEYs?  In the registry-registrar model one can use the
+   DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
+   and optionally DNSKEY RRs.
+
+4.4.3.  Security Lameness
+
+   Security Lameness is defined as what happens when a parent has a DS
+   RR pointing to a non-existing DNSKEY RR.  When this happens the
+   child's zone may be marked as "Bogus" by verifying DNS clients.
+
+   As part of a comprehensive delegation check the parent could, at key
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 25]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   exchange time, verify that the child's key is actually configured in
+   the DNS.  However if a parent does not understand the hashing
+   algorithm used by child the parental checks are limited to only
+   comparing the key id.
+
+   Child zones should be very careful removing DNSKEY material,
+   specifically SEP keys, for which a DS RR exists.
+
+   Once a zone is "security lame", a fix (e.g. removing a DS RR) will
+   take time to propagate through the DNS.
+
+4.4.4.  DS Signature Validity Period
+
+   Since the DS can be replayed as long as it has a valid signature, a
+   short signature validity period over the DS minimizes the time a
+   child is vulnerable in the case of a compromise of the child's
+   KSK(s).  A signature validity period that is too short introduces the
+   possibility that a zone is marked Bogus in case of a configuration
+   error in the signer.  There may not be enough time to fix the
+   problems before signatures expire.  Something as mundane as operator
+   unavailability during weekends shows the need for DS signature
+   validity periods longer than 2 days.  We recommend an absolute
+   minimum for a DS signature validity period of a few days.
+
+   The maximum signature validity period of the DS record depends on how
+   long child zones are willing to be vulnerable after a key compromise.
+   On the other hand shortening the DS signature validity interval
+   increases the operational risk for the parent.  Therefore the parent
+   may have policy to use a signature validity interval that is
+   considerably longer than the child would hope for.
+
+   A compromise between the operational constraints of the parent and
+   minimizing damage for the child may result in a DS signature validity
+   period somewhere between the order of a week to order of months.
+
+   In addition to the signature validity period, which sets a lower
+   bound on the number of times the zone owner will need to sign the
+   zone data and which sets an upper bound to the time a child is
+   vulnerable after key compromise, there is the TTL value on the DS
+   RRs.  Shortening the TTL means that the authoritative servers will
+   see more queries.  But on the other hand, a short TTL lowers the
+   persistence of DS RRSets in caches thereby increases the speed with
+   which updated DS RRSets propagate through the DNS.
+
+
+5.  IANA Considerations
+
+   This overview document introduces no new IANA considerations.
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 26]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+6.  Security Considerations
+
+   DNSSEC adds data integrity to the DNS.  This document tries to assess
+   the operational considerations to maintain a stable and secure DNSSEC
+   service.  Not taking into account the 'data propagation' properties
+   in the DNS will cause validation failures and may make secured zones
+   unavailable to security aware resolvers.
+
+
+7.  Acknowledgments
+
+   Most of the ideas in this draft were the result of collective efforts
+   during workshops, discussions and try outs.
+
+   At the risk of forgetting individuals who were the original
+   contributors of the ideas we would like to acknowledge people who
+   were actively involved in the compilation of this document.  In
+   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
+   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
+   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
+   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
+
+   Some material in this document has been copied from RFC 2541 [12].
+
+   Mike StJohns designed the key exchange between parent and child
+   mentioned in the last paragraph of Section 4.2.2
+
+   Section 4.2.4 was supplied by G. Guette and O. Courtay.
+
+   Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
+   the spelling and style issues.
+
+   Kolkman and Gieben take the blame for introducing all miscakes(SIC).
+
+   Kolkman was employed by the RIPE NCC while working on this document.
+
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 27]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [6]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+8.2.  Informative References
+
+   [7]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+         August 1996.
+
+   [8]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
+         (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [10]  Eastlake, D., "Secure Domain Name System Dynamic Update",
+         RFC 2137, April 1997.
+
+   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+         RFC 2308, March 1998.
+
+   [12]  Eastlake, D., "DNS Security Operational Considerations",
+         RFC 2541, March 1999.
+
+   [13]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+         RFC 3658, December 2003.
+
+   [14]  Orman, H. and P. Hoffman, "Determining Strengths For Public
+         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
+         April 2004.
+
+   [15]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+         Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [16]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
+         Mapping for the Extensible Provisioning Protocol (EPP)",
+         RFC 4310, December 2005.
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 28]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   [17]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
+         Sizes", The Journal of Cryptology 14 (255-293), 2001.
+
+   [18]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
+         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
+         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
+         1996.
+
+   [19]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
+
+   [20]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
+         Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
+         (work in progress), January 2006.
+
+   [21]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+         Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
+         (work in progress), January 2006.
+
+
+Appendix A.  Terminology
+
+   In this document there is some jargon used that is defined in other
+   documents.  In most cases we have not copied the text from the
+   documents defining the terms but given a more elaborate explanation
+   of the meaning.  Note that these explanations should not be seen as
+   authoritative.
+
+   Anchored Key: A DNSKEY configured in resolvers around the globe.
+      This key is hard to update, hence the term anchored.
+   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
+      "Bogus" when a signature of a RRSet does not validate against a
+      DNSKEY.
+   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
+      exclusively for signing the apex key set.  The fact that a key is
+      a KSK is only relevant to the signing tool.
+   Key size: The term 'key size' can be substituted by 'modulus size'
+      throughout the document.  It is mathematically more correct to use
+      modulus size, but as this is a document directed at operators we
+      feel more at ease with the term key size.
+   Private and Public Keys: DNSSEC secures the DNS through the use of
+      public key cryptography.  Public key cryptography is based on the
+      existence of two (mathematically related) keys, a public key and a
+      private key.  The public keys are published in the DNS by use of
+      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
+      remain private.
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 29]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   Key Rollover: A key rollover (also called key supercession in some
+      environments) is the act of replacing one key pair by another at
+      the end of a key effectivity period.
+   Secure Entry Point key or SEP Key: A KSK that has a parental DS
+      record pointing to it or is configured as a trust anchor.
+      Although not required by the protocol we recommend that the SEP
+      flag [3] is set on these keys.
+   Self-signature: This is only applies to signatures over DNSKEYs; a
+      signature made with DNSKEY x, over DNSKEY x is called a self-
+      signature.  Note: without further information self-signatures
+      convey no trust, they are useful to check the authenticity of the
+      DNSKEY, i.e. they can be used as a hash.
+   Singing the Zone File: The term used for the event where an
+      administrator joyfully signs its zone file while producing melodic
+      sound patterns.
+   Signer: The system that has access to the private key material and
+      signs the Resource Record sets in a zone.  A signer may be
+      configured to sign only parts of the zone e.g. only those RRSets
+      for which existing signatures are about to expire.
+   Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
+      used for signing all data in a zone.  The fact that a key is a ZSK
+      is only relevant to the signing tool.
+   Zone Administrator: The 'role' that is responsible for signing a zone
+      and publishing it on the primary authoritative server.
+
+
+Appendix B.  Zone Signing Key Rollover Howto
+
+   Using the pre-published signature scheme and the most conservative
+   method to assure oneself that data does not live in caches, here
+   follows the "HOWTO".
+   Step 0: The preparation: Create two keys and publish both in your key
+      set.  Mark one of the keys as "active" and the other as
+      "published".  Use the "active" key for signing your zone data.
+      Store the private part of the "published" key, preferably off-
+      line.
+      The protocol does not provide for attributes to mark a key as
+      active or published.  This is something you have to do on your
+      own, through the use of a notebook or key management tool.
+   Step 1: Determine expiration: At the beginning of the rollover make a
+      note of the highest expiration time of signatures in your zone
+      file created with the current key marked as "active".
+      Wait until the expiration time marked in Step 1 has passed
+   Step 2: Then start using the key that was marked as "published" to
+      sign your data i.e. mark it as "active".  Stop using the key that
+      was marked as "active", mark it as "rolled".
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 30]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   Step 3: It is safe to engage in a new rollover (Step 1) after at
+      least one "signature validity period".
+
+
+Appendix C.  Typographic Conventions
+
+   The following typographic conventions are used in this document:
+   Key notation: A key is denoted by DNSKEYx, where x is a number or an
+      identifier, x could be thought of as the key id.
+   RRSet notations: RRs are only denoted by the type.  All other
+      information - owner, class, rdata and TTL - is left out.  Thus:
+      "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
+      list of RRs.  A example of this would be: "A1, A2", specifying the
+      RRSet containing two "A" records.  This could again be abbreviated
+      to just "A".
+   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
+      means that RRSet is signed with DNSKEYx.
+   Zone representation: Using the above notation we have simplified the
+      representation of a signed zone by leaving out all unnecessary
+      details such as the names and by representing all data by "SOAx"
+   SOA representation: SOAs are represented as SOAx, where x is the
+      serial number.
+   Using this notation the following signed zone:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 31]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
+                            2006022100   ; serial
+                            86400        ; refresh (  24 hours)
+                            7200         ; retry   (   2 hours)
+                            3600000      ; expire  (1000 hours)
+                            28800 )      ; minimum (   8 hours)
+                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  cmL62SI6iAX46xGNQAdQ... )
+                     86400  NS      a.iana-servers.net.
+                     86400  NS      b.iana-servers.net.
+                     86400  RRSIG   NS 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  SO5epiJei19AjXoUpFnQ ... )
+                     86400  DNSKEY  256 3 5 (
+                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
+                     86400  DNSKEY  257 3 5 (
+                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  J4zCe8QX4tXVGjV4e1r9... )
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 15 example.net.
+                                  keVDCOpsSeDReyV6O... )
+                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  obj3HEp1GjnmhRjX... )
+   a.example.net.    86400  IN TXT  "A label"
+                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  IkDMlRdYLmXH7QJnuF3v... )
+                     86400  NSEC    b.example.com. TXT RRSIG NSEC
+                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  bZMjoZ3bHjnEz0nIsPMM... )
+                     ...
+
+   is reduced to the following representation:
+
+       SOA2006022100
+       RRSIG14(SOA2006022100)
+       DNSKEY14
+       DNSKEY15
+
+       RRSIG14(KEY)
+       RRSIG15(KEY)
+
+   The rest of the zone data has the same signature as the SOA record,
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 32]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   i.e a RRSIG created with DNSKEY 14.
+
+
+Appendix D.  Document Details and Changes
+
+   This section is to be removed by the RFC editor if and when the
+   document is published.
+
+   $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
+   2005/03/21 15:51:41 dnssec Exp $
+
+D.1.  draft-ietf-dnsop-dnssec-operational-practices-00
+
+   Submission as working group document.  This document is a modified
+   and updated version of draft-kolkman-dnssec-operational-practices-00.
+
+D.2.  draft-ietf-dnsop-dnssec-operational-practices-01
+
+   changed the definition of "Bogus" to reflect the one in the protocol
+   draft.
+
+   Bad to Bogus
+
+   Style and spelling corrections
+
+   KSK - SEP mapping made explicit.
+
+   Updates from Sam Weiler added
+
+D.3.  draft-ietf-dnsop-dnssec-operational-practices-02
+
+   Style and errors corrected.
+
+   Added Automatic rollover requirements from I-D.ietf-dnsop-key-
+   rollover-requirements.
+
+D.4.  draft-ietf-dnsop-dnssec-operational-practices-03
+
+   Added the definition of Key effectivity period and used that term
+   instead of Key validity period.
+
+   Modified the order of the sections, based on a suggestion by Rip
+   Loomis.
+
+   Included parts from RFC 2541 [12].  Most of its ground was already
+   covered.  This document obsoletes RFC 2541 [12].  Section 3.1.2
+   deserves some review as it in contrast to RFC 2541 does _not_ give
+   recomendations about root-zone keys.
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 33]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+   added a paragraph to Section 4.4.4
+
+D.5.  draft-ietf-dnsop-dnssec-operational-practices-04
+
+   Somewhat more details added about the pre-publish KSK rollover.  Also
+   moved that subsection down a bit.
+
+   Editorial and content nits that came in during wg last call were
+   fixed.
+
+D.6.  draft-ietf-dnsop-dnssec-operational-practices-05
+
+   Applied some another set of comments that came in _after_ the the
+   WGLC.
+
+   Applied comments from Hilarie Orman and made a referece to RFC 3766.
+   Deleted of a lot of key length discussion and took over the
+   recommendations from RFC 3766.
+
+   Reworked all the heading of the rollover figures
+
+D.7.  draft-ietf-dnsop-dnssec-operational-practices-06
+
+   One comment from Scott Rose applied.
+
+   Marcos Sanz gave a lots of editorial nits.  Almost all are
+   incorporated.
+
+D.8.  draft-ietf-dnsop-dnssec-operational-practices-07
+
+   Peter Koch's comments applied.
+
+   SHA-1/SHA-256 remarks added
+
+D.9.  draft-ietf-dnsop-dnssec-operational-practices-08
+
+   IESG comments applied.  Added headers and some captions to the tables
+   and applied all the nits.
+
+   IESG DISCUSS comments applied
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 34]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+Authors' Addresses
+
+   Olaf M. Kolkman
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098 VA
+   The Netherlands
+
+   Email: olaf@nlnetlabs.nl
+   URI:   http://www.nlnetlabs.nl
+
+
+   Miek Gieben
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098 VA
+   The Netherlands
+
+   Email: miek@nlnetlabs.nl
+   URI:   http://www.nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 35]
+
+Internet-Draft        DNSSEC Operational Practices            March 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Kolkman & Gieben        Expires September 7, 2006              [Page 36]
+
diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
new file mode 100644
index 0000000..bcd0d14
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
@@ -0,0 +1,396 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                                  D. Senie
+Category: BCP                                     Amaranth Networks Inc.
+Expires in six months                                          July 2005
+
+               Encouraging the use of DNS IN-ADDR Mapping
+		    draft-ietf-dnsop-inaddr-required-07.txt 
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+Abstract
+
+   Mapping of addresses to names has been a feature of DNS.  Many sites,
+   implement it, many others don't.  Some applications attempt to use it
+   as a part of a security strategy. The goal of this document is to
+   encourage proper deployment of address to name mappings, and provide
+   guidance for their use.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society. (2005)
+
+1. Introduction
+
+   The Domain Name Service has provision for providing mapping of IP
+   addresses to host names. It is common practice to ensure both name to
+   address, and address to name mappings are provided for networks. This
+   practice, while documented, has never been required, though it is
+   generally encouraged.  This document both encourages the presence of
+
+
+
+Senie                                                           [Page 1]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   these mappings and discourages reliance on such mappings for security
+   checks.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Discussion
+
+
+   From the early days of the Domain Name Service [RFC883] a special
+   domain has been set aside for resolving mappings of IP addresses to
+   domain names.  This was refined in [RFC1035], describing the .IN-
+   ADDR.ARPA in use today.  For the in the IPv6 address space, .IP6.ARPA
+   was added [RFC3152]. This document uses IPv4 CIDR block sizes and
+   allocation strategy where there are differences and uses IPv4
+   terminology.  Aside from these differences, this document can and
+   should be applied to both address spaces.
+
+   The assignment of blocks of IP address space was delegated to three
+   regional registries. Guidelines for the registries are specified in
+   [RFC2050], which requires regional registries to maintain IN-ADDR
+   records on the large blocks of space issued to ISPs and others.
+
+   ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
+   allocations. For smaller allocations, ARIN can provide IN-ADDR for
+   /24 and shorter prefixes. [ARIN].  APNIC provides methods for ISPs to
+   update IN-ADDR, however the present version of its policy document
+   for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
+   copies of this document. As of this writing, it appears APNIC has no
+   actual policy on IN-ADDR.  RIPE appears to have the strongest policy
+   in this area [RIPE302] indicating Local Internet Registries should
+   provide IN-ADDR services, and delegate those as appropriate when
+   address blocks are delegated.
+
+   As we can see, the regional registries have their own policies for
+   recommendations and/or requirements for IN-ADDR maintenance. It
+   should be noted, however, that many address blocks were allocated
+   before the creation of the regional registries, and thus it is
+   unclear whether any of the policies of the registries are binding on
+   those who hold blocks from that era.
+
+   Registries allocate address blocks on CIDR [RFC1519] boundaries.
+   Unfortunately the IN-ADDR zones are based on classful allocations.
+   Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
+   exist, but are not always implemented.
+
+3. Examples of impact of missing IN-ADDR
+
+
+
+Senie                                                           [Page 2]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   These are some examples of problems that may be introduced by
+   reliance on IN-ADDR.
+
+   Some applications use DNS lookups for security checks. To ensure
+   validity of claimed names, some applications will look up IN-ADDR
+   records to get names, and then look up the resultant name to see if
+   it maps back to the address originally known. Failure to resolve
+   matching names is seen as a potential security concern.
+
+   Some FTP sites will flat-out reject users, even for anonymous FTP, if
+   the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
+   itself resolved, does not match. Some Telnet servers also implement
+   this check.
+
+   Web sites are in some cases using IN-ADDR checks to verify whether
+   the client is located within a certain geopolitical entity. This
+   approach has been employed for downloads of crypto software, for
+   example, where export of that software is prohibited to some locales.
+   Credit card anti-fraud systems also use these methods for geographic
+   placement purposes.
+
+   The popular TCP Wrappers program found on most Unix and Linux systems
+   has options to enforce IN-ADDR checks and to reject any client that
+   does not resolve. This program also has a way to check to see that
+   the name given by a PTR record then resolves back to the same IP
+   address. This method provdes more comfort but no appreciable
+   additional security.
+
+   Some anti-spam (anti junk email) systems use IN-ADDR to verify the
+   presence of a PTR record, or validate the PTR value points back to
+   the same address.
+
+   Many web servers look up the IN-ADDR of visitors to be used in log
+   analysis.  This adds to the server load, but in the case of IN-ADDR
+   unavailability, it can lead to delayed responses for users.
+
+   Traceroutes with descriptive IN-ADDR naming proves useful when
+   debugging problems spanning large areas. When this information is
+   missing, the traceroutes take longer, and it takes additional steps
+   to determine that network is the cause of problems.
+
+   Wider-scale implementation of IN-ADDR on dialup, wireless access and
+   other such client-oriented portions of the Internet would result in
+   lower latency for queries (due to lack of negative caching), and
+   lower name server load and DNS traffic.
+
+4. Recommendations
+
+
+
+
+Senie                                                           [Page 3]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   4.1 Delegation Recommendations
+
+
+   Regional Registries and any Local Registries to whom they delegate
+   should establish and convey a policy to those to whom they delegate
+   blocks that IN-ADDR mappings are recommended.  Policies should
+   recommend those receiving delegations to provide IN-ADDR service
+   and/or delegate to downstream customers.
+
+   Network operators should define and implement policies and procedures
+   which delegate IN-ADDR to their clients who wish to run their own IN-
+   ADDR DNS services, and provide IN-ADDR services for those who do not
+   have the resources to do it themselves.  Delegation mechanisms should
+   permit the downstream customer to implement and comply with IETF
+   recommendations application of IN-ADDR to CIDR [RFC2317].
+
+   All IP address space assigned and in use should be resolved by IN-
+   ADDR records. All PTR records must use canonical names.
+
+   All IP addresses in use within a block should have an IN-ADDR
+   mapping. Those addresses not in use, and those that are not valid for
+   use (zeros or ones broadcast addresses within a CIDR block) need not
+   have mappings.
+
+   It should be noted that due to CIDR, many addresses that appear to be
+   otherwise valid host addresses may actually be zeroes or ones
+   broadcast addresses. As such, attempting to audit a site's degree of
+   compliance may only be done with knowledge of the internal subnet
+   architecture of the site.  It can be assumed, however, any host that
+   originates an IP packet necessarily will have a valid host address,
+   and must therefore have an IN-ADDR mapping.
+
+4.2 Application Recommendations
+
+
+   Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
+   of IN-ADDR, sometimes in conjunction with a lookup of the name
+   resulting from the PTR record provides no real security, can lead to
+   erroneous results and generally just increases load on DNS servers.
+   Further, in cases where address block holders fail to properly
+   configure IN-ADDR, users of those blocks are penalized.
+
+5. Security Considerations
+
+   This document has no negative impact on security. While it could be
+   argued that lack of PTR record capabilities provides a degree of
+   anonymity, this is really not valid. Trace routes, whois lookups and
+   other sources will still provide methods for discovering identity.
+
+
+
+Senie                                                           [Page 4]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   By recommending applications avoid using IN-ADDR as a security
+   mechanism this document points out that this practice, despite its
+   use by many applications, is an ineffective form of security.
+   Applications should use better mechanisms of authentication.
+
+6. IANA Considerations
+
+   There are no IANA considerations for this document.
+
+7. References
+
+7.1 Normative References
+
+   [RFC883] P.V. Mockapetris, "Domain names: Implementation
+   specification," RFC883, November 1983.
+
+   [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
+   Specification," RFC 1035, November 1987.
+
+   [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
+   an Address Assignment and Aggregation Strategy," RFC 1519, September
+   1993.
+
+   [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
+   RFC 2026, BCP 9, October 1996.
+
+   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
+   Guidelines", RFC2050, BCP 12, Novebmer 1996.
+
+   [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
+   RFC 2317, March 1998.
+
+   [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
+   2001.
+
+7.2 Informative References
+
+   [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
+   unknown, http://www.arin.net/regserv/initial-isp.html
+
+   [APNIC] "Policies For IPv4 Address Space Management in the Asia
+   Pacific Region," APNIC-086, 13 January 2003.
+
+   [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
+   Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
+
+
+
+Senie                                                           [Page 5]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+   2004. http://www.ripe.net//ripe/docs/rev-del.html
+
+
+
+8. Acknowledgements
+
+   Thanks to Peter Koch and Gary Miller for their input, and to many
+   people who encouraged me to write this document.
+
+9. Author's Address
+
+   Daniel Senie
+   Amaranth Networks Inc.
+   324 Still River Road
+   Bolton, MA 01740
+
+   Phone: (978) 779-5100
+
+   EMail: dts@senie.com
+
+10.  Full Copyright Statement
+
+      Copyright (C) The Internet Society (2005).
+
+      This document is subject to the rights, licenses and restrictions
+      contained in BCP 78, and except as set forth therein, the authors
+      retain all their rights.
+
+      This document and the information contained herein are provided
+      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
+      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
+      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
+      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+      PARTICULAR PURPOSE.
+
+Intellectual Property
+
+      The IETF takes no position regarding the validity or scope of any
+      Intellectual Property Rights or other rights that might be claimed
+      to pertain to the implementation or use of the technology
+      described in this document or the extent to which any license
+      under such rights might or might not be available; nor does it
+      represent that it has made any independent effort to identify any
+      such rights.  Information on the procedures with respect to
+      rights in RFC documents can be found in BCP 78 and BCP 79.
+
+
+
+
+Senie                                                           [Page 6]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
+
+
+      Copies of IPR disclosures made to the IETF Secretariat and any
+      assurances of licenses to be made available, or the result of an
+      attempt made to obtain a general license or permission for the use
+      of such proprietary rights by implementers or users of this
+      specification can be obtained from the IETF on-line IPR repository
+      at http://www.ietf.org/ipr.
+
+      The IETF invites any interested party to bring to its attention
+      any copyrights, patents or patent applications, or other
+      proprietary rights that may cover technology that may be required
+      to implement this standard.  Please address the information to the
+      IETF at ietf-ipr@ietf.org.
+
+      Internet-Drafts are working documents of the
+      Internet Engineering Task Force (IETF), its areas, and its
+      working groups. Note that other groups may also distribute
+      working documents as Internet-Drafts.
+
+      Internet-Drafts are draft documents valid for a maximum of
+      six months and may be updated, replaced, or obsoleted by
+      other documents at any time. It is inappropriate to use
+      Internet-Drafts as reference material or to cite them other
+      than as "work in progress."
+
+      The list of current Internet-Drafts can be accessed at
+      http://www.ietf.org/1id-abstracts.html
+
+      The list of Internet-Draft Shadow Directories can be
+      accessed at http://www.ietf.org/shadow.html
+
+Acknowledgement
+
+      Funding for the RFC Editor function is currently provided by the
+      Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Senie                                                           [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
new file mode 100644
index 0000000..bf2afcd
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
@@ -0,0 +1,1848 @@
+
+
+
+DNS Operations WG                                          J. Jeong, Ed.
+Internet-Draft                              ETRI/University of Minnesota
+Expires: November 6, 2005                                    May 5, 2005
+
+
+      IPv6 Host Configuration of DNS Server Information Approaches
+             draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on November 6, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes three approaches for IPv6 recursive DNS
+   server address configuration.  It details the operational attributes
+   of three solutions: RA option, DHCPv6 option, and Well-known anycast
+   addresses for recursive DNS servers.  Additionally, it suggests the
+   deployment scenarios in four kinds of networks, such as ISP,
+   Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
+   resolution.  Therefore, this document will give the audience a
+
+
+
+Jeong                   Expires November 6, 2005                [Page 1]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   guideline for IPv6 host DNS configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 2]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  IPv6 DNS Configuration Approaches  . . . . . . . . . . . . . .  7
+     3.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . .  7
+       3.1.1   Advantages . . . . . . . . . . . . . . . . . . . . . .  8
+       3.1.2   Disadvantages  . . . . . . . . . . . . . . . . . . . .  8
+       3.1.3   Observations . . . . . . . . . . . . . . . . . . . . .  9
+     3.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . .  9
+       3.2.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 11
+       3.2.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 12
+       3.2.3   Observations . . . . . . . . . . . . . . . . . . . . . 12
+     3.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
+       3.3.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 13
+       3.3.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 14
+       3.3.3   Observations . . . . . . . . . . . . . . . . . . . . . 14
+   4.  Interworking among IPv6 DNS Configuration Approaches . . . . . 15
+   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
+     5.1   ISP Network  . . . . . . . . . . . . . . . . . . . . . . . 16
+       5.1.1   RA Option Approach . . . . . . . . . . . . . . . . . . 16
+       5.1.2   DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
+       5.1.3   Well-known Anycast Addresses Approach  . . . . . . . . 17
+     5.2   Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
+     5.3   3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
+       5.3.1   Currently Available Mechanisms and Recommendations . . 19
+       5.3.2   RA Extension . . . . . . . . . . . . . . . . . . . . . 19
+       5.3.3   Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
+       5.3.4   Well-known Addresses . . . . . . . . . . . . . . . . . 21
+       5.3.5   Recommendations  . . . . . . . . . . . . . . . . . . . 21
+     5.4   Unmanaged Network  . . . . . . . . . . . . . . . . . . . . 22
+       5.4.1   Case A: Gateway does not provide IPv6 at all . . . . . 22
+       5.4.2   Case B: A dual-stack gateway connected to a
+               dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
+       5.4.3   Case C: A dual-stack gateway connected to an
+               IPv4-only ISP  . . . . . . . . . . . . . . . . . . . . 22
+       5.4.4   Case D: A gateway connected to an IPv6-only ISP  . . . 23
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
+     6.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . . 25
+     6.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . . 25
+     6.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
+   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+     9.1   Normative References . . . . . . . . . . . . . . . . . . . 29
+     9.2   Informative References . . . . . . . . . . . . . . . . . . 29
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
+   A.  Link-layer Multicast Acknowledgements for RA Option  . . . . . 32
+
+
+
+Jeong                   Expires November 6, 2005                [Page 3]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+       Intellectual Property and Copyright Statements . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 4]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+1.  Introduction
+
+   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+   Autoconfiguration provide the ways to configure either fixed or
+   mobile nodes with one or more IPv6 addresses, default routes and some
+   other parameters [3][4].  To support the access to additional
+   services in the Internet that are identified by a DNS name, such as a
+   web server, the configuration of at least one recursive DNS server is
+   also needed for DNS name resolution.
+
+   This document describes three approaches of recursive DNS server
+   address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
+   option [5]-[7], and (c) Well-known anycast addresses for recursive
+   DNS servers [9].  Also, it suggests the applicable scenarios for four
+   kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP
+   network, and (d) Unmanaged network.
+
+   This document is just an analysis of each possible approach, and does
+   not make any recommendation on a particular one or on a combination
+   of particular ones.  Some approaches may even not be adopted at all
+   as a result of further discussion.
+
+   Therefore, the objective of this document is to help the audience
+   select the approaches suitable for IPv6 host configuration of
+   recursive DNS servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 5]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+2.  Terminology
+
+   This document uses the terminology described in [3]-[9].  In
+   addition, a new term is defined below:
+
+   o  Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
+      server that offers the recursive service of DNS name resolution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005                [Page 6]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+3.  IPv6 DNS Configuration Approaches
+
+   In this section, the operational attributes of the three solutions
+   are described in detail.
+
+3.1  RA Option
+
+   The RA approach is to define a new ND option called the RDNSS option
+   that contains a recursive DNS server address.  Existing ND transport
+   mechanisms (i.e., advertisements and solicitations) are used.  This
+   works in the same way that nodes learn about routers and prefixes.
+   An IPv6 host can configure the IPv6 addresses of one or more RDNSSes
+   via RA message periodically sent by a router or solicited by a Router
+   Solicitation (RS) [8].
+
+   This approach needs RDNSS information to be configured in the routers
+   doing the advertisements.  The configuration of RDNSS addresses can
+   be performed manually by an operator or other ways, such as automatic
+   configuration through a DHCPv6 client running on the router.  When
+   advertising more than one RDNSS option, an RA message includes as
+   many RDNSS options as RDNSSes.
+
+   Through the ND protocol and RDNSS option along with a prefix
+   information option, an IPv6 host can perform its network
+   configuration of its IPv6 address and RDNSS simultaneously [3][4].
+   The RA option for RDNSS can be used on any network that supports the
+   use of ND.
+
+   However, it is worth noting that some link layers, such as Wireless
+   LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast,
+   which means that they cannot guarantee the timely delivery of RA
+   messages [25]-[28].  This is discussed in Appendix A.
+
+   The RA approach is useful in some mobile environments where the
+   addresses of the RDNSSes are changing because the RA option includes
+   a lifetime field that allows client to use RDNSSes nearer to the
+   client.  This can be configured to a value that will require the
+   client to time out the entry and switch over to another RDNSS address
+   [8].  However, from the viewpoint of implementation, the lifetime
+   field would seem to make matters a bit more complex.  Instead of just
+   writing to a DNS configuration file, such as resolv.conf for the list
+   of RDNSS addresses, we have to have a daemon around (or a program
+   that is called at the defined intervals) that keeps monitoring the
+   lifetime of RDNSSes all the time.
+
+   The preference value of RDNSS, included in the RDNSS option, allows
+   IPv6 hosts to select primary RDNSS among several RDNSSes; this can be
+   used for the load balancing of RDNSSes [8].
+
+
+
+Jeong                   Expires November 6, 2005                [Page 7]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+3.1.1  Advantages
+
+   The RA option for RDNSS has a number of advantages.  These include:
+
+   1.  The RA option is an extension of existing ND/Autoconfig
+       mechanisms [3][4], and does not require a change in the base ND
+       protocol.
+
+   2.  This approach, like ND, works well on a variety of link types
+       including point-to-point links, point-to-multipoint, and
+       multipoint-to-multipoint (i.e., Ethernet LANs), etc.  RFC 2461
+       [3] states, however, that there may be some link types on which
+       ND is not feasible; on such links, some other mechanisms will be
+       needed for DNS configuration.
+
+   3.  All of the information a host needs to run the basic Internet
+       applications such as the email, web, ftp, etc., can be obtained
+       with the addition of this option to ND and address
+       autoconfiguration.  The use of a single mechanism is more
+       reliable and easier to provide than when the RDNSS information is
+       learned via another protocol mechanism.  Debugging problems when
+       multiple protocol mechanisms are being used is harder and much
+       more complex.
+
+   4.  This mechanism works over a broad range of scenarios and
+       leverages IPv6 ND.  This works well on links that support
+       broadcast reliably (e.g., Ethernet LANs) but not necessarily on
+       other links (e.g., Wireless LANs): Refer to Appendix A.  Also,
+       this works well on links that are high performance (e.g.,
+       Ethernet LANs) and low performance (e.g., Cellular networks).  In
+       the latter case, by combining the RDNSS information with the
+       other information in the RA, the host can learn all of the
+       information needed to use most Internet applications, such as the
+       web in a single packet.  This not only saves bandwidth where this
+       is an issue, but also minimizes the delay needed to learn the
+       RDNSS information.
+
+   5.  The RA approach could be used as a model for other similar types
+       of configuration information.  New RA options for other server
+       addresses, such as NTP server address, that are common to all
+       clients on a subnet would be easy to define.
+
+
+3.1.2  Disadvantages
+
+   1.  ND is mostly implemented in the kernel of operating system.
+       Therefore, if ND supports the configuration of some additional
+       services, such as DNS servers, ND should be extended in the
+
+
+
+Jeong                   Expires November 6, 2005                [Page 8]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+       kernel, and complemented by a user-land process.  DHCPv6,
+       however, has more flexibility for the extension of service
+       discovery because it is an application layer protocol.
+
+   2.  The current ND framework should be modified to facilitate the
+       synchronization between another ND cache for RDNSSes in the
+       kernel space and the DNS configuration file in the user space.
+       Because it is unacceptable to write and rewrite to the DNS
+       configuration file (e.g., resolv.conf) from the kernel, another
+       approach is needed.  One simple approach to solve this is to have
+       a daemon listening to what the kernel conveys, and to have the
+       daemon do these steps, but such a daemon is not needed with the
+       current ND framework.
+
+   3.  It is necessary to configure RDNSS addresses at least at one
+       router on every link where this information needs to be
+       configured via the RA option.
+
+
+3.1.3  Observations
+
+   The proposed RDNSS RA option along with the IPv6 ND and
+   Autoconfiguration allows a host to obtain all of the information it
+   needs to access the basic Internet services like the web, email, ftp,
+   etc.  This is preferable in the environments where hosts use RAs to
+   autoconfigure their addresses and all the hosts on the subnet share
+   the same router and server addresses.  If the configuration
+   information can be obtained from a single mechanism, it is preferable
+   because it does not add additional delay, and it uses a minimum of
+   bandwidth.  The environments like this include the homes, public
+   cellular networks, and enterprise environments where no per host
+   configuration is needed, but exclude public WLAN hot spots.
+
+   DHCPv6 is preferable where it is being used for address configuration
+   and if there is a need for host specific configuration [5]-[7].  The
+   environments like this are most likely to be the enterprise
+   environments where the local administration chooses to have per host
+   configuration control.
+
+Note
+
+   The observation section is based on what the proponents of each
+   approach think makes a good overall solution.
+
+3.2  DHCPv6 Option
+
+   DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
+   which a host can obtain a list of IP addresses of recursive DNS
+
+
+
+Jeong                   Expires November 6, 2005                [Page 9]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   servers [7].  The DNS Recursive Name Server option carries a list of
+   IPv6 addresses of RDNSSes to which the host may send DNS queries.
+   The DNS servers are listed in the order of preference for use by the
+   DNS resolver on the host.
+
+   The DNS Recursive Name Server option can be carried in any DHCPv6
+   Reply message, in response to either a Request or an Information
+   request message.  Thus, the DNS Recursive Name Server option can be
+   used either when DHCPv6 is used for address assignment, or when
+   DHCPv6 is used only for other configuration information as stateless
+   DHCPv6 [6].
+
+   Stateless DHCPv6 can be deployed either using DHCPv6 servers running
+   on general-purpose computers, or on router hardware.  Several router
+   vendors currently implement stateless DHCPv6 servers.  Deploying
+   stateless DHCPv6 in routers has the advantage that no special
+   hardware is required, and should work well for networks where DHCPv6
+   is needed for very straightforward configuration of network devices.
+
+   However, routers can also act as DHCPv6 relay agents.  In this case,
+   the DHCPv6 server need not be on the router - it can be on a general
+   purpose computer.  This has the potential to give the operator of the
+   DHCPv6 server more flexibility in how the DHCPv6 server responds to
+   individual clients - clients can easily be given different
+   configuration information based on their identity, or for any other
+   reason.  Nothing precludes adding this flexibility to a router, but
+   generally in current practice, DHCP servers running on general-
+   purpose hosts tend to have more configuration options than those that
+   are embedded in routers.
+
+   DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
+   clients that use a stateful configuration assignment.  To do this,
+   the DHCPv6 server sends a Reconfigure message to the client.  The
+   client validates the Reconfigure message, and then contacts the
+   DHCPv6 server to obtain updated configuration information.  Using
+   this mechanism, it is currently possible to propagate new
+   configuration information to DHCPv6 clients as this information
+   changes.
+
+   The DHC Working Group is currently studying an additional mechanism
+   through which configuration information, including the list of
+   RDNSSes, can be updated.  The lifetime option for DHCPv6 [10] assigns
+   a lifetime to configuration information obtained through DHCPv6.  At
+   the expiration of the lifetime, the host contacts the DHCPv6 server
+   to obtain updated configuration information, including the list of
+   RDNSSes.  This lifetime gives the network administrator another
+   mechanism to configure hosts with new RDNSSes by controlling the time
+   at which the host refreshes the list.
+
+
+
+Jeong                   Expires November 6, 2005               [Page 10]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   The DHC Working Group has also discussed the possibility of defining
+   an extension to DHCPv6 that would allow the use of multicast to
+   provide configuration information to multiple hosts with a single
+   DHCPv6 message.  Because of the lack of deployment experience, the WG
+   has deferred consideration of multicast DHCPv6 configuration at this
+   time.  Experience with DHCPv4 has not identified a requirement for
+   multicast message delivery, even in large service provider networks
+   with tens of thousands of hosts that may initiate a DHCPv4 message
+   exchange simultaneously.
+
+3.2.1  Advantages
+
+   The DHCPv6 option for RDNSS has a number of advantages.  These
+   include:
+
+   1.  DHCPv6 currently provides a general mechanism for conveying
+       network configuration information to clients.  So configuring
+       DHCPv6 servers allows the network administrator to configure
+       RDNSSes along with the addresses of other network services, as
+       well as location-specific information like time zones.
+
+   2.  As a consequence, when the network administrator goes to
+       configure DHCPv6, all the configuration information can be
+       managed through a single service, typically with a single user
+       interface and a single configuration database.
+
+   3.  DHCPv6 allows for the configuration of a host with information
+       specific to that host, so that hosts on the same link can be
+       configured with different RDNSSes as well as with other
+       configuration information.  This capability is important in some
+       network deployments such as service provider networks or WiFi hot
+       spots.
+
+   4.  A mechanism exists for extending DHCPv6 to support the
+       transmission of additional configuration that has not yet been
+       anticipated.
+
+   5.  Hosts that require other configuration information such as the
+       addresses of SIP servers and NTP servers are likely to need
+       DHCPv6 for other configuration information.
+
+   6.  The specification for configuration of RDNSSes through DHCPv6 is
+       available as an RFC.  No new protocol extensions such as new
+       options are necessary.
+
+   7.  Interoperability among independent implementations has been
+       demonstrated.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 11]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+3.2.2  Disadvantages
+
+   The DHCPv6 option for RDNSS has a few disadvantages.  These include:
+
+   1.  Update currently requires message from server (however, see
+       [10]).
+
+   2.  Because DNS information is not contained in RA messages, the host
+       must receive two messages from the router, and must transmit at
+       least one message to the router.  On networks where bandwidth is
+       at a premium, this is a disadvantage, although on most networks
+       it is not a practical concern.
+
+   3.  Increased latency for initial configuration - in addition to
+       waiting for an RA message, the client must now exchange packets
+       with a DHCPv6 server; even if it is locally installed on a
+       router, this will slightly extend the time required to configure
+       the client.  For clients that are moving rapidly from one network
+       to another, this will be a disadvantage.
+
+
+3.2.3  Observations
+
+   In the general case, on general-purpose networks, stateless DHCPv6
+   provides significant advantages and no significant disadvantages.
+   Even in the case where bandwidth is at a premium and low latency is
+   desired, if hosts require other configuration information in addition
+   to a list of RDNSSes or if hosts must be configured selectively,
+   those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
+   name server option will be advantageous.
+
+   However, we are aware of some applications where it would be
+   preferable to put the RDNSS information into an RA packet; for
+   example, on a cell phone network, where bandwidth is at a premium and
+   extremely low latency is desired.  The final DNS configuration draft
+   should be written so as to allow these special applications to be
+   handled using DNS information in the RA packet.
+
+3.3  Well-known Anycast Addresses
+
+   Anycast uses the same routing system as unicast [11].  However,
+   administrative entities are local ones.  The local entities may
+   accept unicast routes (including default routes) to anycast servers
+   from adjacent entities.  The administrative entities should not
+   advertise their peers routes to their internal anycast servers, if
+   they want to prohibit external access from some peers to the servers.
+   If some advertisement is inevitable (such as the case with default
+   routes), the packets to the servers should be blocked at the boundary
+
+
+
+Jeong                   Expires November 6, 2005               [Page 12]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   of the entities.  Thus, for this anycast, not only unicast routing
+   but also unicast ND protocols can be used as is.
+
+   First of all, the well-known anycast addresses approach is much
+   different from that discussed at IPv6 Working Group in the past [9].
+   It should be noted that "anycast" in this memo is simpler than that
+   of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be
+   prohibited to have multiple servers on a single link sharing an
+   anycast address.  That is, on a link, an anycast address is assumed
+   to be unique.  DNS clients today already have redundancy by having
+   multiple well-known anycast addresses configured as RDNSS addresses.
+   There is no point in having multiple RDNSSes sharing an anycast
+   address on a single link.
+
+   The approach with well-known anycast addresses is to set multiple
+   well-known anycast addresses in clients' resolver configuration files
+   from the beginning, say, as factory default.  Thus, there is no
+   transport mechanism and no packet format [9].
+
+   An anycast address is an address shared by multiple servers (in this
+   case, the servers are RDNSSes).  A request from a client to the
+   anycast address is routed to a server selected by the routing system.
+   However, it is a bad idea to mandate "site" boundary on anycast
+   addresses, because most users just do not have their own servers and
+   want to access their ISPs' across their site boundaries.  Larger
+   sites may also depend on their ISPs or may have their own RDNSSes
+   within "site" boundaries.
+
+3.3.1  Advantages
+
+   The basic advantage of the well-known addresses approach is that it
+   uses no transport mechanism.  Thus,
+
+   1.  There is no delay to get the response and no further delay by
+       packet losses.
+
+   2.  The approach can be combined with any other configuration
+       mechanisms, such as the RA-based approach and DHCP based
+       approach, as well as the factory default configuration.
+
+   3.  The approach works over any environment where DNS works.
+
+   Another advantage is that the approach needs to configure DNS servers
+   as a router, but nothing else.  Considering that DNS servers do need
+   configuration, the amount of overall configuration effort is
+   proportional to the number of the DNS servers and scales linearly.
+   It should be noted that, in the simplest case where a subscriber to
+   an ISP does not have any DNS server, the subscriber naturally
+
+
+
+Jeong                   Expires November 6, 2005               [Page 13]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   accesses DNS servers of the ISP even though the subscriber and the
+   ISP do nothing and there is no protocol to exchange DNS server
+   information between the subscriber and the ISP.
+
+3.3.2  Disadvantages
+
+   Well-known anycast addresses approach requires that DNS servers (or
+   routers near it as a proxy) act as routers to advertise their anycast
+   addresses to the routing system, which requires some configuration
+   (see the last paragraph of the previous section on the scalability of
+   the effort).
+
+3.3.3  Observations
+
+   If other approaches are used in addition, the well-known anycast
+   addresses should also be set in RA or DHCP configuration files to
+   reduce the configuration effort of users.
+
+   The redundancy by multiple RDNSSes is better provided by multiple
+   servers having different anycast addresses than multiple servers
+   sharing the same anycast address because the former approach allows
+   stale servers to still generate routes to their anycast addresses.
+   Thus, in a routing domain (or domains sharing DNS servers), there
+   will be only one server having an anycast address unless the domain
+   is so large that load distribution is necessary.
+
+   Small ISPs will operate one RDNSS at each anycast address which is
+   shared by all the subscribers.  Large ISPs may operate multiple
+   RDNSSes at each anycast address to distribute and reduce load, where
+   the boundary between RDNSSes may be fixed (redundancy is still
+   provided by multiple addresses) or change dynamically.  DNS packets
+   with the well-known anycast addresses are not expected (though not
+   prohibited) to cross ISP boundaries, as ISPs are expected to be able
+   to take care of themselves.
+
+   Because "anycast" in this memo is simpler than that of RFC 1546 [11]
+   and RFC 3513 [12] where it is assumed to be administratively
+   prohibited to have multiple servers on a single link sharing an
+   anycast address, anycast in this memo should be implemented as
+   UNICAST of RFC 2461 [3] and RFC 3513 [12].  As a result, ND-related
+   instability disappears.  Thus, anycast in well-known anycast
+   addresses approach can and should use the anycast address as a source
+   unicast (according to RFC 3513 [12]) address of packets of UDP and
+   TCP responses.  With TCP, if a route flips and packets to an anycast
+   address are routed to a new server, it is expected that the flip is
+   detected by ICMP or sequence number inconsistency and the TCP
+   connection is reset and retried.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 14]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+4.  Interworking among IPv6 DNS Configuration Approaches
+
+   Three approaches can work together for IPv6 host configuration of
+   RDNSS.  This section shows a consideration on how these approaches
+   can interwork each other.
+
+   For ordering between RA and DHCP approaches, the O (Other stateful
+   configuration) flag in RA message can be used [8][32].  If no RDNSS
+   option is included, an IPv6 host may perform DNS configuration
+   through DHCPv6 [5]-[7] regardless of whether the O flag is set or
+   not.
+
+   The well-known anycast addresses approach fully interworks with the
+   other approaches.  That is, the other approaches can remove the
+   configuration effort on servers by using the well-known addresses as
+   the default configuration.  Moreover, the clients preconfigured with
+   the well-known anycast addresses can be further configured to use
+   other approaches to override the well-known addresses, if the
+   configuration information from other approaches is available.
+   Otherwise, all the clients need to have the well-known anycast
+   addresses preconfigured.  In order to use the anycast approach along
+   with two other approaches, there are three choices as follows:
+
+   1.  The first choice is that well-known addresses are used as last
+       resort, when an IPv6 host cannot get RDNSS information through RA
+       and DHCP.  The well-known anycast addresses have to be
+       preconfigured in all of IPv6 hosts' resolver configuration files.
+
+   2.  The second is that an IPv6 host can configure well-known
+       addresses as the most preferable in its configuration file even
+       though either an RA option or DHCP option is available.
+
+   3.  The last is that the well-known anycast addresses can be set in
+       RA or DHCP configuration to reduce the configuration effort of
+       users.  According to either the RA or DHCP mechanism, the well-
+       known addresses can be obtained by an IPv6 host.  Because this
+       approach is the most convenient for users, the last option is
+       recommended.
+
+
+Note
+
+   This section does not necessarily mean this document suggests
+   adopting all these three approaches and making them interwork in the
+   way described here.  In fact, some approaches may even not be adopted
+   at all as a result of further discussion.
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 15]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+5.  Deployment Scenarios
+
+   Regarding the DNS configuration on the IPv6 host, several mechanisms
+   are being considered at the DNSOP Working Group such as RA option,
+   DHCPv6 option and well-known preconfigured anycast addresses as of
+   today, and this document is a final result from the long thread.  In
+   this section, we suggest four applicable scenarios of three
+   approaches for IPv6 DNS configuration.
+
+Note
+
+   In the applicable scenarios, authors do not implicitly push any
+   specific approaches into the restricted environments.  No enforcement
+   is in each scenario and all mentioned scenarios are probable.  The
+   main objective of this work is to provide a useful guideline for IPv6
+   DNS configuration.
+
+5.1  ISP Network
+
+   A characteristic of ISP network is that multiple Customer Premises
+   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+   routers and each PE connects multiple CPE devices to the backbone
+   network infrastructure [13].  The CPEs may be hosts or routers.
+
+   In the case where the CPE is a router, there is a customer network
+   that is connected to the ISP backbone through the CPE.  Typically,
+   each customer network gets a different IPv6 prefix from an IPv6 PE
+   router, but the same RDNSS configuration will be distributed.
+
+   This section discusses how the different approaches to distributing
+   DNS information are compared in an ISP network.
+
+5.1.1  RA Option Approach
+
+   When the CPE is a host, the RA option for RDNSS can be used to allow
+   the CPE to get RDNSS information as well as /64 prefix information
+   for stateless address autoconfiguration at the same time when the
+   host is attached to a new subnet [8].  Because an IPv6 host must
+   receive at least one RA message for stateless address
+   autoconfiguration and router configuration, the host could receive
+   RDNSS configuration information in that RA without the overhead of an
+   additional message exchange.
+
+   When the CPE is a router, the CPE may accept the RDNSS information
+   from the RA on the interface connected to the ISP, and copy that
+   information into the RAs advertised in the customer network.
+
+   This approach is more valuable in the mobile host scenario, in which
+
+
+
+Jeong                   Expires November 6, 2005               [Page 16]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   the host must receive at least an RA message for detecting a new
+   network, than in other scenarios generally although administrator
+   should configure RDNSS information on the routers.  Secure ND [14]
+   can provide extended security when using RA messages.
+
+5.1.2  DHCPv6 Option Approach
+
+   DHCPv6 can be used for RDNSS configuration through the use of the DNS
+   option, and can provide other configuration information in the same
+   message with RDNSS configuration [5]-[7].  The DHCPv6 DNS option is
+   already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
+   stateless DHCP [6] is nowhere as complex as a full DHCPv6
+   implementation.  DHCP is a client-server model protocol, so ISPs can
+   handle user identification on its network intentionally, and also
+   authenticated DHCP [15] can be used for secure message exchange.
+
+   The expected model for deployment of IPv6 service by ISPs is to
+   assign a prefix to each customer, which will be used by the customer
+   gateway to assign a /64 prefix to each network in the customer's
+   network.  Prefix delegation with DHCP (DHCPv6 PD) has already been
+   adopted by ISPs for automating the assignment of the customer prefix
+   to the customer gateway [17].  DNS configuration can be carried in
+   the same DHCPv6 message exchange used for DHCPv6 to efficiently
+   provide that information, along with any other configuration
+   information needed by the customer gateway or customer network.  This
+   service model can be useful to Home or SOHO subscribers.  The Home or
+   SOHO gateway, which is a customer gateway for ISP, can then pass that
+   RDNSS configuration information to the hosts in the customer network
+   through DHCP.
+
+5.1.3  Well-known Anycast Addresses Approach
+
+   The well-known anycast addresses approach is also a feasible and
+   simple mechanism for ISP [9].  The use of well-known anycast
+   addresses avoids some of the security risks in rogue messages sent
+   through an external protocol like RA or DHCPv6.  The configuration of
+   hosts for the use of well-known anycast addresses requires no
+   protocol or manual configuration, but the configuration of routing
+   for the anycast addresses requires intervention on the part of the
+   network administrator.  Also, the number of special addresses would
+   be equal to the number of RDNSSes that could be made available to
+   subscribers.
+
+5.2  Enterprise Network
+
+   Enterprise network is defined as a network that has multiple internal
+   links, one or more router connections, to one or more Providers and
+   is actively managed by a network operations entity [16].  An
+
+
+
+Jeong                   Expires November 6, 2005               [Page 17]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   enterprise network can get network prefixes from an ISP by either
+   manual configuration or prefix delegation [17].  In most cases,
+   because an enterprise network manages its own DNS domains, it
+   operates its own DNS servers for the domains.  These DNS servers
+   within enterprise network process recursive DNS name resolution
+   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
+   enterprise network can be performed like in Section 4, in which three
+   approaches can be used together as follows:
+
+   1.  An IPv6 host can decide which approach is or may be used in its
+       subnet with the O flag in RA message [8][32].  As the first
+       choice in Section 4, well-known anycast addresses can be used as
+       a last resort when RDNSS information cannot be obtained through
+       either an RA option or DHCP option.  This case needs IPv6 hosts
+       to preconfigure the well-known anycast addresses in their DNS
+       configuration files.
+
+   2.  When the enterprise prefers the well-known anycast approach to
+       others, IPv6 hosts should preconfigure the well-known anycast
+       addresses like in the first choice.
+
+   3.  The last choice, a more convenient and transparent way, does not
+       need IPv6 hosts to preconfigure the well-known anycast addresses
+       because the addresses are delivered to IPv6 hosts via either the
+       RA option or DHCPv6 option as if they were unicast addresses.
+       This way is most recommended for the sake of user's convenience.
+
+
+5.3  3GPP Network
+
+   The IPv6 DNS configuration is a missing part of IPv6
+   autoconfiguration and an important part of the basic IPv6
+   functionality in the 3GPP User Equipment (UE).  The higher level
+   description of the 3GPP architecture can be found in [18], and
+   transition to IPv6 in 3GPP networks is analyzed in [19] and [20].
+
+   In the 3GPP architecture, there is a dedicated link between the UE
+   and the GGSN called the Packet Data Protocol (PDP) Context.  This
+   link is created through the PDP Context activation procedure [21].
+   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
+   3GPP UE user is communicating using IPv6 (having an active IPv6 PDP
+   context), it cannot be assumed that (s)he has simultaneously an
+   active IPv4 PDP context, and DNS queries could be done using IPv4.  A
+   3GPP UE can thus be an IPv6 node, and it needs to somehow discover
+   the address of the RDNSS.  Before IP-based services (e.g., web
+   browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses
+   need to be discovered in the 3GPP UE.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 18]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   Section 5.3.1 briefly summarizes currently available mechanisms in
+   3GPP networks and recommendations. 5.3.2 analyzes the Router
+   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
+   mechanism, and 5.3.4 analyzes the Well-known addresses approach.
+   Section 5.3.5 finally summarizes the recommendations.
+
+5.3.1  Currently Available Mechanisms and Recommendations
+
+   3GPP has defined a mechanism, in which RDNSS addresses can be
+   received in the PDP context activation (a control plane mechanism).
+   That is called the Protocol Configuration Options Information Element
+   (PCO-IE) mechanism [22].  The RDNSS addresses can also be received
+   over the air (using text messages), or typed in manually in the UE.
+   Note that the two last mechanisms are not very well scalable.  The UE
+   user most probably does not want to type IPv6 RDNSS addresses
+   manually in his/her UE.  The use of well-known addresses is briefly
+   discussed in section 5.3.4.
+
+   It is seen that the mechanisms above most probably are not sufficient
+   for the 3GPP environment.  IPv6 is intended to operate in a zero-
+   configuration manner, no matter what the underlying network
+   infrastructure is.  Typically, the RDNSS address is needed to make an
+   IPv6 node operational - and the DNS configuration should be as simple
+   as the address autoconfiguration mechanism.  It must also be noted
+   that there will be additional IP interfaces in some near future 3GPP
+   UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such
+   as PCO-IE [22]) do not work for those IP interfaces.  In other words,
+   a good IPv6 DNS configuration mechanism should also work in a multi-
+   access network environment.
+
+   From a 3GPP point of view, the best IPv6 DNS configuration solution
+   is feasible for a very large number of IPv6-capable UEs (can be even
+   hundreds of millions in one operator's network), is automatic and
+   thus requires no user action.  It is suggested to standardize a
+   lightweight, stateless mechanism that works in all network
+   environments.  The solution could then be used for 3GPP, 3GPP2, WLAN
+   and other access network technologies.  A light, stateless IPv6 DNS
+   configuration mechanism is thus not only needed in 3GPP networks, but
+   also 3GPP networks and UEs would certainly benefit from the new
+   mechanism.
+
+5.3.2  RA Extension
+
+   Router Advertisement extension [8] is a lightweight IPv6 DNS
+   configuration mechanism that requires minor changes in the 3GPP UE
+   IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
+   the 3GPP architecture) IPv6 stack.  This solution can be specified in
+   the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs
+
+
+
+Jeong                   Expires November 6, 2005               [Page 19]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   and GGSNs
+
+   In this solution, an IPv6-capable UE configures DNS information via
+   RA message sent by its default router (GGSN), i.e., RDNSS option for
+   recursive DNS server is included in the RA message.  This solution is
+   easily scalable for a very large number of UEs.  The operator can
+   configure the RDNSS addresses in the GGSN as a part of normal GGSN
+   configuration.  The IPv6 RDNSS address is received in the Router
+   Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS
+   addresses can be avoided.
+
+   If thinking about the cons, this mechanism still requires
+   standardization effort in the IETF, and the end nodes and routers
+   need to support this mechanism.  The equipment software update
+   should, however, be pretty straightforward, and new IPv6 equipment
+   could support RA extension already from the beginning.
+
+5.3.3  Stateless DHCPv6
+
+   DHCPv6-based solution needs the implementation of Stateless DHCP [6]
+   and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the
+   operator's network.  A possible configuration is such that the GGSN
+   works as a DHCP relay.
+
+   Pros for Stateless DHCPv6-based solution are
+
+   1.  Stateless DHCPv6 is a standardized mechanism.
+
+   2.  DHCPv6 can be used for receiving other configuration information
+       than RDNSS addresses, e.g., SIP server addresses.
+
+   3.  DHCPv6 works in different network environments.
+
+   4.  When DHCPv6 service is deployed through a single, centralized
+       server, the RDNSS configuration information can be updated by the
+       network administrator at a single source.
+
+   Some issues with DHCPv6 in 3GPP networks are listed below:
+
+   1.  DHCPv6 requires an additional server in the network unless the
+       (Stateless) DHCPv6 functionality is integrated into a router
+       already existing, and that means one box more to be maintained.
+
+   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+       (3GPP Stateless Address Autoconfiguration is typically used), and
+       not automatically implemented in 3GPP IPv6 UEs.
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 20]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   3.  Scalability and reliability of DHCPv6 in very large 3GPP networks
+       (with tens or hundreds of millions of UEs) may be an issue, at
+       least the redundancy needs to be taken care of.  However, if the
+       DHCPv6 service is integrated into the network elements, such as a
+       router operating system, scalability and reliability is
+       comparable with other DNS configuration approaches.
+
+   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
+       for DHCPv6 messages if there is a simpler alternative available.
+
+       *  The use of Stateless DHCPv6 adds one round trip delay to the
+          case in which the UE can start transmitting data right after
+          the Router Advertisement.
+
+   5.  If the DNS information (suddenly) changes, Stateless DHCPv6 can
+       not automatically update the UE, see [23].
+
+
+5.3.4  Well-known Addresses
+
+   Using well-known addresses is also a feasible and a light mechanism
+   for 3GPP UEs.  Those well-known addresses can be preconfigured in the
+   UE software and the operator makes the corresponding configuration on
+   the network side.  So this is a very easy mechanism for the UE, but
+   requires some configuration work in the network.  When using well-
+   known addresses, UE forwards queries to any of the preconfigured
+   addresses.  In the current proposal [9], IPv6 anycast addresses are
+   suggested.
+
+Note
+
+   The IPv6 DNS configuration proposal based on the use of well-known
+   site-local addresses developed at the IPv6 Working Group was seen as
+   a feasible mechanism for 3GPP UEs, but opposition by some people in
+   the IETF and finally deprecating IPv6 site-local addresses made it
+   impossible to standardize it.  Note that this mechanism is
+   implemented in some existing operating systems today (also in some
+   3GPP UEs) as a last resort of IPv6 DNS configuration.
+
+5.3.5  Recommendations
+
+   It is suggested that a lightweight, stateless DNS configuration
+   mechanism is specified as soon as possible.  From a 3GPP UE and
+   network point of view, the Router Advertisement based mechanism looks
+   most promising.  The sooner a light, stateless mechanism is
+   specified, the sooner we can get rid of using well-known site-local
+   addresses for IPv6 DNS configuration.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 21]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+5.4  Unmanaged Network
+
+   There are 4 deployment scenarios of interest in unmanaged networks
+   [24]:
+
+   1.  A gateway which does not provide IPv6 at all;
+
+   2.  A dual-stack gateway connected to a dual-stack ISP;
+
+   3.  A dual-stack gateway connected to an IPv4-only ISP; and
+
+   4.  A gateway connected to an IPv6-only ISP.
+
+
+5.4.1  Case A: Gateway does not provide IPv6 at all
+
+   In this case, the gateway does not provide IPv6; the ISP may or may
+   not provide IPv6.  Automatic or Configured tunnels are the
+   recommended transition mechanisms for this scenario.
+
+   The case where dual-stack hosts behind an NAT, that need access to an
+   IPv6 RDNSS, cannot be entirely ruled out.  The DNS configuration
+   mechanism has to work over the tunnel, and the underlying tunneling
+   mechanism could be implementing NAT traversal.  The tunnel server
+   assumes the role of a relay (both for DHCP and Well-known anycast
+   addresses approaches).
+
+   RA-based mechanism is relatively straightforward in its operation,
+   assuming the tunnel server is also the IPv6 router emitting RAs.
+   Well-known anycast addresses approach seems also simple in operation
+   across the tunnel, but the deployment model using Well-known anycast
+   addresses in a tunneled environment is unclear or not well
+   understood.
+
+5.4.2  Case B: A dual-stack gateway connected to a dual-stack ISP
+
+   This is similar to a typical IPv4 home user scenario, where DNS
+   configuration parameters are obtained using DHCP.  Except that
+   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
+   DHCP server is stateful (maintains the state for clients).
+
+5.4.3  Case C: A dual-stack gateway connected to an IPv4-only ISP
+
+   This is similar to Case B. If a gateway provides IPv6 connectivity by
+   managing tunnels, then it is also supposed to provide access to an
+   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
+   the dual-stack gateway instead of the host.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 22]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+5.4.4  Case D: A gateway connected to an IPv6-only ISP
+
+   This is similar to Case B.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 23]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+6.  Security Considerations
+
+   As security requirements depend solely on applications and are
+   different application by application, there can be no generic
+   requirement defined at IP or application layer for DNS.
+
+   However, it should be noted that cryptographic security requires
+   configured secret information that full autoconfiguration and
+   cryptographic security are mutually exclusive.  People insisting on
+   secure full autoconfiguration will get false security, false
+   autoconfiguration or both.
+
+   In some deployment scenarios [19], where cryptographic security is
+   required for applications, the secret information for the
+   cryptographic security is preconfigured through which application
+   specific configuration data, including those for DNS, can be securely
+   configured.  It should be noted that if applications requiring
+   cryptographic security depend on DNS, the applications also require
+   cryptographic security to DNS.  Therefore, the full autoconfiguration
+   of DNS is not acceptable.
+
+   However, with full autoconfiguration, weaker but still reasonable
+   security is being widely accepted and will continue to be acceptable.
+   That is, with full autoconfiguration, which means there is no
+   cryptographic security for the autoconfiguration, it is already
+   assumed that the local environment is secure enough that the
+   information from the local autoconfiguration server has acceptable
+   security even without cryptographic security.  Thus, the
+   communication between the local DNS client and local DNS server has
+   acceptable security.
+
+   In autoconfiguring recursive servers, DNSSEC may be overkill, because
+   DNSSEC [29] needs the configuration and reconfiguration of clients at
+   root key roll-over [30][31].  Even if additional keys for secure key
+   roll-over are added at the initial configuration, they are as
+   vulnerable as the original keys to some forms of attacks, such as
+   social hacking.  Another problem of using DNSSEC and
+   autoconfiguration together is that DNSSEC requires secure time, which
+   means secure communication with autoconfigured time servers, which
+   requires configured secret information.  Therefore, in order that the
+   autoconfiguration may be secure, it requires configured secret
+   information.
+
+   If DNSSEC [29] is used and the signatures are verified on the client
+   host, the misconfiguration of a DNS server may be simply denial of
+   service.  Also, if local routing environment is not reliable, clients
+   may be directed to a false resolver with the same IP address as the
+   true one.
+
+
+
+Jeong                   Expires November 6, 2005               [Page 24]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+6.1  RA Option
+
+   The security of RA option for RDNSS is the same as the ND protocol
+   security [3][8].  The RA option does not add any new vulnerability.
+
+   It should be noted that the vulnerability of ND is not worse and is a
+   subset of the attacks that any node attached to a LAN can do
+   independently of ND.  A malicious node on a LAN can promiscuously
+   receive packets for any router's MAC address and send packets with
+   the router's MAC address as the source MAC address in the L2 header.
+   As a result, the L2 switches send packets addressed to the router to
+   the malicious node.  Also, this attack can send redirects that tell
+   the hosts to send their traffic somewhere else.  The malicious node
+   can send unsolicited RA or NA replies, answer RS or NS requests, etc.
+   All of this can be done independently of implementing ND.  Therefore,
+   the RA option for RDNSS does not add to the vulnerability.
+
+   Security issues regarding the ND protocol were discussed at IETF SEND
+   (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
+   security has been published [14].
+
+6.2  DHCPv6 Option
+
+   The DNS Recursive Name Server option may be used by an intruder DHCP
+   server to cause DHCP clients to send DNS queries to an intruder DNS
+   recursive name server [7].  The results of these misdirected DNS
+   queries may be used to spoof DNS names.
+
+   To avoid attacks through the DNS Recursive Name Server option, the
+   DHCP client SHOULD require DHCP authentication (see section
+   "Authentication of DHCP messages" in RFC 3315 [5]) before installing
+   a list of DNS recursive name servers obtained through authenticated
+   DHCP.
+
+6.3  Well-known Anycast Addresses
+
+   Well-known anycast addresses does not require configuration security
+   since there is no protocol [9].
+
+   The DNS server with the preconfigured addresses are still reasonably
+   reliable, if local environment is reasonably secure, that is, there
+   is no active attackers receiving queries to the anycast addresses of
+   the servers and reply to them.
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 25]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+7.  Contributors
+
+   Ralph Droms
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxboro, MA  01719
+   US
+
+   Phone: +1 978 936 1674
+   Email: rdroms@cisco.com
+
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA  94043
+   US
+
+   Phone: +1 650 625 2004
+   Email: bob.hinden@nokia.com
+
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA  94043
+   US
+
+   Email: Ted.Lemon@nominum.com
+
+
+   Masataka Ohta
+   Tokyo Institute of Technology
+   2-12-1, O-okayama, Meguro-ku
+   Tokyo  152-8552
+   Japan
+
+   Phone: +81 3 5734 3299
+   Fax:   +81 3 5734 3299
+   Email: mohta@necom830.hpcl.titech.ac.jp
+
+
+   Soohong Daniel Park
+   Mobile Platform Laboratory, SAMSUNG Electronics
+   416 Maetan-3dong, Yeongtong-Gu
+   Suwon, Gyeonggi-Do  443-742
+   Korea
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 26]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   Phone: +82 31 200 4508
+   Email: soohong.park@samsung.com
+
+
+   Suresh Satapati
+   Cisco Systems, Inc.
+   San Jose, CA  95134
+   US
+
+   Email: satapati@cisco.com
+
+
+   Juha Wiljakka
+   Nokia
+   Visiokatu 3
+   FIN-33720, TAMPERE
+   Finland
+
+   Phone: +358 7180 48372
+   Email: juha.wiljakka@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 27]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+8.  Acknowledgements
+
+   This draft has greatly benefited from inputs by David Meyer, Rob
+   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
+   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
+   Also, Tony Bonanno proofread this draft.  The authors appreciate
+   their contribution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 28]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+9.  References
+
+9.1  Normative References
+
+   [1]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
+        February 2004.
+
+   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
+        RFC 3668, February 2004.
+
+   [3]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+        for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [4]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+        Autoconfiguration", RFC 2462, December 1998.
+
+   [5]  Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
+        (DHCPv6)", RFC 3315, July 2003.
+
+   [6]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
+        Service for IPv6", RFC 3736, April 2004.
+
+   [7]  Droms, R., Ed., "DNS Configuration options for Dynamic Host
+        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+        December 2003.
+
+9.2  Informative References
+
+   [8]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS
+         Discovery based on Router Advertisement",
+         draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress),
+         February 2005.
+
+   [9]   Ohta, M., "Preconfigured DNS Server Addresses",
+         draft-ohta-preconfigured-dns-01.txt (Work in Progress),
+         February 2004.
+
+   [10]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
+         Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in
+         Progress), January 2005.
+
+   [11]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+         Service", RFC 1546, November 1993.
+
+   [12]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+         Addressing Architecture", RFC 3513, April 2003.
+
+   [13]  Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6
+
+
+
+Jeong                   Expires November 6, 2005               [Page 29]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+         into ISP Networks", RFC 4029, March 2005.
+
+   [14]  Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971,
+         March 2005.
+
+   [15]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+         RFC 3118, June 2001.
+
+   [16]  Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
+         draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress),
+         July 2004.
+
+   [17]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+         Configuration Protocol (DHCP) version 6", RFC 3633,
+         December 2003.
+
+   [18]  Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP
+         Standards", RFC 3314, September 2002.
+
+   [19]  Soininen, J., Ed., "Transition Scenarios for 3GPP Networks",
+         RFC 3574, August 2003.
+
+   [20]  Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP
+         Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in
+         Progress), October 2004.
+
+   [21]  3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
+         Service description; Stage 2 (Release 5)", December 2002.
+
+   [22]  3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+         specification; Core network protocols; Stage 3 (Release 5)",
+         June 2003.
+
+   [23]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
+         Requirements for Stateless DHCPv6",
+         draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in
+         Progress), October 2004.
+
+   [24]  Huitema, C., Ed., "Unmanaged Networks IPv6 Transition
+         Scenarios", RFC 3750, April 2004.
+
+   [25]  ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
+         Control (MAC) and Physical Layer (PHY) Specifications",
+         March 1999.
+
+   [26]  IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
+         (MAC) and Physical Layer (PHY) specifications: High-speed
+         Physical Layer in the 5 GHZ Band", September 1999.
+
+
+
+Jeong                   Expires November 6, 2005               [Page 30]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+   [27]  IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
+         (MAC) and Physical Layer (PHY) specifications: Higher-Speed
+         Physical Layer Extension in the 2.4 GHz Band", September 1999.
+
+   [28]  IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
+         Control (MAC) and Physical Layer (PHY) specifications: Further
+         Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
+
+   [29]  Eastlake, D., "Domain Name System Security Extensions",
+         RFC 2535, March 1999.
+
+   [30]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+         draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in
+         Progress), December 2004.
+
+   [31]  Guette, G. and O. Courtay, "Requirements for Automated Key
+         Rollover in DNSSEC",
+         draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in
+         Progress), January 2005.
+
+   [32]  Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
+         and O Flags of IPv6 Router Advertisement",
+         draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress),
+         March 2005.
+
+
+Author's Address
+
+   Jaehoon Paul Jeong (editor)
+   ETRI/Department of Computer Science and Engineering
+   University of Minnesota
+   117 Pleasant Street SE
+   Minneapolis, MN  55455
+   US
+
+   Phone: +1 651 587 7774
+   Fax:   +1 612 625 2002
+   Email: jjeong@cs.umn.edu
+   URI:   http://www.cs.umn.edu/~jjeong/
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 31]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+Appendix A.  Link-layer Multicast Acknowledgements for RA Option
+
+   One benefit of an RA option [8] is to be able to multicast the
+   advertisements, reducing the need for duplicated unicast
+   communications.
+
+   However, some link-layers may not support this as well as others.
+   Consider, for example, WLAN networks where multicast is unreliable.
+   The unreliability problem is caused by lack of ACK for multicast,
+   especially on the path from the Access Point (AP) to the Station
+   (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11
+   a/b/g [25]-[28].  That is, a multicast packet is unacknowledged on
+   the path from the AP to the STA, but acknowledged in the reverse
+   direction from the STA to the AP [25].  For example, when a router is
+   placed at wired network connected to an AP, a host may sometimes not
+   receive RA message advertised through the AP.  Therefore, the RA
+   option solution might not work well on a congested medium that uses
+   unreliable multicast for RA.
+
+   The fact that this problem has not been addressed in Neighbor
+   Discovery [3] indicates that the extra link-layer acknowledgements
+   have not been considered a serious problem till now.
+
+   A possible mitigation technique could be to map all-nodes link- local
+   multicast address to the link-layer broadcast address, and to rely on
+   the ND retransmissions for message delivery in order to achieve more
+   reliability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 32]
+
+Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Jeong                   Expires November 6, 2005               [Page 33]
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
new file mode 100644
index 0000000..1276f9f
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
@@ -0,0 +1,1682 @@
+
+
+
+
+DNS Operations WG                                              A. Durand
+Internet-Draft                                    SUN Microsystems, Inc.
+Expires: January 17, 2006                                       J. Ihren
+                                                              Autonomica
+                                                               P. Savola
+                                                               CSC/FUNET
+                                                           July 16, 2005
+
+
+          Operational Considerations and Issues with IPv6 DNS
+                draft-ietf-dnsop-ipv6-dns-issues-11.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 17, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This memo presents operational considerations and issues with IPv6
+   Domain Name System (DNS), including a summary of special IPv6
+   addresses, documentation of known DNS implementation misbehaviour,
+   recommendations and considerations on how to perform DNS naming for
+   service provisioning and for DNS resolver IPv6 support,
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 1]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   considerations for DNS updates for both the forward and reverse
+   trees, and miscellaneous issues.  This memo is aimed to include a
+   summary of information about IPv6 DNS considerations for those who
+   have experience with IPv4 DNS.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1   Representing IPv6 Addresses in DNS Records . . . . . . . .  4
+     1.2   Independence of DNS Transport and DNS Records  . . . . . .  4
+     1.3   Avoiding IPv4/IPv6 Name Space Fragmentation  . . . . . . .  5
+     1.4   Query Type '*' and A/AAAA Records  . . . . . . . . . . . .  5
+   2.  DNS Considerations about Special IPv6 Addresses  . . . . . . .  5
+     2.1   Limited-scope Addresses  . . . . . . . . . . . . . . . . .  6
+     2.2   Temporary Addresses  . . . . . . . . . . . . . . . . . . .  6
+     2.3   6to4 Addresses . . . . . . . . . . . . . . . . . . . . . .  6
+     2.4   Other Transition Mechanisms  . . . . . . . . . . . . . . .  6
+   3.  Observed DNS Implementation Misbehaviour . . . . . . . . . . .  7
+     3.1   Misbehaviour of DNS Servers and Load-balancers . . . . . .  7
+     3.2   Misbehaviour of DNS Resolvers  . . . . . . . . . . . . . .  7
+   4.  Recommendations for Service Provisioning using DNS . . . . . .  7
+     4.1   Use of Service Names instead of Node Names . . . . . . . .  8
+     4.2   Separate vs the Same Service Names for IPv4 and IPv6 . . .  8
+     4.3   Adding the Records Only when Fully IPv6-enabled  . . . . .  9
+     4.4   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
+       4.4.1   TTL With Courtesy Additional Data  . . . . . . . . . . 10
+       4.4.2   TTL With Critical Additional Data  . . . . . . . . . . 10
+     4.5   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 11
+   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 11
+     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
+     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 13
+     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 13
+   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 13
+     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
+     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 14
+   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 15
+     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
+     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
+     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 16
+     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
+     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 18
+   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
+     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 19
+     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 19
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
+   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
+   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
+     11.1  Normative References . . . . . . . . . . . . . . . . . . . 20
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 2]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+     11.2  Informative References . . . . . . . . . . . . . . . . . . 22
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
+   A.  Unique Local Addressing Considerations for DNS . . . . . . . . 25
+   B.  Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
+     B.1   Description of Additional Data Scenarios . . . . . . . . . 26
+     B.2   Which Additional Data to Keep, If Any? . . . . . . . . . . 27
+     B.3   Discussion of the Potential Problems . . . . . . . . . . . 28
+       Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 3]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+1.  Introduction
+
+   This memo presents operational considerations and issues with IPv6
+   DNS; it is meant to be an extensive summary and a list of pointers
+   for more information about IPv6 DNS considerations for those with
+   experience with IPv4 DNS.
+
+   The purpose of this document is to give information about various
+   issues and considerations related to DNS operations with IPv6; it is
+   not meant to be a normative specification or standard for IPv6 DNS.
+
+   The first section gives a brief overview of how IPv6 addresses and
+   names are represented in the DNS, how transport protocols and
+   resource records (don't) relate, and what IPv4/IPv6 name space
+   fragmentation means and how to avoid it; all of these are described
+   at more length in other documents.
+
+   The second section summarizes the special IPv6 address types and how
+   they relate to DNS.  The third section describes observed DNS
+   implementation misbehaviours which have a varying effect on the use
+   of IPv6 records with DNS.  The fourth section lists recommendations
+   and considerations for provisioning services with DNS.  The fifth
+   section in turn looks at recommendations and considerations about
+   providing IPv6 support in the resolvers.  The sixth and seventh
+   sections describe considerations with forward and reverse DNS
+   updates, respectively.  The eighth section introduces several
+   miscellaneous IPv6 issues relating to DNS for which no better place
+   has been found in this memo.  Appendix A looks briefly at the
+   requirements for unique local addressing.
+
+1.1  Representing IPv6 Addresses in DNS Records
+
+   In the forward zones, IPv6 addresses are represented using AAAA
+   records.  In the reverse zones, IPv6 address are represented using
+   PTR records in the nibble format under the ip6.arpa. tree.  See
+   [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
+   for background information.
+
+   In particular one should note that the use of A6 records in the
+   forward tree or Bitlabels in the reverse tree is not recommended
+   [RFC3363].  Using DNAME records is not recommended in the reverse
+   tree in conjunction with A6 records; the document did not mean to
+   take a stance on any other use of DNAME records [RFC3364].
+
+1.2  Independence of DNS Transport and DNS Records
+
+   DNS has been designed to present a single, globally unique name space
+   [RFC2826].  This property should be maintained, as described here and
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 4]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   in Section 1.3.
+
+   The IP version used to transport the DNS queries and responses is
+   independent of the records being queried: AAAA records can be queried
+   over IPv4, and A records over IPv6.  The DNS servers must not make
+   any assumptions about what data to return for Answer and Authority
+   sections based on the underlying transport used in a query.
+
+   However, there is some debate whether the addresses in Additional
+   section could be selected or filtered using hints obtained from which
+   transport was being used; this has some obvious problems because in
+   many cases the transport protocol does not correlate with the
+   requests, and because a "bad" answer is in a way worse than no answer
+   at all (consider the case where the client is led to believe that a
+   name received in the additional record does not have any AAAA records
+   at all).
+
+   As stated in [RFC3596]:
+
+      The IP protocol version used for querying resource records is
+      independent of the protocol version of the resource records; e.g.,
+      IPv4 transport can be used to query IPv6 records and vice versa.
+
+
+1.3  Avoiding IPv4/IPv6 Name Space Fragmentation
+
+   To avoid the DNS name space from fragmenting into parts where some
+   parts of DNS are only visible using IPv4 (or IPv6) transport, the
+   recommendation is to always keep at least one authoritative server
+   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
+   See DNS IPv6 transport guidelines [RFC3901] for more information.
+
+1.4  Query Type '*' and A/AAAA Records
+
+   QTYPE=* is typically only used for debugging or management purposes;
+   it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
+   any available RRsets, not *all* the RRsets, because the caches do not
+   necessarily have all the RRsets and have no way of guaranteeing that
+   they have all the RRsets.  Therefore, to get both A and AAAA records
+   reliably, two separate queries must be made.
+
+2.  DNS Considerations about Special IPv6 Addresses
+
+   There are a couple of IPv6 address types which are somewhat special;
+   these are considered here.
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 5]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+2.1  Limited-scope Addresses
+
+   The IPv6 addressing architecture [RFC3513] includes two kinds of
+   local-use addresses: link-local (fe80::/10) and site-local
+   (fec0::/10).  The site-local addresses have been deprecated [RFC3879]
+   but are discussed with unique local addresses in Appendix A.
+
+   Link-local addresses should never be published in DNS (whether in
+   forward or reverse tree), because they have only local (to the
+   connected link) significance [I-D.durand-dnsop-dont-publish].
+
+2.2  Temporary Addresses
+
+   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
+   "privacy addresses") use a random number as the interface identifier.
+   Having DNS AAAA records that are updated to always contain the
+   current value of a node's temporary address would defeat the purpose
+   of the mechanism and is not recommended.  However, it would still be
+   possible to return a non-identifiable name (e.g., the IPv6 address in
+   hexadecimal format), as described in [RFC3041].
+
+2.3  6to4 Addresses
+
+   6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
+   a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
+
+   If the reverse DNS population would be desirable (see Section 7.1 for
+   applicability), there are a number of possible ways to do so.
+
+   The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
+   autonomous reverse-delegation system that anyone being capable of
+   communicating using a specific 6to4 address would be able to set up a
+   reverse delegation to the corresponding 6to4 prefix.  This could be
+   deployed by e.g., Regional Internet Registries (RIRs).  This is a
+   practical solution, but may have some scalability concerns.
+
+2.4  Other Transition Mechanisms
+
+   6to4 is mentioned as a case of an IPv6 transition mechanism requiring
+   special considerations.  In general, mechanisms which include a
+   special prefix may need a custom solution; otherwise, for example
+   when IPv4 address is embedded as the suffix or not embedded at all,
+   special solutions are likely not needed.
+
+   Note that it does not seem feasible to provide reverse DNS with
+   another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
+   teredo]; this is because the IPv6 address is based on the IPv4
+   address and UDP port of the current NAT mapping which is likely to be
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 6]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   relatively short-lived.
+
+3.  Observed DNS Implementation Misbehaviour
+
+   Several classes of misbehaviour in DNS servers, load-balancers and
+   resolvers have been observed.  Most of these are rather generic, not
+   only applicable to IPv6 -- but in some cases, the consequences of
+   this misbehaviour are extremely severe in IPv6 environments and
+   deserve to be mentioned.
+
+3.1  Misbehaviour of DNS Servers and Load-balancers
+
+   There are several classes of misbehaviour in certain DNS servers and
+   load-balancers which have been noticed and documented [RFC4074]: some
+   implementations silently drop queries for unimplemented DNS records
+   types, or provide wrong answers to such queries (instead of a proper
+   negative reply).  While typically these issues are not limited to
+   AAAA records, the problems are aggravated by the fact that AAAA
+   records are being queried instead of (mainly) A records.
+
+   The problems are serious because when looking up a DNS name, typical
+   getaddrinfo() implementations, with AF_UNSPEC hint given, first try
+   to query the AAAA records of the name, and after receiving a
+   response, query the A records.  This is done in a serial fashion --
+   if the first query is never responded to (instead of properly
+   returning a negative answer), significant timeouts will occur.
+
+   In consequence, this is an enormous problem for IPv6 deployments, and
+   in some cases, IPv6 support in the software has even been disabled
+   due to these problems.
+
+   The solution is to fix or retire those misbehaving implementations,
+   but that is likely not going to be effective.  There are some
+   possible ways to mitigate the problem, e.g., by performing the
+   lookups somewhat in parallel and reducing the timeout as long as at
+   least one answer has been received; but such methods remain to be
+   investigated; slightly more on this is included in Section 5.
+
+3.2  Misbehaviour of DNS Resolvers
+
+   Several classes of misbehaviour have also been noticed in DNS
+   resolvers [I-D.ietf-dnsop-bad-dns-res].  However, these do not seem
+   to directly impair IPv6 use, and are only referred to for
+   completeness.
+
+4.  Recommendations for Service Provisioning using DNS
+
+   When names are added in the DNS to facilitate a service, there are
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 7]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   several general guidelines to consider to be able to do it as
+   smoothly as possible.
+
+4.1  Use of Service Names instead of Node Names
+
+   It makes sense to keep information about separate services logically
+   separate in the DNS by using a different DNS hostname for each
+   service.  There are several reasons for doing this, for example:
+
+   o  It allows more flexibility and ease for migration of (only a part
+      of) services from one node to another,
+
+   o  It allows configuring different properties (e.g., TTL) for each
+      service, and
+
+   o  It allows deciding separately for each service whether to publish
+      the IPv6 addresses or not (in cases where some services are more
+      IPv6-ready than others).
+
+   Using SRV records [RFC2782] would avoid these problems.
+   Unfortunately, those are not sufficiently widely used to be
+   applicable in most cases.  Hence an operation technique is to use
+   service names instead of node names (or, "hostnames").  This
+   operational technique is not specific to IPv6, but required to
+   understand the considerations described in Section 4.2 and
+   Section 4.3.
+
+   For example, assume a node named "pobox.example.com" provides both
+   SMTP and IMAP service.  Instead of configuring the MX records to
+   point at "pobox.example.com", and configuring the mail clients to
+   look up the mail via IMAP from "pobox.example.com", one could use
+   e.g., "smtp.example.com" for SMTP (for both message submission and
+   mail relaying between SMTP servers) and "imap.example.com" for IMAP.
+   Note that in the specific case of SMTP relaying, the server itself
+   must typically also be configured to know all its names to ensure
+   loops do not occur.  DNS can provide a layer of indirection between
+   service names and where the service actually is, and using which
+   addresses.  (Obviously, when wanting to reach a specific node, one
+   should use the hostname rather than a service name.)
+
+4.2  Separate vs the Same Service Names for IPv4 and IPv6
+
+   The service naming can be achieved in basically two ways: when a
+   service is named "service.example.com" for IPv4, the IPv6-enabled
+   service could either be added to "service.example.com", or added
+   separately under a different name, e.g., in a sub-domain, like,
+   "service.ipv6.example.com".
+
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 8]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   These two methods have different characteristics.  Using a different
+   name allows for easier service piloting, minimizing the disturbance
+   to the "regular" users of IPv4 service; however, the service would
+   not be used transparently, without the user/application explicitly
+   finding it and asking for it -- which would be a disadvantage in most
+   cases.  When the different name is under a sub-domain, if the
+   services are deployed within a restricted network (e.g., inside an
+   enterprise), it's possible to prefer them transparently, at least to
+   a degree, by modifying the DNS search path; however, this is a
+   suboptimal solution.  Using the same service name is the "long-term"
+   solution, but may degrade performance for those clients whose IPv6
+   performance is lower than IPv4, or does not work as well (see
+   Section 4.3 for more).
+
+   In most cases, it makes sense to pilot or test a service using
+   separate service names, and move to the use of the same name when
+   confident enough that the service level will not degrade for the
+   users unaware of IPv6.
+
+4.3  Adding the Records Only when Fully IPv6-enabled
+
+   The recommendation is that AAAA records for a service should not be
+   added to the DNS until all of following are true:
+
+   1.  The address is assigned to the interface on the node.
+
+   2.  The address is configured on the interface.
+
+   3.  The interface is on a link which is connected to the IPv6
+       infrastructure.
+
+   In addition, if the AAAA record is added for the node, instead of
+   service as recommended, all the services of the node should be IPv6-
+   enabled prior to adding the resource record.
+
+   For example, if an IPv6 node is isolated from an IPv6 perspective
+   (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
+   that it should not have an address in the DNS.
+
+   Consider the case of two dual-stack nodes, which both have IPv6
+   enabled, but the server does not have (global) IPv6 connectivity.  As
+   the client looks up the server's name, only A records are returned
+   (if the recommendations above are followed), and no IPv6
+   communication, which would have been unsuccessful, is even attempted.
+
+   The issues are not always so black-and-white.  Usually it's important
+   that the service offered using both protocols is of roughly equal
+   quality, using the appropriate metrics for the service (e.g.,
+
+
+
+Durand, et al.          Expires January 17, 2006                [Page 9]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   latency, throughput, low packet loss, general reliability, etc.) --
+   this is typically very important especially for interactive or real-
+   time services.  In many cases, the quality of IPv6 connectivity may
+   not yet be equal to that of IPv4, at least globally -- this has to be
+   taken into consideration when enabling services.
+
+4.4  The Use of TTL for IPv4 and IPv6 RRs
+
+   The behaviour of DNS caching when different TTL values are used for
+   different RRsets of the same name calls for explicit discussion.  For
+   example, let's consider two unrelated zone fragments:
+
+      example.com.        300    IN    MX     foo.example.com.
+      foo.example.com.    300    IN    A      192.0.2.1
+      foo.example.com.    100    IN    AAAA   2001:db8::1
+
+   ...
+
+      child.example.com.    300  IN    NS     ns.child.example.com.
+      ns.child.example.com. 300  IN    A      192.0.2.1
+      ns.child.example.com. 100  IN    AAAA   2001:db8::1
+
+   In the former case, we have "courtesy" additional data; in the
+   latter, we have "critical" additional data.  See more extensive
+   background discussion of additional data handling in Appendix B.
+
+4.4.1  TTL With Courtesy Additional Data
+
+   When a caching resolver asks for the MX record of example.com, it
+   gets back "foo.example.com".  It may also get back either one or both
+   of the A and AAAA records in the additional section.  The resolver
+   must explicitly query for both A and AAAA records [RFC2821].
+
+   After 100 seconds, the AAAA record is removed from the cache(s)
+   because its TTL expired.  It could be argued to be useful for the
+   caching resolvers to discard the A record when the shorter TTL (in
+   this case, for the AAAA record) expires; this would avoid the
+   situation where there would be a window of 200 seconds when
+   incomplete information is returned from the cache.  Further argument
+   for discarding is that in the normal operation, the TTL values are so
+   high that very likely the incurred additional queries would not be
+   noticeable, compared to the obtained performance optimization.  The
+   behaviour in this scenario is unspecified.
+
+4.4.2  TTL With Critical Additional Data
+
+   The difference to courtesy additional data is that the A/AAAA records
+   served by the parent zone cannot be queried explicitly.  Therefore
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 10]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   after 100 seconds the AAAA record is removed from the cache(s), but
+   the A record remains.  Queries for the remaining 200 seconds
+   (provided that there are no further queries from the parent which
+   could refresh the caches) only return the A record, leading to a
+   potential opererational situation with unreachable servers.
+
+   Similar cache flushing strategies apply in this scenario; the record.
+
+4.5  IPv6 Transport Guidelines for DNS Servers
+
+   As described in Section 1.3 and [RFC3901], there should continue to
+   be at least one authoritative IPv4 DNS server for every zone, even if
+   the zone has only IPv6 records.  (Note that obviously, having more
+   servers with robust connectivity would be preferable, but this is the
+   minimum recommendation; also see [RFC2182].)
+
+5.  Recommendations for DNS Resolver IPv6 Support
+
+   When IPv6 is enabled on a node, there are several things to consider
+   to ensure that the process is as smooth as possible.
+
+5.1  DNS Lookups May Query IPv6 Records Prematurely
+
+   The system library that implements the getaddrinfo() function for
+   looking up names is a critical piece when considering the robustness
+   of enabling IPv6; it may come in basically three flavours:
+
+   1.  The system library does not know whether IPv6 has been enabled in
+       the kernel of the operating system: it may start looking up AAAA
+       records with getaddrinfo() and AF_UNSPEC hint when the system is
+       upgraded to a system library version which supports IPv6.
+
+   2.  The system library might start to perform IPv6 queries with
+       getaddrinfo() only when IPv6 has been enabled in the kernel.
+       However, this does not guarantee that there exists any useful
+       IPv6 connectivity (e.g., the node could be isolated from the
+       other IPv6 networks, only having link-local addresses).
+
+   3.  The system library might implement a toggle which would apply
+       some heuristics to the "IPv6-readiness" of the node before
+       starting to perform queries; for example, it could check whether
+       only link-local IPv6 address(es) exists, or if at least one
+       global IPv6 address exists.
+
+   First, let us consider generic implications of unnecessary queries
+   for AAAA records: when looking up all the records in the DNS, AAAA
+   records are typically tried first, and then A records.  These are
+   done in serial, and the A query is not performed until a response is
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 11]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   received to the AAAA query.  Considering the misbehaviour of DNS
+   servers and load-balancers, as described in Section 3.1, the look-up
+   delay for AAAA may incur additional unnecessary latency, and
+   introduce a component of unreliability.
+
+   One option here could be to do the queries partially in parallel; for
+   example, if the final response to the AAAA query is not received in
+   0.5 seconds, start performing the A query while waiting for the
+   result (immediate parallelism might be unoptimal, at least without
+   information sharing between the look-up threads, as that would
+   probably lead to duplicate non-cached delegation chain lookups).
+
+   An additional concern is the address selection, which may, in some
+   circumstances, prefer AAAA records over A records even when the node
+   does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
+   In some cases, the implementation may attempt to connect or send a
+   datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
+   incurring very long protocol timeouts, instead of quickly failing
+   back to IPv4.
+
+   Now, we can consider the issues specific to each of the three
+   possibilities:
+
+   In the first case, the node performs a number of completely useless
+   DNS lookups as it will not be able to use the returned AAAA records
+   anyway.  (The only exception is where the application desires to know
+   what's in the DNS, but not use the result for communication.)  One
+   should be able to disable these unnecessary queries, for both latency
+   and reliability reasons.  However, as IPv6 has not been enabled, the
+   connections to IPv6 addresses fail immediately, and if the
+   application is programmed properly, the application can fall
+   gracefully back to IPv4 [RFC4038].
+
+   The second case is similar to the first, except it happens to a
+   smaller set of nodes when IPv6 has been enabled but connectivity has
+   not been provided yet; similar considerations apply, with the
+   exception that IPv6 records, when returned, will be actually tried
+   first which may typically lead to long timeouts.
+
+   The third case is a bit more complex: optimizing away the DNS lookups
+   with only link-locals is probably safe (but may be desirable with
+   different lookup services which getaddrinfo() may support), as the
+   link-locals are typically automatically generated when IPv6 is
+   enabled, and do not indicate any form of IPv6 connectivity.  That is,
+   performing DNS lookups only when a non-link-local address has been
+   configured on any interface could be beneficial -- this would be an
+   indication that either the address has been configured either from a
+   router advertisement, DHCPv6 [RFC3315], or manually.  Each would
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 12]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   indicate at least some form of IPv6 connectivity, even though there
+   would not be guarantees of it.
+
+   These issues should be analyzed at more depth, and the fixes found
+   consensus on, perhaps in a separate document.
+
+5.2  Obtaining a List of DNS Recursive Resolvers
+
+   In scenarios where DHCPv6 is available, a host can discover a list of
+   DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
+   option [RFC3646].  This option can be passed to a host through a
+   subset of DHCPv6 [RFC3736].
+
+   The IETF is considering the development of alternative mechanisms for
+   obtaining the list of DNS recursive name servers when DHCPv6 is
+   unavailable or inappropriate.  No decision about taking on this
+   development work has been reached as of this writing (Aug 2004)
+   [I-D.ietf-dnsop-ipv6-dns-configuration].
+
+   In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
+   under consideration for development include the use of well-known
+   addresses [I-D.ohta-preconfigured-dns] and the use of Router
+   Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
+   discovery].
+
+   Note that even though IPv6 DNS resolver discovery is a recommended
+   procedure, it is not required for dual-stack nodes in dual-stack
+   networks as IPv6 DNS records can be queried over IPv4 as well as
+   IPv6.  Obviously, nodes which are meant to function without manual
+   configuration in IPv6-only networks must implement the DNS resolver
+   discovery function.
+
+5.3  IPv6 Transport Guidelines for Resolvers
+
+   As described in Section 1.3 and [RFC3901], the recursive resolvers
+   should be IPv4-only or dual-stack to be able to reach any IPv4-only
+   DNS server.  Note that this requirement is also fulfilled by an IPv6-
+   only stub resolver pointing to a dual-stack recursive DNS resolver.
+
+6.  Considerations about Forward DNS Updating
+
+   While the topic of how to enable updating the forward DNS, i.e., the
+   mapping from names to the correct new addresses, is not specific to
+   IPv6, it should be considered especially due to the advent of
+   Stateless Address Autoconfiguration [RFC2462].
+
+   Typically forward DNS updates are more manageable than doing them in
+   the reverse DNS, because the updater can often be assumed to "own" a
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 13]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   certain DNS name -- and we can create a form of security relationship
+   with the DNS name and the node which is allowed to update it to point
+   to a new address.
+
+   A more complex form of DNS updates -- adding a whole new name into a
+   DNS zone, instead of updating an existing name -- is considered out
+   of scope for this memo as it could require zone-wide authentication.
+   Adding a new name in the forward zone is a problem which is still
+   being explored with IPv4, and IPv6 does not seem to add much new in
+   that area.
+
+6.1  Manual or Custom DNS Updates
+
+   The DNS mappings can also be maintained by hand, in a semi-automatic
+   fashion or by running non-standardized protocols.  These are not
+   considered at more length in this memo.
+
+6.2  Dynamic DNS
+
+   Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
+   mechanism for dynamically updating the DNS.  It works equally well
+   with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
+   address configuration.  It is important to consider how each of these
+   behave if IP address-based authentication, instead of stronger
+   mechanisms [RFC3007], was used in the updates.
+
+   1.  manual addresses are static and can be configured
+
+   2.  DHCPv6 addresses could be reasonably static or dynamic, depending
+       on the deployment, and could or could not be configured on the
+       DNS server for the long term
+
+   3.  SLAAC addresses are typically stable for a long time, but could
+       require work to be configured and maintained.
+
+   As relying on IP addresses for Dynamic DNS is rather insecure at
+   best, stronger authentication should always be used; however, this
+   requires that the authorization keying will be explicitly configured
+   using unspecified operational methods.
+
+   Note that with DHCP it is also possible that the DHCP server updates
+   the DNS, not the host.  The host might only indicate in the DHCP
+   exchange which hostname it would prefer, and the DHCP server would
+   make the appropriate updates.  Nonetheless, while this makes setting
+   up a secure channel between the updater and the DNS server easier, it
+   does not help much with "content" security, i.e., whether the
+   hostname was acceptable -- if the DNS server does not include
+   policies, they must be included in the DHCP server (e.g., a regular
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 14]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   host should not be able to state that its name is "www.example.com").
+   DHCP-initiated DDNS updates have been extensively described in
+   [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
+   [I-D.ietf-dnsext-dhcid-rr].
+
+   The nodes must somehow be configured with the information about the
+   servers where they will attempt to update their addresses, sufficient
+   security material for authenticating themselves to the server, and
+   the hostname they will be updating.  Unless otherwise configured, the
+   first could be obtained by looking up the authoritative name servers
+   for the hostname; the second must be configured explicitly unless one
+   chooses to trust the IP address-based authentication (not a good
+   idea); and lastly, the nodename is typically pre-configured somehow
+   on the node, e.g., at install time.
+
+   Care should be observed when updating the addresses not to use longer
+   TTLs for addresses than are preferred lifetimes for the addresses, so
+   that if the node is renumbered in a managed fashion, the amount of
+   stale DNS information is kept to the minimum.  That is, if the
+   preferred lifetime of an address expires, the TTL of the record needs
+   be modified unless it was already done before the expiration.  For
+   better flexibility, the DNS TTL should be much shorter (e.g., a half
+   or a third) than the lifetime of an address; that way, the node can
+   start lowering the DNS TTL if it seems like the address has not been
+   renewed/refreshed in a while.  Some discussion on how an
+   administrator could manage the DNS TTL is included in [I-D.ietf-
+   v6ops-renumbering-procedure]; this could be applied to (smart) hosts
+   as well.
+
+7.  Considerations about Reverse DNS Updating
+
+   Updating the reverse DNS zone may be difficult because of the split
+   authority over an address.  However, first we have to consider the
+   applicability of reverse DNS in the first place.
+
+7.1  Applicability of Reverse DNS
+
+   Today, some applications use reverse DNS to either look up some hints
+   about the topological information associated with an address (e.g.
+   resolving web server access logs), or as a weak form of a security
+   check, to get a feel whether the user's network administrator has
+   "authorized" the use of the address (on the premises that adding a
+   reverse record for an address would signal some form of
+   authorization).
+
+   One additional, maybe slightly more useful usage is ensuring that the
+   reverse and forward DNS contents match (by looking up the pointer to
+   the name by the IP address from the reverse tree, and ensuring that a
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 15]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   record under the name in the forward tree points to the IP address)
+   and correspond to a configured name or domain.  As a security check,
+   it is typically accompanied by other mechanisms, such as a user/
+   password login; the main purpose of the reverse+forward DNS check is
+   to weed out the majority of unauthorized users, and if someone
+   managed to bypass the checks, he would still need to authenticate
+   "properly".
+
+   It may also be desirable to store IPsec keying material corresponding
+   to an IP address in the reverse DNS, as justified and described in
+   [RFC4025].
+
+   It is not clear whether it makes sense to require or recommend that
+   reverse DNS records be updated.  In many cases, it would just make
+   more sense to use proper mechanisms for security (or topological
+   information lookup) in the first place.  At minimum, the applications
+   which use it as a generic authorization (in the sense that a record
+   exists at all) should be modified as soon as possible to avoid such
+   lookups completely.
+
+   The applicability is discussed at more length in [I-D.ietf-dnsop-
+   inaddr-required].
+
+7.2  Manual or Custom DNS Updates
+
+   Reverse DNS can of course be updated using manual or custom methods.
+   These are not further described here, except for one special case.
+
+   One way to deploy reverse DNS would be to use wildcard records, for
+   example, by configuring one name for a subnet (/64) or a site (/48).
+   As a concrete example, a site (or the site's ISP) could configure the
+   reverses of the prefix 2001:db8:f00::/48 to point to one name using a
+   wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN PTR
+   site.example.com."  Naturally, such a name could not be verified from
+   the forward DNS, but would at least provide some form of "topological
+   information" or "weak authorization" if that is really considered to
+   be useful.  Note that this is not actually updating the DNS as such,
+   as the whole point is to avoid DNS updates completely by manually
+   configuring a generic name.
+
+7.3  DDNS with Stateless Address Autoconfiguration
+
+   Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
+   some regard, while being more difficult in another, as described
+   below.
+
+   The address space administrator decides whether the hosts are trusted
+   to update their reverse DNS records or not.  If they are trusted and
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 16]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   deployed at the same site (e.g., not across the Internet), a simple
+   address-based authorization is typically sufficient (i.e., check that
+   the DNS update is done from the same IP address as the record being
+   updated); stronger security can also be used [RFC3007].  If they
+   aren't allowed to update the reverses, no update can occur.  However,
+   such address-based update authorization operationally requires that
+   ingress filtering [RFC3704] has been set up at the border of the site
+   where the updates occur, and as close to the updater as possible.
+
+   Address-based authorization is simpler with reverse DNS (as there is
+   a connection between the record and the address) than with forward
+   DNS.  However, when a stronger form of security is used, forward DNS
+   updates are simpler to manage because the host can be assumed to have
+   an association with the domain.  Note that the user may roam to
+   different networks, and does not necessarily have any association
+   with the owner of that address space -- so, assuming stronger form of
+   authorization for reverse DNS updates than an address association is
+   generally infeasible.
+
+   Moreover, the reverse zones must be cleaned up by an unspecified
+   janitorial process: the node does not typically know a priori that it
+   will be disconnected, and cannot send a DNS update using the correct
+   source address to remove a record.
+
+   A problem with defining the clean-up process is that it is difficult
+   to ensure that a specific IP address and the corresponding record are
+   no longer being used.  Considering the huge address space, and the
+   unlikelihood of collision within 64 bits of the interface
+   identifiers, a process which would remove the record after no traffic
+   has been seen from a node in a long period of time (e.g., a month or
+   year) might be one possible approach.
+
+   To insert or update the record, the node must discover the DNS server
+   to send the update to somehow, similar to as discussed in
+   Section 6.2.  One way to automate this is looking up the DNS server
+   authoritative (e.g., through SOA record) for the IP address being
+   updated, but the security material (unless the IP address-based
+   authorization is trusted) must also be established by some other
+   means.
+
+   One should note that Cryptographically Generated Addresses [RFC3972]
+   (CGAs) may require a slightly different kind of treatment.  CGAs are
+   addresses where the interface identifier is calculated from a public
+   key, a modifier (used as a nonce), the subnet prefix, and other data.
+   Depending on the usage profile, CGAs might or might not be changed
+   periodically due to e.g., privacy reasons.  As the CGA address is not
+   predicatable, a reverse record can only reasonably be inserted in the
+   DNS by the node which generates the address.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 17]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+7.4  DDNS with DHCP
+
+   With DHCPv4, the reverse DNS name is typically already inserted to
+   the DNS that reflects to the name (e.g., "dhcp-67.example.com").  One
+   can assume similar practice may become commonplace with DHCPv6 as
+   well; all such mappings would be pre-configured, and would require no
+   updating.
+
+   If a more explicit control is required, similar considerations as
+   with SLAAC apply, except for the fact that typically one must update
+   a reverse DNS record instead of inserting one (if an address
+   assignment policy that reassigns disused addresses is adopted) and
+   updating a record seems like a slightly more difficult thing to
+   secure.  However, it is yet uncertain how DHCPv6 is going to be used
+   for address assignment.
+
+   Note that when using DHCP, either the host or the DHCP server could
+   perform the DNS updates; see the implications in Section 6.2.
+
+   If disused addresses were to be reassigned, host-based DDNS reverse
+   updates would need policy considerations for DNS record modification,
+   as noted above.  On the other hand, if disused address were not to be
+   assigned, host-based DNS reverse updates would have similar
+   considerations as SLAAC in Section 7.3.  Server-based updates have
+   similar properties except that the janitorial process could be
+   integrated with DHCP address assignment.
+
+7.5  DDNS with Dynamic Prefix Delegation
+
+   In cases where a prefix, instead of an address, is being used and
+   updated, one should consider what is the location of the server where
+   DDNS updates are made.  That is, where the DNS server is located:
+
+   1.  At the same organization as the prefix delegator.
+
+   2.  At the site where the prefixes are delegated to.  In this case,
+       the authority of the DNS reverse zone corresponding to the
+       delegated prefix is also delegated to the site.
+
+   3.  Elsewhere; this implies a relationship between the site and where
+       DNS server is located, and such a relationship should be rather
+       straightforward to secure as well.  Like in the previous case,
+       the authority of the DNS reverse zone is also delegated.
+
+   In the first case, managing the reverse DNS (delegation) is simpler
+   as the DNS server and the prefix delegator are in the same
+   administrative domain (as there is no need to delegate anything at
+   all); alternatively, the prefix delegator might forgo DDNS reverse
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 18]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   capability altogether, and use e.g., wildcard records (as described
+   in Section 7.2).  In the other cases, it can be slighly more
+   difficult, particularly as the site will have to configure the DNS
+   server to be authoritative for the delegated reverse zone, implying
+   automatic configuration of the DNS server -- as the prefix may be
+   dynamic.
+
+   Managing the DDNS reverse updates is typically simple in the second
+   case, as the updated server is located at the local site, and
+   arguably IP address-based authentication could be sufficient (or if
+   not, setting up security relationships would be simpler).  As there
+   is an explicit (security) relationship between the parties in the
+   third case, setting up the security relationships to allow reverse
+   DDNS updates should be rather straightforward as well (but IP
+   address-based authentication might not be acceptable).  In the first
+   case, however, setting up and managing such relationships might be a
+   lot more difficult.
+
+8.  Miscellaneous DNS Considerations
+
+   This section describes miscellaneous considerations about DNS which
+   seem related to IPv6, for which no better place has been found in
+   this document.
+
+8.1  NAT-PT with DNS-ALG
+
+   The DNS-ALG component of NAT-PT mangles A records  to look like AAAA
+   records to the IPv6-only nodes.  Numerous problems have been
+   identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl].  This is
+   a strong reason not to use NAT-PT in the first place.
+
+8.2  Renumbering Procedures and Applications' Use of DNS
+
+   One of the most difficult problems of systematic IP address
+   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
+   an application which looks up a DNS name disregards information such
+   as TTL, and uses the result obtained from DNS as long as it happens
+   to be stored in the memory of the application.  For applications
+   which run for a long time, this could be days, weeks or even months;
+   some applications may be clever enough to organize the data
+   structures and functions in such a manner that look-ups get refreshed
+   now and then.
+
+   While the issue appears to have a clear solution, "fix the
+   applications", practically this is not reasonable immediate advice;
+   the TTL information is not typically available in the APIs and
+   libraries (so, the advice becomes "fix the applications, APIs and
+   libraries"), and a lot more analysis is needed on how to practically
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 19]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   go about to achieve the ultimate goal of avoiding using the names
+   longer than expected.
+
+9.  Acknowledgements
+
+   Some recommendations (Section 4.3, Section 5.1) about IPv6 service
+   provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
+   Nordmark and Bob Gilligan.  Havard Eidnes and Michael Patton provided
+   useful feedback and improvements.  Scott Rose, Rob Austein, Masataka
+   Ohta, and Mark Andrews helped in clarifying the issues regarding
+   additional data and the use of TTL.  Jefsey Morfin, Ralph Droms,
+   Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
+   Rob Austein provided useful feedback during the WG last call.  Thomas
+   Narten provided extensive feedback during the IESG evaluation.
+
+10.  Security Considerations
+
+   This document reviews the operational procedures for IPv6 DNS
+   operations and does not have security considerations in itself.
+
+   However, it is worth noting that in particular with Dynamic DNS
+   Updates, security models based on the source address validation are
+   very weak and cannot be recommended -- they could only be considered
+   in the environments where ingress filtering [RFC3704] has been
+   deployed.  On the other hand, it should be noted that setting up an
+   authorization mechanism (e.g., a shared secret, or public-private
+   keys) between a node and the DNS server has to be done manually, and
+   may require quite a bit of time and expertise.
+
+   To re-emphasize what was already stated, the reverse+forward DNS
+   check provides very weak security at best, and the only
+   (questionable) security-related use for them may be in conjunction
+   with other mechanisms when authenticating a user.
+
+11.  References
+
+11.1  Normative References
+
+   [I-D.ietf-dnsop-ipv6-dns-configuration]
+              Jeong, J., "IPv6 Host Configuration of DNS Server
+              Information Approaches",
+              draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
+              progress), May 2005.
+
+   [I-D.ietf-ipv6-unique-local-addr]
+              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
+              progress), January 2005.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 20]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   [I-D.ietf-v6ops-renumbering-procedure]
+              Baker, F., "Procedures for Renumbering an IPv6 Network
+              without a Flag Day",
+              draft-ietf-v6ops-renumbering-procedure-05 (work in
+              progress), March 2005.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+              July 1997.
+
+   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+              Autoconfiguration", RFC 2462, December 1998.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+              April 2001.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
+              Stateless Address Autoconfiguration in IPv6", RFC 3041,
+              January 2001.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+              August 2001.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+              Hain, "Representing Internet Protocol version 6 (IPv6)
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 21]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+              Addresses in the Domain Name System (DNS)", RFC 3363,
+              August 2002.
+
+   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
+              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+              August 2002.
+
+   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
+              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+              December 2003.
+
+   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
+              (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
+              Addresses", RFC 3879, September 2004.
+
+   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
+              Guidelines", BCP 91, RFC 3901, September 2004.
+
+   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+              Castro, "Application Aspects of IPv6 Transition",
+              RFC 4038, March 2005.
+
+   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
+              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+11.2  Informative References
+
+   [I-D.durand-dnsop-dont-publish]
+              Durand, A. and T. Chown, "To publish, or not to publish,
+              that is the question.", draft-durand-dnsop-dont-publish-00
+              (work in progress), February 2005.
+
+   [I-D.huitema-v6ops-teredo]
+              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              NATs", draft-huitema-v6ops-teredo-05 (work in progress),
+              April 2005.
+
+   [I-D.huston-6to4-reverse-dns]
+              Huston, G., "6to4 Reverse DNS Delegation",
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 22]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+              draft-huston-6to4-reverse-dns-03 (work in progress),
+              October 2004.
+
+   [I-D.ietf-dhc-ddns-resolution]
+              Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
+              DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
+              progress), June 2005.
+
+   [I-D.ietf-dhc-fqdn-option]
+              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
+              draft-ietf-dhc-fqdn-option-10 (work in progress),
+              February 2005.
+
+   [I-D.ietf-dnsext-dhcid-rr]
+              Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
+              encoding DHCP information (DHCID RR)",
+              draft-ietf-dnsext-dhcid-rr-09 (work in progress),
+              February 2005.
+
+   [I-D.ietf-dnsop-bad-dns-res]
+              Larson, M. and P. Barber, "Observed DNS Resolution
+              Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
+              progress), October 2004.
+
+   [I-D.ietf-dnsop-inaddr-required]
+              Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
+              draft-ietf-dnsop-inaddr-required-06 (work in progress),
+              February 2005.
+
+   [I-D.ietf-v6ops-3gpp-analysis]
+              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
+              Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
+              progress), October 2004.
+
+   [I-D.ietf-v6ops-mech-v2]
+              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
+              (work in progress), March 2005.
+
+   [I-D.ietf-v6ops-natpt-to-exprmntl]
+              Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
+              Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
+              in progress), July 2005.
+
+   [I-D.ietf-v6ops-onlinkassumption]
+              Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
+              Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
+              (work in progress), May 2005.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 23]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   [I-D.ietf-v6ops-v6onbydefault]
+              Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
+              IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
+              (work in progress), July 2004.
+
+   [I-D.jeong-dnsop-ipv6-dns-discovery]
+              Jeong, J., "IPv6 DNS Configuration based on Router
+              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
+              (work in progress), February 2005.
+
+   [I-D.ohta-preconfigured-dns]
+              Ohta, M., "Preconfigured DNS Server Addresses",
+              draft-ohta-preconfigured-dns-01 (work in progress),
+              February 2004.
+
+   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
+              Translation - Protocol Translation (NAT-PT)", RFC 2766,
+              February 2000.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
+
+   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
+              Unique DNS Root", RFC 2826, May 2000.
+
+   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+              Networks", BCP 84, RFC 3704, March 2004.
+
+   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
+              RFC 3972, March 2005.
+
+   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
+              Material in DNS", RFC 4025, March 2005.
+
+
+Authors' Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc.
+   17 Network circle UMPL17-202
+   Menlo Park, CA  94025
+   USA
+
+   Email: Alain.Durand@sun.com
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 24]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm
+   Sweden
+
+   Email: johani@autonomica.se
+
+
+   Pekka Savola
+   CSC/FUNET
+   Espoo
+   Finland
+
+   Email: psavola@funet.fi
+
+Appendix A.  Unique Local Addressing Considerations for DNS
+
+   Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
+   replaced the now-deprecated site-local addresses [RFC3879].  From the
+   perspective of the DNS, the locally generated unique local addresses
+   (LUL) and site-local addresses have similar properties.
+
+   The interactions with DNS come in two flavors: forward and reverse
+   DNS.
+
+   To actually use local addresses within a site, this implies the
+   deployment of a "split-faced" or a fragmented DNS name space, for the
+   zones internal to the site, and the outsiders' view to it.  The
+   procedures to achieve this are not elaborated here.  The implication
+   is that local addresses must not be published in the public DNS.
+
+   To faciliate reverse DNS (if desired) with local addresses, the stub
+   resolvers must look for DNS information from the local DNS servers,
+   not e.g. starting from the root servers, so that the local
+   information may be provided locally.  Note that the experience of
+   private addresses in IPv4 has shown that the root servers get loaded
+   for requests for private address lookups in any case.  This
+   requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
+
+Appendix B.  Behaviour of Additional Data in IPv4/IPv6 Environments
+
+   DNS responses do not always fit in a single UDP packet.  We'll
+   examine the cases which happen when this is due to too much data in
+   the Additional Section.
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 25]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+B.1  Description of Additional Data Scenarios
+
+   There are two kinds of additional data:
+
+   1.  "critical" additional data; this must be included in all
+       scenarios, with all the RRsets, and
+
+   2.  "courtesy" additional data; this could be sent in full, with only
+       a few RRsets, or with no RRsets, and can be fetched separately as
+       well, but at the cost of additional queries.
+
+   The responding server can algorithmically determine which type the
+   additional data is by checking whether it's at or below a zone cut.
+
+   Only those additional data records (even if sometimes carelessly
+   termed "glue") are considered "critical" or real "glue" if and only
+   if they meet the abovementioned condition, as specified in Section
+   4.2.1 of [RFC1034].
+
+   Remember that resource record sets (RRsets) are never "broken up", so
+   if a name has 4 A records and 5 AAAA records, you can either return
+   all 9, all 4 A records, all 5 AAAA records or nothing.  In
+   particular, notice that for the "critical" additional data getting
+   all the RRsets can be critical.
+
+   In particular, [RFC2181] specifies (in Section 9) that:
+
+   a.  if all the "critical" RRsets do not fit, the sender should set
+       the TC bit, and the recipient should discard the whole response
+       and retry using mechanism allowing larger responses such as TCP.
+
+   b.  "courtesy" additional data should not cause the setting of TC
+       bit, but instead all the non-fitting additional data RRsets
+       should be removed.
+
+   An example of the "courtesy" additional data is A/AAAA records in
+   conjunction with MX records as shown in Section 4.4; an example of
+   the "critical" additional data is shown below (where getting both the
+   A and AAAA RRsets is critical w.r.t. to the NS RR):
+
+      child.example.com.    IN   NS ns.child.example.com.
+      ns.child.example.com. IN    A 192.0.2.1
+      ns.child.example.com. IN AAAA 2001:db8::1
+
+   When there is too much "courtesy" additional data, at least the non-
+   fitting RRsets should be removed [RFC2181]; however, as the
+   additional data is not critical, even all of it could be safely
+   removed.
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 26]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   When there is too much "critical" additional data, TC bit will have
+   to be set, and the recipient should ignore the response and retry
+   using TCP; if some data were to be left in the UDP response, the
+   issue is which data could be retained.
+
+   Failing to discard the response with TC bit or omitting critical
+   information but not setting TC bit lead to an unrecoverable problem.
+   Omitting only some of the RRsets if all would not fit (but not
+   setting TC bit) leads to a performance problem.  These are discussed
+   in the next two subsections.
+
+B.2  Which Additional Data to Keep, If Any?
+
+   If the implementation decides to keep as much data (whether
+   "critical" or "courtesy") as possible in the UDP responses, it might
+   be tempting to use the transport of the DNS query as a hint in either
+   of these cases: return the AAAA records if the query was done over
+   IPv6, or return the A records if the query was done over IPv4.
+   However, this breaks the model of independence of DNS transport and
+   resource records, as noted in Section 1.2.
+
+   With courtesy additional data, as long as enough RRsets will be
+   removed so that TC will not be set, it is allowed to send as many
+   complete RRsets as the implementations prefers.  However, the
+   implementations are also free to omit all such RRsets, even if
+   complete.  Omitting all the RRsets (when removing only some would
+   suffice) may create a performance penalty, whereby the client may
+   need to issue one or more additional queries to obtain necessary
+   and/or consistent information.
+
+   With critical additional data, the alternatives are either returning
+   nothing (and absolutely requiring a retry with TCP) or returning
+   something (working also in the case if the recipient does not discard
+   the response and retry using TCP) in addition to setting the TC bit.
+   If the process for selecting "something" from the critical data would
+   otherwise be practically "flipping the coin" between A and AAAA
+   records, it could be argued that if one looked at the transport of
+   the query, it would have a larger possibility of being right than
+   just 50/50.  In other words, if the returned critical additional data
+   would have to be selected somehow, using something more sophisticated
+   than a random process would seem justifiable.
+
+   That is, leaving in some intelligently selected critical additional
+   data is a tradeoff between creating an optimization for those
+   resolvers which ignore the "should discard" recommendation, and
+   causing a protocol problem by propagating inconsistent information
+   about "critical" records in the caches.
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 27]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   Similarly, leaving in the complete courtesy additional data RRsets
+   instead of removing all the RRsets is a performance tradeoff as
+   described in the next section.
+
+B.3  Discussion of the Potential Problems
+
+   As noted above, the temptation for omitting only some of the
+   additional data could be problematic.  This is discussed more below.
+
+   For courtesy additional data, this causes a potential performance
+   problem as this requires that the clients issue re-queries for the
+   potentially omitted RRsets.  For critical additional data, this
+   causes a potential unrecoverable problem if the response is not
+   discarded and the query not re-tried with TCP, as the nameservers
+   might be reachable only through the omitted RRsets.
+
+   If an implementation would look at the transport used for the query,
+   it is worth remembering that often the host using the records is
+   different from the node requesting them from the authoritative DNS
+   server (or even a caching resolver).  So, whichever version the
+   requestor (e.g., a recursive server in the middle) uses makes no
+   difference to the ultimate user of the records, whose transport
+   capabilities might differ from those of the requestor.  This might
+   result in e.g., inappropriately returning A records to an IPv6-only
+   node, going through a translation, or opening up another IP-level
+   session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
+   Therefore, at least in many scenarios, it would be very useful if the
+   information returned would be consistent and complete -- or if that
+   is not feasible, return no misleading information but rather leave it
+   to the client to query again.
+
+   The problem of too much additional data seems to be an operational
+   one: the zone administrator entering too many records which will be
+   returned either truncated (or missing some RRsets, depending on
+   implementations) to the users.  A protocol fix for this is using
+   EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
+   pushing up the relevant threshold.  Further, DNS server
+   implementations should rather omit courtesy additional data
+   completely rather than including only some RRsets [RFC2181].  An
+   operational fix for this is having the DNS server implementations
+   return a warning when the administrators create zones which would
+   result in too much additional data being returned.  Further, DNS
+   server implementations should warn of or disallow such zone
+   configurations which are recursive or otherwise difficult to manage
+   by the protocol.
+
+   Additionally, to avoid the case where an application would not get an
+   address at all due to some of courtesy additional data being omitted,
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 28]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+   the resolvers should be able to query the specific records of the
+   desired protocol, not just rely on getting all the required RRsets in
+   the additional section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 29]
+
+Internet-Draft        Considerations with IPv6 DNS             July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Durand, et al.          Expires January 17, 2006               [Page 30]
+
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
new file mode 100644
index 0000000..b2e2341
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
@@ -0,0 +1,300 @@
+Internet Engineering Task Force                         A.Durand
+INTERNET-DRAFT                             SUN Microsystems,inc.
+November, 24, 2003                                      J. Ihren
+Expires May 25, 2004                                  Autonomica
+
+
+               DNS IPv6 transport operational guidelines
+          <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
+
+
+
+Status of this Memo
+
+   This memo provides information to the Internet community. It does not
+   specify an Internet standard of any kind. This memo is in full
+   conformance with all provisions of Section 10 of RFC2026
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+
+Abstract
+
+   This memo provides guidelines and Best Current Practice to operate
+   DNS in a world where queries and responses are carried in a mixed
+   environment of IPv4 and IPv6 networks.
+
+
+Acknowledgment
+
+   This document is the result of many conversations that happened in
+   the DNS community at IETF and elsewhere since 2001. During that
+   period of time, a number of Internet drafts have been published to
+   clarify various aspects of the issues at stake. This document focuses
+   on the conclusion of those discussions.
+
+   The authors would like to acknowledge the role of Pekka Savola in his
+   thorough review of the document.
+
+
+1. Terminology
+
+   The phrase "IPv4 name server" indicates a name server available over
+   IPv4 transport. It does not imply anything about what DNS data is
+   served. Likewise, "IPv6 name server" indicates a name server
+   available over IPv6 transport. The phrase "dual-stack DNS server"
+   indicates a DNS server that is actually configured to run both
+   protocols, IPv4 and IPv6, and not merely a server running on a system
+   capable of running both but actually configured to run only one.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [2119].
+
+
+2. Introduction to the Problem of Name Space Fragmentation:
+     following the referral chain
+
+   The caching resolver that tries to look up a name starts out at the
+   root, and follows referrals until it is referred to a nameserver that
+   is authoritative for the name.  If somewhere down the chain of
+   referrals it is referred to a nameserver that is only accessible over
+   an unavailable type of transport, a traditional nameserver is unable
+   to finish the task.
+
+   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
+   only a matter of time until this starts to happen. The complete DNS
+   hierarchy then starts to fragment into a graph where authoritative
+   nameservers for certain nodes are only accessible over a certain
+   transport. What is feared is that a node using only a particular
+   version of IP, querying information about another node using the same
+   version of IP can not do it because, somewhere in the chain of
+   servers accessed during the resolution process, one or more of them
+   will only be accessible with the other version of IP.
+
+   With all DNS data only available over IPv4 transport everything is
+   simple. IPv4 resolvers can use the intended mechanism of following
+   referrals from the root and down while IPv6 resolvers have to work
+   through a "translator", i.e. they have to use a second name server on
+   a so-called "dual stack" host as a "forwarder" since they cannot
+   access the DNS data directly.
+
+   With all DNS data only available over IPv6 transport everything would
+   be equally simple, with the exception of old legacy IPv4 name servers
+   having to switch to a forwarding configuration.
+
+   However, the second situation will not arise in a foreseeable time.
+   Instead, it is expected that the transition will be from IPv4 only to
+   a mixture of IPv4 and IPv6, with DNS data of theoretically three
+   categories depending on whether it is available only over IPv4
+   transport, only over IPv6 or both.
+
+   Having DNS data available on both transports is the best situation.
+   The major question is how to ensure that it as quickly as possible
+   becomes the norm. However, while it is obvious that some DNS data
+   will only be available over v4 transport for a long time it is also
+   obvious that it is important to avoid fragmenting the name space
+   available to IPv4 only hosts. I.e. during transition it is not
+   acceptable to break the name space that we presently have available
+   for IPv4-only hosts.
+
+
+3. Policy Based Avoidance of Name Space Fragmentation
+
+   Today there are only a few DNS "zones" on the public Internet that
+   are  available over IPv6 transport, and most of them can be regarded
+   as "experimental". However, as soon as the root and top level domains
+   are available over IPv6 transport, it is reasonable to expect that it
+   will become more common to have zones served by IPv6 servers.
+
+   Having those zones served only by IPv6-only name server would not be
+   a good development, since this will fragment the previously
+   unfragmented IPv4 name space and there are strong reasons to find a
+   mechanism to avoid it.
+
+   The RECOMMENDED approach to maintain name space continuity is to use
+   administrative policies, as described in the next section.
+
+
+4. DNS IPv6 Transport RECOMMENDED Guidelines
+
+   In order to preserve name space continuity, the following administrative
+   policies are RECOMMENDED:
+      - every recursive DNS server SHOULD be either IPv4-only or dual
+      stack,
+      - every single DNS zone SHOULD be served by at least one IPv4
+      reachable DNS server.
+
+   This rules out IPv6-only DNS servers performing full recursion and
+   DNS zones served only by IPv6-only DNS servers.  However, one could
+   very well design a configuration where a chain of IPv6 only DNS
+   servers forward queries to a set of dual stack DNS servers actually
+   performing those recursive queries.  This approach could be revisited
+   if/when translation techniques between IPv4 and IPv6 were to be
+   widely deployed.
+
+   In order to help enforcing the second point, the optional operational
+   zone validation processes SHOULD ensure that there is at least one
+   IPv4 address record available for the name servers of any child
+   delegations within the zone.
+
+
+5. Security Considerations
+
+   Being a critical piece of the Internet infrastructure, the DNS is a
+   potential value target and thus should be protected.  Great care
+   should be taken not to weaken the security of DNS while introducing
+   IPv6 operation.
+
+   Keeping the DNS name space from fragmenting is a critical thing for
+   the availability and the operation of the Internet; this memo
+   addresses this issue by clear and simple operational guidelines.
+
+   The RECOMMENDED guidelines are compatible with the operation of
+   DNSSEC and do not introduce any new security issues.
+
+
+6. Author Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17 Network circle UMPK17-202
+   Menlo Park, CA, 94025
+   USA
+   Mail: Alain.Durand@sun.com
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm, Sweden
+   Mail: johani@autonomica.se
+
+
+7. Normative References
+
+   [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
+           Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+8. Full Copyright Statement
+
+   "Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
new file mode 100644
index 0000000..6bece56
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
@@ -0,0 +1,389 @@
+
+DNSOP                                                          G. Guette
+Internet-Draft                                             IRISA / INRIA
+Expires: July 19, 2005                                        O. Courtay
+                                                             Thomson R&D
+                                                        January 18, 2005
+
+           Requirements for Automated Key Rollover in DNSSEC
+           draft-ietf-dnsop-key-rollover-requirements-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable 
+   patent or other IPR claims of which I am aware have been disclosed, 
+   and any of which I become aware will be disclosed, in accordance with 
+   RFC 3668.  
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 19, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document describes problems that appear during an automated
+   rollover and gives the requirements for the design of communication
+   between parent zone and child zone during an automated rollover
+   process.  This document is essentially about in-band key rollover.
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 1]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
+   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
+   4.   Messages authentication and information exchanged  . . . . . . 5
+   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
+   6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
+   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
+   8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
+   A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
+        Intellectual Property and Copyright Statements . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 2]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+1.  Introduction
+
+   The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
+   cryptography and digital signatures.  It stores the public part of
+   keys in DNSKEY Resource Records (RRs).  Because old keys and
+   frequently used keys are vulnerable, they must be renewed
+   periodically.  In DNSSEC, this is the case for Zone Signing Keys
+   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
+   exchanges between parents and children is necessary for large zones
+   because there are too many changes to handle.
+
+   Let us consider for example a zone with 100000 secure delegations.
+   If the child zones change their keys once a year on average, that
+   implies 300 changes per day for the parent zone.  This amount of
+   changes is hard to manage manually.
+
+   Automated rollover is optional and resulting from an agreement
+   between the administrator of the parent zone and the administrator of
+   the child zone.  Of course, key rollover can also be done manually by
+   administrators.
+
+   This document describes the requirements for a protocol to perform
+   the automated key rollover process and focusses on interaction
+   between parent and child zone.
+
+2.  The Key Rollover Process
+
+   Key rollover consists of renewing the DNSSEC keys used to sign
+   resource records in a given DNS zone file.  There are two types of
+   rollover, ZSK rollovers and KSK rollovers.
+
+   During a ZSK rollover, all changes are local to the zone that renews
+   its key: there is no need to contact other zones administrators to
+   propagate the performed changes because a ZSK has no associated DS
+   record in the parent zone.
+
+   During a KSK rollover, new DS RR(s) must be created and stored in the
+   parent zone.  In consequence, data must be exchanged between child
+   and parent zones.
+
+   The key rollover is built from two parts of different nature:
+   o  An algorithm that generates new keys and signs the zone file.  It
+      can be local to the zone,
+   o  the interaction between parent and child zones.
+
+   One example of manual key rollover [3] is:
+   o  The child zone creates a new KSK,
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 3]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+   o  the child zone waits for the creation of the DS RR in its parent
+      zone,
+   o  the child zone deletes the old key,
+   o  the parent zone deletes the old DS RR.
+
+   This document concentrates on defining interactions between entities
+   present in key rollover process.
+
+3.  Basic Requirements
+
+   This section provides the requirements for automated key rollover in
+   case of normal use.  Exceptional case like emergency rollover is
+   specifically described later in this document.
+
+   The main condition during a key rollover is that the chain of trust
+   must be preserved to every validating DNS client.  No matter if this
+   client retrieves some of the RRs from recursive caching name server
+   or from the authoritative servers for the zone involved in the
+   rollover.
+
+   Automated key rollover solution may be interrupted by a manual
+   intervention.  This manual intervention should not compromise the
+   security state of the chain of trust.  If the chain is safe before
+   the manual intervention, the chain of trust must remain safe during
+   and after the manual intervention
+
+   Two entities act during a KSK rollover: the child zone and its parent
+   zone.  These zones are generally managed by different administrators.
+   These administrators should agree on some parameters like
+   availability of automated rollover, the maximum delay between
+   notification of changes in the child zone and the resigning of the
+   parent zone.  The child zone needs to know this delay to schedule its
+   changes and/or to verify that the changes had been taken into account
+   in the parent zone.  Hence, the child zone can also avoid some
+   critical cases where all child key are changed prior to the DS RR
+   creation.
+
+   By keeping some resource records during a given time, the recursive
+   cache servers can act on the automated rollover.  The existence of
+   recursive cache servers must be taken into account by automated
+   rollover solution.
+
+   Indeed, during an automated key rollover a name server could have to
+   retrieve some DNSSEC data.  An automated key rollover solution must
+   ensure that these data are not old DNSSEC material retrieved from a
+   recursive name server.
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 4]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+4.  Messages authentication and information exchanged
+
+   This section addresses in-band rollover, security of out-of-band
+   mechanisms is out of scope of this document.
+
+   The security provided by DNSSEC must not be compromised by the key
+   rollover, thus every exchanged message must be authenticated to avoid
+   fake rollover messages from malicious parties.
+
+   Once the changes related to a KSK are made in a child zone, there are
+   two ways for the parent zone to take this changes into account:
+   o  the child zone notify directly or not directly its parent zone in
+      order to create the new DS RR and store this DS RR in parent zone
+      file,
+   o  or the parent zone poll the child zone.
+
+   In both cases, the parent zone must receive all the child keys that
+   need the creation of associated DS RRs in the parent zone.
+
+   Because errors could occur during the transmission of keys between
+   child and parent, the key exchange protocol must be fault tolerant.
+   Should an error occured during the automated key rollover, an
+   automated key rollover solution must be able to keep the zone files
+   in a consistent state.
+
+5.  Emergency Rollover
+
+   Emergency key rollover is a special case of rollover decided by the
+   zone administrator generally for security reasons.  In consequence,
+   emergency key rollover can break some of the requirement described
+   above.
+
+   A zone key might be compromised and an attacker can use the
+   compromised key to create and sign fake records.  To avoid this, the
+   zone administrator may change the compromised key or all its keys as
+   soon as possible, without waiting for the creation of new DS RRs in
+   its parent zone.
+
+   Fast changes may break the chain of trust.  The part of DNS tree
+   having this zone as apex can become unverifiable, but the break of
+   the chain of trust is necessary if the administrator wants to prevent
+   the compromised key from being used (to spoof DNS data).
+
+   Parent and child zones sharing an automated rollover mechanism,
+   should have an out-of-band way to re-establish a consistent state at
+   the delegation point (DS and DNSKEY RRs).  This allows to avoid that
+   a malicious party uses the compromised key to roll the zone keys.
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 5]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+6.  Security consideration
+
+   The automated key rollover process in DNSSEC allows automated renewal
+   of any kind of DNS key (ZSK or KSK).  It is essential that parent
+   side and child side can do mutual authentication.  Moreover,
+   integrity of the material exchanged between the parent and child zone
+   must be provided to ensure the right DS are created.
+
+   As in any application using public key cryptography, in DNSSEC a key
+   may be compromised.  What to do in such a case can be describe in the
+   zone local policy and can violate some requirements described in this
+   draft.  The emergency rollover can break the chain of trust in order
+   to protect the zone against the use of the compromised key.
+
+7.  Acknowledgments
+
+   The authors want to thank members of IDsA project for their
+   contribution to this document.
+
+8  Normative References
+
+   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+        RFC 3658, December 2003.
+
+   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+   [3]  Kolkman, O., "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
+        progress), May 2004.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "Resource Records for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-records-11 (work in progress), October
+        2004.
+
+   [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "DNS Security Introduction and Requirements",
+        draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
+        2004.
+
+   [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 6]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+        2004.
+
+Authors' Addresses
+
+   Gilles Guette
+   IRISA / INRIA
+   Campus de Beaulieu
+   35042  Rennes CEDEX
+   FR
+
+   EMail: gilles.guette@irisa.fr
+   URI:   http://www.irisa.fr
+
+   Olivier Courtay
+   Thomson R&D
+   1, avenue Belle Fontaine
+   35510  Cesson S?vign? CEDEX
+   FR
+
+   EMail: olivier.courtay@thomson.net
+
+Appendix A.  Documents details and changes
+
+   This section is to be removed by the RFC editor if and when the
+   document is published.
+
+   Section about NS RR rollover has been removed
+
+   Remarks from Samuel Weiler and Rip Loomis added
+
+   Clarification about in-band rollover and in emergency section
+
+   Section 3, details about recursive cache servers added
+
+
+
+
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 7]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+Intellectual Property Statement
+
+     The IETF takes no position regarding the validity or scope of any 
+     intellectual property or other rights that might be claimed to 
+     pertain to the implementation or use of the technology described 
+     in this document or the extent to which any license under such 
+     rights might or might not be available; neither does it represent 
+     that it has made any effort to identify any such rights. 
+     Information on the IETF's procedures with respect to rights in 
+     IETF Documents can be found in BCP 78 and 79.   
+          
+     Copies of IPR disclosures made to the IETF Secretariat and any 
+     assurances of licenses to be made available, or the result of an 
+     attempt made to obtain a general license or permission for the use 
+     of such proprietary rights by implementers or users of this 
+     specification can be obtained from the IETF on-line IPR repository 
+     at http://www.ietf.org/ipr. 
+      
+     The IETF invites any interested party to bring to its attention 
+     any copyrights, patents or patent applications, or other 
+     proprietary rights which may cover technology that may be required 
+     to implement this standard. Please address the information to the 
+     IETF at ietf-ipr.org. 
+      
+    
+ Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (2005).  This document is subject 
+   to the rights, licenses and restrictions contained in BCP 78, and 
+   except as set forth therein, the authors retain all their rights. 
+    
+   This document and the information contained herein are provided on an 
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+ Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+         
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 8]
diff --git a/doc/draft/draft-ietf-dnsop-respsize-02.txt b/doc/draft/draft-ietf-dnsop-respsize-02.txt
new file mode 100644
index 0000000..63fe2de
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-respsize-02.txt
@@ -0,0 +1,480 @@
+
+
+
+
+
+
+   DNSOP Working Group                                     Paul Vixie, ISC
+   INTERNET-DRAFT                                         Akira Kato, WIDE
+   <draft-ietf-dnsop-respsize-02.txt>                            July 2005
+
+                           DNS Response Size Issues
+
+   Status of this Memo
+      By submitting this Internet-Draft, each author represents that any
+      applicable patent or other IPR claims of which he or she is aware
+      have been or will be disclosed, and any of which he or she becomes
+      aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+      Internet-Drafts are working documents of the Internet Engineering
+      Task Force (IETF), its areas, and its working groups.  Note that
+      other groups may also distribute working documents as Internet-
+      Drafts.
+
+      Internet-Drafts are draft documents valid for a maximum of six months
+      and may be updated, replaced, or obsoleted by other documents at any
+      time.  It is inappropriate to use Internet-Drafts as reference
+      material or to cite them other than as "work in progress."
+
+      The list of current Internet-Drafts can be accessed at
+      http://www.ietf.org/ietf/1id-abstracts.txt
+
+      The list of Internet-Draft Shadow Directories can be accessed at
+      http://www.ietf.org/shadow.html.
+
+   Copyright Notice
+
+      Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+
+
+
+                                    Abstract
+
+      With a mandated default minimum maximum message size of 512 octets,
+      the DNS protocol presents some special problems for zones wishing to
+      expose a moderate or high number of authority servers (NS RRs).  This
+      document explains the operational issues caused by, or related to
+      this response size limit.
+
+
+
+
+
+
+   Expires December 2005                                           [Page 1]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   1 - Introduction and Overview
+
+   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
+   octets.  Even though this limitation was due to the required minimum UDP
+   reassembly limit for IPv4, it is a hard DNS protocol limit and is not
+   implicitly relaxed by changes in transport, for example to IPv6.
+
+   1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
+   responses by mutual agreement of the requestor and responder.  However,
+   deployment of EDNS0 cannot be expected to reach every Internet resolver
+   in the short or medium term.  The 512 octet message size limit remains
+   in practical effect at this time.
+
+   1.3. Since DNS responses include a copy of the request, the space
+   available for response data is somewhat less than the full 512 octets.
+   For negative responses, there is rarely a space constraint.  For
+   positive and delegation responses, though, every octet must be carefully
+   and sparingly allocated.  This document specifically addresses
+   delegation response sizes.
+
+   2 - Delegation Details
+
+   2.1. A delegation response will include the following elements:
+
+      Header Section: fixed length (12 octets)
+      Question Section: original query (name, class, type)
+      Answer Section: (empty)
+      Authority Section: NS RRset (nameserver names)
+      Additional Section: A and AAAA RRsets (nameserver addresses)
+
+   2.2. If the total response size would exceed 512 octets, and if the data
+   that would not fit belonged in the question, answer, or authority
+   section, then the TC bit will be set (indicating truncation) which may
+   cause the requestor to retry using TCP, depending on what information
+   was desired and what information was omitted.  If a retry using TCP is
+   needed, the total cost of the transaction is much higher.  (See [RFC1123
+   6.1.3.2] for details on the protocol requirement that UDP be attempted
+   before falling back to TCP.)
+
+   2.3. RRsets are never sent partially unless truncation occurs, in which
+   case the final apparent RRset in the final nonempty section must be
+   considered "possibly damaged".  With or without truncation, the glue
+   present in the additional data section should be considered "possibly
+   incomplete", and requestors should be prepared to re-query for any
+   damaged or missing RRsets.  For multi-transport name or mail services,
+
+
+
+   Expires December 2005                                           [Page 2]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
+   RRset is present.
+
+   2.4. DNS label compression allows a domain name to be instantiated only
+   once per DNS message, and then referenced with a two-octet "pointer"
+   from other locations in that same DNS message.  If all nameserver names
+   in a message are similar (for example, all ending in ".ROOT-
+   SERVERS.NET"), then more space will be available for uncompressable data
+   (such as nameserver addresses).
+
+   2.5. The query name can be as long as 255 characters of presentation
+   data, which can be up to 256 octets of network data.  In this worst case
+   scenario, the question section will be 260 octets in size, which would
+   leave only 240 octets for the authority and additional sections (after
+   deducting 12 octets for the fixed length header.)
+
+   2.6. Average and maximum question section sizes can be predicted by the
+   zone owner, since they will know what names actually exist, and can
+   measure which ones are queried for most often.  For cost and performance
+   reasons, the majority of requests should be satisfied without truncation
+   or TCP retry.
+
+   2.7. Requestors who deliberately send large queries to force truncation
+   are only increasing their own costs, and cannot effectively attack the
+   resources of an authority server since the requestor would have to retry
+   using TCP to complete the attack.  An attack that always used TCP would
+   have a lower cost.
+
+   2.8. The minimum useful number of address records is two, since with
+   only one address, the probability that it would refer to an unreachable
+   server is too high.  Truncation which occurs after two address records
+   have been added to the additional data section is therefore less
+   operationally significant than truncation which occurs earlier.
+
+   2.9. The best case is no truncation.  This is because many requestors
+   will retry using TCP by reflex, or will automatically re-query for
+   RRsets that are "possibly truncated", without considering whether the
+   omitted data was actually necessary.
+
+   2.10. Each added NS RR for a zone will add a minimum of between 16 and
+   44 octets to every untruncated referral or negative response from the
+   zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
+   and 28 octets for an AAAA RR), in addition to whatever space is taken by
+   the nameserver name (NS NSDNAME and A/AAAA owner name).
+
+
+
+
+   Expires December 2005                                           [Page 3]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   3 - Analysis
+
+   3.1. An instrumented protocol trace of a best case delegation response
+   follows.  Note that 13 servers are named, and 13 addresses are given.
+   This query was artificially designed to exactly reach the 512 octet
+   limit.
+
+      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
+      ;; QUERY SECTION:
+      ;;  [23456789.123456789.123456789.\
+           123456789.123456789.123456789.com A IN]        ;; @80
+
+      ;; AUTHORITY SECTION:
+      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
+      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
+      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
+      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
+      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
+      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
+      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
+      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
+      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
+      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
+      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
+      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
+      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
+
+      ;; ADDITIONAL SECTION:
+      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
+      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
+      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
+      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
+      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
+      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
+      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
+      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
+      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
+      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
+      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
+      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
+      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
+
+      ;; MSG SIZE  sent: 80  rcvd: 512
+
+
+
+
+
+   Expires December 2005                                           [Page 4]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   3.2. For longer query names, the number of address records supplied will
+   be lower.  Furthermore, it is only by using a common parent name (which
+   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
+   fit.  The following output from a response simulator demonstrates these
+   properties:
+
+      % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
+      a.dns.br requires 10 bytes
+      b.dns.br requires 4 bytes
+      c.dns.br requires 4 bytes
+      d.dns.br requires 4 bytes
+      # of NS: 4
+      For maximum size query (255 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
+      For average size query (64 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 4 (green)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
+
+      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
+      ns-ext.isc.org requires 16 bytes
+      ns.psg.com requires 12 bytes
+      ns.ripe.net requires 13 bytes
+      ns.eu.int requires 11 bytes
+      # of NS: 4
+      For maximum size query (255 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
+      For average size query (64 byte):
+              if only A is considered:     # of A is 4 (green)
+              if A and AAAA are condered:  # of A+AAAA is 4 (green)
+              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
+
+   (Note: The response simulator program is shown in Section 5.)
+
+   Here we use the term "green" if all address records could fit, or
+   "orange" if two or more could fit, or "red" if fewer than two could fit.
+   It's clear that without a common parent for nameserver names, much space
+   would be lost.  For these examples we use an average/common name size of
+   15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
+   parent name.
+
+
+
+
+   Expires December 2005                                           [Page 5]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   We're assuming an average query name size of 64 since that is the
+   typical average maximum size seen in trace data at the time of this
+   writing.  If Internationalized Domain Name (IDN) or any other technology
+   which results in larger query names be deployed significantly in advance
+   of EDNS, then new measurements and new estimates will have to be made.
+
+   4 - Conclusions
+
+   4.1. The current practice of giving all nameserver names a common parent
+   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
+   responses and allows for more nameservers to be enumerated than would
+   otherwise be possible.  (Note that in this case it is wise to serve the
+   common parent domain's zone from the same servers that are named within
+   it, in order to limit external dependencies when all your eggs are in a
+   single basket.)
+
+   4.2. Thirteen (13) seems to be the effective maximum number of
+   nameserver names usable traditional (non-extended) DNS, assuming a
+   common parent domain name, and given that response truncation is
+   undesirable as an average case, and assuming mostly IPv4-only
+   reachability (only A RRs exist, not AAAA RRs).
+
+   4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
+   prototypical delegation that currently contains thirteen (13) IPv4
+   nameserver addresses (A RRs) for thirteen (13) nameserver names under a
+   common parent, would not have a significant negative operational impact
+   on the domain name system.
+
+   5 - Source Code
+
+   #!/usr/bin/perl
+   #
+   # SYNOPSIS
+   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
+   #        if all queries are assumed to have zone suffux, such as "jp" in
+   #     JP TLD servers, specify it in -z option
+   #
+   use strict;
+   use Getopt::Std;
+   my ($sz_msg) = (512);
+   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
+   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
+   my (%namedb, $name, $nssect, %opts, $optz);
+   my $n_ns = 0;
+
+
+
+
+   Expires December 2005                                           [Page 6]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   getopt('z', opts);
+   if (defined($opts{'z'})) {
+        server_name_len($opts{'z'}); # just register it
+   }
+
+   foreach $name (@ARGV) {
+        my $len;
+        $n_ns++;
+        $len = server_name_len($name);
+           print "$name requires $len bytes\n";
+        $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
+   }
+   print "# of NS: $n_ns\n";
+   arsect(255, $nssect, $n_ns, "maximum");
+   arsect(64, $nssect, $n_ns, "average");
+
+   sub server_name_len {
+       my ($name) = @_;
+       my (@labels, $len, $n, $suffix);
+
+       $name =~ tr/A-Z/a-z/;
+       @labels = split(/./, $name);
+       $len = length(join('.', @labels)) + 2;
+       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
+           $suffix = join('.', @labels);
+           return length($name) - length($suffix) + $sz_ptr
+               if (defined($namedb{$suffix}));
+           $namedb{$suffix} = 1;
+       }
+       return $len;
+   }
+
+   sub arsect {
+       my ($sz_query, $nssect, $n_ns, $cond) = @_;
+       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
+       $ansect = $sz_query + 1 + $sz_type + $sz_class;
+       $space = $sz_msg - $sz_header - $ansect - $nssect;
+       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
+       $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
+       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
+       printf "For %s size query (%d byte):\n", $cond, $sz_query;
+       printf "if only A is considered:     ";
+       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
+       printf "if A and AAAA are condered:  ";
+       printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
+
+
+
+   Expires December 2005                                           [Page 7]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+       printf "if prefer_glue A is assumed: ";
+       printf "# of A is %d, # of AAAA is %d (%s)\n",
+           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
+   }
+
+   sub judge {
+       my ($n, $n_ns) = @_;
+       return "green" if ($n >= $n_ns);
+       return "yellow" if ($n >= 2);
+       return "orange" if ($n == 1);
+       return "red";
+   }
+
+   sub atmost {
+       my ($a, $b) = @_;
+       return 0 if ($a < 0);
+       return $b if ($a > $b);
+       return $a;
+   }
+
+   Security Considerations
+
+   The recommendations contained in this document have no known security
+   implications.
+
+   IANA Considerations
+
+   This document does not call for changes or additions to any IANA
+   registry.
+
+   IPR Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except as
+   set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
+   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+   Expires December 2005                                           [Page 8]
+
+   INTERNET-DRAFT                  July 2005                       RESPSIZE
+
+
+   Authors' Addresses
+
+   Paul Vixie
+      950 Charter Street
+      Redwood City, CA 94063
+      +1 650 423 1301
+      vixie@isc.org
+
+   Akira Kato
+      University of Tokyo, Information Technology Center
+      2-11-16 Yayoi Bunkyo
+      Tokyo 113-8658, JAPAN
+      +81 3 5841 2750
+      kato@wide.ad.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+   Expires December 2005                                           [Page 9]
+
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt
new file mode 100644
index 0000000..c6ec7e4
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-serverid-06.txt
@@ -0,0 +1,618 @@
+
+
+
+
+Network Working Group                                           S. Woolf
+Internet-Draft                         Internet Systems Consortium, Inc.
+Expires: September 6, 2006                                     D. Conrad
+                                                           Nominum, Inc.
+                                                           March 5, 2006
+
+
+    Requirements for a Mechanism Identifying a Name Server Instance
+                      draft-ietf-dnsop-serverid-06
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 6, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  A standardized mechanism to
+   determine the identity of a name server responding to a particular
+   query would be useful, particularly as a diagnostic aid for
+   administrators.  Existing ad hoc mechanisms for addressing this need
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 1]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+   have some shortcomings, not the least of which is the lack of prior
+   analysis of exactly how such a mechanism should be designed and
+   deployed.  This document describes the existing convention used in
+   some widely deployed implementations of the DNS protocol, including
+   advantages and disadvantages, and discusses some attributes of an
+   improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 2]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+1.  Introduction and Rationale
+
+   Identifying which name server is responding to queries is often
+   useful, particularly in attempting to diagnose name server
+   difficulties.  This is most obviously useful for authoritative
+   nameservers in the attempt to diagnose the source or prevalence of
+   inaccurate data, but can also conceivably be useful for caching
+   resolvers in similar and other situations.  Furthermore, the ability
+   to identify which server is responding to a query has become more
+   useful as DNS has become more critical to more Internet users, and as
+   network and server deployment topologies have become more complex.
+
+   The traditional means for determining which of several possible
+   servers is answering a query has traditionally been based on the use
+   of the server's IP address as a unique identifier.  However, the
+   modern Internet has seen the deployment of various load balancing,
+   fault-tolerance, or attack-resistance schemes such as shared use of
+   unicast IP addresses as documented in [RFC3258].  An unfortunate side
+   effect of these schemes has been to make the use of IP addresses as
+   identifiers somewhat problematic.  Specifically, a dedicated DNS
+   query may not go to the same server as answered a previous query,
+   even though sent to the same IP address.  Non-DNS methods such as
+   ICMP ping, TCP connections, or non-DNS UDP packets (such as those
+   generated by tools like "traceroute"), etc., may well be even less
+   certain to reach the same server as the one which receives the DNS
+   queries.
+
+   There is a well-known and frequently-used technique for determining
+   an identity for a nameserver more specific than the possibly-non-
+   unique "server that answered the query I sent to IP address XXX".
+   The widespread use of the existing convention suggests a need for a
+   documented, interoperable means of querying the identity of a
+   nameserver that may be part of an anycast or load-balancing cluster.
+   At the same time, however, it also has some drawbacks that argue
+   against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 3]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+2.  Existing Conventions
+
+   For some time, the commonly deployed Berkeley Internet Name Domain
+   implementation of the DNS protocol suite from the Internet Systems
+   Consortium [BIND] has supported a way of identifying a particular
+   server via the use of a standards-compliant, if somewhat unusual, DNS
+   query.  Specifically, a query to a recent BIND server for a TXT
+   resource record in class 3 (CHAOS) for the domain name
+   "HOSTNAME.BIND." will return a string that can be configured by the
+   name server administrator to provide a unique identifier for the
+   responding server.  (The value defaults to the result of a
+   gethostname() call).  This mechanism, which is an extension of the
+   BIND convention of using CHAOS class TXT RR queries to sub-domains of
+   the "BIND." domain for version information, has been copied by
+   several name server vendors.
+
+   A refinement to the BIND-based mechanism, which dropped the
+   implementation-specific string, replaces ".BIND" with ".SERVER".
+   Thus the query string to learn the unique name of a server may be
+   queried as "ID.SERVER".
+
+   (For reference, the other well-known name used by recent versions of
+   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
+   query for a CHAOS TXT RR for this name will return an
+   administratively defined string which defaults to the version of the
+   server responding.  This is, however, not generally implemented by
+   other vendors.)
+
+2.1.  Advantages
+
+   There are several valuable attributes to this mechanism, which
+   account for its usefulness.
+
+   1.  The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
+       within the DNS protocol itself.  An identification mechanism that
+       relies on the DNS protocol is more likely to be successful
+       (although not guaranteed) in going to the same system as a
+       "normal" DNS query.
+
+   2.  Since the identity information is requested and returned within
+       the DNS protocol, it doesn't require allowing any other query
+       mechanism to the server, such as holes in firewalls for
+       otherwise-unallowed ICMP Echo requests.  Thus it is likely to
+       reach the same server over a path subject to the same routing,
+       resource, and security policy as the query, without any special
+       exceptions to site security policy.
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 4]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+   3.  It is simple to configure.  An administrator can easily turn on
+       this feature and control the results of the relevant query.
+
+   4.  It allows the administrator complete control of what information
+       is given out in the response, minimizing passive leakage of
+       implementation or configuration details.  Such details are often
+       considered sensitive by infrastructure operators.
+
+   5.  Hypothetically, since it's an ordinary DNS record and the
+       relevant DNSSEC RRs are class independent, the id.server response
+       RR could be signed, which has the advantages described in
+       [RFC4033].
+
+2.2.  Disadvantages
+
+   At the same time, there are some serious drawbacks to the CHAOS/TXT
+   query mechanism that argue against standardizing it as it currently
+   operates.
+
+   1.  It requires an additional query to correlate between the answer
+       to a DNS query under normal conditions and the supposed identity
+       of the server receiving the query.  There are a number of
+       situations in which this simply isn't reliable.
+
+   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
+       to one zone.  While CHAOS class is defined in [RFC1034] and
+       [RFC1035], it's not clear that supporting it solely for this
+       purpose is a good use of the namespace or of implementation
+       effort.
+
+   3.  The initial and still common form, using .BIND, is implementation
+       specific.  BIND is one DNS implementation.  At the time of this
+       writing, it is probably the most prevalent for authoritative
+       servers.  This does not justify standardizing on its ad hoc
+       solution to a problem shared across many operators and
+       implementors.  Meanwhile, the proposed refinement changes the
+       string but preserves the ad hoc CHAOS/TXT mechanism.
+
+   4.  There is no convention or shared understanding of what
+       information an answer to such a query for a server identity could
+       or should include, including a possible encoding or
+       authentication mechanism.
+
+   The first of the listed disadvantages may be technically the most
+   serious.  It argues for an attempt to design a good answer to the
+   problem that "I need to know what nameserver is answering my
+   queries", not simply a convenient one.
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 5]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+2.3.  Characteristics of an Implementation Neutral Convention
+
+   The discussion above of advantages and disadvantages to the
+   HOSTNAME.BIND mechanism suggest some requirements for a better
+   solution to the server identification problem.  These are summarized
+   here as guidelines for any effort to provide appropriate protocol
+   extensions:
+
+   1.  The mechanism adopted must be in-band for the DNS protocol.  That
+       is, it needs to allow the query for the server's identifying
+       information to be part of a normal, operational query.  It should
+       also permit a separate, dedicated query for the server's
+       identifying information.  But it should preserve the ability of
+       the CHAOS/TXT query-based mechanism to work through firewalls and
+       in other situations where only DNS can be relied upon to reach
+       the server of interest.
+
+   2.  The new mechanism should not require dedicated namespaces or
+       other reserved values outside of the existing protocol mechanisms
+       for these, i.e. the OPT pseudo-RR.  In particular, it should not
+       propagate the existing drawback of requiring support for a CLASS
+       and top level domain in the authoritative server (or the querying
+       tool) to be useful.
+
+   3.  Support for the identification functionality should be easy to
+       implement and easy to enable.  It must be easy to disable and
+       should lend itself to access controls on who can query for it.
+
+   4.  It should be possible to return a unique identifier for a server
+       without requiring the exposure of information that may be non-
+       public and considered sensitive by the operator, such as a
+       hostname or unicast IP address maintained for administrative
+       purposes.
+
+   5.  It should be possible to authenticate the received data by some
+       mechanism analogous to those provided by DNSSEC.  In this
+       context, the need could be met by including encryption options in
+       the specification of a new mechanism.
+
+   6.  The identification mechanism should not be implementation-
+       specific.
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 6]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+3.  IANA Considerations
+
+   This document proposes no specific IANA action.  Protocol extensions,
+   if any, to meet the requirements described are out of scope for this
+   document.  A proposed extension, specified and adopted by normal IETF
+   process, is described in [NSID], including relevant IANA action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 7]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+4.  Security Considerations
+
+   Providing identifying information as to which server is responding to
+   a particular query from a particular location in the Internet can be
+   seen as information leakage and thus a security risk.  This motivates
+   the suggestion above that a new mechanism for server identification
+   allow the administrator to disable the functionality altogether or
+   partially restrict availability of the data.  It also suggests that
+   the serverid data should not be readily correlated with a hostname or
+   unicast IP address that may be considered private to the nameserver
+   operator's management infrastructure.
+
+   Propagation of protocol or service meta-data can sometimes expose the
+   application to denial of service or other attack.  As DNS is a
+   critically important infrastructure service for the production
+   Internet, extra care needs to be taken against this risk for
+   designers, implementors, and operators of a new mechanism for server
+   identification.
+
+   Both authentication and confidentiality of serverid data are
+   potentially of interest to administrators-- that is, operators may
+   wish to make serverid data available and reliable to themselves and
+   their chosen associates only.  This would imply both an ability to
+   authenticate it to themselves and keep it private from arbitrary
+   other parties.  This led to Characteristics 4 and 5 of an improved
+   solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 8]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+5.  Acknowledgements
+
+   The technique for host identification documented here was initially
+   implemented by Paul Vixie of the Internet Software Consortium in the
+   Berkeley Internet Name Daemon package.  Comments and questions on
+   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+   ICANN Root Server System Advisory Committee.  The newest version
+   takes a significantly different direction from previous versions,
+   owing to discussion among contributors to the DNSOP working group and
+   others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
+   Weiler, and Rob Austein.
+
+6.  References
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        RFC 1034, STD 0013, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", RFC 1035, STD 0013, November 1987.
+
+   [3]  Hardie, T., "Distributing Authoritative Name Servers via Shared
+        Unicast Addresses", RFC 3258, April 2002.
+
+   [4]  ISC, "BIND 9 Configuration Reference".
+
+   [5]  Austein, S., "DNS Name Server Identifier Option (NSID)",
+        Internet Drafts http://www.ietf.org/internet-drafts/
+        draft-ietf-dnsext-nsid-01.txt, January 2006.
+
+   [6]  Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 9]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+Authors' Addresses
+
+   Suzanne Woolf
+   Internet Systems Consortium, Inc.
+   950 Charter Street
+   Redwood City, CA  94063
+   US
+
+   Phone: +1 650 423-1333
+   Email: woolf@isc.org
+   URI:   http://www.isc.org/
+
+
+   David Conrad
+   Nominum, Inc.
+   2385 Bay Road
+   Redwood City, CA  94063
+   US
+
+   Phone: +1 1 650 381 6003
+   Email: david.conrad@nominum.com
+   URI:   http://www.nominum.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006              [Page 10]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006              [Page 11]
+
+
diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
new file mode 100644
index 0000000..3353b3b
--- /dev/null
+++ b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
@@ -0,0 +1,1588 @@
+
+                                                            Mark Foster 
+Internet Draft                                              Tom McGarry 
+Document: <draft-ietf-enum-e164-gstn-np-05.txt>                James Yu 
+                                                          NeuStar, Inc. 
+Category: Informational                                   June 24, 2002 
+ 
+ 
+              Number Portability in the GSTN: An Overview 
+ 
+ 
+Status of this Memo 
+ 
+   This document is an Internet-Draft and is in full conformance with 
+   all provisions of Section 10 of RFC2026 [RFC].  
+ 
+   Internet-Drafts are working documents of the Internet Engineering 
+   Task Force (IETF), its areas, and its working groups. Note that 
+   other groups may also distribute working documents as Internet-
+   Drafts. Internet-Drafts are draft documents valid for a maximum of 
+   six months and may be updated, replaced, or obsoleted by other 
+   documents at any time. It is inappropriate to use Internet- Drafts 
+   as reference material or to cite them other than as "work in 
+   progress."  
+    
+   The list of current Internet-Drafts can be accessed at 
+   http://www.ietf.org/ietf/1id-abstracts.txt. 
+     
+   The list of Internet-Draft Shadow Directories can be accessed at 
+   http://www.ietf.org/shadow.html. 
+    
+ 
+   Copyright Notice 
+ 
+      Copyright (C) The Internet Society (2002).  All rights reserved. 
+    
+    
+   Abstract 
+    
+   This document provides an overview of E.164 telephone number 
+   portability (NP) in the Global Switched Telephone Network (GSTN).    
+   NP is a regulatory imperative seeking to liberalize local telephony 
+   service competition, by enabling end-users to retain telephone 
+   numbers while changing service providers.  NP changes the 
+   fundamental nature of a dialed E.164 number from a hierarchical 
+   physical routing address to a virtual address, thereby requiring the 
+   transparent translation of the later to the former.  In addition, 
+   there are various regulatory constraints that establish relevant 
+   parameters for NP implementation, most of which are not network 
+   technology specific.  Consequently, the implementation of NP 
+   behavior consistent with applicable regulatory constraints, as well 
+   as the need for interoperation with the existing GSTN NP 
+   implementations, are relevant topics for numerous areas of IP 
+   telephony work-in-progress at IETF. 
+  
+Foster,McGarry,Yu         Expired on December 23, 2002        [Page 1] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+    
+   Table of Contents 
+    
+    1.  Introduction ...............................................  2 
+    2.  Abbreviations and Acronyms .................................  4 
+    3.  Types of Number Portability ................................  5 
+    4.  Service Provider Number Portability Schemes ................  7 
+       4.1   All Call Query (ACQ) ..................................  7 
+       4.2   Query on Release (QoR) ................................  8 
+       4.3   Call Dropback .........................................  9 
+       4.4   Onward Routing (OR) ...................................  9 
+       4.5   Comparisons of the Four Schemes ....................... 10 
+    5.  Database Queries in the NP Environment ..................... 11 
+       5.1   U.S. and Canada ....................................... 12 
+       5.2   Europe ................................................ 13 
+    6.  Call Routing in the NP Environment ......................... 14 
+       6.1   U.S. and Canada ....................................... 14 
+       6.2   Europe ................................................ 15 
+    7.  NP Implementations for Geographic E.164 Numbers ............ 17 
+    8.  Number Conservation Method Enabled By NP ................... 20 
+       8.1   Block Pooling ......................................... 20 
+       8.2   ITN Pooling ........................................... 21 
+    9.  Potential Implications ..................................... 21 
+   10.  Security Considerations .................................... 24 
+   11.  IANA Considerations ........................................ 24 
+   12.  Normative References ....................................... 24 
+   13.  Informative References ..................................... 25 
+   14.  Acknowledgement ............................................ 25 
+   15.  AuthorsË Addresses ......................................... 25 
+    
+ 
+    
+1. Introduction 
+    
+   This document provides an overview of E.164 telephone number 
+   portability in the Global Switched Telephone Network (GSTN).  There 
+   are considered to be three types of number portability (NP): service 
+   provider portability (SPNP), location portability (not to be 
+   confused with terminal mobility), and service portability. 
+    
+   Service provider portability (SPNP), the focus of the present draft, 
+   is a regulatory imperative in many countries seeking to liberalize 
+   telephony service competition, especially local service.  
+   Historically, local telephony service (as compared to long distance 
+   or international service) has been regulated as a utility-like form 
+   of service.  While a number of countries had begun liberalization 
+   (e.g. privatization, de-regulation, or re-regulation) some years 
+   ago, the advent of NP is relatively recent (since ~1995). 
+    
+   E.164 numbers can be non-geographic and geographic numbers.  Non-
+   geographic numbers do not reveal the locations information of those 
+   numbers.  Geographic E.164 numbers were intentionally designed as 
+   hierarchical routing addresses which could systematically be digit-
+   analyzed to ascertain the country, serving network provider, serving 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 2] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   end-office switch, and specific line of the called party.  As such, 
+   without NP a subscriber wishing to change service providers would 
+   incur a number change as a consequence of being served off of a 
+   different end-office switch operated by the new service provider.  
+   The cost and convenience impact to the subscriber of changing 
+   numbers is seen as barrier to competition.  Hence NP has become 
+   associated with GSTN infrastructure enhancements associated with a 
+   competitive environment driven by regulatory directives. 
+    
+   Forms of SPNP have been deployed or are being deployed widely in the 
+   GSTN in various parts of the world, including the U.S., Canada, 
+   Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). 
+   Other regions, such as South America (e.g. Brazil) are actively 
+   considering it. 
+    
+   Implementation of NP within a national telephony infrastructure 
+   entails potentially significant changes to numbering administration, 
+   network element signaling, call routing and processing, billing, 
+   service management, and other functions. 
+    
+   NP changes the fundamental nature of a dialed E.164 number from a 
+   hierarchical physical routing address to a virtual address.  NP 
+   implementations attempt to encapsulate the impacts to the GSTN and 
+   make NP transparent to subscribers by incorporating a translation 
+   function to map a dialed, potentially ported E.164 address, into a 
+   network routing address (either a number prefix or another E.164 
+   address) which can be hierarchically routed. 
+    
+   This is roughly analogous to the use of network address translation 
+   on IP addresses to enable IP address portability by containing the 
+   impact of the address change to the edge of the network and retain 
+   the use of CIDR blocks in the core which can be route aggregated by 
+   the network service provider to the rest of the internet. 
+    
+   NP bifurcates the historical role of a subscriberËs E.164 address 
+   into two or more data elements (a dialed or virtual address, and a 
+   network routing address) that must be made available to network 
+   elements through an NP translations database, carried by forward 
+   call signaling, and recorded on call detail records.  Not only is 
+   call processing and routing affected, but also so is SS7/C7 
+   messaging.  A number of TCAP-based SS7 messaging sets utilize an 
+   E.164 address as an application-level network element address in the 
+   global title address (GTA) field of the SCCP message header.  
+   Consequently, SS7/C7 signaling transfer points (STPs) and gateways 
+   need to be able to perform n-digit global title translation (GTT) to 
+   translate a dialed E.164 address into its network address 
+   counterpart via the NP database. 
+    
+   In addition, there are various national regulatory constraints that 
+   establish relevant parameters for NP implementation, most of which 
+   are not network technology specific.  Consequently, implementations 
+   of NP behavior in IP telephony consistent with applicable regulatory 
+   constraints, as well as the need for interoperation with the 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 3] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   existing GSTN NP implementations, are relevant topics for numerous 
+   areas of IP telephony work-in-progress at IETF. 
+    
+   This document describes three types of number portability and the 
+   four schemes that have been standardized to support SPNP for 
+   geographic E.164 numbersspecifically.  Following that, specific 
+   information regarding the call routing and database query 
+   implementations are described for several regions (North American 
+   and Europe) and industries (wireless vs. wireline). The Number 
+   Portability Database (NPDB) interfaces and the call routing schemes 
+   that are used in the North America and Europe are described to show 
+   the variety of standards that may be implemented worldwide.  A 
+   glance of the NP implementations worldwide is provided.  Number 
+   pooling is briefly discussed to show how NP is being enhanced in the 
+   U.S. to conserve North American area codes.  The conclusion briefly 
+   touches the potential impacts of NP on IP & Telecommunications 
+   Interoperability.  Appendix A provides some specific technical and 
+   regulatory information on NP in North America.  Appendix B describes 
+   the number portability administration process that manages the 
+   number portability database in North America. 
+    
+    
+2. Abbreviations and Acronyms 
+    
+   ACQ     All Call Query 
+   AIN     Advanced Intelligent Network 
+   AMPS    Advanced Mobile Phone System 
+   ANSI    American National Standards Institute 
+   CDMA    Code Division Multiple Access 
+   CdPA    Called Party Address 
+   CdPN    Called Party Number 
+   CH      Code Holder 
+   CMIP    Common Management Information Protocol 
+   CS1     Capability Set 1 
+   CS2     Capability Set 2 
+   DN      Directory Number 
+   DNS     Domain Name System 
+   ETSI    European Technical Standards Institute 
+   FCI     Forward Call Indicator 
+   GAP     Generic Address Parameter 
+   GMSC    Gateway Mobile Services Switching Center or Gateway Mobile 
+           Switching Center 
+   GSM     Global System for Mobile Communications 
+   GSTN    Global Switched Telephone Network 
+   GW      Gateways 
+   HLR     Home Location Register 
+   IAM     Initial Address Message 
+   IETF    Internet Engineering Task Force 
+   ILNP    Interim LNP 
+   IN      Intelligent Network 
+   INAP    Intelligent Network Application Part 
+   INP     Interim NP     
+   IP      Internet Protocol 
+   IS-41   Interim Standards Number 41 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 4] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   ISDN    Integrated Services Digital Network 
+   ISUP    ISDN User Part 
+   ITN     Individual Telephony Number  
+   ITU     International Telecommunication Union 
+   ITU-TS  ITU-Telecommunication Sector 
+   LDAP    Lightweight Directory Access Protocol  
+   LEC     Local Exchange Carrier 
+   LERG    Local Exchange Routing Guide 
+   LNP     Local Number Portability 
+   LRN     Location Routing Number 
+   MAP     Mobile Application Part 
+   MNP     Mobile Number Portability 
+   MSRN    Mobile Station Roaming Number 
+   MTP     Message Transfer Part 
+   NANP    North American Numbering Plan 
+   NP      Number Portability 
+   NPDB    Number Portability Database 
+   NRN     Network Routing Number 
+   OR      Onward Routing 
+   OSS     Operation Support System 
+   PCS     Personal Communication Services 
+   PNTI    Ported Number Translation Indicator 
+   PODP    Public Office Dialing Plan 
+   PUC     Public Utility Commission 
+   QoR     Query on Release 
+   RN      Routing Number 
+   RTP     Return to Pivot 
+   SCCP    Signaling Connection Control Part 
+   SCP     Service Control Point  
+   SIP     Session Initiation Protocol 
+   SMR     Special Mobile Radio 
+   SMS     Service Management System 
+   SPNP    Service Provider Number Portability 
+   SRF     Signaling Relaying Function 
+   SRI     Send Routing Information 
+   SS7     Signaling System Number 7 
+   STP     Signaling Transfer Point 
+   TCAP    Transaction Capabilities Application Part 
+   TDMA    Time Division Multiple Access 
+   TN      Telephone Number 
+   TRIP    Telephony Routing Information Protocol 
+   URL     Universal Resource Locator 
+   U.S.    United States 
+    
+    
+3. Types of Number Portability 
+    
+   As there are several types of E.164 numbers (telephone numbers, or 
+   just TN) in the GSTN, there are correspondingly several types of 
+   E.164 NP in the GSTN.  First there are so-call non-geographic E.164 
+   numbers, commonly used for service-specific applications such as 
+   freephone (800 or 0800).  Portability of these numbers is called 
+   non-geographic number portability (NGNP).  NGNP, for example, was 
+   deployed in the U.S. in 1986-92. 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 5] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+    
+   Geographic number portability, which includes traditional fixed or 
+   wireline numbers as well as mobile numbers which are allocated out 
+   of geographic number range prefixes, is called NP or GNP or in the 
+   U.S. local number portability (LNP). 
+    
+   Number portability allows the telephony subscribers in the Global 
+   Switched Telephone Network (GSTN) to keep their phone numbers when 
+   they change their service providers or subscribed services, or when 
+   they move to a new location.   
+    
+   The ability to change the service provider while keeping the same 
+   phone number is called service provider portability (SPNP) also 
+   known as "operator portability." 
+    
+   The ability to change the subscriberËs fixed service location while 
+   keeping the same phone number is called location portability. 
+    
+   The ability to change the subscribed services (e.g., from the plain 
+   old telephone service to Integrated Services Digital Network (ISDN) 
+   services) while keeping the same phone number is called service 
+   portability.  Another aspect of service portability is to allow the 
+   subscribers to enjoy the subscribed services in the same way when 
+   they roam outside their home networks as is supported by the 
+   cellular/wireless networks. 
+    
+   In addition, mobile number portability (MNP) refers to specific NP 
+   implementation in mobile networks either as part of a broader NP 
+   implementation in the GSTN or on a stand-alone basis.  Where 
+   interoperation of LNP and MNP is supported, service portability 
+   between fixed and mobile service types is possible. 
+    
+   At present, SPNP has been the primary form of NP deployed due to its 
+   relevance in enabling local service competition. 
+    
+   Also in use in the GSTN are the terms interim NP (INP) or Interim 
+   LNP (ILNP) and true NP.  Interim NP usually refers to the use of 
+   remote call forwarding-like measures to forward calls to ported 
+   numbers through the donor network to the new service network.  These 
+   are considered interim relative to true NP, which seeks to remove 
+   the donor network or old service provider from the call or signaling 
+   path altogether.  Often the distinction between interim and true NP 
+   is a national regulatory matter relative to the 
+   technical/operational requirements imposed on NP in that country. 
+    
+   Implementations of true NP in certain countries (e.g. U.S., Canada, 
+   Spain, Belgium, Denmark) may pose specific requirements for IP 
+   telephony implementations as a result of regulatory and industry 
+   requirements for providing call routing and signaling independent of 
+   the donor network or last previous serving network. 
+    
+    
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 6] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+ 
+4. Service Provider Number Portability Schemes 
+    
+   Four schemes can be used to support service provider portability and 
+   are briefly described below.  But first, some further terms are 
+   introduced. 
+    
+   The donor network is the network that first assigned a telephone 
+   number (e.g., TN +1-202-533-1234) to a subscriber, out of a number 
+   range administratively (e.g., +1 202-533) assigned to it.  The 
+   current service provider (new SP) or new serving network is the 
+   network that currently serves the ported number. The old serving 
+   network (or old SP) is the network that previously served the ported 
+   number before the number was ported to the new serving network. 
+   Since a TN can port a number of times, the old SP is not necessarily 
+   the same as the donor network, except for the first time the TN 
+   ports away, or if the TN ports back into the donor network and away 
+   again.  While the new SP and old SP roles are transitory as a TN 
+   ports around, the donor network is always the same for any 
+   particular TN based on the service provider to whom the subtending 
+   number range was administratively assigned.  See the discussion 
+   below on number pooling, as this enhancement to NP further 
+   bifurcates the role of donor network into two (the number range or 
+   code holder network, and the block holder network). 
+    
+   To simplify the illustration, all the transit networks are ignored, 
+   the originating or donor network is the one that performs the 
+   database queries or call redirection, and the dialed directory 
+   number (TN) has been ported out of the donor network before.  
+    
+   It is assumed that the old serving network, the new serving network 
+   and the donor network are different networks so as to show which 
+   networks are involved in call handling and routing and database 
+   queries in each of four schemes.  Please note that the port of the 
+   number (process of moving it from one network to another) happened 
+   prior to the call setup and is not included in the call steps.  
+   Information carried in the signaling messages to support each of the 
+   four schemes is not discussed to simplify the explanation. 
+    
+    
+4.1 All Call Query (ACQ) 
+    
+   Figure 1 shows the call steps for the ACQ scheme.  Those call steps 
+   are as follows: 
+ 
+   (1) The Originating Network receives a call from the caller and 
+       sends a query to a centrally administered Number Portability 
+       Database (NPDB), a copy of which is usually resident on a 
+       network element within its network or through a third party 
+       provider. 
+   (2) The NPDB returns the routing number associated with the dialed 
+       directory number.  The routing number is discussed later in 
+       Section 6. 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 7] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   (3) The Originating Network uses the routing number to route the 
+       call to the new serving network. 
+    
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    ported   | Old Serv. | 
+   |    NPDB     |    +-------->|  Network  |<------------|  Network  | 
+   +-------------+    |         +-----------+             +-----------+ 
+       ^  |           | 
+       |  |           | 
+      1|  |         3.| 
+       |  | 2.        | 
+       |  |           | 
+       |  v           | 
+    +----------+      |         +----------+           +----------+ 
+    |   Orig.  |------+         |   Donor  |           | Internal | 
+    |  Network |                |  Network |           |   NPDB   | 
+    +----------+                +----------+           +----------+ 
+    
+    
+              Figure 1 - All Call Query (ACQ) Scheme. 
+ 
+ 
+4.2 Query on Release (QoR) 
+ 
+  Figure 2 shows the call steps for the QoR scheme.  Those call steps 
+  are as follows: 
+    
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    ported   | Old Serv. | 
+   |    NPDB     |              |  Network  |<------------|  Network  | 
+   +-------------+              +-----------+             +-----------+ 
+       ^  |                          ^ 
+       |  | 4.                       | 
+     3.|  |              5.          | 
+       |  |   +----------------------+ 
+       |  |   | 
+       |  v   | 
+    +----------+      2.        +----------+           +----------+ 
+    |   Orig.  |<---------------|   Donor  |           | Internal | 
+    |  Network |--------------->|  Network |           |   NPDB   | 
+    +----------+      1.        +----------+           +----------+ 
+    
+                   
+                Figure 2 - Query on Release (QoR) Scheme. 
+    
+   (1) The Originating Network receives a call from the caller and 
+       routes the call to the donor network. 
+   (2) The donor network releases the call and indicates that the 
+       dialed directory number has been ported out of that switch. 
+   (3) The Originating Network sends a query to its copy of the 
+       centrally administered NPDB. 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 8] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   (4) The NPDB returns the routing number associated with the dialed 
+       directory number.   
+   (5) The Originating Network uses the routing number to route the 
+       call to the new serving network. 
+    
+    
+4.3 Call Dropback 
+    
+  Figure 3 shows the call steps for the Dropback scheme.  This scheme 
+  is also known as "Return to Pivot (RTP)."  Those call steps are as 
+  follows: 
+    
+   (1) The Originating Network receives a call from the caller and 
+       routes the call to the donor network. 
+   (2) The donor network detects that the dialed directory number has 
+       been ported out of the donor switch and checks with an internal 
+       network-specific NPDB.  
+   (3) The internal NPDB returns the routing number associated with the 
+       dialed directory number. 
+   (4) The donor network releases the call by providing the routing 
+       number. 
+   (5) The Originating Network uses the routing number to route the 
+       call to the new serving network. 
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    porting  | Old Serv. | 
+   |    NPDB     |              |  Network  |<------------|  Network  | 
+   +-------------+              +-----------+             +-----------+ 
+                                    /\ 
+                                     | 
+                           5.        | 
+            +------------------------+ 
+            | 
+            | 
+    +----------+       4.       +----------+     3.    +----------+ 
+    |   Orig.  |<---------------|   Donor  |<----------| Internal | 
+    |  Network |--------------->|  Network |---------->|   NPDB   | 
+    +----------+      1.        +----------+    2.     +----------+ 
+    
+                   
+                      Figure 3 - Dropback Scheme. 
+    
+    
+4.4 Onward Routing (OR) 
+    
+  Figure 4 shows the call steps for the OR scheme.  Those call steps 
+  are as follows: 
+    
+   (1) The Originating Network receives a call from the caller and 
+       routes the call to the donor network. 
+   (2) The donor network detects that the dialed directory number has 
+       been ported out of the donor switch and checks with an internal 
+       network-specific NPDB.  
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 9] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   (3) The internal NPDB returns the routing number associated with the 
+       dialed directory number. 
+   (4) The donor network uses the routing number to route the call to 
+       the new serving network. 
+ 
+    
+   +-------------+              +-----------+    Number   +-----------+ 
+   | Centralized |              | New Serv. |    porting  | Old Serv. | 
+   |    NPDB     |              |  Network  |<------------|  Network  | 
+   +-------------+              +-----------+             +-----------+ 
+                                    /\ 
+                                     | 
+                                   4.| 
+                                     | 
+    +----------+                +----------+     3.    +----------+ 
+    |   Orig.  |                |   Donor  |<----------| Internal | 
+    |  Network |--------------->|  Network |---------->|   NPDB   | 
+    +----------+      1.        +----------+    2.     +----------+ 
+    
+                   
+                 Figure 4 - Onward Routing (OR) Scheme. 
+ 
+4.5 Comparisons of the Four Schemes 
+    
+   Only the ACQ scheme does not involve the donor network when routing 
+   the call to the new serving network of the dialed ported number.  
+   The other three schemes involve call setup to or signaling with the 
+   donor network.   
+    
+   Only the OR scheme requires the setup of two physical call segments, 
+   one from the Originating Network to the donor network and the other 
+   from the donor network to the new serving network.  The OR scheme is 
+   the least efficient in terms of using the network transmission 
+   facilities.  The QoR and Dropback schemes set up calls to the donor 
+   network first but release the call back to the Originating Network 
+   that then initiates a new call to the Current Serving Network.  For 
+   the QoR and Dropback schemes, circuits are still reserved one by one 
+   between the Originating Network and the donor network when the 
+   Originating Network sets up the call towards the donor network.  
+   Those circuits are released one by one when the call is released 
+   from the donor network back to the Originating Network.  The ACQ 
+   scheme is the most efficient in terms of using the switching and 
+   transmission facilities for the call. 
+    
+   Both the ACQ and QoR schemes involve Centralized NPDBs for the 
+   Originating Network to retrieve the routing information.  
+   Centralized NPDB means that the NPDB contains ported number 
+   information from multiple networks.  This is in contrast to the 
+   internal network-specific NPDB that is used for the Dropback and OR 
+   schemes.  The internal NPDB only contains information about the 
+   numbers that were ported out of the donor network.  The internal 
+   NPDB can be a stand-alone database that contains information about 
+   all or some ported-out numbers from the donor network.  It can also 
+   reside on the donor switch and only contains information about those 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 10] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   numbers ported out of the donor switch.  In that case, no query to a 
+   stand-alone internal NPDB is required.  The donor switch for a 
+   particular phone number is the switch to which the number range is 
+   assigned from which that phone number was originally assigned. 
+    
+   For example, number ranges in the North American Numbering Plan 
+   (NANP) are usually assigned in the form of central office codes (CO 
+   codes) comprising a six-digit prefix formatted as a NPA+NXX.  Thus a 
+   switch serving +1-202-533 would typically serve +1-202-533-0000 
+   through +1-202-533-9999. In major cities, switches usually host 
+   several CO codes.  NPA stands for Numbering Plan Area that is also 
+   known as the area code.  It is three-digit long and has the format 
+   of NXX where N is any digit from 2 to 9 and X is any digit from 0 to 
+   9.  NXX in the NPA+NXX format is known as the office code that has 
+   the same format as the NPA.  When a NPA+NXX code is set as 
+   Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a 
+   "portable NPA+NXX" code. 
+    
+   Similarly, in other national E.164 numbering plans, number ranges 
+   cover a contiguous range of numbers within that range.  Once a 
+   number within that range has ported away from the donor network, all 
+   numbers in that range are considered potentially ported and should 
+   be queried in the NPDB. 
+    
+   The ACQ scheme has two versions.  One version is for the Originating 
+   Network to always query the NPDB when a call is received from the 
+   caller regardless whether the dialed directory number belongs to any 
+   number range that is portable or has at least one number ported out. 
+   The other version is to check whether the dialed directory number 
+   belongs to any number range that is portable or has at least one 
+   number ported out.  If yes, an NPDB query is sent. If not, no NPDB 
+   query is sent.  The former performs better when there are many 
+   portable number ranges.  The latter performs better when there are 
+   not too many portable number ranges at the expense of checking every 
+   call to see whether NPDB query is needed.  The latter ACQ scheme is 
+   similar to the QoR scheme except that the QoR scheme uses call setup 
+   and relies on the donor network to indicate "number ported out" 
+   before launching the NPDB query. 
+    
+    
+5. Database Queries in the NP Environment 
+    
+   As indicated earlier, the ACQ and QoR schemes require that a switch 
+   query the NPDB for routing information.  Various standards have been 
+   defined for the switch-to-NPDB interface.  Those interfaces with 
+   their protocol stacks are briefly described below.  The term "NPDB" 
+   is used for a stand-alone database that may support just one or some 
+   or all of the interfaces mentioned below.  The NPDB query contains 
+   the dialed directory number and the NPDB response contains the 
+   routing number.  There are certainly other information that is sent 
+   in the query and response.  The primary interest is to get the 
+   routing number from the NPDB to the switch for call routing. 
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 11] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+5.1 U.S. and Canada 
+    
+   One of the following five NPDB interfaces can be used to query an 
+   NPDB: 
+    
+   (a) Advanced Intelligent Network (AIN) using the American National 
+       Standards Institute (ANSI)  version of the Intelligent Network 
+       Application Part (INAP) [ANSI SS] [ANSI DB].  The INAP is 
+       carried on top of the protocol stack that includes the (ANSI) 
+       Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling 
+       Connection Control Part (SCCP), and ANSI Transaction 
+       Capabilities Application Part (TCAP).  This interface can be 
+       used by the wireline or wireless switches, is specific to the NP 
+       implementation in North America, and is modeled on the Public 
+       Office Dialing Plan (PODP) trigger defined in the Advanced 
+       Intelligent Network (AIN) 0.1 call model.  
+    
+   (b) Intelligent Network (IN), which is similar to the one used for 
+       querying the 800 databases.  The IN protocol is carried on top 
+       of the protocol stack that includes the ANSI MTP Levels 1 
+       through 3, ANSI SCCP, and ANSI TCAP.  This interface can be used 
+       by the wireline or wireless switches. 
+    
+   (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the 
+       protocol stack that includes the ANSI MTP Levels 1 through 3, 
+       ANSI SCCP, and ANSI TCAP.  This interface can be used by the IS-
+       41 based cellular/Personal Communication Services (PCS) wireless 
+       switches (e.g., AMPS, TDMA and CDMA).  Cellular systems use 
+       spectrum at 800 MHz range and PCS systems use spectrum at 1900 
+       MHz range. 
+    
+   (d) Global System for Mobile Communication Mobile Application Part 
+       (GSM MAP) [GSM], which is carried on top of the protocol stack 
+       that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and 
+       International Telecommunication Union - Telecommunication Sector  
+       (ITU-TS) TCAP.  It can be used by the PCS1900 wireless switches 
+       that are based on the GSM technologies.  GSM is a series of 
+       wireless standards defined by the European Telecommunications 
+       Standards Institute (ETSI). 
+    
+   (e) ISUP triggerless translation.  NP translations are performed 
+       transparently to the switching network by the signaling network 
+       (e.g. Signaling Transfer Points (STPs) or signaling gateways).  
+       ISUP IAM messages are examined to determine if the CdPN field 
+       has already been translated, and if not, an NPDB query is 
+       performed, and the appropriate parameters in the IAM message 
+       modified to reflect the results of the translation.   The 
+       modified IAM message is forwarded by the signaling node on to 
+       the designated DPC in a transparent manner to continue call 
+       setup.  The NPDB can be integrated with the signaling node or be 
+       accessed via an API locally or by a query to a remote NPDB using 
+       a proprietary protocol or the schemes described above. 
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 12] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   Wireline switches have the choice of using either (a), (b), or (e).  
+   IS-41 based wireless switches have the choice of using (a), (b), 
+   (c), or (e).  PCS1900 wireless switches have the choice of using 
+   (a), (b), (d), or (e). In the United States, service provider 
+   portability will be supported by both the wireline and wireless 
+   systems, not only within the wireline or wireless domain but also 
+   across the wireline/wireless boundary.  However, this is not true in 
+   Europe where service provider portability is usually supported only 
+   within the wireline or wireless domain, not across the 
+   wireline/wireless boundary due to explicit use of service-specific 
+   number range prefixes.  The reason is to avoid caller confusion 
+   about the call charge. GSM systems in Europe are assigned 
+   distinctive destination network codes, and the caller pays a higher 
+   charge when calling a GSM directory number. 
+    
+      
+5.2 Europe 
+    
+   One of the following two interfaces can be used to query an NPDB: 
+    
+   (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is 
+       carried on top of the protocol stack that includes the ITU-TS 
+       MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. 
+    
+   (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is 
+       carried on top of the protocol stack that includes the ITU-TS 
+       MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, 
+       and ITU-TS TCAP. 
+    
+   Wireline switches have the choice of using either (a) or (b); 
+   however, all the implementations in Europe so far are based on CS1.  
+   As indicated earlier that number portability in Europe does not go 
+   across the wireline/wireless boundary.  The wireless switches can 
+   also use (a) or (b) to query the NPDBs if those NPDBs contains 
+   ported wireless directory numbers.  The term "Mobile Number 
+   Portability (MNP)" is used for the support of service provider 
+   portability by the GSM networks in Europe.  
+    
+   In most, if not all, cases in Europe, the calls to the wireless 
+   directory numbers are routed to the wireless donor network first.  
+   Over there, an internal NPDB is queried to determine whether the 
+   dialed wireless directory number has been ported out or not.  In 
+   this case, the interface to the internal NPDB is not subject to 
+   standardization. 
+
+   MNP in Europe can also be supported via MNP Signaling Relay Function 
+   (MNP-SRF).  Again, an internal NPDB or a database integrated at the 
+   MNP-SRF is used to modify the SCCP Called Party Address parameter in 
+   the GSM MAP messages so that they can be re-directed to the wireless 
+   serving network.   Call routing involving MNP will be explained in 
+   Section 6.2. 
+    
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 13] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+6. Call Routing in the NP Environment 
+ 
+   This section discusses the call routing after the routing 
+   information has been retrieved either through an NPDB query or an 
+   internal database lookup at the donor switch, or from the Integrated 
+   Services Digital Network User Part (ISUP) signaling message (e.g., 
+   for the Dropback scheme).  For the ACQ, QoR and Dropback schemes, it 
+   is the Originating Network that has the routing information and is 
+   ready to route the call.  For the OR scheme, it is the donor network 
+   that has the routing information and is ready to route the call.   
+    
+   A number of triggering schemes may be employed that determine where 
+   in the call path the NPDB query is performed.  In the U.S. an ŸN-1÷ 
+   policy is used, which essentially says that for domestic calls, the 
+   originating local carriers performs the query, otherwise, the long 
+   distance carrier is expected to.  To ensure independence of the 
+   actual trigger policy employed in any one carrier, forward call 
+   signaling is used to flag that an NPDB query has already been 
+   performed and to therefore suppress any subsequent NP triggers that 
+   may be encountered in downstream switches, in downstream networks.  
+   This allows the earliest able network in the call path to perform 
+   the query without introducing additional costs and call setup delays 
+   were redundant queries performed downstream. 
+    
+     
+6.1 U.S. and Canada 
+    
+   In the U.S. and Canada, a ten-digit North American Numbering Plan 
+   (NANP) number called Location Routing Number (LRN) is assigned to 
+   every switch involved in NP.  In the NANP, a switch is not reachable 
+   unless it has a unique number range (CO code) assigned to it.  
+   Consequently, the LRN for a switch is always assigned out of a CO 
+   code that is assigned to that switch. 
+    
+   The LRN assigned to a switch currently serving a particular ported 
+   telephone number is returned as the network routing address in the 
+   NPDB response.  The service portability scheme that was adopted in 
+   the North America is very often referred to as the LRN scheme or 
+   method. 
+    
+   LRN serves as a network address for terminating calls served off 
+   that switch using ported numbers.  The LRN is assigned by the switch 
+   operator using any of the unique CO codes (NPA+NXX) assigned to that 
+   switch.  The LRN is considered a non-dialable address, as the same 
+   10-digit number value may be assigned to a line on that switch.  A 
+   switch may have more than one LRN. 
+    
+   During call routing/processing, a switch performs an NPDB query to 
+   obtain the LRN associated with the dialed directory number. NPDB 
+   queries are performed for all the dialed directory numbers whose 
+   NPA+NXX codes are marked as portable NPA+NXX at that switch. When 
+   formulating the ISUP Initial Address Message (IAM) to be sent to the 
+   next switch, the switch puts the ten-digit LRN in the ISUP Called 
+   Party Number (CdPN) parameter and the originally dialed directory 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 14] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   number in the ISUP Generic Address parameter (GAP).  A new code in 
+   the GAP was defined to indicate that the address information in the 
+   GAP is the dialed directory number. A new bit in the ISUP Forward 
+   Call Indicator (FCI) parameter, the Ported Number Translation 
+   Indicator (PNTI) bit, is set to imply that NPDB query has already 
+   been performed.  All the switches in the downstream will not perform 
+   the NPDB query if the PNTI bit is set. 
+    
+   When the terminating switch receives the IAM and sees the PNTI bit 
+   in the FCI parameter set and its own LRN in the CdPN parameter, it 
+   retrieves the originally dialed directory number from the GAP and 
+   uses the dialed directory number to terminate the call. 
+    
+   A dialed directory number with a portable NPA+NXX does not imply 
+   that directory number has been ported.  The NPDBs currently do not 
+   store records for non-ported directory numbers.  In that case, the 
+   NPDB will return the same dialed directory number instead of the 
+   LRN.  The switch will then set the PNTI bit but keep the dialed 
+   directory number in the CdPN parameter. 
+    
+   In the real world environment, the Originating Network is not always 
+   the one that performs the NPDB query.  For example, it is usually 
+   the long distance carriers that query the NPDBs for long distance 
+   calls.  In that case, the Originating Network operated by the local 
+   exchange carrier (LEC) simply routes the call to the long distance 
+   carrier that is to handle that call.   A wireless network acting as 
+   the Originating Network can also route the call to the 
+   interconnected local exchange carrier network if it does not want to 
+   support the NPDB interface at its mobile switches. 
+    
+    
+6.2 Europe 
+    
+   In some European countries, a routing number is prefixed to the 
+   dialed directory number.  The ISUP CdPN parameter in the IAM will 
+   contain the routing prefix and the dialed directory number.  For 
+   example, United Kingdom uses routing prefixes with the format of 
+   5XXXXX and Italy uses C600XXXXX as the routing prefix.  The networks 
+   use the information in the ISUP CdPN parameter to route the call to 
+   the New/Current Serving Network. 
+    
+   The routing prefix can identify the Current Serving Network or the 
+   Current Serving Switch of a ported number.  For the former case, 
+   another query to the "internal" NPDB at the Current Serving Network 
+   is required to identify the Current Serving Switch before routing 
+   the call to that switch.  This shields the Current Serving Switch 
+   information for a ported number from the other networks at the 
+   expense of an additional NPDB query.  Another routing number, may be 
+   meaningful within the Current Serving Network, will replace the 
+   previously prefixed routing number in the ISUP CdPN parameter.  For 
+   the latter case, the call is routed to the Current Serving Switch 
+   without an additional NPDB query. 
+    
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 15] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   When the terminating switch receives the IAM and sees its own 
+   routing prefix in the CdPN parameter, it retrieves the originally 
+   dialed directory number after the routing prefix, and uses the 
+   dialed directory number to terminate the call.  
+    
+   The call routing example described above shows one of the three 
+   methods that can be used to transport the Directory Number (DN) and 
+   the Routing Number (RN) in the ISUP IAM message.  In addition, some 
+   other information may be added/modified as is listed in the ETSI 302 
+   097 document [ETSIISUP], which is based on the ITU-T Recommendation 
+   Q.769.1 [ITUISUP].  The three methods and the enhancements in the 
+   ISUP to support number portability are briefly described below 
+    
+   (a) Two separate parameters with the CdPN parameter containing the 
+      RN and a new Called Directory Number (CdDN) parameter containing 
+      the DN.  A new value for the Nature of Address (NOA) indicator in 
+      the CdPN parameter is defined to indicate that the RN is in the 
+      CdPN parameter.  The switches use the CdPN parameter to route the 
+      call as is done today. 
+    
+   (b) Two separate parameters with the CdPN parameter containing the 
+      DN and a new Network Routing Number (NRN) parameter containing 
+      the RN.  This method requires that the switches use the NRN 
+      parameter to route the call. 
+    
+   (c) Concatenated parameter with the CdPN parameter containing the RN 
+      plus the DN.  A new Nature of Address (NOA) indicator in the CdPN 
+      parameter is defined to indicate that the RN is concatenated with 
+      the DN in the CdPN parameter.  Some countries may not use new NOA 
+      value because the routing prefix does not overlap with the dialed 
+      directory numbers.  But if the routing prefix overlaps with the 
+      dialed directory numbers, a new NOA value must be assigned.  For 
+      example, Spain uses "XXXXXX" as the routing prefix to identify 
+      the new serving network and uses a new NOA value of 126. 
+    
+   There is also a network option to add a new ISUP parameter called 
+   Number Portability Forwarding Information parameter.  This parameter 
+   has a four-bit Number Portability Status Indicator field that can 
+   provide an indication whether number portability query is done for 
+   the called directory number and whether the called directory number 
+   is ported or not if the number portability query is done. 
+ 
+   Please note that all those NP enhancements for a ported number can 
+   only be used in the country that defined them.  This is because 
+   number portability is supported within a nation.  Within each 
+   nation, the telecommunications industry or the regulatory bodies can 
+   decide which method or methods to use.  Number portability related 
+   parameters and coding are usually not passed across the national 
+   boundaries unless the interconnection agreements allow that.  For 
+   example, a UK routing prefix can only be used in UK, and would cause 
+   routing problem if it appears outside UK. 
+    
+
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 16] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   As indicated earlier, an originating wireless network can query the 
+   NPDB and concatenate the RN with DN in the CdPN parameter and route 
+   the call directly to the Current Serving Network.   
+    
+   If NPDBs do not contain information about the wireless directory 
+   numbers, the call, originated from either a wireline or a wireless 
+   network, will be routed to the Wireless donor network.  Over there, 
+   an internal NPDB is queried to retrieve the RN that then is 
+   concatenated with the DN in the CdPN parameter. 
+    
+   There are several ways of realizing MNP.  When MNP-SRF is supported, 
+   the Gateway Mobile Services Switching Center (GMSC) at the wireless 
+   donor network, when receiving a call from the wireline network, can 
+   send the GSM MAP Send Routing Information (SRI) message to the MNP-
+   SRF.  The MNP-SRF interrogates an internal or integrated NPDB for 
+   the RN of the MNP-SRF of the wireless Current Serving Network and 
+   prefixes the RN to the dialed wireless directory number in the 
+   global title address information in the SCCP Called Party Address 
+   (CdPA) parameter.  This SRI message will be routed to the MNP-SRF of 
+   the wireless Current Serving Network, which then responds with an 
+   acknowledgement by providing the RN plus the dialed wireless 
+   directory number as the Mobile Station Roaming Number (MSRN).  The 
+   GMSC of the wireless donor network formulates the ISUP IAM with the 
+   RN plus the dialed wireless directory number in the CdPN parameter 
+   and routes the call to the wireless Current Serving Network.  A GMSC 
+   of the wireless Current Serving Network receives the call and sends 
+   an SRI message to the associated MNP-SRF where the global title 
+   address information of the SCCP CdPA parameter contains only the 
+   dialed wireless directory number.  The MNP-SRF then replaces the 
+   global title address information in the SCCP CdPA parameter with the 
+   address information associated with a Home Location Register (HLR) 
+   that hosts the dialed wireless directory number and forwards the 
+   message to that HLR after verifying that the dialed wireless 
+   directory number is a ported-in number.   The HLR then returns an 
+   acknowledgement by providing an MSRN for the GMSC to route the call 
+   to the MSC that currently serves the mobile station that is 
+   associated with the dialed wireless directory number.  Please see 
+   [MNP] for details and additional scenarios. 
+    
+    
+7. NP Implementations for Geographic E.164 Numbers 
+ 
+   This section shows the known SPNP implementations worldwide.  
+    
+   +-------------+----------------------------------------------------+ 
+   +   Country   +             SPNP Implementation                    + 
+   +-------------+----------------------------------------------------+ 
+   +  Argentina  + Analyzing operative viability now. Will determine  + 
+   +             + whether portability should be made obligatory      + 
+   +             + after a technical solution has been determined.    + 
+   +-------------+----------------------------------------------------+ 
+   +  Australia  + NP supported by wireline operators since 11/30/99. + 
+   +             + NP among wireless operators in March/April 2000,   + 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 17] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   +             + but may be delayed to 1Q01. The access provider    + 
+   +             + or long distance provider has the obligation to    + 
+   +             + route the call to the correct destination. The     + 
+   +             + donor network is obligated to maintain and make    + 
+   +             + available a register of numbers ported away from   +  
+   +             + its network.  Telstra uses onward routing via an   + 
+   +             + on-switch solution.                                + 
+   +-------------+----------------------------------------------------+ 
+   +   Austria   + Uses onward routing at the donor network.  Routing + 
+   +             + prefix is "86xx" where "xx" identifies the         + 
+   +             + recipient network.                                 + 
+   +-------------+----------------------------------------------------+ 
+   +  Belgium    + ACQ selected by the industry. Routing prefix is    + 
+   +             + "Cxxxx" where "xxxx" identifies the recipient      + 
+   +             + switch. Another routing prefix is "C00xx" with "xx"+ 
+   +             + identifying the recipient network.  Plan to use NOA+ 
+   +             + to identify concatenated numbers and abandon the   + 
+   +             + hexadecimal routing prefix.                        + 
+   +-------------+----------------------------------------------------+ 
+   +  Brazil     + Considering NP for wireless users.                 + 
+   +-------------+----------------------------------------------------+ 
+   +  Chile      + There has been discussions lately on NP.           + 
+   +-------------+----------------------------------------------------+ 
+   +  Colombia   + There was an Article 3.1 on NP to support NP prior + 
+   +             + to December 31, 1999 when NP became technically    + 
+   +             + possible. Regulator has not yet issued regulations + 
+   +             + concerning this matter.                            + 
+   +-------------+----------------------------------------------------+ 
+   +  Denmark    + Uses ACQ. Routing number not passed between        + 
+   +             + operators; however, NOA is set to "112" to         + 
+   +             + indicate "ported number."  QoR can be used based   + 
+   +             + on bilateral agreements.                           +        
+   +-------------+----------------------------------------------------+ 
+   +  Finland    + Uses ACQ.  Routing prefix is "1Dxxy" where "xxy"   + 
+   +             + identifies the recipient network and service type. + 
+   +-------------+----------------------------------------------------+ 
+   +  France     + Uses onward routing.  Routing prefix is "Z0xxx"    + 
+   +             + where "xxx" identifies the recipient switch.       + 
+   +-------------+----------------------------------------------------+ 
+   +  Germany    + The originating network needs to do necessary      + 
+   +             + rerouting.  Operators decide their own solution(s).+ 
+   +             + Deutsche Telekom uses ACQ.  Routing prefix is      + 
+   +             + "Dxxx" where "xxx" identifies the recipient        + 
+   +             + network.                                           + 
+   +-------------+----------------------------------------------------+ 
+   +  Hong Kong  + Recipient network informs other networks about     + 
+   +             + ported-in numbers.  Routing prefix is "14x" where  + 
+   +             + "14x" identifies the recipient network, or a       + 
+   +             + routing number of "4x" plus 7 or 8 digits is used  +  
+   +             + where "4x" identifies the recipient network and    + 
+   +             + the rest of digits identify the called party.      + 
+   +-------------+----------------------------------------------------+ 
+   +  Ireland    + Operators choose their own solution but use onward + 
+   +             + routing now. Routing prefix is "1750" as the intra-+ 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 18] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   +             + network routing code (network-specific) and        + 
+   +             + "1752xxx" to "1759xxx" for GNP where "xxx"         + 
+   +             + identifies the recipient switch.                   + 
+   +-------------+----------------------------------------------------+ 
+   +  Italy      + Uses onward routing. Routing prefix is "C600xxxxx" + 
+   +             + where "xxxxx" identifies the recipient switch.     + 
+   +             + Telecom Italia uses IN solution and other operators+              
+   +             + use on-switch solution.                            + 
+   +-------------+----------------------------------------------------+ 
+   +  Japan      + Uses onward routing.  Donor switch uses IN to get  + 
+   +             + routing number.                                    + 
+   +-------------+----------------------------------------------------+ 
+   +  Mexico     + NP is considered in the Telecom law; however, the  + 
+   +             + regulator (Cofetel) or the new local entrants have + 
+   +             + started no initiatives on this process.            + 
+   +-------------+----------------------------------------------------+ 
+   + Netherlands + Operators decide NP scheme to use.  Operators have + 
+   +             + chosen ACQ or QoR.  KPN implemented IN solution    + 
+   +             + similar to U.S. solution.  Routing prefix is not   + 
+   +             + passed between operators.                          + 
+   +-------------+----------------------------------------------------+ 
+   +  Norway     + OR for short-term and ACQ for long-term.  QoR is   + 
+   +             + optional. Routing prefix can be "xxx" with NOA=8,  + 
+   +             + or "142xx" with NOA=3 where "xxx" or "xx"          + 
+   +             + identifies the recipient network.                  + 
+   +------------ +----------------------------------------------------+ 
+   +  Peru       + Wireline NP may be supported in 2001.              + 
+   +-------------+----------------------------------------------------+ 
+   +  Portugal   + No NP today.                                       + 
+   +-------------+----------------------------------------------------+ 
+   +  Spain      + Uses ACQ.  Telefonica uses QoR within its network. + 
+   +             + Routing prefix is  "xxyyzz" where "xxyyzz"         + 
+   +             + identifies the recipient network.  NOA is set to   + 
+   +             + 126.                                               + 
+   +-------------+----------------------------------------------------+ 
+   +  Sweden     + Standardized the ACQ but OR for operators without  + 
+   +             + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + 
+   +             + with NOA=3 where "xxx" identifies the recipient    + 
+   +             + network. But operators decide NP scheme to use.    + 
+   +             + Telia uses onward routing between operators.       + 
+   +-------------+----------------------------------------------------+ 
+   + Switzerland + Uses OR now and QoR in 2001.  Routing prefix is    + 
+   +             + "980xxx" where "xxx" identifies the recipient      +        
+   +             + network.                                           + 
+   +-------------+----------------------------------------------------+ 
+   +  UK         + Uses onward routing. Routing prefix is "5xxxxx"    + 
+   +             + where "xxxxx" identifies the recipient switch. NOA + 
+   +             + is 126. BT uses the dropback scheme in some parts  + 
+   +             + of its network.                                    + 
+   +-------------+----------------------------------------------------+ 
+   +  US         + Uses ACQ.  "Location Routing Number (LRN)" is used + 
+   +             + in the Called Party Number parameter.  Called party+ 
+   +             + number is carried in the Generic Address Parameter + 
+   +             + Use a PNTI indicator in the Forward Call Indicator + 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 19] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   +             + parameter to indicate that NPDB dip has been       + 
+   +             + performed.                                         + 
+   +-------------+----------------------------------------------------+ 
+    
+    
+8. Number Conservation Methods Enabled by NP 
+ 
+   In addition to porting numbers NP provides the ability for number 
+   administrators to assign numbering resources to operators in smaller 
+   increments.  Today it is common for numbering resources to be 
+   assigned to telephone operators in a large block of consecutive 
+   telephone numbers (TNs).  For example, in North America each of 
+   these blocks contains 10,000 TNs and is of the format NXX+0000 to 
+   NXX+9999.  Operators are assigned a specific NXX, or block.  That 
+   operator is referred to as the block holder.  In that block there 
+   are 10,000 TNs with line numbers ranging from 0000 to 9999.   
+    
+   Instead of assigning an entire block to the operator NP allows the 
+   administrator to assign a sub-block or even an individual telephone 
+   number.  This is referred to as block pooling and individual 
+   telephone number (ITN) pooling, respectively.  
+     
+    
+8.1 Block Pooling 
+    
+   Block Pooling refers to the process whereby the number administrator 
+   assigns a range of numbers defined by a logical sub-block of the 
+   existing block.  Using North America as an example, block pooling 
+   would allow the administrator to assign sub-blocks of 1,000 TNs to 
+   multiple operators.  That is, NXX+0000 to NXX+0999 can be assigned 
+   to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, 
+   NXX-2000 to 2999 can be assigned to operator C, etc.  In this 
+   example block pooling divides one block of 10,000 TNs into ten 
+   blocks of 1,000 TNs.   
+    
+   Porting the sub-blocks from the block holder enables block pooling.  
+   Using the example above operator A is the block holder, as well as, 
+   the holder of the first sub-block, NXX+0000 to NXX+0999.  The second 
+   sub-block, NXX+1000 to NXX+1999, is ported from operator A to 
+   operator B.  The third sub-block, NXX+2000 to NXX+2999, is ported 
+   from operator A to operator C, and so on.  NP administrative 
+   processes and call processing will enable proper and efficient 
+   routing.   
+    
+   From a number administration and NP administration perspective block 
+   pooling introduces a new concept, that of the sub-block holder.  
+   Block pooling requires coordination between the number 
+   administrator, the NP administrator, the block holder, and the sub-
+   block holder.  Block pooling must be implemented in a manner that 
+   allows for NP within the sub-blocks.  Each TN can have a different 
+   serving operator, sub-block holder, and block holder. 
+      
+    
+    
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 20] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+8.2 ITN Pooling 
+    
+   ITN pooling refers to the process whereby the number administrator 
+   assigns individual telephone numbers to operators.  Using the North 
+   American example, one block of 10,000 TNs can be divided into 10,000 
+   ITNs.  ITN is more commonly deployed in freephone services.   
+    
+   In ITN the block is not assigned to an operator but to a central 
+   administrator.  The administrator then assigns ITNs to operators.  
+   NP administrative processes and call processing will enable proper 
+   and efficient routing. 
+    
+ 
+9. Potential Implications 
+    
+   There are three general areas of impact to IP telephony work-in-
+   progress at IETF: 
+    
+   - Interoperation between NP in GSTN and IP telephony 
+   - NP implementation or emulation in IP telephony 
+   - Interconnection to NP administrative environment 
+    
+   A good understanding of how number portability is supported in the 
+   GSTN is important when addressing the interworking issues between 
+   IP-based networks and the GSTN.  This is especially important when 
+   the IP-based network needs to route the calls to the GSTN.  As shown 
+   in Section 5, there are a variety of standards with various protocol 
+   stacks for the switch-to-NPDB interface.  Not only that, the 
+   national variations of the protocol standards make it very 
+   complicated to deal with in a global environment.  If an entity in 
+   the IP-based network needs to query those existing NPDBs for routing 
+   number information to terminate the calls to the destination GSTN, 
+   it would be impractical, if not an impossible, job for that entity 
+   to support all those interface standards to access the NPDBs in many 
+   countries. 
+    
+   Several alternatives may address this particular problem.  One 
+   alternative is to use certain entities in the IP-based networks for 
+   dealing with NP query, similar to the International Switches that 
+   are used in the GSTN to interwork different national ISUP 
+   variations.  This will force signaling information associated with 
+   the calls to certain NP-capable networks in the terminating GSTN to 
+   be routed to those IP entities that support the NP functions.  Those 
+   IP entities then query the NPDBs in the terminating country.   This 
+   will limit the number of NPDB interfaces that certain IP entities 
+   need to support.  Another alternative can be to define a "common" 
+   interface to be supported by all the NPDBs so that all the IP 
+   entities use that standardized protocol to query them.   The 
+   existing NPDBs can support this additional interface, or new NPDBs 
+   can be deployed that contain the same information but support the 
+   common IP interface. The candidates for such a common interface 
+   include Lightweight Directory Access Protocol (LDAP) and SIP 
+   [SIP](e.g., using the SIP redirection capability).  Certainly 
+
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 21] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   another possibility is to use interworking function to convert from 
+   one protocol to another. 
+    
+   IP-based networks can handle the domestic calls between two GSTNs.  
+   If the originating GSTN has performed NPDB query, SIP will need to 
+   transport and make use of some of the ISUP signaling information 
+   even if ISUP signaling may be encapsulated in SIP.  Also, IP-based 
+   networks may perform the NPDB queries, as the N-1 carrier.  In that 
+   case, SIP also needs to transport the NP related information while 
+   the call is being routed to the destination GSTN.  There are three 
+   pieces of NP related information that SIP needs to transport.  They 
+   are 1) the called directory number, 2) a routing number, and 3) a 
+   NPDB dip indicator.  The NPDB dip indicator is needed so that the 
+   terminating GSTN will not perform another NPDB dip.  The routing 
+   number is needed so that it is used to route the call to the 
+   destination network or switch in the destination GSTN.  The called 
+   directory number is needed so that the terminating GSTN switch can 
+   terminate the call.  When the routing number is present, the NPDB 
+   dip indicator may not be present because there are cases where 
+   routing number is added for routing the call even if NP is not 
+   involved.  One issue is how to transport the NP related information 
+   via SIP.  The SIP Universal Resource Locator (URL) is one mechanism.  
+   Another better choice may be to add an extension to the "tel" URL 
+   [TEL] that is also supported by SIP.  Please see [TELNP] for the 
+   proposed extensions to the "tel" URL to support NP and freephone 
+   service.  Those extensions to the "tel" URL will be automatically 
+   supported by SIP because they can be carried as the optional 
+   parameters in the user portion of the "sip" URL. 
+    
+   For a called directory number that belongs to a country that 
+   supports NP, and if the IP-based network is to perform the NPDB 
+   query, the logical step is to perform the NPDB dip first to retrieve 
+   the routing number and use that routing number to select the correct 
+   IP telephony gateways that can reach the serving switch that serves 
+   the called directory number.  Therefore, if the "rn" parameter is 
+   present in the "tel" URL or sip URL in the SIP INVITE message, it 
+   instead of the called directory number should be used for making 
+   routing decisions assuming that no other higher priority routing-
+   related parameters such as the Ÿcic÷ are present.  If "rn" is not 
+   present, then the dialed directory number can be used as the routing 
+   number for making routing decisions.   
+    
+   Telephony Routing Information Protocol (TRIP) [TRIP] is a policy 
+   driven inter-administrative domain protocol for advertising the 
+   reachability of telephony destinations between location servers, and 
+   for advertising attributes of the routes to those destinations.  
+   With the NP in mind, it is very important to know that it is the 
+   routing number, if present, not the called directory number that 
+   should be used to check against the TRIP tables for making the 
+   routing decisions.   
+    
+   Overlap signaling exists in the GSTN today.  For a call routing from 
+   the originating GSTN to the IP-based network that involves overlap 
+   signaling, NP will impact the call processing within the IP-based 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 22] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   networks if they must deal with the overlap signaling.  The entities 
+   in the IP-based networks that are to retrieve the NP information 
+   (e.g., the routing number) must collect a complete called directory 
+   number information before retrieving the NP information for a ported 
+   number.  Otherwise, the information retrieval won't be successful.   
+   This is an issue for the IP-based networks if the originating GSTN 
+   does not handle the overlap signaling by collecting the complete 
+   called directory number. 
+    
+   The IETF enum working group is defining the use of Domain Name 
+   System (DNS) for identifying available services associated with a 
+   particular E.164 number [ENUM].  [ENUMPO] outlines the principles 
+   for the operation of a telephone number service that resolves 
+   telephone numbers into Internet domain name addresses and service-
+   specific directory discovery.  [ENUMPO] implements a three-level 
+   approach where the first level is the mapping of the telephone 
+   number delegation tree to the authority to which the number has been 
+   delegated, the second level is the provision of the requested DNS 
+   resource records from a service registrar, and the third level is 
+   the provision of service specific data from the service provider 
+   itself.  NP certainly must be considered at the first level because 
+   the telephony service providers do not "own" or control the 
+   telephone numbers under the NP environment; therefore, they may not 
+   be the proper entities to have the authority for a given E.164 
+   number.  Not only that, there is a regulatory requirement on NP in 
+   some countries that the donor network should not be relied on to 
+   reach the delegated authority during the DNS process .  The 
+   delegated authority for a given E.164 number is likely to be an 
+   entity designated by the end user that owns/controls a specific 
+   telephone number or one that is designated by the service registrar. 
+    
+   Since the telephony service providers may have the need to use ENUM 
+   for their network-related services (e.g., map an E.164 number to a 
+   HLR Identifier in the wireless networks), their ENUM records must be 
+   collocated with those of the telephony subscribers.  If that is the 
+   case, NP will impact ENUM when a telephony subscriber who has ENUM 
+   service changes the telephony service provider.  This is because 
+   that the ENUM records from the new telephony service provider must 
+   replace those from the old telephony service provider.  To avoid the 
+   NP impact on ENUM, it is recommended that the telephony service 
+   providers use a different domain tree for their network-related 
+   service.  For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a 
+   domain tree different from e164.arpa should be used for Ÿcarrier÷ 
+   ENUM. 
+    
+   The IP-based networks also may need to support some forms of number 
+   portability in the future if E.164 numbers [E164] are assigned to 
+   the IP-based end users.  One method is to assign a GSTN routing 
+   number for each IP-based network domain or entity in a NP-capable 
+   country.  This may increase the number of digits in the routing 
+   number to incorporate the IP entities and impact the existing 
+   routing in the GSTN.  Another method is to associate each IP entity 
+   with a particular GSTN gateway.  At that particular GSTN gateway, 
+   the called directory number then is used to locate the IP-entity 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 23] 
+
+Number Portability in the GSTN: An Overview               June 24, 2002 
+
+   that serves that dialed directory number.  Yet, another method can 
+   be to assign a special routing number so that the call to an end 
+   user currently served by an IP entity is routed to the nearest GSTN 
+   gateway.  The called directory number then is used to locate the IP-
+   entity that serves that dialed directory number.  A mechanism can be 
+   developed or used for the IP-based network to locate the IP entity 
+   that serves a particular dialed directory number.  Many other types 
+   of networks use E.164 numbers to identify the end users or terminals 
+   in those networks.  Number portability among GSTN, IP-based network 
+   and those various types of networks may also need to be supported in 
+   the future. 
+    
+ 
+10. Security Considerations 
+ 
+   This document does not raise any security issues. 
+ 
+ 
+11. IANA Considerations 
+ 
+   This document introduces no new values for IANA registration. 
+    
+ 
+12. Normative References  
+ 
+   [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
+        Operator Services Switching Systems," April 1999. 
+    
+   [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
+        Switching Systems," April 1999. 
+             
+   [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability 
+        Database and Global Title Translation," April 1999.         
+          
+   [CS1] ITU-T Q-series  Recommendations - Supplement 4, "Number 
+        portability Capability set 1 requirements for service provider 
+        portability (All call query and onward routing)," May 1998. 
+    
+   [CS2] ITU-T Q-series  Recommendations - Supplement 5, "Number 
+        portability -Capability set 2 requirements for service provider 
+        portability (Query on release and Dropback)," March 1999. 
+    
+   [E164] ITU-T Recommendation E.164, "The International Public 
+        Telecommunications Numbering Plan," 1997. 
+    
+   [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. 
+    
+   [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital 
+        Network (ISDN); Signalling System No.7 (SS7); ISDN User Part 
+        (ISUP); Enhancement for support of Number Portability (NP) 
+        [ITU-T Recommendation Q.769.1 (2000), modified] 
+    
+   [GSM]  GSM 09.02: "Digital cellular telecommunications system (Phase 
+        2+); Mobile Application Part (MAP) specification". 
+  
+Foster,McGarry,Yu           Expired on December 23, 2002      [Page 24] 
+
+Number Portability in the GSTN: An Overview              March 1, 2002 
+ 
+ 
+ 
+   [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for 
+        Wireless Number Portability Phase II (December 1998)"Number 
+        Portability Network Support," April 1998. 
+    
+   [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - 
+        ISDN User Part Enhancements for the Support of Number 
+        Portability," December 1999. 
+    
+   [MNP] ETSI EN 301 716 (2000-10) European Standard 
+        (Telecommunications series) Digital cellular telecommunications 
+        system (Phase 2+); Support of Mobile Number Portability (MNP); 
+        Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 
+        Release 1998). 
+    
+   [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- 
+        Revision 3," October 1996. 
+    
+ 
+13. Informative References  
+ 
+   [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific 
+        Provisioning: Principles of Operations," draft-ietf-enum-
+        operation-02.txt, February 23, 2001. 
+    
+   [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: 
+        Session Initiation Protocol," February 27, 2002. 
+    
+   [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis-
+        04.txt, "URIs for Telephone Calls," May 24, 2002. 
+ 
+   [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL 
+        to support Number Portability and Freephone Service," June 14, 
+        2002. 
+    
+   [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony 
+        Routing Information Protocol (TRIP)," January 2002. 
+    
+    
+14. Acknowledgment 
+    
+   The authors would like to thank Monika Muench for providing 
+   information on ISUP and MNP. 
+    
+    
+15. Authors' Addresses 
+    
+   Mark D. Foster 
+   NeuStar, Inc. 
+   1120 Vermont Avenue, NW, 
+   Suite 400 
+   Washington, D.C. 20005 
+   United States 
+  
+Foster,McGarry,Yu           Expired on August 31, 2002        [Page 25] 
+
+Number Portability in the GSTN: An Overview              March 1, 2002 
+ 
+ 
+    
+   Phone: +1-202-533-2800 
+   Fax:   +1-202-533-2987 
+   Email: mark.foster@neustar.biz 
+          
+   Tom McGarry 
+   NeuStar, Inc. 
+   1120 Vermont Avenue, NW, 
+   Suite 400 
+   Washington, D.C. 20005 
+   United States 
+    
+   Phone: +1-202-533-2810 
+   Fax:   +1-202-533-2987 
+   Email: tom.mcgarry@neustar.biz 
+    
+   James Yu 
+   NeuStar, Inc. 
+   1120 Vermont Avenue, NW,  
+   Suite 400 
+   Washington, D.C. 20005 
+   United States 
+    
+   Phone: +1-202-533-2814 
+   Fax:   +1-202-533-2987 
+   Email: james.yu@neustar.biz 
+    
+    
+    
+Full Copyright Statement 
+ 
+   "Copyright (C) The Internet Society (2002). All Rights Reserved. 
+    
+   This document and translations of it may be copied and furnished to 
+   others, and derivative works that comment on or otherwise explain it 
+   or assist in its implementation may be prepared, copied, published 
+   and distributed, in whole or in part, without restriction of any 
+   kind, provided that the above copyright notice and this paragraph 
+   are included on all such copies and derivative works. However, this 
+   document itself may not be modified in any way, such as by removing 
+   the copyright notice or references to the Internet Society or other 
+   Internet organizations, except as needed for the purpose of 
+   developing Internet standards in which case the procedures for 
+   copyrights defined in the Internet Standards process must be 
+   followed, or as required to translate it into languages other than 
+   English. 
+    
+   The limited permissions granted above are perpetual and will not be 
+   revoked by the Internet Society or its successors or assigns. 
+    
+
+  
+Foster,McGarry,Yu           Expired on August 31, 2002        [Page 26] 
+
+Number Portability in the GSTN: An Overview              March 1, 2002 
+ 
+ 
+   This document and the information contained herein is provided on an 
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
+    
+    
+Acknowledgement 
+ 
+   Funding for the RFC Editor function is currently provided by the 
+   Internet Society. 
+ 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+Foster,McGarry,Yu           Expired on August 31, 2002        [Page 27] 
+
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
new file mode 100644
index 0000000..2d5c87e
--- /dev/null
+++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
@@ -0,0 +1,1200 @@
+
+
+
+
+
+
+IPv6 Working Group                                 John Loughney (ed)
+Internet-Draft                                                  Nokia
+                                                     January 14, 2004
+
+Expires: July 14, 2004
+
+
+
+                         IPv6 Node Requirements
+                draft-ietf-ipv6-node-requirements-08.txt
+
+
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines requirements for IPv6 nodes.  It is expected
+   that IPv6 will be deployed in a wide range of devices and situations.
+   Specifying the requirements for IPv6 nodes allows IPv6 to function
+   well and interoperate in a large number of situations and
+   deployments.
+
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 1]
+
+
+
+
+
+Internet-Draft
+
+
+Table of Contents
+
+   1.   Introduction
+   1.1 Requirement Language
+   1.2  Scope of this Document
+   1.3  Description of IPv6 Nodes
+   2.   Abbreviations Used in This Document
+   3.   Sub-IP Layer
+   3.1  Transmission of IPv6 Packets over Ethernet Networks - RFC2464
+   3.2  IP version 6 over PPP - RFC2472
+   3.3  IPv6 over ATM Networks - RFC2492
+   4.   IP Layer
+   4.1  Internet Protocol Version 6 - RFC2460
+   4.2  Neighbor Discovery for IPv6 - RFC2461
+   4.3  Path MTU Discovery & Packet Size
+   4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
+   4.5  Addressing
+   4.6  Multicast Listener Discovery (MLD) for IPv6 - RFC2710
+   5.   Transport and DNS
+   5.1  Transport Layer
+   5.2  DNS
+   5.3  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+   6.   IPv4 Support and Transition
+   6.1  Transition Mechanisms
+   7.   Mobility
+   8.   Security
+   8.1  Basic Architecture
+   8.2  Security Protocols
+   8.3  Transforms and Algorithms
+   8.4  Key Management Methods
+   9.   Router Functionality
+   9.1  General
+   10.  Network Management
+   10.1 MIBs
+   11.  Security Considerations
+   12.  References
+   12.1 Normative
+   12.2 Non-Normative
+   13.  Authors and Acknowledgements
+   14.  Editor's Address
+   Notices
+
+
+
+
+
+
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 2]
+
+
+
+
+
+Internet-Draft
+
+
+1. Introduction
+
+   The goal of this document is to define the common functionality
+   required from both IPv6 hosts and routers.  Many IPv6 nodes will
+   implement optional or additional features, but all IPv6 nodes can be
+   expected to implement the mandatory requirements listed in this
+   document.
+
+   This document tries to avoid discussion of protocol details, and
+   references RFCs for this purpose.  In case of any conflicting text,
+   this document takes less precedence than the normative RFCs, unless
+   additional clarifying text is included in this document.
+
+   Although the document points to different specifications, it should
+   be noted that in most cases, the granularity of requirements are
+   smaller than a single specification, as many specifications define
+   multiple, independent pieces, some of which may not be mandatory.
+
+   As it is not always possible for an implementer to know the exact
+   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
+   that they should adhere to Jon Postel's Robustness Principle:
+
+      Be conservative in what you do, be liberal in what you accept from
+      others [RFC-793].
+
+1.1 Requirement Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC-2119].
+
+1.2 Scope of this Document
+
+   IPv6 covers many specifications.  It is intended that IPv6 will be
+   deployed in many different situations and environments.  Therefore,
+   it is important to develop the requirements for IPv6 nodes, in order
+   to ensure interoperability.
+
+   This document assumes that all IPv6 nodes meet the minimum
+   requirements specified here.
+
+1.3 Description of IPv6 Nodes
+
+   From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we
+   have the following definitions:
+
+      Description of an IPv6 Node
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 3]
+
+
+
+
+
+Internet-Draft
+
+
+       - a device that implements IPv6
+
+      Description of an IPv6 router
+
+       - a node that forwards IPv6 packets not explicitly addressed to
+         itself.
+
+      Description of an IPv6 Host
+
+       - any node that is not a router.
+
+2. Abbreviations Used in This Document
+
+   ATM   Asynchronous Transfer Mode
+
+   AH    Authentication Header
+
+   DAD   Duplicate Address Detection
+
+   ESP   Encapsulating Security Payload
+
+   ICMP  Internet Control Message Protocol
+
+   IKE   Internet Key Exchange
+
+   MIB   Management Information Base
+
+   MLD   Multicast Listener Discovery
+
+   MTU   Maximum Transfer Unit
+
+   NA    Neighbor Advertisement
+
+   NBMA  Non-Broadcast Multiple Access
+
+   ND    Neighbor Discovery
+
+   NS    Neighbor Solicitation
+
+   NUD   Neighbor Unreachability Detection
+
+   PPP   Point-to-Point Protocol
+
+   PVC   Permanent Virtual Circuit
+
+   SVC   Switched Virtual Circuit
+
+3. Sub-IP Layer
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 4]
+
+
+
+
+
+Internet-Draft
+
+
+   An IPv6 node must include support for one or more IPv6 link-layer
+   specifications.  Which link-layer specifications are included will
+   depend upon what link-layers are supported by the hardware available
+   on the system.  It is possible for a conformant IPv6 node to support
+   IPv6 on some of its interfaces and not on others.
+
+   As IPv6 is run over new layer 2 technologies, it is expected that new
+   specifications will be issued.  This section highlights some major
+   layer 2 technologies and is not intended to be complete.
+
+3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
+
+   Nodes supporting IPv6 over Ethernet interfaces MUST implement
+   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
+
+3.2 IP version 6 over PPP - RFC2472
+
+   Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-
+   2472].
+
+3.3 IPv6 over ATM Networks - RFC2492
+
+   Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
+   Networks [RFC-2492].  Additionally, RFC 2492 states:
+
+      A minimally conforming IPv6/ATM driver SHALL support the PVC mode
+      of operation. An IPv6/ATM driver that supports the full SVC mode
+      SHALL also support PVC mode of operation.
+
+4. IP Layer
+
+4.1 Internet Protocol Version 6 - RFC2460
+
+   The Internet Protocol Version 6 is specified in [RFC-2460]. This
+   specification MUST be supported.
+
+   Unrecognized options in Hop-by-Hop Options or Destination Options
+   extensions MUST be processed as described in RFC 2460.
+
+   The node MUST follow the packet transmission rules in RFC 2460.
+
+   Nodes MUST always be able to send, receive and process fragment
+   headers.  All conformant IPv6 implementations MUST be capable of
+   sending and receving IPv6 packets; forwarding functionality MAY be
+   supported
+
+   RFC 2460 specifies extension headers and the processing for these
+   headers.
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 5]
+
+
+
+
+
+Internet-Draft
+
+
+      A full implementation of IPv6 includes implementation of the
+      following extension headers: Hop-by-Hop Options, Routing (Type 0),
+      Fragment, Destination Options, Authentication and Encapsulating
+      Security Payload. [RFC-2460]
+
+   An IPv6 node MUST be able to process these headers.  It should be
+   noted that there is some discussion about the use of Routing Headers
+   and possible security threats [IPv6-RH] caused by them.
+
+4.2 Neighbor Discovery for IPv6 - RFC2461
+
+   Neighbor Discovery SHOULD be supported.  RFC 2461 states:
+
+      "Unless specified otherwise (in a document that covers operating
+      IP over a particular link type) this document applies to all link
+      types. However, because ND uses link-layer multicast for some of
+      its services, it is possible that on some link types (e.g., NBMA
+      links) alternative protocols or mechanisms to implement those
+      services will be specified (in the appropriate document covering
+      the operation of IP over a particular link type).  The services
+      described in this document that are not directly dependent on
+      multicast, such as Redirects, Next-hop determination, Neighbor
+      Unreachability Detection, etc., are expected to be provided as
+      specified in this document.  The details of how one uses ND on
+      NBMA links is an area for further study."
+
+   Some detailed analysis of Neighbor Discovery follows:
+
+   Router Discovery is how hosts locate routers that reside on an
+   attached link. Router Discovery MUST be supported for
+   implementations.
+
+   Prefix Discovery is how hosts discover the set of address prefixes
+   that define which destinations are on-link for an attached link.
+   Prefix discovery MUST be supported for implementations. Neighbor
+   Unreachability Detection (NUD) MUST be supported for all paths
+   between hosts and neighboring nodes. It is not required for paths
+   between routers.  However, when a node receives a unicast Neighbor
+   Solicitation (NS) message (that may be a NUD's NS), the node MUST
+   respond to it (i.e. send a unicast Neighbor Advertisement).
+
+   Duplicate Address Detection MUST be supported on all links supporting
+   link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take
+   place on all unicast addresses).
+
+   A host implementation MUST support sending Router Solicitations.
+
+   Receiving and processing Router Advertisements MUST be supported for
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 6]
+
+
+
+
+
+Internet-Draft
+
+
+   host implementations. The ability to understand specific Router
+   Advertisement options is dependent on supporting the specification
+   where the RA is specified.
+
+   Sending and Receiving Neighbor Solicitation (NS) and Neighbor
+   Advertisement (NA) MUST be supported. NS and NA messages are required
+   for Duplicate Address Detection (DAD).
+
+   Redirect functionality SHOULD be supported. If the node is a router,
+   Redirect functionality MUST be supported.
+
+4.3 Path MTU Discovery & Packet Size
+
+4.3.1 Path MTU Discovery - RFC1981
+
+   Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
+   implementations MAY choose to not support it and avoid large packets.
+   The rules in RFC 2460 MUST be followed for packet fragmentation and
+   reassembly.
+
+4.3.2 IPv6 Jumbograms - RFC2675
+
+   IPv6 Jumbograms [RFC-2675] MAY be supported.
+
+4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
+
+   ICMPv6 [RFC-2463] MUST be supported.
+
+4.5 Addressing
+
+4.5.1 IP Version 6 Addressing Architecture - RFC3513
+
+   The IPv6 Addressing Architecture [RFC-3513] MUST be supported.
+
+4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462
+
+   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
+   This specification MUST be supported for nodes that are hosts.
+
+   Nodes that are routers MUST be able to generate link local addresses
+   as described in RFC 2462 [RFC-2462].
+
+   From 2462:
+
+      The autoconfiguration process specified in this document applies
+      only to hosts and not routers. Since host autoconfiguration uses
+      information advertised by routers, routers will need to be
+      configured by some other means. However, it is expected that
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 7]
+
+
+
+
+
+Internet-Draft
+
+
+      routers will generate link-local addresses using the mechanism
+      described in this document. In addition, routers are expected to
+      successfully pass the Duplicate Address Detection procedure
+      described in this document on all addresses prior to assigning
+      them to an interface.
+
+   Duplicate Address Detection (DAD) MUST be supported.
+
+4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041
+
+   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
+   SHOULD be supported.  It is recommended that this behavior be
+   configurable on a connection basis within each application when
+   available.  It is noted that a number of applications do not work
+   with addresses generated with this method, while other applications
+   work quite well with them.
+
+4.5.4 Default Address Selection for IPv6 - RFC3484
+
+   The rules specified in the Default Address Selection for IPv6 [RFC-
+   3484] document MUST be implemented. It is expected that IPv6 nodes
+   will need to deal with multiple addresses.
+
+4.5.5 Stateful Address Autoconfiguration
+
+   Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
+   3315] is the standard stateful address configuration protocol; see
+   section 5.3 for DHCPv6 support.
+
+   Nodes which do not support Stateful Address Autoconfiguration may be
+   unable to obtain any IPv6 addresses aside from link-local addresses
+   when it receives a router advertisement with the 'M' flag (Managed
+   address configuration) set and which contains no prefixes advertised
+   for Stateless Address Autoconfiguration (see section 4.5.2).
+   Additionally, such nodes will be unable to obtain other configuration
+   information such as the addresses of DNS servers when it is connected
+   to a link over which the node receives a router advertisement in
+   which the 'O' flag ("Other stateful configuration") is set.
+
+4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
+
+   Nodes that need to join multicast groups SHOULD implement MLDv2
+   [MLDv2]. However, if the node has applications, which only need
+   support for Any- Source Multicast [RFC3569], the node MAY implement
+   MLDv1 [MLDv1] instead. If the node has applications, which need
+   support for Source- Specific Multicast [RFC3569, SSMARCH], the node
+   MUST support MLDv2 [MLDv2].
+
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 8]
+
+
+
+
+
+Internet-Draft
+
+
+   When MLD is used, the rules in "Source Address Selection for the
+   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
+   followed.
+
+5. Transport Layer and DNS
+
+5.1 Transport Layer
+
+5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
+
+   This specification MUST be supported if jumbograms are implemented
+   [RFC- 2675].
+
+5.2 DNS
+
+   DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
+   and [RFC-3596] MAY be supported.  Not all nodes will need to resolve
+   names. All nodes that need to resolve names SHOULD implement stub-
+   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
+   support for:
+
+    - AAAA type Resource Records [RFC-3596];
+    - reverse addressing in ip6.arpa using PTR records [RFC-3152];
+    - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
+      octets.
+
+   Those nodes are RECOMMENDED to support DNS security extentions
+   [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].
+
+   Those nodes are NOT RECOMMENDED to support the experimental A6 and
+   DNAME Resource Records [RFC-3363].
+
+5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732
+
+   RFC 2732 MUST be supported if applications on the node use URL's.
+
+5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315
+
+5.3.1 Managed Address Configuration
+
+   Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
+   to obtain IPv6 addresses and other configuration information upon
+   receipt of a Router Advertisement with the 'M' flag set, as described
+   in section 5.5.3 of RFC 2462.  In addition, in the absence of a
+   router, those IPv6 Nodes that use DHCP for address assignment MUST
+   initiate DHCP to obtain IPv6 addresses and other configuration
+   information, as described in section 5.5.2 of RFC 2462.  Those IPv6
+   nodes that do not use DHCP for address assignment can ignore the 'M'
+
+
+
+Loughney (editor)          February 16, 2004                    [Page 9]
+
+
+
+
+
+Internet-Draft
+
+
+   flag in Router Advertisements.
+
+5.3.2 Other Configuration Information
+
+   Those IPv6 Nodes that use DHCP to obtain other configuration
+   information initiate DHCP for other configuration information upon
+   receipt of a Router Advertisement with the 'O' flag set, as described
+   in section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
+   for other configuration information can ignore the 'O' flag in Router
+   Advertisements.
+
+   An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
+   obtain other configuration information.
+
+6. IPv4 Support and Transition
+
+   IPv6 nodes MAY support IPv4.
+
+6.1 Transition Mechanisms
+
+6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893
+
+   If an IPv6 node implements dual stack and tunneling, then RFC2893
+   MUST be supported.
+
+   RFC 2893 is currently being updated.
+
+7. Mobile IP
+
+   The Mobile IPv6 [MIPv6] specification defines requirements for the
+   following types of nodes:
+
+       - mobile nodes
+       - correspondent nodes with support for route optimization
+       - home agents
+       - all IPv6 routers
+
+   Hosts MAY support mobile node functionality described in Section 8.5
+   of [MIPv6], including support of generic packet tunneling [RFC-2473]
+   and secure home agent communications [MIPv6-HASEC].
+
+   Hosts SHOULD support route optimization requirements for
+   correspondent nodes described in Section 8.2 of [MIPv6].
+
+   Routers SHOULD support the generic mobility-related requirements for
+   all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
+   support the home agent functionality described in Section 8.4 of
+   [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 10]
+
+
+
+
+
+Internet-Draft
+
+
+8. Security
+
+   This section describes the specification of IPsec for the IPv6 node.
+
+8.1 Basic Architecture
+
+   Security Architecture for the Internet Protocol [RFC-2401] MUST be
+   supported. RFC-2401 is being updated by the IPsec Working Group.
+
+8.2 Security Protocols
+
+   ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
+   RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.
+
+
+8.3 Transforms and Algorithms
+
+   Current IPsec RFCs specify the support of certain transforms and
+   algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
+   The requirements for these are discussed first, and then additional
+   algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.
+
+   NULL encryption algorithm [RFC-2410] MUST be supported for providing
+   integrity service and also for debugging use.
+
+   The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
+   NOT be supported. Security issues related to the use of DES are
+   discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
+   required by the existing IPsec RFCs, but as it is currently viewed as
+   an inherently weak algorithm, and no longer fulfills its intended
+   role.
+
+   The NULL authentication algorithm [RFC-2406] MUST be supported within
+   ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
+   2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
+   described in [RFC-2403] MUST be supported. An implementer MUST refer
+   to Keyed- Hashing for Message Authentication [RFC-2104].
+
+   3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
+   and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
+   CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
+   to be a widely available, secure algorithm that is required for
+   interoperability. It is not required by the current IPsec RFCs, but
+   is expected to become required in the future.
+
+   In addition to the above requirements, "Cryptographic Algorithm
+   Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
+   current set of mandatory to implement algorithms for ESP and AH as
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 11]
+
+
+
+
+
+Internet-Draft
+
+
+   well as specifying algorithms that should be implemented because they
+   may be promoted to mandatory at some future time.  It is RECOMMENDED
+   that IPv6 nodes conform to the requirements in this document.
+
+8.4 Key Management Methods
+
+   Manual keying MUST be supported.
+
+   IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
+   traffic. Where key refresh, anti-replay features of AH and ESP, or
+   on- demand creation of Security Associations (SAs) is required,
+   automated keying MUST be supported. Note that the IPsec WG is working
+   on the successor to IKE [IKE2]. Key management methods for multicast
+   traffic are also being worked on by the MSEC WG.
+
+   "Cryptographic Algorithms for use in the Internet Key Exchange
+   Version 2" [IKEv2ALGO] defines the current set of mandatory to
+   implement algorithms for use of IKEv2 as well as specifying
+   algorithms that should be implemented because they made be promoted
+   to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
+   implementing IKEv2 conform to the requirements in this
+   document.
+
+9. Router-Specific Functionality
+
+   This section defines general host considerations for IPv6 nodes that
+   act as routers.  Currently, this section does not discuss routing-
+   specific requirements.
+
+9.1 General
+
+9.1.1 IPv6 Router Alert Option - RFC2711
+
+
+   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
+   Hop Header that is used in conjunction with some protocols (e.g.,
+   RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
+   need to be implemented whenever protocols that mandate its usage are
+   implemented. See Section 4.6.
+
+9.1.2 Neighbor Discovery for IPv6 - RFC2461
+
+   Sending Router Advertisements and processing Router Solicitation MUST
+   be supported.
+
+10. Network Management
+
+   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 12]
+
+
+
+
+
+Internet-Draft
+
+
+   nodes that are embedded devices, network management may be the only
+   possibility to control these nodes.
+
+10.1 Management Information Base Modules (MIBs)
+
+   The following two MIBs SHOULD be supported by nodes that support an
+   SNMP agent.
+
+10.1.1  IP Forwarding Table MIB
+
+   IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
+   that support an SNMP agent.
+
+10.1.2 Management Information Base for the Internet Protocol (IP)
+
+   IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
+   SNMP agent.
+
+11. Security Considerations
+
+   This draft does not affect the security of the Internet, but
+   implementations of IPv6 are expected to support a minimum set of
+   security features to ensure security on the Internet.  "IP Security
+   Document Roadmap" [RFC-2411] is important for everyone to read.
+
+   The security considerations in RFC2460 describe the following:
+
+      The security features of IPv6 are described in the Security
+      Architecture for the Internet Protocol [RFC-2401].
+
+12. References
+
+12.1 Normative
+
+   [CRYPTREQ]     D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
+                  tion Requirements For ESP And AH", draft-ietf-ipsec-
+                  esp-ah-algorithms-01.txt, January 2004.
+
+   [IKEv2ALGO]    J. Schiller, "Cryptographic Algorithms for use in the
+                  Internet Key Exchange Version 2", draft-ietf-ipsec-
+                  ikev2-algorithms-04.txt, Work in Progress.
+
+   [DHCPv6-SL]    R. Droms, "A Guide to Implementing Stateless DHCPv6
+                  Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
+                  Work in Progress.
+
+   [MIPv6]        J. Arkko, D. Johnson and C. Perkins, "Mobility Support
+                  in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 13]
+
+
+
+
+
+Internet-Draft
+
+
+                  progress.
+
+   [MIPv6-HASEC]  J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
+                  to Protect Mobile IPv6 Signaling between Mobile Nodes
+                  and Home Agents", draft-ietf- mobileip-mipv6-ha-
+                  ipsec-06.txt, Work in Progress.
+
+   [MLDv2]        Vida, R. et al., "Multicast Listener Discovery Version
+                  2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
+                  Progress.
+
+   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
+                  specification", STD 13, RFC 1035, November 1987.
+
+   [RFC-1981]     McCann, J., Mogul, J. and Deering, S., "Path MTU
+                  Discovery for IP version 6", RFC 1981, August 1996.
+
+   [RFC-2096BIS]  Haberman, B. and Wasserman, M., "IP Forwarding Table
+                  MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in
+                  Progress.
+
+   [RFC-2011BIS]  Routhier, S (ed), "Management Information Base for the
+                  Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-
+                  update-07.txt, Work in progress.
+
+   [RFC-2104]     Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
+                  Keyed-Hashing for Message Authentication", RFC 2104,
+                  February 1997.
+
+   [RFC-2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC-2401]     Kent, S. and Atkinson, R., "Security Architecture for
+                  the Internet Protocol", RFC 2401, November 1998.
+
+   [RFC-2402]     Kent, S. and Atkinson, R.,  "IP Authentication
+                  Header", RFC 2402, November 1998.
+
+   [RFC-2403]     Madson, C., and Glenn, R., "The Use of HMAC-MD5 within
+                  ESP and AH", RFC 2403, November 1998.
+
+   [RFC-2404]     Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
+                  within ESP and AH", RFC 2404, November 1998.
+
+   [RFC-2405]     Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
+                  Algorithm With Explicit IV", RFC 2405, November 1998.
+
+   [RFC-2406]     Kent, S. and Atkinson, R., "IP Encapsulating Security
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 14]
+
+
+
+
+
+Internet-Draft
+
+
+                  Protocol (ESP)", RFC 2406, November 1998.
+
+   [RFC-2407]     Piper, D., "The Internet IP Security Domain of
+                  Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [RFC-2408]     Maughan, D., Schertler, M., Schneider, M., and Turner,
+                  J., "Internet Security Association and Key Management
+                  Protocol (ISAKMP)", RFC 2408, November 1998.
+
+   [RFC-2409]     Harkins, D., and Carrel, D., "The Internet Key
+                  Exchange (IKE)", RFC 2409, November 1998.
+
+   [RFC-2410]     Glenn, R. and Kent, S., "The NULL Encryption Algorithm
+                  and Its Use With IPsec", RFC 2410, November 1998.
+
+   [RFC-2451]     Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
+                  Algorithms", RFC 2451, November 1998.
+
+   [RFC-2460]     Deering, S. and Hinden, R., "Internet Protocol, Ver-
+                  sion 6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC-2461]     Narten, T., Nordmark, E. and Simpson, W., "Neighbor
+                  Discovery for IP Version 6 (IPv6)", RFC 2461, December
+                  1998.
+
+   [RFC-2462]     Thomson, S. and Narten, T., "IPv6 Stateless Address
+                  Autoconfiguration", RFC 2462.
+
+   [RFC-2463]     Conta, A. and Deering, S., "ICMP for the Internet Pro-
+                  tocol Version 6 (IPv6)", RFC 2463, December 1998.
+
+   [RFC-2472]     Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
+                  2472, December 1998.
+
+   [RFC-2473]     Conta, A. and Deering, S., "Generic Packet Tunneling
+                  in IPv6 Specification", RFC 2473, December 1998.  Xxx
+                  add
+
+   [RFC-2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                  2671, August 1999.
+
+   [RFC-2710]     Deering, S., Fenner, W. and Haberman, B., "Multicast
+                  Listener Discovery (MLD) for IPv6", RFC 2710, October
+                  1999.
+
+   [RFC-2711]     Partridge, C. and Jackson, A., "IPv6 Router Alert
+                  Option", RFC 2711, October 1999.
+
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 15]
+
+
+
+
+
+Internet-Draft
+
+
+   [RFC-3041]     Narten, T. and Draves, R., "Privacy Extensions for
+                  Stateless Address Autoconfiguration in IPv6", RFC
+                  3041, January 2001.
+
+   [RFC-3152]     Bush, R., "Delegation of IP6.ARPA", RFC 3152, August
+                  2001.
+
+   [RFC-3315]     Bound, J. et al., "Dynamic Host Configuration Protocol
+                  for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC-3363]     Bush, R., et al., "Representing Internet Protocol ver-
+                  sion 6 (IPv6) Addresses in the Domain Name System
+                  (DNS)", RFC 3363, August 2002.
+
+   [RFC-3484]     Draves, R., "Default Address Selection for IPv6", RFC
+                  3484, February 2003.
+
+   [RFC-3513]     Hinden, R. and Deering, S. "IP Version 6 Addressing
+                  Architecture", RFC 3513, April 2003.
+
+   [RFC-3590]     Haberman, B., "Source Address Selection for the Multi-
+                  cast Listener Discovery (MLD) Protocol", RFC 3590,
+                  September 2003.
+
+   [RFC-3596]     Thomson, S., et al., "DNS Extensions to support IP
+                  version 6", RFC 3596, October 2003.
+
+   [RFC-3602]     S. Frankel, "The AES-CBC Cipher Algorithm and Its Use
+                  with IPsec", RFC 3602, September 2003.
+
+12.2 Non-Normative
+
+   [ANYCAST]      Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast",
+                  draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in
+                  Progress.
+
+   [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
+                  DES-like cryptosystems", Journal of Cryptology Vol 4, Jan
+                  1991.
+
+   [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
+   
+   [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
+                  Strong Integrity", Proceedings of the 32nd IETF, Danvers,
+                  MA, April 1995.
+
+   [DHCPv6-SL]    Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser-
+                  vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 16]
+
+
+
+
+
+Internet-Draft
+
+
+                  Progress.
+
+   [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+                  S., "DNS Security Introduction and Requirements" draft-
+                  ietf-dnsext-dnssec-intro- 06.txt, Work in Progress.
+
+   [DNSSEC-REC]   Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+                  S., "Resource Records for the DNS Security Extensions",
+                  draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro-
+                  gress.
+
+   [DNSSEC-PROT]  Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+                  S., "Protocol Modifications for the DNS Security Exten-
+                  sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work
+                  in Progress.
+
+   [IKE2]         Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto-
+                  col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress.
+  
+   [IPv6-RH]      P. Savola, "Security of IPv6 Routing Header and Home
+                  Address Options", draft-savola-ipv6-rh-ha-security-
+                  03.txt, Work in Progress, March 2002.
+
+   [MC-THREAT]    Ballardie A. and Crowcroft, J.; Multicast-Specific Secu-
+                  rity Threats and Counter-Measures; In Proceedings "Sympo-
+                  sium on Network and Distributed System Security", Febru-
+                  ary 1995, pp.2-16.
+
+   [RFC-793]      Postel, J., "Transmission Control Protocol", RFC 793,
+                  August 1980.
+
+   [RFC-1034]     Mockapetris, P., "Domain names - concepts and facili-
+                  ties", RFC 1034, November 1987.
+
+   [RFC-2147]     Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
+                  May 1997.
+
+   [RFC-2205]     Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and
+                  S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC
+                  2205, September 1997.
+
+   [RFC-2464]     Crawford, M., "Transmission of IPv6 Packets over Ethernet
+                  Networks", RFC 2462, December 1998.
+
+   [RFC-2492]     G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over
+                  ATM Networks", RFC 2492, January 1999.
+
+   [RFC-2675]     Borman, D., Deering, S. and Hinden, B., "IPv6
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 17]
+
+
+
+
+
+Internet-Draft
+
+
+                  Jumbograms", RFC 2675, August 1999.
+
+   [RFC-2732]     R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
+                  IPv6 Addresses in URL's", RFC 2732, December 1999.
+
+   [RFC-2851]     M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
+                  "Textual Conventions for Internet Network Addresses", RFC
+                  2851, June 2000.
+
+   [RFC-2893]     Gilligan, R. and Nordmark, E., "Transition Mechanisms for
+                  IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+   [RFC-3569]     S. Bhattacharyya, Ed., "An Overview of Source-Specific
+                  Multicast (SSM)", RFC 3569, July 2003.
+
+   [SSM-ARCH]     H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
+                  draft-ietf- ssm-arch-03.txt, Work in Progress.
+
+13. Authors and Acknowledgements
+
+   This document was written by the IPv6 Node Requirements design team:
+
+      Jari Arkko
+      [jari.arkko@ericsson.com]
+
+      Marc Blanchet
+      [marc.blanchet@viagenie.qc.ca]
+
+      Samita Chakrabarti
+      [samita.chakrabarti@eng.sun.com]
+
+      Alain Durand
+      [alain.durand@sun.com]
+
+      Gerard Gastaud
+      [gerard.gastaud@alcatel.fr]
+
+      Jun-ichiro itojun Hagino
+      [itojun@iijlab.net]
+
+      Atsushi Inoue
+      [inoue@isl.rdc.toshiba.co.jp]
+
+      Masahiro Ishiyama
+      [masahiro@isl.rdc.toshiba.co.jp]
+
+      John Loughney
+      [john.loughney@nokia.com]
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 18]
+
+
+
+
+
+Internet-Draft
+
+
+      Rajiv Raghunarayan
+      [raraghun@cisco.com]
+
+      Shoichi Sakane
+      [shouichi.sakane@jp.yokogawa.com]
+
+      Dave Thaler
+      [dthaler@windows.microsoft.com]
+
+      Juha Wiljakka
+      [juha.wiljakka@Nokia.com]
+
+   The authors would like to thank Ran Atkinson, Jim Bound, Brian Car-
+   penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten,
+   Juha Ollila and Pekka Savola for their comments.
+
+14. Editor's Contact Information
+
+   Comments or questions regarding this document should be sent to the
+   IPv6 Working Group mailing list (ipv6@ietf.org) or to:
+
+      John Loughney
+      Nokia Research Center
+      Itamerenkatu 11-13
+      00180 Helsinki
+      Finland
+
+      Phone: +358 50 483 6242
+      Email: John.Loughney@Nokia.com
+
+Notices
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to per-
+   tain to the implementation or use of the technology described in this
+   document or the extent to which any license under such rights might
+   or might not be available; neither does it represent that it has made
+   any effort to identify any such rights.  Information on the IETF's
+   procedures with respect to rights in standards-track and standards-
+   related documentation can be found in BCP-11.  Copies of claims of
+   rights made available for publication and any assurances of licenses
+   to be made available, or the result of an attempt made to obtain a
+   general license or permission for the use of such proprietary rights
+   by implementors or users of this specification can be obtained from
+   the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 19]
+
+
+
+
+
+Internet-Draft
+
+
+   rights, which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney (editor)          February 16, 2004                   [Page 20]
+
+
diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt
new file mode 100644
index 0000000..a272d81
--- /dev/null
+++ b/doc/draft/draft-ietf-secsh-dns-05.txt
@@ -0,0 +1,614 @@
+Secure Shell Working Group                                   J. Schlyter
+Internet-Draft                                                   OpenSSH
+Expires: March 5, 2004                                        W. Griffin
+                                                                  SPARTA
+                                                       September 5, 2003
+
+
+           Using DNS to Securely Publish SSH Key Fingerprints
+                      draft-ietf-secsh-dns-05.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that other
+   groups may also distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 5, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+   This document describes a method to verify SSH host keys using
+   DNSSEC. The document defines a new DNS resource record that contains
+   a standard SSH key fingerprint.
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 1]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SSH Host Key Verification  . . . . . . . . . . . . . . . . .  3
+   2.1   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.2   Implementation Notes . . . . . . . . . . . . . . . . . . . .  3
+   2.3   Fingerprint Matching . . . . . . . . . . . . . . . . . . . .  4
+   2.4   Authentication . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.    The SSHFP Resource Record  . . . . . . . . . . . . . . . . .  4
+   3.1   The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . .  5
+   3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . .  5
+   3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . .  5
+   3.1.3 Fingerprint  . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.2   Presentation Format of the SSHFP RR  . . . . . . . . . . . .  6
+   4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
+   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
+         Normative References . . . . . . . . . . . . . . . . . . . .  8
+         Informational References . . . . . . . . . . . . . . . . . .  8
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
+   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
+         Intellectual Property and Copyright Statements . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 2]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+1. Introduction
+
+   The SSH [6] protocol provides secure remote login and other secure
+   network services over an insecure network.  The security of the
+   connection relies on the server authenticating itself to the client
+   as well as the user authenticating itself to the server.
+
+   If a connection is established to a server whose public key is not
+   already known to the client, a fingerprint of the key is presented to
+   the user for verification.  If the user decides that the fingerprint
+   is correct and accepts the key, the key is saved locally and used for
+   verification for all following connections. While some
+   security-conscious users verify the fingerprint out-of-band before
+   accepting the key, many users blindly accept the presented key.
+
+   The method described here can provide out-of-band verification by
+   looking up a fingerprint of the server public key in the DNS [1][2]
+   and using DNSSEC [5] to verify the lookup.
+
+   In order to distribute the fingerprint using DNS, this document
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
+
+   Basic understanding of the DNS system [1][2] and the DNS security
+   extensions [5] is assumed by this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+2. SSH Host Key Verification
+
+2.1 Method
+
+   Upon connection to a SSH server, the SSH client MAY look up the SSHFP
+   resource record(s) for the host it is connecting to.  If the
+   algorithm and fingerprint of the key received from the SSH server
+   match the algorithm and fingerprint of one of the SSHFP resource
+   record(s) returned from DNS, the client MAY accept the identity of
+   the server.
+
+2.2 Implementation Notes
+
+   Client implementors SHOULD provide a configurable policy used to
+   select the order of methods used to verify a host key. This document
+   defines one method: Fingerprint storage in DNS. Another method
+   defined in the SSH Architecture [6] uses local files to store keys
+   for comparison. Other methods that could be defined in the future
+   might include storing fingerprints in LDAP or other databases. A
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 3]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   configurable policy will allow administrators to determine which
+   methods they want to use and in what order the methods should be
+   prioritized. This will allow administrators to determine how much
+   trust they want to place in the different methods.
+
+   One specific scenario for having a configurable policy is where
+   clients do not use fully qualified host names to connect to servers.
+   In this scenario, the implementation SHOULD verify the host key
+   against a local database before verifying the key via the fingerprint
+   returned from DNS. This would help prevent an attacker from injecting
+   a DNS search path into the local resolver and forcing the client to
+   connect to a different host.
+
+2.3 Fingerprint Matching
+
+   The public key and the SSHFP resource record are matched together by
+   comparing algorithm number and fingerprint.
+
+      The public key algorithm and the SSHFP algorithm number MUST
+      match.
+
+      A message digest of the public key, using the message digest
+      algorithm specified in the SSHFP fingerprint type, MUST match the
+      SSHFP fingerprint.
+
+
+2.4 Authentication
+
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not
+   authenticated by a trusted SIG RR.
+
+   Clients that do validate the DNSSEC signatures themselves SHOULD use
+   standard DNSSEC validation procedures.
+
+   Clients that do not validate the DNSSEC signatures themselves MUST
+   use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
+   between themselves and the entity performing the signature
+   validation.
+
+3. The SSHFP Resource Record
+
+   The SSHFP resource record (RR) is used to store a fingerprint of a
+   SSH public host key that is associated with a Domain Name System
+   (DNS) name.
+
+   The RR type code for the SSHFP RR is TBA.
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 4]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+3.1 The SSHFP RDATA Format
+
+   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
+   type and the fingerprint of the public host key.
+
+         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         |   algorithm   |    fp type    |                               /
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
+         /                                                               /
+         /                          fingerprint                          /
+         /                                                               /
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1 Algorithm Number Specification
+
+   This algorithm number octet describes the algorithm of the public
+   key.  The following values are assigned:
+
+          Value    Algorithm name
+          -----    --------------
+          0        reserved
+          1        RSA
+          2        DSS
+
+   Reserving other types requires IETF consensus [4].
+
+3.1.2 Fingerprint Type Specification
+
+   The fingerprint type octet describes the message-digest algorithm
+   used to calculate the fingerprint of the public key.  The following
+   values are assigned:
+
+          Value    Fingerprint type
+          -----    ----------------
+          0        reserved
+          1        SHA-1
+
+   Reserving other types requires IETF consensus [4].
+
+   For interoperability reasons, as few fingerprint types as possible
+   should be reserved.  The only reason to reserve additional types is
+   to increase security.
+
+3.1.3 Fingerprint
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 5]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   The fingerprint is calculated over the public key blob as described
+   in [7].
+
+   The message-digest algorithm is presumed to produce an opaque octet
+   string output which is placed as-is in the RDATA fingerprint field.
+
+3.2 Presentation Format of the SSHFP RR
+
+   The RDATA of the presentation format of the SSHFP resource record
+   consists of two numbers (algorithm and fingerprint type) followed by
+   the fingerprint itself presented in hex, e.g:
+
+         host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
+
+   The use of mnemonics instead of numbers is not allowed.
+
+4. Security Considerations
+
+   Currently, the amount of trust a user can realistically place in a
+   server key is proportional to the amount of attention paid to
+   verifying that the public key presented actually corresponds to the
+   private key of the server. If a user accepts a key without verifying
+   the fingerprint with something learned through a secured channel, the
+   connection is vulnerable to a man-in-the-middle attack.
+
+   The overall security of using SSHFP for SSH host key verification is
+   dependent on the security policies of the SSH host administrator and
+   DNS zone administrator (in transferring the fingerprint), detailed
+   aspects of how verification is done in the SSH implementation, and in
+   the client's diligence in accessing the DNS in a secure manner.
+
+   One such aspect is in which order fingerprints are looked up (e.g.
+   first checking local file and then SSHFP).  We note that in addition
+   to protecting the first-time transfer of host keys, SSHFP can
+   optionally be used for stronger host key protection.
+
+      If SSHFP is checked first, new SSH host keys may be distributed by
+      replacing the corresponding SSHFP in DNS.
+
+      If SSH host key verification can be configured to require SSHFP,
+      SSH host key revocation can be implemented by removing the
+      corresponding SSHFP from DNS.
+
+   As stated in Section 2.2, we recommend that SSH implementors provide
+   a policy mechanism to control the order of methods used for host key
+   verification. One specific scenario for having a configurable policy
+   is where clients use unqualified host names to connect to servers. In
+   this case, we recommend that SSH implementations check the host key
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 6]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   against a local database before verifying the key via the fingerprint
+   returned from DNS. This would help prevent an attacker from injecting
+   a DNS search path into the local resolver and forcing the client to
+   connect to a different host.
+
+   A different approach to solve the DNS search path issue would be for
+   clients to use a trusted DNS search path, i.e., one not acquired
+   through DHCP or other autoconfiguration mechanisms. Since there is no
+   way with current DNS lookup APIs to tell whether a search path is
+   from a trusted source, the entire client system would need to be
+   configured with this trusted DNS search path.
+
+   Another dependency is on the implementation of DNSSEC itself.  As
+   stated in Section 2.4, we mandate the use of secure methods for
+   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
+   is especially important if SSHFP is to be used as a basis for host
+   key rollover and/or revocation, as described above.
+
+   Since DNSSEC only protects the integrity of the host key fingerprint
+   after it is signed by the DNS zone administrator, the fingerprint
+   must be transferred securely from the SSH host administrator to the
+   DNS zone administrator.  This could be done manually between the
+   administrators or automatically using secure DNS dynamic update [11]
+   between the SSH server and the nameserver.  We note that this is no
+   different from other key enrollment situations, e.g. a client sending
+   a certificate request to a certificate authority for signing.
+
+5. IANA Considerations
+
+   IANA needs to allocate a RR type code for SSHFP from the standard RR
+   type space (type 44 requested).
+
+   IANA needs to open a new registry for the SSHFP RR type for public
+   key algorithms.  Defined types are:
+
+         0 is reserved
+         1 is RSA
+         2 is DSA
+
+    Adding new reservations requires IETF consensus [4].
+
+   IANA needs to open a new registry for the SSHFP RR type for
+   fingerprint types.  Defined types are:
+
+         0 is reserved
+         1 is SHA-1
+
+    Adding new reservations requires IETF consensus [4].
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 7]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [6]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+        Lehtinen, "SSH Protocol Architecture",
+        draft-ietf-secsh-architecture-14 (work in progress), July 2003.
+
+   [7]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+        Lehtinen, "SSH Transport Layer Protocol",
+        draft-ietf-secsh-transport-16 (work in progress), July 2003.
+
+Informational References
+
+   [8]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
+         Roadmap", RFC 2411, November 1998.
+
+   [9]   Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+         2845, May 2000.
+
+   [10]  Eastlake, D., "DNS Request and Transaction Signatures (
+         SIG(0)s)", RFC 2931, September 2000.
+
+   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 8]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Authors' Addresses
+
+   Jakob Schlyter
+   OpenSSH
+   812 23rd Avenue SE
+   Calgary, Alberta  T2G 1N8
+   Canada
+
+   EMail: jakob@openssh.com
+   URI:   http://www.openssh.com/
+
+
+   Wesley Griffin
+   SPARTA
+   7075 Samuel Morse Drive
+   Columbia, MD  21046
+   USA
+
+   EMail: wgriffin@sparta.com
+   URI:   http://www.sparta.com/
+
+Appendix A. Acknowledgements
+
+   The authors gratefully acknowledge, in no particular order, the
+   contributions of the following persons:
+
+      Martin Fredriksson
+
+      Olafur Gudmundsson
+
+      Edward Lewis
+
+      Bill Sommerfeld
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 9]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works. However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                 [Page 10]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                 [Page 11]
+
diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
new file mode 100644
index 0000000..3578d2a
--- /dev/null
+++ b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
@@ -0,0 +1,519 @@
+
+Internet Draft                                          Johan Ihren
+draft-ihren-dnsext-threshold-validation-00.txt          Autonomica
+February 2003
+Expires in six months
+
+
+                        Threshold Validation: 
+
+	 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months and may be updated, replaced, or obsoleted by other
+   documents at any time. It is inappropriate to use Internet-Drafts
+   as reference material or to cite them other than as "work in
+   progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+   This memo documents a proposal for a different method of validation
+   for DNSSEC aware resolvers. The key change is that by changing from
+   a model of one Key Signing Key, KSK, at a time to multiple KSKs it
+   will be possible to increase the aggregated trust in the signed
+   keys by leveraging from the trust associated with the different
+   signees. 
+
+   By having multiple keys to chose from validating resolvers get the
+   opportunity to use local policy to reflect actual trust in
+   different keys. For instance, it is possible to trust a single,
+   particular key ultimately, while requiring multiple valid
+   signatures by less trusted keys for validation to succeed.
+   Furthermore, with multiple KSKs there are additional redundancy
+   benefits available since it is possible to roll over different KSKs
+   at different times which may make rollover scenarios easier to
+   manage.
+
+Contents
+
+	1. Terminology
+	2. Introduction and Background
+
+	3. Trust in DNSSEC Keys
+	3.1. Key Management, Split Keys and Trust Models
+	3.2. Trust Expansion: Authentication versus Authorization
+
+	4. Proposed Semantics for Signing the KEY Resource Record 
+           Set
+	4.1. Packet Size Considerations
+
+	5. Proposed Use of Multiple "Trusted Keys" in a Validating 
+           Resolver
+	5.1. Not All Possible KSKs Need to Be Trusted
+	5.2. Possible to do Threshold Validation
+	5.3. Not All Trusted Keys Will Be Available
+
+	6. Additional Benefits from Having Multiple KSKs
+	6.1. More Robust Key Rollovers
+	6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+	7. Security Considerations
+	8. IANA Considerations.
+	9. References
+	9.1. Normative.
+	9.2. Informative.
+	10. Acknowledgments.
+	11. Authors' Address
+
+
+1. Terminology
+
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+   and "MAY" in this document are to be interpreted as described in
+   RFC 2119. 
+
+   The term "zone" refers to the unit of administrative control in the
+   Domain Name System. "Name server" denotes a DNS name server that is
+   authoritative (i.e. knows all there is to know) for a DNS zone,
+   typically the root zone. A "resolver", is a DNS "client", i.e. an
+   entity that sends DNS queries to authoritative nameservers and
+   interpret the results. A "validating resolver" is a resolver that
+   attempts to perform DNSSEC validation on data it retrieves by doing
+   DNS lookups.
+
+
+2. Introduction and Background
+
+   From a protocol perspective there is no real difference between
+   different keys in DNSSEC. They are all just keys. However, in
+   actual use there is lots of difference. First and foremost, most
+   DNSSEC keys have in-band verification. I.e. the keys are signed by
+   some other key, and this other key is in its turn also signed by
+   yet another key. This way a "chain of trust" is created. Such
+   chains have to end in what is referred to as a "trusted key" for
+   validation of DNS lookups to be possible. 
+
+   A "trusted key" is a the public part of a key that the resolver
+   acquired by some other means than by looking it up in DNS. The
+   trusted key has to be explicitly configured.
+
+   A node in the DNS hierarchy that issues such out-of-band "trusted
+   keys" is called a "security apex" and the trusted key for that apex
+   is the ultimate source of trust for all DNS lookups within that
+   entire subtree.
+
+   DNSSEC is designed to be able to work with more than on security
+   apex. These apexes will all share the problem of how to distribute
+   their "trusted keys" in a way that provides validating resolvers
+   confidence in the distributed keys. 
+
+   Maximizing that confidence is crucial to the usefulness of DNSSEC
+   and this document tries to address this issue.
+
+
+3. Trust in DNSSEC Keys
+
+   In the end the trust that a validating resolver will be able to put
+   in a key that it cannot validate within DNSSEC will have to be a
+   function of
+
+   	    * trust in the key issuer, aka the KSK holder
+
+	    * trust in the distribution method
+
+	    * trust in extra, out-of-band verification
+
+   The KSK holder needs to be trusted not to accidentally lose private
+   keys in public places. Furthermore it needs to be trusted to
+   perform correct identification of the ZSK holders in case they are
+   separate from the KSK holder itself.
+
+   The distribution mechanism can be more or less tamper-proof. If the
+   key holder publishes the public key, or perhaps just a secure
+   fingerprint of the key in a major newspaper it may be rather
+   difficult to tamper with. A key acquired that way may be easier to
+   trust than if it had just been downloaded from a web page.
+
+   Out-of-band verification can for instance be the key being signed
+   by a certificate issued by a known Certificate Authority that the
+   resolver has reason to trust.
+
+3.1. Simplicity vs Trust 
+
+   The fewer keys that are in use the simpler the key management
+   becomes. Therefore increasing the number of keys should only be
+   considered when the complexity is not the major concern. A perfect
+   example of this is the distinction between so called Key Signing
+   Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
+   overall complexity but simplifies real life operations and was an
+   overall gain since operational simplification was considered to be
+   a more crucial issue than the added complexity.
+
+   In the case of a security apex there are additional issues to
+   consider, among them
+
+      * maximizing trust in the KSK received out-of-band
+
+      * authenticating the legitimacy of the ZSKs used
+
+   In some cases this will be easy, since the same entity will manage
+   both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
+   similar to a self-signed certificate). In some environments it will
+   be possible to get the trusted key installed in the resolver end by
+   decree (this would seem to be a likely method within corporate and
+   government environments).
+
+   In other cases, however, this will possibly not be sufficient. In
+   the case of the root zone this is obvious, but there may well be
+   other cases.
+
+3.2. Expanding the "Trust Base"
+
+   For a security apex where the ZSKs and KSK are not held by the same
+   entity the KSK will effectively authenticate the identity of
+   whoever does real operational zone signing. The amount of trust
+   that the data signed by a ZSK will get is directly dependent on
+   whether the end resolver trusts the KSK or not, since the resolver
+   has no OOB access to the public part of the ZSKs (for practical
+   reasons).
+
+   Since the KSK holder is distinct from the ZSK holder the obvious
+   question is whether it would then be possible to further improve
+   the situation by using multiple KSK holders and thereby expanding
+   the trust base to the union of that available to each individual
+   KSK holder. "Trust base" is an invented term intended to signify
+   the aggregate of Internet resolvers that will eventually choose to
+   trust a key issued by a particular KSK holder.
+
+   A crucial issue when considering trust expansion through addition
+   of multiple KSK holders is that the KSK holders are only used to
+   authenticate the ZSKs used for signing the zone. I.e. the function
+   performed by the KSK is basically:
+
+   	     "This is indeed the official ZSK holder for this zone,
+   	     I've verified this fact to the best of my abilitites."
+
+   Which can be thought of as similar to the service of a public
+   notary. I.e. the point with adding more KSK holders is to improve
+   the public trust in data signed by the ZSK holders by improving the
+   strength of available authentication. 
+
+   Therefore adding more KSK holders, each with their own trust base,
+   is by definition a good thing. More authentication is not
+   controversial. On the contrary, when it comes to authentication,
+   the more the merrier.
+
+   
+4. Proposed Semantics for Signing the KEY Resource Record Set
+
+   In DNSSEC according to RFC2535 all KEY Resource Records are used to
+   sign all authoritative data in the zone, including the KEY RRset
+   itself, since RFC2535 makes no distinction between Key Signing
+   Keys, KSK, and Zone Signing Keys, ZSK.  With Delegation Signer [DS]
+   it is possible to change this to the KEY RRset being signed with
+   all KSKs and ZSKs but the rest of the zone only being signed by the
+   ZSKs.
+
+   This proposal changes this one step further, by recommending that
+   the KEY RRset is only signed by the Key Signing Keys, KSK, and
+   explicitly not by the Zone Signing Keys, ZSK. The reason for this
+   is to maximize the amount of space in the DNS response packet that
+   is available for additional KSKs and signatures thereof. The rest
+   of the authoritative zone contents are as previously signed by only
+   the ZSKs.
+
+4.1. Packet Size Considerations
+
+   The reason for the change is to keep down the size of the aggregate
+   of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
+   perform validation of data below a security apex. For DNSSEC data
+   to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
+   set, and therefore the allowed packet size can be assumed to be at
+   least the EDNS0 minimum of 4000 bytes.
+
+   When querying for KEY + SIG(KEY) for "." (the case that is assumed
+   to be most crucial) the size of the response packet after the
+   change to only sign the KEY RR with the KSKs break down into a
+   rather large space of possibilities. Here are a few examples for
+   the possible alternatives for different numbers of KSKs and ZSKs
+   for some different key lengths (all RSA keys, with a public
+   exponent that is < 254). This is all based upon the size of the
+   response for the particular example of querying for
+   
+	". KEY IN"
+
+   with a response of entire KEY + SIG(KEY) with the authority and
+   additional sections empty:
+
+   	      ZSK/768 and KSK/1024   (real small)
+	      Max 12 KSK +  3 ZSK  at 3975
+	          10 KSK +  8 ZSK  at 3934
+		   8 KSK + 13 ZSK  at 3893
+
+	      ZSK/768 + KSK/1280
+	      MAX 10 KSK +  2 ZSK  at 3913
+	           8 KSK +  9 ZSK  at 3970
+                   6 KSK + 15 ZSK  at 3914
+
+	      ZSK/768 + KSK/1536
+	      MAX  8 KSK +  4 ZSK  at 3917
+                   7 KSK +  8 ZSK  at 3938
+                   6 KSK + 12 ZSK  at 3959
+
+              ZSK/768 + KSK/2048
+              MAX  6 KSK +  5 ZSK  at 3936
+                   5 KSK + 10 ZSK  at 3942
+
+              ZSK/1024 + KSK/1024
+              MAX 12 KSK +  2 ZSK  at 3943
+                  11 KSK +  4 ZSK  at 3930
+                  10 KSK +  6 ZSK  at 3917
+                   8 KSK + 10 ZSK  at 3891
+
+              ZSK/1024 + KSK/1536
+              MAX  8 KSK +  3 ZSK  at 3900
+                   7 KSK +  6 ZSK  at 3904
+                   6 KSK +  9 ZSK  at 3908
+
+              ZSK/1024 + KSK/2048
+              MAX  6 KSK +  4 ZSK  at 3951
+                   5 KSK +  8 ZSK  at 3972
+                   4 KSK + 12 ZSK  at 3993
+
+   Note that these are just examples and this document is not making
+   any recommendations on suitable choices of either key lengths nor
+   number of different keys employed at a security apex.
+
+   This document does however, based upon the above figures, make the
+   recommendation that at a security apex that expects to distribute
+   "trusted keys" the KEY RRset should only be signed with the KSKs
+   and not with the ZSKs to keep the size of the response packets
+   down.
+
+
+5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
+
+   In DNSSEC according to RFC2535[RFC2535] validation is the process
+   of tracing a chain of signatures (and keys) upwards through the DNS
+   hierarchy until a "trusted key" is reached. If there is a known
+   trusted key present at a security apex above the starting point
+   validation becomes an exercise with a binary outcome: either the
+   validation succeeds or it fails. No intermediate states are
+   possible.
+
+   With multiple "trusted keys" (i.e. the KEY RRset for the security
+   apex signed by multiple KSKs) this changes into a more complicated
+   space of alternatives. From the perspective of complexity that may
+   be regarded as a change for the worse. However, from a perspective
+   of maximizing available trust the multiple KSKs add value to the
+   system.
+
+5.1. Possible to do Threshold Validation
+
+   With multiple KSKs a new option that opens for the security
+   concious resolver is to not trust a key individually. Instead the
+   resolver may decide to require the validated signatures to exceed a
+   threshold. For instance, given M trusted keys it is possible for
+   the resolver to require N-of-M signatures to treat the data as
+   validated.
+
+   I.e. with the following pseudo-configuration in a validating
+   resolver
+
+   	security-apex "." IN {
+	   keys { ksk-1 .... ;
+      	          ksk-2 .... ;
+	          ksk-3 .... ; 
+		  ksk-4 .... ;
+		  ksk-5 .... ;
+	        };
+	   validation {
+	      # Note that ksk-4 is not present below
+	      keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 
+              # 3 signatures needed with 4 possible keys, aka 75%
+              needed-signatures 3;
+           };
+	};
+
+   we configure five trusted keys for the root zone, but require two
+   valid signatures for the top-most KEY for validation to
+   succeed. I.e.  threshold validation does not force multiple
+   signatures on the entire signature chain, only on the top-most
+   signature, closest to the security apex for which the resolver has
+   trusted keys.		    
+
+5.2. Not All Trusted Keys Will Be Available
+
+   With multiple KSKs held and managed by separate entities the end
+   resolvers will not always manage to get access to all possible
+   trusted keys. In the case of just a single KSK this would be fatal
+   to validation and necessary to avoid at whatever cost. But with
+   several fully trusted keys available the resolver can decide to
+   trust several of them individually. An example based upon more
+   pseudo-configuration:
+
+   	security-apex "." IN {
+	   keys { ksk-1 .... ;
+      	          ksk-2 .... ;
+	          ksk-3 .... ; 
+		  ksk-4 .... ;
+		  ksk-5 .... ;
+	        };
+	   validation {
+	      # Only these two keys are trusted independently
+	      keys { ksk-1; ksk-4; }; 
+              # With these keys a single signature is sufficient
+	      needed-signatures 1;
+           };
+	};
+
+   Here we have the same five keys and instruct the validating
+   resolver to fully trust data that ends up with just one signature
+   from by a fully trusted key.
+
+   The typical case where this will be useful is for the case where
+   there is a risk of the resolver not catching a rollover event by
+   one of the KSKs. By doing rollovers of different KSKs with
+   different schedules it is possible for a resolver to "survive"
+   missing a rollover without validation breaking. This improves
+   overall robustness from a management point of view.
+
+5.3. Not All Possible KSKs Need to Be Trusted
+
+   With just one key available it simply has to be trusted, since that
+   is the only option available. With multiple KSKs the validating
+   resolver immediately get the option of implementing a local policy
+   of only trusting some of the possible keys.
+
+   This local policy can be implemented either by simply not
+   configuring keys that are not trusted or, possibly, configure them
+   but specify to the resolver that certain keys are not to be
+   ultimately trusted alone.
+
+
+6. Additional Benefits from Having Multiple KSKs
+
+6.1. More Robust Key Rollovers
+
+   With only one KSK the rollover operation will be a delicate
+   operation since the new trusted key needs to reach every validating
+   resolver before the old key is retired. For this reason it is
+   expected that long periods of overlap will be needed.
+
+   With multiple KSKs this changes into a system where different
+   "series" of KSKs can have different rollover schedules, thereby
+   changing from one "big" rollover to several "smaller" rollovers.
+
+   If the resolver trusts several of the available keys individually
+   then even a failure to track a certain rollover operation within
+   the overlap period will not be fatal to validation since the other
+   available trusted keys will be sufficient.
+
+6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+   Distribution of the trusted keys for the DNS root zone is
+   recognized to be a difficult problem that ...
+
+   With only one trusted key, from one single "source" to distribute
+   it will be difficult to evaluate what distribution mechanism works
+   best. With multiple KSKs, held by separate entitites it will be
+   possible to measure how large fraction of the resolver population
+   that is trusting what subsets of KSKs.
+
+
+7. Security Considerations
+
+   From a systems perspective the simplest design is arguably the
+   best, i.e. one single holder of both KSK and ZSKs. However, if that
+   is not possible in all cases a more complex scheme is needed where
+   additional trust is injected by using multiple KSK holders, each
+   contributing trust, then there are only two alternatives
+   available. The first is so called "split keys", where a single key
+   is split up among KSK holders, each contributing trust. The second
+   is the multiple KSK design outlined in this proposal.
+
+   Both these alternatives provide for threshold mechanisms. However
+   split keys makes the threshold integral to the key generating
+   mechanism (i.e. it will be a property of the keys how many
+   signatures are needed). In the case of multiple KSKs the threshold
+   validation is not a property of the keys but rather local policy in
+   the validating resolver. A benefit from this is that it is possible
+   for different resolvers to use different trust policies. Some may
+   configure threshold validation requiring multiple signatures and
+   specific keys (optimizing for security) while others may choose to
+   accept a single signature from a larger set of keys (optimizing for
+   redundancy). Since the security requirements are different it would
+   seem to be a good idea to make this choice local policy rather than
+   global policy.
+
+   Furthermore, a clear issue for validating resolvers will be how to
+   ensure that they track all rollover events for keys they
+   trust. Even with operlap during the rollover (which is clearly
+   needed) there is still a need to be exceedingly careful not to miss
+   any rollovers (or fail to acquire a new key) since without this
+   single key validation will fail. With multiple KSKs this operation
+   becomes more robust, since different KSKs may roll at different
+   times according to different rollover schedules and losing one key,
+   for whatever reason, will not be crucial unless the resolver
+   intentionally chooses to be completely dependent on that exact key.
+
+8. IANA Considerations.
+
+   NONE.
+
+
+9. References
+
+9.1. Normative.
+
+   [RFC2535] Domain Name System Security Extensions. D. Eastlake. 
+	     March 1999.
+
+   [RFC3090] DNS Security Extension Clarification on Zone Status. 
+	     E. Lewis.  March 2001.
+
+
+9.2. Informative.
+
+   [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+	     (DNS). D.  Eastlake 3rd. May 2001.
+
+   [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 
+	     December 2001.
+
+   [DS]      Delegation Signer Resource Record. 
+	     O. Gudmundsson. October 2002. Work In Progress.
+
+10. Acknowledgments.
+
+   Bill Manning came up with the original idea of moving complexity
+   from the signing side down to the resolver in the form of threshold
+   validation. I've also had much appreciated help from (in no
+   particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
+   Olaf Kolkman.
+
+
+11. Authors' Address
+Johan Ihren
+Autonomica AB
+Bellmansgatan 30
+SE-118 47 Stockholm, Sweden
+johani@autonomica.se
diff --git a/doc/draft/draft-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt
new file mode 100644
index 0000000..d857cd9
--- /dev/null
+++ b/doc/draft/draft-kato-dnsop-local-zones-00.txt
@@ -0,0 +1,295 @@
+
+
+
+Internet Engineering Task Force                         Akira Kato, WIDE
+INTERNET-DRAFT                                           Paul Vixie, ISC
+Expires: August 24, 2003                               February 24, 2003
+
+
+          Operational Guidelines for "local" zones in the DNS
+                  draft-kato-dnsop-local-zones-00.txt
+
+Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups.  Note that other groups
+may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as ``work in progress.''
+
+To view the list Internet-Draft Shadow Directories, see
+http://www.ietf.org/shadow.html.
+
+Distribution of this memo is unlimited.
+
+The internet-draft will expire in 6 months.  The date of expiration will
+be August 24, 2003.
+
+
+Abstract
+
+A large number of DNS queries regarding to the "local" zones are sent
+over the Internet in every second.  This memo describes operational
+guidelines to reduce the unnecessary DNS traffic as well as the load of
+the Root DNS Servers.
+
+1.  Introduction
+
+While it has yet been described in a RFC, .local is used to provide a
+local subspace of the DNS tree.  Formal delegation process has not been
+completed for this TLD.  In spite of this informal status, .local has
+been used in many installations regardless of the awareness of the
+users.  Usually, the local DNS servers are not authoritative to the
+.local domain, they end up to send queries to the Root DNS Servers.
+
+There are several other DNS zones which describe the "local"
+information.  .localhost has been used to describe the localhost for
+more than a couple of decades and virtually all of the DNS servers are
+configured authoritative for .localhost and its reverse zone .127.in-
+
+
+KATO                    Expires: August 24, 2003                [Page 1]
+
+
+DRAFT                        DNS local zones               February 2003
+
+addr.arpa.  However, there are other "local" zones currently used in the
+Internet or Intranets connected to the Internet through NATs or similar
+devices.
+
+At a DNS server of an university in Japan, half of the DNS queries sent
+to one of the 13 Root DNS Servers were regarding to the .local.  At
+another DNS Server running in one of the Major ISPs in Japan, the 1/4
+were .local.  If those "local" queries are able to direct other DNS
+servers than Root, or they can be resolved locally, it contributes the
+reduction of the Root DNS Servers.
+
+2.  Rationale
+
+Any DNS queries regarding to "local" names should not be sent to the DNS
+servers on the Internet.
+
+3.  Operational Guidelines
+
+Those queries should be processed at the DNS servers internal to each
+site so that the severs respond with NXDOMAIN rather than sending
+queries to the DNS servers outside.
+
+The "local" names have common DNS suffixes which are listed below:
+
+3.1.  Local host related zones:
+
+Following two zones are described in [Barr, 1996] and .localhost is also
+defined in [Eastlake, 1999] .
+
+     o .localhost
+     o .127.in-addr.arpa
+
+
+Following two zones are for the loopback address in IPv6 [Hinden, 1998]
+.  While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
+2001] , the old TLD .int has been used for this purpose for years
+[Thomson, 1995] and many implementations still use .int.  So it is
+suggested that both zones should be provided for each IPv6 reverse
+lookup zone for a while.
+
+     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
+     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
+
+
+3.2.  Locally created name space
+
+While the use of .local has been proposed in several Internet-Drafts, it
+has not been described in any Internet documents with formal status.
+However, the amount of the queries for .local is much larger than
+others, it is suggested to resolve the following zone locally:
+
+
+
+
+KATO                    Expires: August 24, 2003                [Page 2]
+
+
+DRAFT                        DNS local zones               February 2003
+
+     o .local
+
+
+
+3.3.  Private or site-local addresses
+
+The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
+local addresses [Hinden, 1998] should be resolved locally:
+
+     o 10.in-addr.arpa
+     o 16.172.in-addr.arpa
+     o 17.172.in-addr.arpa
+     o 18.172.in-addr.arpa
+     o 19.172.in-addr.arpa
+     o 20.172.in-addr.arpa
+     o 21.172.in-addr.arpa
+     o 22.172.in-addr.arpa
+     o 23.172.in-addr.arpa
+     o 24.172.in-addr.arpa
+     o 25.172.in-addr.arpa
+     o 26.172.in-addr.arpa
+     o 27.172.in-addr.arpa
+     o 28.172.in-addr.arpa
+     o 29.172.in-addr.arpa
+     o 30.172.in-addr.arpa
+     o 31.172.in-addr.arpa
+     o 168.192.in-addr.arpa
+     o c.e.f.ip6.int
+     o d.e.f.ip6.int
+     o e.e.f.ip6.int
+     o f.e.f.ip6.int
+     o c.e.f.ip6.arpa
+     o d.e.f.ip6.arpa
+     o e.e.f.ip6.arpa
+     o f.e.f.ip6.arpa
+
+
+3.4.  Link-local addresses
+
+The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
+1998] should be resolved locally:
+
+     o 254.169.in-addr.arpa
+     o 8.e.f.ip6.int
+     o 9.e.f.ip6.int
+     o a.e.f.ip6.int
+     o b.e.f.ip6.int
+     o 8.e.f.ip6.arpa
+     o 9.e.f.ip6.arpa
+     o a.e.f.ip6.arpa
+     o b.e.f.ip6.arpa
+
+
+
+KATO                    Expires: August 24, 2003                [Page 3]
+
+
+DRAFT                        DNS local zones               February 2003
+
+4.  Suggestions to developers
+
+4.1.  Suggestions to DNS software implementors
+
+In order to avoid unnecessary traffic, it is suggested that DNS software
+implementors provide configuration templates or default configurations
+so that the names described in the previous section are resolved locally
+rather than sent to other DNS servers in the Internet.
+
+4.2.  Suggestions to developers of NATs or similar devices
+
+There are many NAT or similar devices available in the market.
+Regardless of the availability of DNS Servers in those devices, it is
+suggested that those devices are able to filter the DNS traffic or
+respond to the DNS traffic related to "local" zones by configuration
+regardless of its ability of DNS service.  It is suggested that this
+functionality is activated by default.
+
+5.  IANA Consideration
+
+While .local TLD has yet defined officially, there are substantial
+queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
+traffic sent to the Root DNS Servers are related to the .local zone.
+Therefore, while it is not formally defined, it is suggested that IANA
+delegates .local TLD to an organization.
+
+The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
+address and the link-local address.  It has several DNS server instances
+around the world by using BGP Anycast [Hardie, 2002] .  So the AS112
+Project is one of the candidates to host the .local TLD.
+
+Authors' addresses
+
+     Akira Kato
+     The University of Tokyo, Information Technology Center
+     2-11-16 Yayoi Bunkyo
+     Tokyo 113-8658, JAPAN
+     Tel: +81 3-5841-2750
+     Email: kato@wide.ad.jp
+
+
+     Paul Vixie
+     Internet Software Consortium
+     950 Charter Street
+     Redwood City, CA 94063, USA
+     Tel: +1 650-779-7001
+     Email: vixie@isc.org
+
+
+
+
+
+
+
+KATO                    Expires: August 24, 2003                [Page 4]
+
+
+DRAFT                        DNS local zones               February 2003
+
+References
+
+To be filled
+
+References
+
+Barr, 1996.
+D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
+(February 1996).
+
+Eastlake, 1999.
+D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
+
+Hinden, 1998.
+R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
+RFC2373 (July 1998).
+
+Bush, 2001.
+R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
+
+Thomson, 1995.
+S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
+RFC1886 (December 1995).
+
+Rekhter, 1996.
+Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
+"Address Allocation for Private Internets" in RFC1918 (February 1996).
+
+IANA, 2002.
+IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
+
+Vixie, .
+P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
+
+Hardie, 2002.
+T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
+Addresses" in RFC3258 (April 2002).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+KATO                    Expires: August 24, 2003                [Page 5]
+
diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
new file mode 100644
index 0000000..f9eaf26
--- /dev/null
+++ b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
@@ -0,0 +1,1830 @@
+  
+  
+  
+  INTERNET-DRAFT                                       S. Daniel Park
+  Expires: October 2003                              Syam Madanapalli
+  File:                                           SAMSUNG Electronics
+  draft-park-ipv6-extensions-dns-pnp-00.txt                April 2003
+  
+  
+  
+  
+                 IPv6 Extensions for DNS Plug and Play
+  
+  
+  
+  Status of This Memo   
+  
+  This document is an Internet-Draft and is in full conformance with
+  all provisions of Section 10 of RFC2026.
+
+  Internet-Drafts are working documents of the Internet Engineering
+  Task Force (IETF), its areas, and its working groups. Note that
+  other groups may also distribute working documents as
+  Internet-Drafts.
+
+  Internet-Drafts are draft documents valid for a maximum of six
+  months and may be updated, replaced, or obsoleted by other
+  documents at any time. It is inappropriate to use Internet-Drafts
+  as reference material or to cite them other than as "work in
+  progress."
+
+  The list of current Internet-Drafts can be accessed at
+  http://www.ietf.org/ietf/1id-abstracts.txt
+
+  The list of Internet-Draft Shadow Directories can be accessed at
+  http://www.ietf.org/shadow.html.
+  
+  
+  
+  Abstract  
+  
+  This document proposes automatic configuration of domain name (FQDN)
+  for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
+  a part of IPv6 plug and play feature. 6DNAC allows the automatic
+  registration of domain name and corresponding IPv6 Addresses with
+  the DNS server. In order to provide 6DNAC function, Neighbor Discovery
+  Protocol [2461] will be used. Moreover, 6DNAC does not require any
+  changes to the existing DNS system.
+  
+  
+  Table of Contents 
+  
+  1.       Introduction .............................................  3
+  2.       Terminology ..............................................  3
+  3.       6DNAC Design Principles ..................................  4
+  4.       6DNAC Overview ...........................................  4
+  5.       6DNAC Requirements .......................................  5
+  5.1.     6DANR Client Requirements ................................  5
+  5.2.     6DNAC Server Requirements ................................  6
+    
+Park & Madanapalli             Expires October 2003             [Page 1]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003    
+    
+  6.       6DNAC Messages and Option Formats ........................  6
+  6.1.     Router Advertisement (RA) Message Format .................  6
+  6.2.     Neighbor Solicitation (NS) Message Format ................  7
+  6.3.     Neighbor Advertisement (NA) Message Format ...............  8
+  6.4.     Option Formats ...........................................  8
+  6.4.1.   DNS Zone Suffix Information Option Format ................  8
+  6.4.2.   Domain Name (FQDN) Option Format .........................  9
+  6.4.3.   Router Alert Option for 6DNAC ............................ 10
+  7.       6DNAC Operation .......................................... 10
+  7.1.     6DNAC Network Topology ................................... 11
+  7.2.     6DNAC Operational Scenarios .............................. 12
+  7.2.1.   Domain Name Registration-Success Case .................... 12
+  7.2.2.   Domain Name Registration-with DupAddrDetectTransmits=2.... 14
+  7.2.3.   Domain Name Registration-Defend Case ..................... 16
+  7.2.4.   Domain Name Registration in Retry Mode ................... 19
+  7.2.5.   Domain Name Registration when DAD Fails .................. 20
+  7.3.     DNS Zone Suffix Discovery and FQDN Construction .......... 22
+  7.3.1.   Sending Router Advertisement Messages .................... 22
+  7.3.2.   Processing Router Advertisement Messages ................. 22
+  7.3.3.   FQDN Lifetime expiry ..................................... 23
+  7.3.4.   Host Naming Algorithm .................................... 23
+  7.4.     Duplicate Domain Name Detection .......................... 23
+  7.4.1.   DAD with All Nodes Multicast Address ..................... 24
+  7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
+  7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
+  7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
+  7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
+  7.4.1.5. Pros and Cons ............................................ 25
+  7.4.2.   DAD with Router Alert Option for 6DNAC ................... 25
+  7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
+  7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
+  7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
+  7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
+  7.4.2.5. Pros and Cons ............................................ 26
+  7.4.3.   Explicit Detection of Duplicate Domain Name .............. 26
+  7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
+  7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
+  7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
+  7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
+  7.4.3.5. Pros and Cons ............................................ 27
+  7.4.4.   Retry Mode for Re-registering Domain Name ................ 27
+  7.5.     Domain Name Registration ................................. 27
+  8.       Security Consideration ................................... 27
+  9.       IANA Consideration ....................................... 28
+  10.      Acknowledgement .......................................... 28
+  11.      Intellectual Property .................................... 28
+  12.      Copyright ................................................ 28
+  13.      References ............................................... 29
+  14.      Author's Addresses ....................................... 30
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003             [Page 2]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  1. Introduction 
+  
+  Today, most networks use DNS[1034][1035] for convenience. In case of
+  IPv6, DNS is more important element because of IPv6 long addresses
+  which are difficult to remember. In addition, small networks like home
+  networks using IPv6, should be able to make network easily without
+  manual configuration. Also, these small networks may not have DHCP
+  Server, DNS Server etc. that are used to configure the network. This
+  document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
+  for generating and registering the Domain Name and IPv6 addresses with
+  the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
+  required to implement lightweight functions specified in this document.
+  6DNAC can be applied to all defined IPv6 unicast addresses except Link
+  local IPv6 addresses, viz: Site-local and Global addresses.
+  
+  6DNAC uses Neighbor Discovery Protocol [2461] with new additions
+  (defined in section 6) and DAD procedures for generating and 
+  registering the Domain Name with the DNS server automatically.
+  
+  
+  2. Terminology
+
+  6DNAC         - IPv6 Domain Name Auto Configuration. It can provide
+                  IPv6 hosts with Domain Name Generation and 
+                  Registration automatically.
+  
+  6DNAC Client  - An IPv6 node that can generate its own unique Domain
+                  Name. Section 3 identifies the new requirements that
+                  6DNAC places on an IPv6 node to be a 6DNAC node.
+                  
+  6DNAC Server  - An IPv6 node that can collect and registrate Domain
+                  Name and IPv6 addresses automatically. 6DNAC server
+                  uses the information from the DAD operation messages
+                  with newly defined options for the registration of the 
+                  Domain Name and IPv6 Addresses. Section 3 identifies
+                  the new requirements that 6DNAC places on an IPv6 
+                  node to be a 6DNAC server. Also 6DNAC server can have 
+                  various other functions depending on network 
+                  environment and the network operator. For instance 
+                  6DNAC Server can acts as a Gateway as well Home Server
+                  in Home Networks.
+ 
+  DAD           - Duplicate Address Detection (is defined [2461]) 
+  
+  DFQDND        - Duplicate Domain Name Detection
+
+  FQDN          - Fully Qualified Domain Name - FQDN and Domain Name are 
+                  used interchangeably in this document.
+  
+  NA            - Neighbor Advertisement message (is defined [2461]) 
+  
+  NS            - Neighbor Solicitation message (is defined [2461])
+
+  RA            - Router Advertisement message (is defined [2461]) 
+
+  SLAAC         - Stateless Address Autoconfiguration [2462].
+
+Park & Madanapalli             Expires October 2003             [Page 3]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  3. 6DNAC Design Principles
+  
+  This section discusses the design principles of 6DNAC mechanism.
+  
+  1. The new procedures for plug and play DNS should not cause changes
+     to existing DNS system. 6DNAC requires lightweight functions to be 
+     implemented only at the client side of the DNS system, and uses the 
+     existing DDNS UPDATE [2136] to communicate with DNS Servers.
+  
+  2. Introducing a new protocol will always introduce new problems. 
+     6DNAC uses the existing protocols NDP [2461] with minor extensions 
+     for generating and registering the domain name automatically 
+     without defining a new protocol
+  
+  3. Reusing proven and well understood design principles/patterns 
+     will always yield a robust system. 6DNAC is based on IPv6 Address 
+     Auotoconfiguration principle, where routers advertise the prefix
+     and host adds the interface ID to the prefix and forms the IPv6 
+     address. Domain Name (FQDN) also contains two parts: host name 
+     and DNS zone suffix. Routers can advertise the DNS zone suffix 
+     on a particular link in Router Advertisements (RA Messages) and 
+     hosts can prefix their preferred host name to the DNS zone suffix
+     and form the fully qualified domain name. Also the detection of
+     duplicate domain name is similar to Duplicate Address Detection
+     (DAD) and can be part of DAD operation itself.
+  
+  
+  4. 6DNAC Overview
+  
+  6DNAC proposes minor extensions to NDP [2461] for automatic generation
+  and registration of domain name with the DNS server. It introduces two
+  new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
+  Suffix option is carried in Router Advertisement (RA) messages for
+  notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
+  FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
+  (NA) messages to detect duplicate domain name. 6DNAC consists of two
+  components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
+  domain name based on DNS Zone Suffix using Host Naming Algorithm (see
+  section 7.3.1) and 6DNAC Server collects and registers the DNS
+  information with the DNS Server on behalf of 6DNAC Clients.
+
+  The automatic configuration of domain name using 6DNAC consists of
+  three parts.
+
+     - DNS Zone Suffix Discovery and FQDN Construction:
+
+       IPv6 Nodes collect DNS Zone Suffix information from Router
+       Advertisements and constructs FQDN by prefixing host name to the
+       DNS Zone Suffix. The IPv6 Nodes are required to implement Host 
+       Naming Algorithm for generating host part of the FQDN in the 
+       absence of administrator.
+
+  Generation of node's FQDN within the node itself has advantages. Nodes
+  can provide forward and reverse name lookups independent of the DNS
+  System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
+  Name is some thing that is owned by the node.
+
+Park & Madanapalli             Expires October 2003             [Page 4]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+     - Duplicate Domain Name Detection
+
+       All nodes are expected to go for DAD for all new IPv6 unicast
+       addresses, regardless of whether they are obtained through 
+       stateful, stateless or manual configuration. 6DNAC uses the DAD 
+       messages with new option for carrying the Domain Name along with 
+       the new IPv6 Address. 6DNAC Server captures this information and
+       updates DNS Server provided that the IPv6 Address and its domain
+       name are not duplicate. If the domain name is already in use, 
+       the 6DNAC server replies to the sender with FQDN Option in NA 
+       message indicating that the domain name is duplicate. Then the
+       node is expected to generate another domain name using host 
+       naming algorithm and go for DAD. This time the DAD is only for
+       duplicate domain name detection (DFQDND). In order to avoid
+       confusion with the normal NDP processing, the target address 
+       field of the NS message must carry the unspecified address 
+       in retry mode.  This can be repeated depending on number of
+       retries defined by the administrator in the host naming algorithm.
+
+  
+     - Domain Name Registration
+
+       6DNAC Server detects the DNS information (IPv6 Address and 
+       corresponding FQDN) from DAD/DFQDND messages and updates DNS 
+       Server using existing protocol DDNS UPDATE [2136] provided that
+       the IPv6 Address and its domain name are not duplicate.
+  
+  If an IPv6 Address is duplicate, the IPv6 node cannot perform
+  stateless address autoconfiguration repeatedly. Unlike IPv6 stateless 
+  address autoconfiguration, 6DNAC allows the automatic configuration of
+  domain name repeatedly if the domain name is duplicate depending on 
+  number of retries defined by the administrator in the host naming 
+  algorithm.
+  
+  
+  5. 6DNAC Requirements 
+  
+  Depending on the 6DNAC functionality, the IPv6 nodes implement, they
+  are called either 6DNAC Clients or 6DNAC Servers. The following 
+  sections lists the requirements that the 6DNAC Client and 6DNAC server
+  must support.
+   
+   
+  5.1. 6DANC Client Requirements
+  
+        - 6DNAC Client must recognize and process the following NDP 
+          extensions
+
+              - DNS Zone Suffix option in RA messages for generating its
+                domain name (FQDN).
+
+              - Domain Name option in NS and NA messages for detecting 
+                the duplicate domain name
+ 
+ 
+ 
+
+Park & Madanapalli             Expires October 2003             [Page 5]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
+  
+        - It must generate its domain name (FQDN) based on the DNS 
+          suffix that it got from the router advertisement. And it must 
+          have a host naming algorithm for generating the host part of
+          the FQDN.
+
+        - If NA message is received with unspecified target address and
+          FQDN option, then the node must treat that the domain is 
+          duplicate.
+  
+  
+  5.2. 6DNAC Server Requirements
+  
+        - 6DNAC Server must recognize and process the following NDP
+          extensions
+      
+              - If the 6DNAC Server is a router on the link, then it
+                must advertise DNS Zone Suffix option in RA messages
+                for hosts to generate their domain name (FQDN).
+
+              - FQDN option in NS messages for detecting new DNS
+                information for of nodes on the link for which it
+                must update the AAAA RR and PTR RR in DNS Server.
+
+              - FQDN option in NA messages for notifying duplicate
+                domain name with unspecified target address.
+  
+        - 6DNAC server must update the DNS Server (both AAAA RR and
+          PTR RR) dynamically using DDNS UPDATE [2136].
+  
+        - 6DNAC server must cache this (newly detected) FQDN, Link
+          Layer Address, and IPv6 Address information, so that it can
+          decide whether it really needs to update DNS Server or not,
+          to avoid redundant updates. This information will also be
+          used for notifying the duplicate domain name.
+  
+  
+  6. 6DNAC Messages and Option Formats
+  
+  In order to achieve the plug and play DNS, 6DNAC proposes new 
+  extensions to the NDP [2461]. This section specifies the new
+  additions to NDP messages and formats of new options.
+  
+  
+  6.1. Router Advertisement (RA) Message Format
+  
+  Routers send out Router Advertisement (RA) message periodically, or
+  in response to a Router Solicitation. 6DNAC does not modify the format
+  of the RA message, but proposes new option (DNS Zone Suffix Information)
+  to be carried in RA messages.
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003             [Page 6]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                         Reachable Time                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          Retrans Timer                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...                                                 |
+     /                                                               /
+     |                  DNS Zone Suffix Information                  |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                          <Figure: 1 RA message>
+  
+  
+  
+  6.2. Neighbor Solicitation (NS) Message Format 
+  
+  6DNAC does not modify the format of the Neighbor Solicitation (NS)
+  message, but proposes new option (FQDN Option) to be carried in NS
+  messages. When a node is going for DAD, the node must include FQDN
+  option in NS message to participate in plug and play DNS. If the
+  node is going for Explicit Detection of Duplicate Domain Name, the
+  node must use FQDN option in NS message and unspecified address in
+  the target address field.
+  
+  
+      0                   1                   2                   3 
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                           Reserved                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                       Target Address                          +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...                                                 |
+     /                                                               /
+     |                         Domain Name                           |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                         <Figure: 2 NS message>
+  
+Park & Madanapalli             Expires October 2003             [Page 7]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  6.3. Neighbor Advertisement (NA) Message Format 
+  
+  6DNAC does not modify the format of the Neighbor Advertisement (NA)
+  message, but proposes new option (FQDN Option) to be carried in NA
+  messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
+  Client that is performing duplicate domain name detection in case
+  the domain name found to be duplicate.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |R|S|O|                     Reserved                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                       Target Address                          +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...                                                 |
+     /                                                               /
+     |                         FQDN Option                           |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                          <Figure: 3 NA message> 
+  
+  
+  6.4 Option Formats
+  
+  6.4.1. DNS Zone Suffix Information Option Format
+  
+  IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
+  6DNAC introduces new option for routers to advertise the DNS Zone
+  Suffix Information for IPv6 nodes on the link. The suffix information
+  should be configured into routers manually.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |    Length     |          Reserved             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          Valid Lifetime                       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     /                       DNS Zone Suffix                         /
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                   <Figure: 4 DNS Zone Suffix Information>
+
+Park & Madanapalli             Expires October 2003             [Page 8]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  Type              [TBD]
+  
+  Length            8-bit unsigned integer. The length of the option
+                    (including the type and length fields) in units of
+                    8 octets.
+  
+  Reserved          This field is unused. It must be initialized to zero
+                    by the sender and must be ignored by the receiver.
+  
+  Valid Life Time   32-bit signed integer.  The maximum time, in 
+                    seconds, over which this suffix is valid. Nodes 
+                    should treat this as the life time for their domain
+                    name. Nodes should contact the source of this
+                    information before expiry of this time interval.
+                    A value of all one bits (0xFFFFFFFF) represents
+                    infinity.
+  
+  DNS Zone Suffix   The suffix part of the FQDN. The data in the DNS 
+                    Zone Suffix field should be encoded according to 
+                    DNS encoding rules specified in [1035].
+  
+  
+  
+  6.4.2. Domain Name (FQDN) Option Format
+  
+  
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |    Length     |          Reserved             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          Valid Lifetime                       |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                       FQDN Target Address                     +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     /                         Domain Name                           /
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  
+  
+                      <Figure: 5 FQDN Information>
+  
+  Type                 [TBD]
+  
+  Length               8-bit unsigned integer. The length of the option
+                       (including the type and length fields) in units 
+                       of 8 octets.  It must be greater than 3.
+                       
+                       
+
+Park & Madanapalli             Expires October 2003             [Page 9]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003                       
+  
+  Reserved             This field is unused. It must be initialized to
+                       zero by the sender and must be ignored by the
+                       receiver.
+  
+  Valid Life Time      32-bit signed integer.  The maximum time, in 
+                       seconds, over which this domain name is valid
+                       6DNAC should deregister this domain name at
+                       the expiry of this interval. 6DNAC clients
+                       should send updates by the expiry of this 
+                       interval. A value of all one bits (0xFFFFFFFF)
+                       represents infinity.
+
+  FQDN Target Address  The Address for which the FQDN maps to.  It 
+                       should be same as Target Address field of the 
+                       NS message in case of DAD & duplicate FQDN are
+                       running in parallel.
+
+  Domain Name          The domain name (FQDN) of the node. The data in
+                       the domain name should be encoded according to
+                       DNS encoding rules specified in [1035].
+  
+  
+  6.4.3. Router Alert Option for 6DNAC
+
+  Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
+  Header for using in NDP messages.  The presence of this option in NS
+  message informs the router that this NS message is carrying Domain
+  Name information and must be processed by the 6DNAC Server on the router.
+  6DNAC Clients can use this option for sending DAD packets instead
+  of addressing the DAD packets to the all-nodes multicast address
+  when 6DNAC Server is implemented on router.
+ 
+  The Router Alert option has the following format:
+
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0|        Value (2 octets)       |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     Length = 2
+
+  Values are registered and maintained by the IANA. For 6DNAC, the 
+  value has to be assigned by IANA.
+
+  Further information about this option can be obtained from 
+  IPv6 Router Alert Option [2711].
+
+
+  7. 6DNAC Operation
+  
+  6DNAC provides mechanisms for automatic generation of domain name
+  and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
+  of two components: 6DNAC Client and 6DNAC Server. All nodes that want
+  to participate in plug and play DNS are required to implement 6DNAC
+  Client functionality, and one of the IPv6 nodes is required to 
+  implement 6DNAC Server functionality. The IPv6 node that implements 
+  the 6DNAC Server functionality must know the location of the DNS 
+  Server and must be a trusted node to send DDNS UPDATE [2136] messages.
+
+Park & Madanapalli             Expires October 2003            [Page 10]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  7.1. 6DNAC Network Topology
+  
+  This section identifies the possible locations for the 6DNAC Server.
+  Note that, all nodes are required to implement 6DNAC Client 
+  functionality for constructing the domain name from the DNS Zone 
+  Suffix Information advertised by the router.  Figure 6 illustrates 
+  IPv6 host (H4) implementing 6DNAC Server functionality. In this case 
+  H4 can serve only one link (that it belongs to) for automatic 
+  registration of domain name. H4 must observe the DAD packets on the 
+  link to detect the DNS information, this requires all nodes on the 
+  link must belong to same solicited node multicast address. In general,
+  this may not be the case. So the node that is going for DAD must use
+  all nodes multicast address for DAD packets, so that the 6DNAC Server
+  (H4) can observe the DAD packets, detects IPv6 address and 
+  corresponding domain name, checks if this domain name is duplicate 
+  and finally registers the domain name with the DNS Server.
+ 
+  
+                          6DNAC Server
+      +---+                   +---+                     +----------+
+      | H1|                   | H4|<--- DDNS UPDATE --->|DNS Server|
+      +-+-+                   +-+-+                     +----+-----+
+        |                       |           +----+       +---/
+        |                       |           |    |      /
+     ---+-----+-----------+-----+-----------+ R1 +-----+
+              |           |                 |    |
+              |           |                 +----+
+            +-+-+       +-+-+
+            | H2|       | H3|
+            +---+       +---+
+  
+  
+  H1, H2, H3 - 6DNAC Clients
+  H4         - 6DNAC Server
+  R1         - Router
+  
+  
+                  <Figure: 6 Example of 6DNAC Topology>
+  
+  
+  Figure 7 shows the 6DNAC Server implemented on a router R1. In this
+  case a single 6DNAC server can serve multiple links for automatic
+  configuration of the domain name. This topology also has flexibility
+  of using DAD packets with Router Alert option instead of sending DAD
+  packets to all nodes multicast address. The routers are required to
+  process all the packets with Router Alert option as per [2711].
+
+  In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
+  connected to ISP. R1 delegates the prefix from the ISP edge router.
+  After delegating the prefix the CPE can advertise the DNS Zone suffix
+  along with the prefix information to the nodes on the links to which
+  the router is connected to. Note that the R1 must be configured with
+  the DNS Zone suffix Information manually. 
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 11]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+                         +---+       +---+ 
+                         | H3+       | H4|
+                         +-+-+       +-+-+
+                           |           |
+                           |   LINK2   |
+      +---+             ---+--------+--+--          +----------+
+      | H1|                         |               |DNS Server|
+      +-+-+                         |               +----+-----+
+        |                        +--+-+           -------/
+        |         LINK 1         |    |          /
+     ---+-----+------------------+ R1 +---------+
+              |                  |    |      DDNS UPDATE
+              |                  +----+
+            +-+-+             6DNAC Server
+            | H2|
+            +---+
+  
+  
+  H1, H2 - 6DNAC Clients on Link1
+  H3, H4 - 6DNAC Clients on Link2
+  R1     - Router with 6DNAC Server, serving both Link1 and Link2
+  
+  
+       <Figure: 7 Example of 6DNAC Server serving multiple links>
+  
+  
+  7.2. 6DNAC Operational Scenarios
+  
+  This section provides message sequence charts for various 6DNAC
+  operational scenarios assuming that the 6DNAC Server is implemented
+  on a router. All the scenarios assume that the normal boot up time
+  stateless address autoconfiguration of Link Local address derived
+  from the Interface Identifier has been completed successfully. And
+  it is also assumed that the router is already configured with the
+  DNS Zone Suffix Information.
+
+  
+  Legend:
+  
+  6DNAC-A, B, C  : 6DNAC Clients
+  6DNAC-S        : 6DNAC Server/Router
+  DAD            : Duplicate Address Detection
+  DFQDND         : Duplicate Domain Name Detection
+  DNS-S          : DNS Server
+  
+  
+  7.2.1. Domain Name Registration-Successful Case 
+
+  This scenario starts when a 6DNAC Client receives RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and wants configure its IPv6 address (Global
+  or Site Local) and domain name. It is Assumed that the 
+  DupAddrDetectTransmits is set to 1.
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 12]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+  
+   +---------+      +---------+      +---------+
+   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+
+        |                |                |
+        |     RA with    |                |
+        | DNS Suffix Opt |                |
+        |<---------------|                |
+        |       #1       |                |
+        |---+            |                |
+  Construct |#2          |                |
+    FQDN    |            |                |
+        |<--+            |                |
+DAD/DFQDND Starts        |                |
+        |                |                |
+        |                |                |
+        |    NS With     |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |       #3       |                |
+        |                |                |
+        |                |------+         |
+        |          Create FQDN  | #4      |
+        |            <FQDN,C>   |         |
+        |                |<-----+         |
+        |                |                |
+        |                |  Register FQDN |
+        |                |--------------->|
+        |                |       #5       |
+        |   #6           |                |
+        |--------+       |                |
+   No Response   |       |                |
+  DFQDND-Success |       |                |
+        |<-------+       |                |
+        |                |                |
+        |                |                |
+        v                V                v  
+
+
+          <Figure: 8 Domain Name Generation and Registration>
+           
+  
+  #1. 6DNAC Server (Router) sends out router advertisement with DNS
+      Suffix information along with other parameters as specified in
+      NDP [2461].
+  
+  #2. 6DNAC Client processes the router advertisement and constructs
+      the FQDN by prefixing hostname to the DNS Zone Suffix. It also
+      constructs IPv6 address from the autoconfiguration prefix
+      information option.
+
+  #3. 6DNAC Client starts duplicate address & FQDN detection for the
+      IPv6 address & FQDN constructed and sends out a Neighbor
+      Solicitation message with FQDN option. 
+
+      Note that the DAD packets must be addressed to all nodes multicast
+      address if Router Alert option is not used. 
+      
+Park & Madanapalli             Expires October 2003            [Page 13]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
+
+  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+      6DNAC Client as part of duplicate FQDN detection procedure and
+      creates a FQDN entry in its FQDN Cache (assuming that there is no
+      entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client.
+
+  #5.  6DNAC Server then registers FQDN and corresponding IPv6 address
+       through the existing protocol DDNS UPDATE.
+
+  #6.  6DNAC Client times out and observes that there is no response to
+       defend its duplicate FQDN detection procedure and the node is
+       successful in configuring its domain name.
+  
+  Note that, Stateless Address Autoconfiguration DAD procedure is not
+  depicted in the following message sequence chart, which simultaneously
+  happens along with duplicate FQDN detection.
+  
+
+  7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 
+
+  This scenario starts when a 6DNAC Client receives RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and wants configure its IPv6 address (Global
+  or Site Local) and domain name. The node is configured with 
+  DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 14]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
+
+   +---------+      +---------+      +---------+
+   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+
+        |                |                |
+        |     RA with    |                |
+        | DNS Suffix Opt |                |
+        |<---------------|                |
+        |       #1       |                |
+        |---+            |                |
+  Construct |#2          |                |
+    FQDN    |            |                |
+        |<--+            |                |
+DAD/DFQDND Starts        |                |
+        |                |                |
+        |                |                |
+        |    NS With     |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |       #3       |                |
+        |                |                |
+        |                |------+         |
+        |          Create FQDN  | #4      |
+        |            <FQDN,C>   |         |
+        |                |<-----+         |
+        |                |                |
+        |                |  Register FQDN |
+        |                |--------------->|
+        |                |       #5       |
+        |    NS With     |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |      #6        |                |
+        |                |                |
+        |          Lookup FQDN            |
+        |          Entry exists           |
+        |                |------+         |
+        |             Ignore    | #7      |
+        |                |<-----+         |
+        |   #8           |                |
+        |--------+       |                |
+   No Response   |       |                |
+  DFQDND-Success |       |                |
+        |<-------+       |                |
+        |                |                |
+        |                |                |
+        v                V                v  
+
+  
+  
+            <Figure: 9 Verification of duplicated Domain Name>
+
+
+  Steps from #1 to #5 are same as that of scenario.7.2.1.
+  
+  #6. 6DNAC Client sends out second Neighbor Solicitation message with
+      FQDN option as part of duplicate FQDN detection.
+      
+Park & Madanapalli             Expires October 2003            [Page 15]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
+
+  #7. 6DNAC Server receives and observes that the FQDN Cache exactly
+      matches with that of the NS information and ignores the NS message.
+
+  #8. 6DNAC Client times out and observes that there is no response to
+      defend its duplicate FQDN detection procedure and the node is
+      successful in configuring its domain name..
+
+  
+  7.2.3. Domain Name Registration-Defend Case 
+
+  This scenario starts when two 6DNAC Client receive RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and both the nodes want configure their IPv6
+  address (Global or Site Local) and domain name. In this scenario both
+  the nodes want to have same domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 16]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+
+   +---------+      +---------+      +---------+      +---------+
+   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+      +----+----+
+        |                |                |                |
+        |     RA with    |     RA with    |                |
+        | DNS Suffix Opt | DNS Suffix Opt |                |
+        |<---------------|--------------->|                |
+        |       #1       |       #1       |                |
+        |---+            |                |---+            |
+  Construct | #2         |          Construct | #2         |
+      FQDN  |            |              FQDN  |            |
+        |<--+            |                |<--+            |
+ DAD/DFQDND Starts       |         DAD/DFQDND Starts       |
+        |                |            <DELAYED>            |
+        |                |                |                |
+        |    NS with     |                |                |
+        |    FQDN Opt    |                |                |
+        |--------------->|                |                |
+        |      #3        |                |                |
+        |            No Entry             |                |
+        |                |------+         |                |
+        |          Create FQDN  | #4      |                |
+        |            <FQDN,A>   |         |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |                |         Register FQDN #5        |
+        |                |-------------------------------->|
+        |                |                |                |
+        |                |    NS with     |                |
+        |                |    FQDN Opt    |                |
+        |                |<---------------|                |
+        |                |       #6       |                |
+        |                |------+         |                |
+        |         FQDN is in use|         |                |
+        |          Defend DFQDND| #7      |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |                |    NA with     |                |
+        |                |    D-flag Set  |                |
+        |                |--------------->|                |
+        |                |       #8       |                |
+        |------+         |                |---+            |
+ No Response   | #9      |            Enter   | #10        |
+ DFQDND Success|         |          Retry Mode|            |
+        |<-----+         |                |<--+            |
+        |                |                |                |
+        v                v                v                v
+
+         
+       <Figure: 10 Multiple Hosts Requesting Same Domain Name>
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 17]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
+
+  #1. 6DNAC Server (Router) sends out router advertisement with DNS
+      Suffix information.
+      
+  #2. 6DNAC Clients A&B process the router advertisement and construct
+      their FQDN by prefixing hostname to the DNS Zone Suffix.  They
+      also construct IPv6 address from the autoconfiguration prefix
+      information option.
+      
+      When each host is trying to go for DAD, all hosts must have
+      random delay to avoid the traffic congestion according to [2461].
+      So here it is assumed that 6DNAC Client-A starts DAD first and
+      6DNAC Client-B starts DAD later.
+
+  #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
+      IPv6 address & FQDN constructed and sends out a Neighbor
+      Solicitation message with FQDN option.
+   
+  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+      6DNAC Client-A as part of duplicate FQDN detection procedure and
+      creates a FQDN entry in its FQDN Cache (assuming that there is no
+      entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A.
+
+  #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
+      through the existing protocol DDNS UPDATE.
+
+  #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
+      IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
+      message with FQDN option. 
+
+  #7. 6DNAC Server processes the Neighbor Solicitation message sent by
+      6DNAC Client-B as part of duplicate FQDN detection procedure and 
+      finds that the domain name is already in use by the 6DNAC Client-A.
+      Hence, concludes to defend the duplicate FQDN detection of 6DNAC
+      Client-B.
+
+  #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
+      option to 6DNAC Client-B to defend its duplicate FQDN detection.
+
+  #9. 6DNAC Client-A times out and observes that there is no response to
+      defend its duplicate FQDN detection procedure and the node is 
+      successful in configuring its domain name.
+
+  #10. 6DNAC Client-B observes that there is a NA with FQDN option
+       indicating that the domain name is duplicate and enters Retry
+       Mode. In retry mode, 6DNAC Client constructs another FQDN based
+       on Host Naming Algorithm. The number of retries is defined by the
+       administrator and must be a configurable value.
+  
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 18]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
+  
+  7.2.4. Domain Name Registration in Retry Mode
+
+  Pre-Conditions:
+
+  1. Duplicate Address Detection has succeeded 
+  2. Duplicate FQDN Detection FAILED
+  3. FQDN is the first FQDN one constructed and FAILED
+  4. FQDN2 is the second FQDN to be constructed
+  5. The Neighbor Solicitation in the 'Retry Mode'
+    carries unspecified address in its target field (NS*).
+
+   +---------+      +---------+      +---------+
+   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+
+        |                |                |
+        |--------+       |                |
+    Construct    | #1    |                |
+    new FQDN2    |       |                |
+        |<-------+       |                |
+        |                |                |
+  DFQDND Restarts        |                |
+        |                |                |
+        |                |                |
+        |    NS* With    |                |
+        |    FQDN Opt    |                |
+        |--------------->|                |
+        |       #2       |                |
+        |                |                |
+        |            No Entry             |
+        |                |------+         |
+        |          Create FQDN  | #3      |
+        |            <FQDN2,C>  |         |
+        |                |<-----+         |
+        |                |                |
+        |                | Register FQDN2 |
+        |                |--------------->|
+        |                |       #4       |
+        |                |                |
+        |--------+       |                |
+   No Response   | #5    |                |
+  DFQDND-Success |       |                |
+        |<-------+       |                |
+        |                |                |
+        v                V                v
+
+                
+                <Figure: 11 Regeneration of Domain Name>
+                
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 19]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+ 
+  #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
+      the DNS Zone Suffix, and it is FQDN2.
+  #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
+      Client sends out NS with FQDN option and unspecified target
+      address.
+
+  #3. 6DNAC Server processes the Retry Mode NS message and finds that
+      the FQDN2 is not in use and creates Cache entry as <FQDN2, C>.
+
+  #4. It then starts registration procedures with the DNS Server.
+
+  #5. Meanwhile, 6DNAC Client timesout and observes that there is no
+      defending NA for its DFQDND NS sent out and successfully
+      configures its domain name.
+
+
+  7.2.5. Domain Name Registration when DAD Fails
+
+  Duplicate domain name detection and subsequent registration starts 
+  if and only if the DAD for IPv6 address succeeds. If the DAD for
+  IPv6 address fails then no actions are taken for domain name. When
+  DAD fails for stateless address autoconfiguration, then the domain
+  configuration starts only when the address has been configured using 
+  Stateful Address Configuration methods and the node is going on DAD
+  for this address.
+
+  This scenario starts when a 6DNAC Client receives RA message with
+  DNS Zone Suffix and other parameters including address prefix as
+  specified in NDP [2461] and wants configure its IPv6 address (Global
+  or Site Local) and domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 20]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+   +---------+      +---------+      +---------+      +---------+
+   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
+   +----+----+      +----+----+      +----+----+      +----+----+
+        |                |                |                |
+        |                |                |                |
+        |     RA with    |                |                |
+        | DNS Suffix Opt |                |                |
+        |<---------------|                |                |
+        |       #1       |                |                |
+        |-----+          |                |                |
+    Construct |          |                |                |
+      FQDN&   | #2       |                |                |
+    IPv6 Addr |          |                |                |
+        |<----+          |                |                |
+ DAD/DFQDND Starts       |                |                |
+        |                |                |                |
+        |                |                |                |
+        |    NS with     |                |                |
+        |    FQDN Opt    |                |                |
+        |--------------->+--------------->|                |
+        |       #3       |        #3      |                |
+        |            No Entry             |                |
+        |                |------+         |                |
+        |          Create FQDN  |         |                |
+        |            <FQDN,A>   | #4      |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |                |                |------+         |
+        |                |           My IPv6 Addr| #5      |
+        |                |                |<-----+         |
+        |                |   Defend DAD   |                |
+        |                |    with NA     |                |
+        |<---------------+<---------------|                |
+        |      #6        |       #6       |                |
+        |              Entry              |                |
+        |                |------+         |                |
+        |          Delete FQDN  | #7      |                |
+        |                |<-----+         |                |
+        |                |                |                |
+        |----+           |                |                |
+  DAD Failed | #8        |                |                |
+ Stop DFQDND |           |                |                |
+        |<---+           |                |                |
+        |                |                |                |
+        v                v                v                v
+
+                     <Figure: 12 DAD failure>
+
+  #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
+
+  #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
+      FQDN as per Host Naming Algorithm. 
+
+  #3. It then starts Duplicate address & FQDN Detection, for the newly 
+      constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
+      with FQDN option.  
+
+Park & Madanapalli             Expires October 2003            [Page 21]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
+
+  #4. 6DNAC Server processes the DAD/DFQDND NS message and finds 
+      that there is no entry for the FQDN in its cache. And,
+      creates Cache entry as <FQDN, A> and starts a Registration
+      timer with RegistrationWaitTime seconds.
+
+  #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is 
+      in its unicast address list.  
+
+  #6. It then starts defending DAD by sending NA to all-nodes multicast.
+
+  #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.  
+      And, deletes its FQDN Cache entry <FQDN,A>.
+      
+  #8. 6DNAC Client gets defending DAD-NA and desists from DAD. 
+      And also, stops Duplicate FQDN Detection as well.
+      At this point the address must be configured using stateful 
+      methods and the domain name registration starts with the DAD
+      for the newly constructed IPv6 address.
+  
+  7.3. DNS Zone Suffix Discovery and FQDN Construction
+  
+  7.3.1. Sending Router Advertisement Messages
+
+  Routers send out Router Advertisement message periodically, 
+  or in response to a Router Solicitation. Router should include 
+  the DNS Zone Suffix Option in their advertisements. If the DNS
+  Zone Suffix changes (similar to Site Renumbering), then it should
+  advertise the Old Zone Suffix with zero Valid Lifetime and New
+  Zone Suffix with proper non-zero Valid Lifetime.  In any other
+  case, a router should not send this option twice in a single
+  router advertisement.
+
+  7.3.2. Processing Router Advertisement Messages  
+
+  For each DNS Zone Suffix Option in Router Advertisement,
+
+  a. 6DNAC node stores the Zone Suffix information in its local
+     database.  Also, constructs FQDN as per Host Naming Algorithm.
+
+  b. If the node has not configured FQDN yet,
+
+     1. If the node is going to perform DAD for either Site local or 
+        Global Address, then it should include FQDN option to perform
+        Duplicate FQDN Detection in parallel with DAD.
+
+     2. If the node has already got either Site local or Global 
+        address, then it should send out NS with FQDN option and 
+        unspecified target address to perform Duplicate FQDN 
+        Detection.
+
+  c. If the node has already configured FQDN, and if the 
+     advertisement carries two DNS Zone Suffix Options,
+     First DNS Zone Suffix should match with the configured FQDN 
+     Suffix and its Valid Lifetime must be zero. Second DNS Zone
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 22]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+     Suffix should have non-zero Valid Lifetime. In this case, the
+     node constructs new FQDN based on the new DNS Zone Suffix (from
+     second DNS Zone Suffix option), and perform Duplicate FQDN 
+     Detection with unspecified target address.  Also, it should
+     overwrite the old FQDN with the newly constructed FQDN.
+     
+
+  7.3.3. FQDN Lifetime expiry
+
+  6DNAC Server:  
+  It should delete the FQDN cache entry and should de-register from
+  the DNS Server.
+
+  6DNAC Client:
+  It should send update to 6DNAC Server by restarting the Duplicate 
+  FQDN Detection. 
+  
+  7.3.4. Host Naming Algorithm
+ 
+  A node constructs FQDN by combining DNS Zone Suffix and the hostname
+  as depicted in the following diagram.
+
+     +------------------+----------------------------------+
+     |     Host Name    |          Advertised Suffix       |
+     +------------------+----------------------------------+
+
+          <Figure 13: Fully Qualified Domain Name format>
+
+  A node can choose Host Name using any of the following methods:
+ 
+  a. String form of random number generated from the Interface 
+     Identifier.
+     
+  b. List of configured Host Names provided by the administrator.
+
+  
+  The number of retries must be specified in this algorithm in 
+  case of domain name duplication.
+  
+    
+  7.4. Duplicate Domain Name Detection
+  
+  The procedure for detecting duplicated FQDNs uses Neighbor
+  Solicitation and Advertisement messages as described below.
+
+  If a duplicate FQDN is detected during the procedure, the
+  FQDN cannot be assigned to the node.
+
+  An FQDN on which the DFQDND Procedure is applied is said 
+  to be tentative until the procedure has completed successfully.  
+  A tentative FQDN is not considered "assigned to the node" in the 
+  traditional sense.  That is, the node must accept Neighbor 
+  Advertisement message containing the tentative FQDN in the FQDN 
+  Option.
+
+
+Park & Madanapalli             Expires October 2003            [Page 23]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  It should also be noted that DFQDN must be performed prior to 
+  registering with DNS Server to prevent multiple nodes from using 
+  the same FQDN simultaneously. All the Duplicate Address Detection 
+  Neighbor Solicitation messages must carry Source Link Layer Address 
+  Option as specified in NDP [2461]. 
+
+  The detection of duplicate FQDN can be achieved through one of the
+  following three types of procedures.
+  
+  1. DAD with All Nodes Multicast Address
+  2. DAD with Router Alert Option for 6DNAC.
+  3. Explicit Detection of Duplicate Domain Name
+   
+  Even though three solutions are listed, authors prefer only one 
+  procedure to be followed in future based on further analysis and
+  comments received from others. 
+  
+  7.4.1. DAD with All Nodes Multicast Address
+  
+  7.4.1.1. Sending Neighbor Solicitation Messages
+
+  6DNAC Client sends Neighbor Solicitation Messages as part
+  of Duplicate Address Detection SLAAC [2462] with the following 
+  extra information and modifications:
+
+  a. Include FQDN Option in the DAD Neighbor Solicitation Message
+  b. Destination Address is set to All Nodes Multicast Address
+
+  There may be a case where DAD has succeeded but DFQDND is in Retry 
+  Mode. In such case, the Neighbor Solicitation must carry unspecified 
+  address in the ICMP target address field and new domain name in FQDN
+  option to re-try the registration of the domain name.
+
+  7.4.1.2. Processing Neighbor Solicitation Messages
+
+  6DNAC Clients must ignore the FQDN option found in any of the
+  neighbor solicitation messages.
+
+  6DNAC Server processes FQDN Option found in the Duplicate Address 
+  Detection Neighbor Solicitation Messages as described below:
+
+  Lookup FQDN Cache for the domain name in FQDN Option.
+
+  If the entry exists and 
+   i. Link Layer Address matches with SLLA option, this is the case, 
+      where node has changed its IPv6 address or updating the valid 
+      life time. 6DNAC Server updates its cache and also updates DNS
+      Server using DDNS-UPDATE. If there is no change in IPv6 address
+      or life time then no updates are sent to the DNS server. 
+
+  ii. Link Layer Address differs with SLLA option, defend the duplicate 
+      FQDN Detection by sending Neighbor Advertisement Message as 
+      described in $7.4.1.3$.
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 24]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  else,
+    Lookup FQDN Cache for the Link Layer Address in SLLA Option.
+
+    If the entry exists, update the FQDN Cache and update DNS Server 
+    using DDNS-UPDATE. This is the case, where node has changed its
+    domain name (similar to Site Re-numbering).
+
+    If then entry does not exists, then it means that this is the new 
+    registration. It must create a cache entry and start Registration    
+    
+    timer with RegistrationWaitTime. At the expiry of the Registration
+    timer, it should update DNS Server with DDNS-UPDATE.
+
+  7.4.1.3. Sending Neighbor Advertisement Messages
+
+  6DNAC Server sends Neighbor Advertisement Messages as part
+  of Duplicate Address Detection SLAAC [2462] with the FQDN Option 
+  in Neighbor Advertisement message to defend duplicate FQDN 
+  detection.
+
+  There may be the case where defending of duplicate address detection 
+  is not required but defending of FQDN is required.  In such instance, 
+  the defending Neighbor Advertisement must carry FQDN and unspecified
+  address in the ICMP target address field.
+
+  7.4.1.4. Processing Neighbor Advertisement Messages
+
+  6DNAC Server must ignore the any FQDN option found any of 
+  the neighbor advertisement messages.  If the Neighbor Advertisement
+  is a DAD defending, then it must delete its FQDN Cache entry created 
+  on the reception of DAD Neighbor Solicitation message.
+
+  When 6DNAC Clients gets the duplicate address detection neighbor
+  advertisement messages with FQDN option set it means that its
+  duplicate FQDN detection failed and enters Retry Mode.
+
+  7.4.1.5. Pros and Cons
+  
+  The advantage of this procedure is that it does not need any 
+  extension header options to be included. The disadvantage of this 
+  procedure is that, it needs change in the existing DAD procedure.
+  The change is only that the DAD neighbor solicitations are to be 
+  addressed to all nodes multicast address instead of solicited 
+  node multicast address. The another disadvantage is that, it needs 
+  the existence of Duplicate Address Detection Procedure to 
+  perform duplicate FQDN detection. 
+  
+  7.4.2. DAD with Router Alert Option for 6DNAC
+
+  7.4.2.1. Sending Neighbor Solicitation Messages
+
+  6DNAC Client sends Neighbor Solicitation Messages as part
+  of Duplicate Address Detection SLAAC [2462] with the following 
+  extra information:
+
+
+Park & Madanapalli             Expires October 2003            [Page 25]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  a. Include Hop-by-Hop extension Header with Router Alert Option
+     for 6DNAC as described in IPv6 Router Alert Option[2711].
+
+  b. Include FQDN Option in the DAD Neighbor Solicitation Message
+
+  7.4.2.2. Processing Neighbor Solicitation Messages
+
+  This is same as described in $7.4.1.2$. 
+
+  7.4.2.3. Sending Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.3$. 
+
+  7.4.2.4. Processing Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.4$.
+
+  7.4.2.5. Pros and Cons
+
+  The advantage of this procedure is that it does not disturb
+  the existing implementation and their way of processing the 
+  packets.  The disadvantage is that, it needs the existence 
+  of Duplicate Address Detection Procedure to perform duplicate 
+  FQDN detection. Another disadvantage is that this procedure 
+  requires 6DNAC Server functionality to be implemented on Router.
+  However, in this case 6DNAC Server can serve multiple links.
+  
+  7.4.3. Explicit Detection of Duplicate Domain Name
+
+  In this procedure Duplicate FQDN Detection starts after completion
+  of successful Site local or Global Address configuration.
+  
+  7.4.3.1. Sending Neighbor Solicitation Messages
+
+  6DNAC Client sends Neighbor Solicitation Messages as part
+  of Duplicate FQDN Detection with the following information:
+
+  a. Include FQDN Option in the Neighbor Solicitation Message
+
+  b. Destination Address is set to All Nodes Multicast Address
+     or uses Router Alert Option for 6DNAC, when 6DNAC Server is 
+     implemented on router.
+
+  c. Target Address is set to Unspecified Address
+
+  d. Other fields are set as per DAD SLAAC [2462].
+
+  7.4.3.2. Processing Neighbor Solicitation Messages
+
+  This is same as described in $7.4.1.2$.
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 26]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
+
+
+  7.4.3.3. Sending Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.3$.
+
+  7.4.3.4. Processing Neighbor Advertisement Messages
+
+  This is same as described in $7.4.1.4$.
+
+  7.4.3.5. Pros and Cons
+
+  The advantage of this procedure is that it does not need the
+  existing duplicate address detection procedure.  This is introduced
+  as the DAD procedure is found to be redundant in when IPv6 addresses
+  are constructed from the interface ID [DIID].
+
+  Note that, if 6DNAC Clients know the address of 6DNAC Server then
+  they can directly send DFQDND-NS to 6DNAC Server. 
+
+  7.4.4. Retry Mode for Re-registering Domain Name
+
+  In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
+  Then they restart Duplicate FQDN Detection as described in $7.4.3$.
+
+
+  7.5. Domain Name Registration
+  
+  6DNAC Server must be an authenticated to update the DNS Server.
+  6DNAC Server must also be configured with the DNS Server 
+  information.
+
+  6DNAC Server detects the DNS information (IPv6 Address and 
+  corresponding FQDN) from DAD/DFQDND messages and caches the
+  information. It also have an associated Registration Timer with 
+  RegistrationWaitTime to wait for the successful completion of 
+  DFQDND and update DNS Server using existing protocol DDNS UPDATE 
+  [2136].
+  
+                 
+  8. Security Consideration
+   
+  If someone wants to hijack correct Domain Name registration, they 
+  could send a NS message with incorrect or same Domain Name to the
+  6DNAC server repeatedly and server would start the Domain Name 
+  registration through above mechanism, which is a security hole. 
+  As described in [2461], a host can check validity of NDP messages.
+  If the NDP message include an IP Authentication Header, the message
+  authenticates correctly. For DNS UPDATE processing, secure DNS
+  Dynamic Update is described in [3007].
+  
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 27]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+  
+  9. IANA Consideration
+  
+  Values in the Router Alert Option are registered and maintained by
+  IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
+  required to assign the Type values for DNS Zone Suffix Information
+  option and FADN option.
+
+  
+  10. Acknowledgement
+  
+  Special thanks are due to Badrinarayana N.S. and Christian Huitema for
+  many helpful suggestions and revisions. 
+  
+  
+  11. Intellectual Property
+
+  The following notice is copied from RFC 2026 [Bradner, 1996],
+  Section 10.4, and describes the position of the IETF concerning
+  intellectual property claims made against this document.
+
+  The IETF takes no position regarding the validity or scope of any
+  intellectual property or other rights that might be claimed to
+  pertain to the implementation or use other technology described in
+
+  this document or the extent to which any license under such rights
+  might or might not be available; neither does it represent that it
+  
+  has made any effort to identify any such rights.  Information on the
+  IETF's procedures with respect to rights in standards-track and
+  standards-related documentation can be found in BCP-11.  Copies of
+  claims of rights made available for publication and any assurances
+  of licenses to be made available, or the result of an attempt made
+  to obtain a general license or permission for the use of such
+  proprietary rights by implementers or users of this specification
+  can be obtained from the IETF Secretariat.
+
+  The IETF invites any interested party to bring to its attention any
+  copyrights, patents or patent applications, or other proprietary
+  rights which may cover technology that may be required to practice
+  this standard.  Please address the information to the IETF Executive
+  Director.
+  
+  
+  12. Copyright
+
+  The following copyright notice is copied from RFC 2026 [Bradner,
+  1996], Section 10.4, and describes the applicable copyright for this
+  document.
+
+  Copyright (C) The Internet Society July 12, 2001. All Rights
+  Reserved.
+  
+  This document and translations of it may be copied and furnished to
+  others, and derivative works that comment on or otherwise explain it
+  or assist in its implementation may be prepared, copied, published
+
+Park & Madanapalli             Expires October 2003            [Page 28]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+
+  and distributed, in whole or in part, without restriction of any
+  kind, provided that the above copyright notice and this paragraph
+  are included on all such copies and derivative works.  However, this
+  
+  document itself may not be modified in any way, such as by removing
+  the copyright notice or references to the Internet Society or other
+  Internet organizations, except as needed for the purpose of
+  developing Internet standards in which case the procedures for
+  copyrights defined in the Internet Standards process must be
+  followed, or as required to translate it into languages other than
+  English.
+
+  The limited permissions granted above are perpetual and will not be
+  revoked by the Internet Society or its successors or assignees.
+
+  This document and the information contained herein is provided on an
+  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+  
+  
+  13. References
+   
+  [2373]        Hinden, R. and S. Deering, "IP Version 6 Addressing 
+                Architecture", RFC 2373, July 1998. 
+       
+  [2460]        Deering, S. abd R. Hinden, "Internet Protocol, 
+                Version 6 (IPv6) Specification", RFC 2460, 
+                December 1998. 
+               
+  [2461]        Narten, T., Nordmark, E. and W. Simpson, "Neighbor 
+                Discovery for IP version 6(IPv6)", RFC 2461, December 
+                1998. 
+
+  [2462]        S. Thomson and Narten T, "IPv6 Stateless Address Auto- 
+                Configuration", RFC 2462, December 1998. 
+               
+  [2711]        C. Patridge and A.Jackson, "IPv6 Router Alert Option",
+                RFC 2711, October 1999. 
+             
+  [1034]        P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND 
+                FACILITIES", RFC 1034, November 1987. 
+               
+  [1035]        P. Mockapetris, "Domain Names - Implementation and 
+                Specification" RFC 1035, November 1987. 
+
+  [2136]        P. Vixie et al., "Dynamic Updates in the Domain Name
+                System (DNS UPDATE)", RFC2136, April 1997.
+                
+  [3007]        B. Wellington, "Secure Domain Name System (DNS) Dynamic 
+                Update", RFC 3007, November 2000.
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 29]
+
+INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
+
+                 
+  [DIID]        yokohama-dad-vs-diid.pdf
+                at http://playground.sun.com/ipng/presentations/July2002/
+                
+  [DNSISSUES]   Durand, A., "IPv6 DNS transition issues", draft-ietf-              
+                dnsop-ipv6-dns-issues-00.txt, work in progress.
+                
+  [PREFIX]      S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
+                delegation", draft-ietf-ipv6-prefix-delegation-
+                requirement-01.txt, work in progress.
+   
+  [Autoreg]     H. Kitamura, "Domain Name Auto-Registration for 
+                Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
+                auto-reg-00.txt, work in progress.
+
+  [NIQ]         Matt Crawford, "IPv6 Node Information Queries", <draft-
+                ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress.
+                  
+  
+  14. Author's Addresses 
+  
+  Soohong Daniel Park 
+  Mobile Platform Laboratory, SAMSUNG Electronics, KOREA 
+  Phone: +82-31-200-3728 
+  Email:soohong.park@samsung.com
+  
+  Syam Madanapalli
+  Network Systems Division, SAMSUNG India Software Operations, INDIA
+  Phone: +91-80-5550555
+  Email:syam@samsung.com
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli             Expires October 2003            [Page 30]
diff --git a/doc/draft/update b/doc/draft/update
new file mode 100644
index 0000000..6ac2090
--- /dev/null
+++ b/doc/draft/update
@@ -0,0 +1,46 @@
+#!/bin/sh
+commit=
+for i
+do
+	z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
+	if test -n "$z"
+	then
+		i="$z"
+	fi
+	if test -f "$i"
+	then
+		continue
+	fi
+	pat=`echo "$i" | sed 's/...txt/??.txt/'`
+	old=`echo $pat 2> /dev/null`
+	if test "X$old" != "X$pat"
+	then
+		newer=0
+		for j in $old
+		do
+			if test $j ">" $i
+			then
+				 newer=1
+			fi
+		done
+		if test $newer = 1
+		then
+			continue;
+		fi
+	fi
+	if fetch "http://www.ietf.org/internet-drafts/$i" 
+	then
+		cvs add "$i" 
+		if test "X$old" != "X$pat"
+		then
+			rm $old
+			cvs delete $old
+			commit="$commit $old"
+		fi
+		commit="$commit $i"
+	fi
+done
+if test -n "$commit"
+then
+	cvs commit -m "new draft" $commit
+fi