This commit was manufactured by cvs2git to create tag 'v9_3_6_P1'.

CHANGES

@@ -1,8 +1,3 @@
-	--- 9.3.6-P2 released ---
-
-2579.	[bug]		DNSSEC lookaside validation failed to handle unknown
-			algorithms. [RT #19479]
-
 	--- 9.3.6-P1 released ---
 
 2522.	[security]	Handle -1 from DSA_do_verify().

COPYRIGHT

@@ -1,4 +1,4 @@
-Copyright (C) 2004-2010  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
 Copyright (C) 1996-2003  Internet Software Consortium.
 
 Permission to use, copy, modify, and/or distribute this software for any
@@ -13,7 +13,7 @@ LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
 OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 PERFORMANCE OF THIS SOFTWARE.
 
-$Id: COPYRIGHT,v 1.6.2.2.8.9 2010/01/20 23:45:39 tbox Exp $
+$Id: COPYRIGHT,v 1.6.2.2.8.7 2008/01/02 23:45:32 tbox Exp $
 
 Portions Copyright (C) 1996-2001  Nominum, Inc.
 

FAQ

@@ -1,6 +1,6 @@
 Frequently Asked Questions about BIND 9
 
-Copyright © 2004-2010 Internet Systems Consortium, Inc. ("ISC")
+Copyright © 2004-2008 Internet Systems Consortium, Inc. ("ISC")
 
 Copyright © 2000-2003 Internet Software Consortium.
 
@@ -153,29 +153,24 @@ A: BIND 9.3 and later: Use TSIG to select the appropriate view.
 
    Master 10.0.1.1:
            key "external" {
-                   algorithm hmac-sha256;
-                   secret "xxxxxxxxxxxxxxxxxxxxxxxx";
+                   algorithm hmac-md5;
+                   secret "xxxxxxxx";
            };
            view "internal" {
-                   match-clients { !key external; // reject message ment for the
-                                                  // external view.
-                                   10.0.1/24; };  // accept from these addresses.
+                   match-clients { !key external; 10.0.1/24; };
                    ...
            };
            view "external" {
                    match-clients { key external; any; };
-                   server 10.0.1.2 { keys external; };  // tag messages from the
-                                                        // external view to the
-                                                        // other servers for the
-                                                        // view.
+                   server 10.0.1.2 { keys external; };
                    recursion no;
                    ...
            };
 
    Slave 10.0.1.2:
            key "external" {
-                   algorithm hmac-sha256;
-                   secret "xxxxxxxxxxxxxxxxxxxxxxxx";
+                   algorithm hmac-md5;
+                   secret "xxxxxxxx";
            };
            view "internal" {
                    match-clients { !key external; 10.0.1/24; };
@@ -225,13 +220,13 @@ A: You choose one view to be master and the second a slave and transfer
 
    Master 10.0.1.1:
            key "external" {
-                   algorithm hmac-sha256;
-                   secret "xxxxxxxxxxxxxxxxxxxxxxxx";
+                   algorithm hmac-md5;
+                   secret "xxxxxxxx";
            };
 
            key "mykey" {
-                   algorithm hmac-sha256;
-                   secret "yyyyyyyyyyyyyyyyyyyyyyyy";
+                   algorithm hmac-md5;
+                   secret "yyyyyyyy";
            };
 
            view "internal" {
@@ -244,7 +239,7 @@ A: You choose one view to be master and the second a slave and transfer
                            type master;
                            file "internal/example.db";
                            allow-update { key mykey; };
-                           also-notify { 10.0.1.1; };
+                           notify-also { 10.0.1.1; };
                    };
            };
 
@@ -254,7 +249,7 @@ A: You choose one view to be master and the second a slave and transfer
                            type slave;
                            file "external/example.db";
                            masters { 10.0.1.1; };
-                           transfer-source 10.0.1.1;
+                           transfer-source { 10.0.1.1; };
                            // allow-update-forwarding { any; };
                            // allow-notify { ... };
                    };
@@ -605,7 +600,7 @@ Q: Why do queries for NSEC3 records fail to return the NSEC3 record?
 
 A: NSEC3 records are strictly meta data and can only be returned in the
    authority section. This is done so that signing the zone using NSEC3
-   records does not bring names into existence that do not exist in the
+   records does not bring names into existance that do not exist in the
    unsigned version of the zone.
 
 5. Operating-System Specific Questions
@@ -784,22 +779,6 @@ A: Red Hat Security Enhanced Linux (SELinux) policy security protections :
    See these man-pages for more information : selinux(8), named_selinux
    (8), chcon(1), setsebool(8)
 
-Q: I'm running BIND on Ubuntu -
-
-   Why can't named update slave zone database files?
-
-   Why can't named create DDNS journal files or update the master zones
-   from journals?
-
-   Why can't named create custom log files?
-
-A: Ubuntu uses AppArmor <http://en.wikipedia.org/wiki/AppArmor> in
-   addition to normal file system permissions to protect the system.
-
-   Adjust the paths to use those specified in /etc/apparmor.d/
-   usr.sbin.named or adjust /etc/apparmor.d/usr.sbin.named to allow named
-   to write at the location specified in named.conf.
-
 Q: Listening on individual IPv6 interfaces does not work.
 
 A: This is usually due to "/proc/net/if_inet6" not being available in the
@@ -846,6 +825,7 @@ A: /dev/random is not configured. Use rndcontrol(8) to tell the kernel to
    use certain interrupts as a source of random events. You can make this
    permanent by setting rand_irqs in /etc/rc.conf.
 
+   /etc/rc.conf
    rand_irqs="3 14 15"
 
    See also <http://people.freebsd.org/~dougb/randomness.html>.

FAQ.xml

@@ -1,7 +1,7 @@
 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
        "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
 <!--
- - Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -17,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: FAQ.xml,v 1.4.6.30 2009/10/06 01:23:32 tbox Exp $ -->
+<!-- $Id: FAQ.xml,v 1.4.6.25 2008/09/10 01:22:05 tbox Exp $ -->
 
 <article class="faq">
   <title>Frequently Asked Questions about BIND 9</title>
@@ -28,7 +28,6 @@
       <year>2006</year>
       <year>2007</year>
       <year>2008</year>
-      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -319,29 +318,24 @@ Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
 	  <programlisting>
 Master 10.0.1.1:
 	key "external" {
-		algorithm hmac-sha256;
-		secret "xxxxxxxxxxxxxxxxxxxxxxxx";
+		algorithm hmac-md5;
+		secret "xxxxxxxx";
 	};
 	view "internal" {
-		match-clients { !key external; // reject message ment for the
-					       // external view.
-				10.0.1/24; };  // accept from these addresses.
+		match-clients { !key external; 10.0.1/24; };
 		...
 	};
 	view "external" {
 		match-clients { key external; any; };
-		server 10.0.1.2 { keys external; };  // tag messages from the
-						     // external view to the
-						     // other servers for the
-						     // view.
+		server 10.0.1.2 { keys external; };
 		recursion no;
 		...
 	};
 
 Slave 10.0.1.2:
 	key "external" {
-		algorithm hmac-sha256;
-		secret "xxxxxxxxxxxxxxxxxxxxxxxx";
+		algorithm hmac-md5;
+		secret "xxxxxxxx";
 	};
 	view "internal" {
 		match-clients { !key external; 10.0.1/24; };
@@ -429,13 +423,13 @@ named-checkzone example.com tmp</programlisting>
 	  <programlisting>
 Master 10.0.1.1:
 	key "external" {
-		algorithm hmac-sha256;
-		secret "xxxxxxxxxxxxxxxxxxxxxxxx";
+		algorithm hmac-md5;
+		secret "xxxxxxxx";
 	};
 
 	key "mykey" {
-		algorithm hmac-sha256;
-		secret "yyyyyyyyyyyyyyyyyyyyyyyy";
+		algorithm hmac-md5;
+		secret "yyyyyyyy";
 	};
 
 	view "internal" {
@@ -1073,7 +1067,7 @@ empty:
 	  NSEC3 records are strictly meta data and can only be
 	  returned in the authority section.  This is done so that
 	  signing the zone using NSEC3 records does not bring names
-	  into existence that do not exist in the unsigned version
+	  into existance that do not exist in the unsigned version
 	  of the zone.
 	</para>
       </answer>
@@ -1476,6 +1470,7 @@ options {
 	</para>
 	<informalexample>
 	  <programlisting>
+/etc/rc.conf
 rand_irqs="3 14 15"</programlisting>
 	</informalexample>
 	<para>

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]

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-----------------------
+

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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

doc/draft/draft-ietf-6man-text-addr-representation-07.txt

@@ -1,785 +0,0 @@
-
-
-
-IPv6 Maintenance Working Group                               S. Kawamura
-Internet-Draft                                         NEC BIGLOBE, Ltd.
-Updates: 4291 (if approved)                                 M. Kawashima
-Intended status: Standards Track                NEC AccessTechnica, Ltd.
-Expires: August 29, 2010                               February 25, 2010
-
-
-         A Recommendation for IPv6 Address Text Representation
-              draft-ietf-6man-text-addr-representation-07
-
-Abstract
-
-   As IPv6 deployment increases there will be a dramatic increase in the
-   need to use IPv6 addresses in text.  While the IPv6 address
-   architecture in RFC 4291 section 2.2 describes a flexible model for
-   text representation of an IPv6 address this flexibility has been
-   causing problems for operators, system engineers, and users.  This
-   document defines a canonical textual representation format.  It does
-   not define a format for internal storage, such as within an
-   application or database.  It is expected that the canonical format is
-   followed by humans and systems when representing IPv6 addresses as
-   text, but all implementations must accept and be able to handle any
-   legitimate RFC 4291 format.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 29, 2010.
-
-Copyright Notice
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 1]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 2]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
-   2.  Text Representation Flexibility of RFC4291 . . . . . . . . . .  4
-     2.1.  Leading Zeros in a 16 Bit Field  . . . . . . . . . . . . .  4
-     2.2.  Zero Compression . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Uppercase or Lowercase . . . . . . . . . . . . . . . . . .  5
-   3.  Problems Encountered with the Flexible Model . . . . . . . . .  6
-     3.1.  Searching  . . . . . . . . . . . . . . . . . . . . . . . .  6
-       3.1.1.  General Summary  . . . . . . . . . . . . . . . . . . .  6
-       3.1.2.  Searching Spreadsheets and Text Files  . . . . . . . .  6
-       3.1.3.  Searching with Whois . . . . . . . . . . . . . . . . .  6
-       3.1.4.  Searching for an Address in a Network Diagram  . . . .  7
-     3.2.  Parsing and Modifying  . . . . . . . . . . . . . . . . . .  7
-       3.2.1.  General Summary  . . . . . . . . . . . . . . . . . . .  7
-       3.2.2.  Logging  . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.2.3.  Auditing: Case 1 . . . . . . . . . . . . . . . . . . .  7
-       3.2.4.  Auditing: Case 2 . . . . . . . . . . . . . . . . . . .  8
-       3.2.5.  Verification . . . . . . . . . . . . . . . . . . . . .  8
-       3.2.6.  Unexpected Modifying . . . . . . . . . . . . . . . . .  8
-     3.3.  Operating  . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.3.1.  General Summary  . . . . . . . . . . . . . . . . . . .  8
-       3.3.2.  Customer Calls . . . . . . . . . . . . . . . . . . . .  8
-       3.3.3.  Abuse  . . . . . . . . . . . . . . . . . . . . . . . .  9
-     3.4.  Other Minor Problems . . . . . . . . . . . . . . . . . . .  9
-       3.4.1.  Changing Platforms . . . . . . . . . . . . . . . . . .  9
-       3.4.2.  Preference in Documentation  . . . . . . . . . . . . .  9
-       3.4.3.  Legibility . . . . . . . . . . . . . . . . . . . . . .  9
-   4.  A Recommendation for IPv6 Text Representation  . . . . . . . .  9
-     4.1.  Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
-     4.2.  "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
-       4.2.1.  Shorten As Much As Possible  . . . . . . . . . . . . . 10
-       4.2.2.  Handling One 16 Bit 0 Field  . . . . . . . . . . . . . 10
-       4.2.3.  Choice in Placement of "::"  . . . . . . . . . . . . . 10
-     4.3.  Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
-   5.  Text Representation of Special Addresses . . . . . . . . . . . 10
-   6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
-   7.  Prefix Representation  . . . . . . . . . . . . . . . . . . . . 12
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 13
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 3]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-1.  Introduction
-
-   A single IPv6 address can be text represented in many ways.  Examples
-   are shown below.
-
-      2001:db8:0:0:1:0:0:1
-
-      2001:0db8:0:0:1:0:0:1
-
-      2001:db8::1:0:0:1
-
-      2001:db8::0:1:0:0:1
-
-      2001:0db8::1:0:0:1
-
-      2001:db8:0:0:1::1
-
-      2001:db8:0000:0:1::1
-
-      2001:DB8:0:0:1::1
-
-   All of the above examples represent the same IPv6 address.  This
-   flexibility has caused many problems for operators, systems
-   engineers, and customers.  The problems are noted in Section 3.
-   Also, a canonical representation format to avoid problems is
-   introduced in Section 4.
-
-1.1.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Text Representation Flexibility of RFC4291
-
-   Examples of flexibility in Section 2.2 of [RFC4291] are described
-   below.
-
-2.1.  Leading Zeros in a 16 Bit Field
-
-      'It is not necessary to write the leading zeros in an individual
-      field.'
-
-   Conversely it is also not necessary to omit leading zeros.  This
-   means that, it is possible to select from such as the following
-   example.  The final 16 bit field is different, but all these
-   addresses represent the same address.
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 4]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
-
-2.2.  Zero Compression
-
-      'A special syntax is available to compress the zeros.  The use of
-      "::" indicates one or more groups of 16 bits of zeros.'
-
-   It is possible to select whether or not to omit just one 16 bits of
-   zeros.
-
-      2001:db8:aaaa:bbbb:cccc:dddd::1
-
-      2001:db8:aaaa:bbbb:cccc:dddd:0:1
-
-   In case where there is more than one zero fields, there is a choice
-   of how many fields can be shortened.
-
-      2001:db8:0:0:0::1
-
-      2001:db8:0:0::1
-
-      2001:db8:0::1
-
-      2001:db8::1
-
-   In addition, [RFC4291] in section 2.2 notes,
-
-      'The "::" can only appear once in an address.'
-
-   This gives a choice on where in a single address to compress the
-   zero.
-
-      2001:db8::aaaa:0:0:1
-
-      2001:db8:0:0:aaaa::1
-
-2.3.  Uppercase or Lowercase
-
-   [RFC4291] does not mention any preference of uppercase or lowercase.
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 5]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
-
-      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
-
-
-3.  Problems Encountered with the Flexible Model
-
-3.1.  Searching
-
-3.1.1.  General Summary
-
-   A search of an IPv6 address if conducted through a UNIX system is
-   usually case sensitive and extended options to allow for regular
-   expression use will come in handy.  However, there are many
-   applications in the Internet today that do not provide this
-   capability.  When searching for an IPv6 address in such systems, the
-   system engineer will have to try each and every possibility to search
-   for an address.  This has critical impacts especially when trying to
-   deploy IPv6 over an enterprise network.
-
-3.1.2.  Searching Spreadsheets and Text Files
-
-   Spreadsheet applications and text editors on GUI systems, rarely have
-   the ability to search for a text using regular expression.  Moreover,
-   there are many non-engineers (who are not aware of case sensitivity
-   and regular expression use) that use these application to manage IP
-   addresses.  This has worked quite well with IPv4 since text
-   representation in IPv4 has very little flexibility.  There is no
-   incentive to encourage these non-engineers to change their tool or
-   learn regular expression when they decide to go dual-stack.  If the
-   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
-   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
-   One example where this will cause problem is, when the search is
-   being conducted to assign a new address from a pool, and a check was
-   being done to see if it was not in use.  This may cause problems to
-   the end-hosts or end-users.  This type of address management is very
-   often seen in enterprise networks and also in ISPs.
-
-3.1.3.  Searching with Whois
-
-   The "whois" utility is used by a wide range of people today.  When a
-   record is set to a database, one will likely check the output to see
-   if the entry is correct.  If an entity was recorded as 2001:db8::/48,
-   but the whois output showed 2001:0db8:0000::/48, most non-engineers
-   would think that their input was wrong and will likely retry several
-   times or make a frustrated call to the database hostmaster.  If there
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 6]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   was a need to register the same address on different systems, and
-   each system showed a different text representation, this would
-   confuse people even more.  Although this document focuses on
-   addresses rather than prefixes, this is worth mentioning since the
-   problems encountered are mostly equal.
-
-3.1.4.  Searching for an Address in a Network Diagram
-
-   Network diagrams and blueprints often show what IP addresses are
-   assigned to a system devices.  In times of trouble shooting there may
-   be a need to search through a diagram to find the point of failure
-   (for example, if a traceroute stopped at 2001:db8::1, one would
-   search the diagram for that address).  This is a technique quite
-   often in use in enterprise networks and managed services.  Again, the
-   different flavors of text representation will result in a time-
-   consuming search leading to longer MTTR in times of trouble.
-
-3.2.  Parsing and Modifying
-
-3.2.1.  General Summary
-
-   With all the possible methods of text representation each application
-   must include a module, object, link, etc. to a function that will
-   parse IPv6 addresses in a manner that no matter how it is
-   represented, they will mean the same address.  Many system engineers
-   who integrate complex computer systems for corporate customers will
-   have difficulties finding that their favorite tool will not have this
-   function, or will encounter difficulties such as having to rewrite
-   their macros or scripts for their customers.
-
-3.2.2.  Logging
-
-   If an application were to output a log summary that represented the
-   address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
-   the output would be highly unreadable compared to the IPv4 output.
-   The address would have to be parsed and reformed to make it useful
-   for human reading.  Sometimes logging for critical systems is done by
-   mirroring the same traffic to two different systems.  Care must be
-   taken so that no matter what the log output is the logs should be
-   parsed so they will mean the same.
-
-3.2.3.  Auditing: Case 1
-
-   When a router or any other network appliance machine configuration is
-   audited, there are many methods to compare the configuration
-   information of a node.  Sometimes auditing will be done by just
-   comparing the changes made each day.  In this case if configuration
-   was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 7]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   0000:0000:0000:0001 just because the new engineer on the block felt
-   it was better, a simple diff will show that a different address was
-   configured.  If this was done on a wide scale network people will be
-   focusing on 'why the extra zeros were put in' instead of doing any
-   real auditing.  Lots of tools are just plain diffs that do not take
-   into account address representation rules.
-
-3.2.4.  Auditing: Case 2
-
-   Node configurations will be matched against an information system
-   that manages IP addresses.  If output notation is different there
-   will need to be a script that is implemented to cover for this.  The
-   result of an SNMP GET operation, converted to text and compared to a
-   textual address written by a human is highly unlikely to match on the
-   first try.
-
-3.2.5.  Verification
-
-   Some protocols require certain data fields to be verified.  One
-   example of this is X.509 certificates.  If an IPv6 address field in a
-   certificate was incorrectly verified by converting it to text and
-   making a simple textual comparison to some other address, the
-   certificate may be mistakenly shown as being invalid due to a
-   difference in text representation methods.
-
-3.2.6.  Unexpected Modifying
-
-   Sometimes, a system will take an address and modify it as a
-   convenience.  For example, a system may take an input of
-   2001:0db8:0::1 and make the output 2001:db8::1.  If the zeros were
-   input for a reason, the outcome may be somewhat unexpected.
-
-3.3.  Operating
-
-3.3.1.  General Summary
-
-   When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
-   0:0:1, the system may take the address and show the configuration
-   result as 2001:DB8::1:0:0:1.  Someone familiar with IPv6 address
-   representation will know that the right address is set, but not
-   everyone may understand this.
-
-3.3.2.  Customer Calls
-
-   When a customer calls to inquire about a suspected outage, IPv6
-   address representation should be handled with care.  Not all
-   customers are engineers nor have the same skill in IPv6 technology.
-   The network operations center will have to take extra steps to
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 8]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   humanly parse the address to avoid having to explain to the customers
-   that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1.  This is one
-   thing that will never happen in IPv4 because IPv4 address cannot be
-   abbreviated.
-
-3.3.3.  Abuse
-
-   Network abuse reports generally include the abusing IP address.  This
-   'reporting' could take any shape or form of the flexible model.  A
-   team that handles network abuse must be able to tell the difference
-   between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
-   placement of the "::" will result in a critical situation.  A system
-   that handles these incidents should be able to handle any type of
-   input and parse it in a correct manner.  Also, incidents are reported
-   over the phone.  It is unnecessary to report if the letter is an
-   uppercase or lowercase.  However, when a letter is spelled uppercase,
-   people tend to clarify that it is uppercase, which is unnecessary
-   information.
-
-3.4.  Other Minor Problems
-
-3.4.1.  Changing Platforms
-
-   When an engineer decides to change the platform of a running service,
-   the same code may not work as expected due to the difference in IPv6
-   address text representation.  Usually, a change in a platform (e.g.
-   Unix to Windows, Cisco to Juniper) will result in a major change of
-   code anyway, but flexibility in address representation will increase
-   the work load.
-
-3.4.2.  Preference in Documentation
-
-   A document that is edited by more than one author may become harder
-   to read.
-
-3.4.3.  Legibility
-
-   Capital case D and 0 can be quite often misread.  Capital B and 8 can
-   also be misread.
-
-
-4.  A Recommendation for IPv6 Text Representation
-
-   A recommendation for a canonical text representation format of IPv6
-   addresses is presented in this section.  The recommendation in this
-   document is one that, complies fully with [RFC4291], is implemented
-   by various operating systems, and is human friendly.  The
-   recommendation in this section SHOULD be followed by systems when
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010                [Page 9]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   generating an address to represent as text, but all implementations
-   MUST accept and be able to handle any legitimate [RFC4291] format.
-   It is advised that humans also follow these recommendations when
-   spelling an address.
-
-4.1.  Handling Leading Zeros in a 16 Bit Field
-
-   Leading zeros MUST be suppressed.  For example 2001:0db8::0001 is not
-   acceptable and must be represented as 2001:db8::1.  A single 16 bit
-   0000 field MUST be represented as 0.
-
-4.2.  "::" Usage
-
-4.2.1.  Shorten As Much As Possible
-
-   The use of symbol "::" MUST be used to its maximum capability.  For
-   example, 2001:db8::0:1 is not acceptable, because the symbol "::"
-   could have been used to produce a shorter representation 2001:db8::1.
-
-4.2.2.  Handling One 16 Bit 0 Field
-
-   The symbol "::" MUST NOT be used to shorten just one 16 bit 0 field.
-   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
-   2001:db8::1:1:1:1:1 is not correct.
-
-4.2.3.  Choice in Placement of "::"
-
-   When there is an alternative choice in the placement of a "::", the
-   longest run of consecutive 16 bit 0 fields MUST be shortened (i.e.
-   the sequence with three consecutive zero fields is shortened in 2001:
-   0:0:1:0:0:0:1).  When the length of the consecutive 16 bit 0 fields
-   are equal (i.e. 2001:db8:0:0:1:0:0:1), the first sequence of zero
-   bits MUST be shortened.  For example 2001:db8::1:0:0:1 is correct
-   representation.
-
-4.3.  Lower Case
-
-   The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
-   be represented in lower case.
-
-
-5.  Text Representation of Special Addresses
-
-   Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
-   IPv4-translatable addresses [I-D.ietf-behave-address-format] have
-   IPv4 addresses embedded in the low-order 32 bits of the address.
-   These addresses have special representation that may mix hexadecimal
-   and dot decimal notations.  The decimal notation may be used only for
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 10]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   the last 32 bits of the address.  For these addresses, mixed notation
-   is RECOMMENDED if the following condition is met: The address can be
-   distinguished as having IPv4 addresses embedded in the lower 32 bits
-   solely from the address field through the use of a well known prefix.
-   Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
-   writing.  If it is known by some external method that a given prefix
-   is used to embed IPv4, it MAY be represented as mixed notation.
-   Tools that provide options to specify prefixes that are (or are not)
-   to be represented as mixed notation may be useful.
-
-   There is a trade-off here where a recommendation to achieve exact
-   match in a search (no dot decimals whatsoever) and recommendation to
-   help the readability of an addresses (dot decimal whenever possible)
-   does not result in the same solution.  The above recommendation is
-   aimed at fixing the representation as much as possible while leaving
-   the opportunity for future well known prefixes to be represented in a
-   human friendly manner as tools adjust to newly assigned prefixes.
-
-   The text representation method noted in Section 4 should be applied
-   for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
-   0:0:0:0:0:ffff:192.0.2.1).
-
-
-6.  Notes on Combining IPv6 Addresses with Port Numbers
-
-   When IPv6 addresses and port numbers are represented in text combined
-   together, there are many different ways to do so.  Examples are shown
-   below.
-
-   o  [2001:db8::1]:80
-
-   o  2001:db8::1:80
-
-   o  2001:db8::1.80
-
-   o  2001:db8::1 port 80
-
-   o  2001:db8::1p80
-
-   o  2001:db8::1#80
-
-   The situation is not much different in IPv4, but the most ambiguous
-   case with IPv6 is the second bullet.  This is due to the "::"usage in
-   IPv6 addresses.  This style is NOT RECOMMENDED for its ambiguity.
-   The [] style as expressed in [RFC3986] SHOULD be employed, and is the
-   default unless otherwise specified.  Other styles are acceptable when
-   there is exactly one style for the given context and cross-platform
-   portability does not become an issue.  For URIs containing IPv6
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 11]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   address literals, [RFC3986] MUST be followed, as well as the rules in
-   this document.
-
-
-7.  Prefix Representation
-
-   Problems with prefixes are just the same as problems encountered with
-   addresses.  The text representation method of IPv6 prefixes should be
-   no different from that of IPv6 addresses.
-
-
-8.  Security Considerations
-
-   This document notes some examples where IPv6 addresses are compared
-   in text format.  The example on Section 3.2.5 is one that may cause a
-   security risk if used for access control.  The common practice of
-   comparing X.509 data is done in binary format.
-
-
-9.  IANA Considerations
-
-   None.
-
-
-10.  Acknowledgements
-
-   The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
-   Toshimitsu Matsuura for their generous and helpful comments in kick
-   starting this document.  We also would like to thank Brian Carpenter,
-   Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
-   Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
-   Vatiainen ,Dan Wing, and Doug Barton for their input.  Also a very
-   special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
-   Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
-   this document to the light of IETF working groups.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
-              (SIIT)", RFC 2765, February 2000.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 12]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-              Resource Identifier (URI): Generic Syntax", STD 66,
-              RFC 3986, January 2005.
-
-   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", RFC 4291, February 2006.
-
-11.2.  Informative References
-
-   [I-D.ietf-behave-address-format]
-              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
-              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
-              draft-ietf-behave-address-format-04 (work in progress),
-              January 2010.
-
-   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
-              Castro, "Application Aspects of IPv6 Transition",
-              RFC 4038, March 2005.
-
-   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
-              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
-              March 2008.
-
-
-Appendix A.  For Developers
-
-   We recommend that developers use display routines that conform to
-   these rules.  For example, the usage of getnameinfo() with flags
-   argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
-   except for the special addresses notes in Section 5.  The function
-   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
-   be called directly.  See [RFC4038] for details.
-
-
-Authors' Addresses
-
-   Seiichi Kawamura
-   NEC BIGLOBE, Ltd.
-   14-22, Shibaura 4-chome
-   Minatoku, Tokyo  108-8558
-   JAPAN
-
-   Phone: +81 3 3798 6085
-   Email: kawamucho@mesh.ad.jp
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 13]
-
-Internet-Draft          IPv6 Text Representation           February 2010
-
-
-   Masanobu Kawashima
-   NEC AccessTechnica, Ltd.
-   800, Shimomata
-   Kakegawa-shi, Shizuoka  436-8501
-   JAPAN
-
-   Phone: +81 537 23 9655
-   Email: kawashimam@necat.nec.co.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kawamura & Kawashima     Expires August 29, 2010               [Page 14]
-
-

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]
+

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]
+
+

doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt

@@ -0,0 +1,562 @@
+
+
+
+
+DNSEXT                                                          M. Stapp
+Internet-Draft                                       Cisco Systems, Inc.
+Expires: August 13, 2005                                        T. Lemon
+                                                           A. Gustafsson
+                                                           Nominum, Inc.
+                                                        February 9, 2005
+
+
+           A DNS RR for Encoding DHCP Information (DHCID RR)
+                  <draft-ietf-dnsext-dhcid-rr-09.txt>
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 13, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   It is possible for multiple DHCP clients to attempt to update the
+   same DNS FQDN as they obtain DHCP leases.  Whether the DHCP server or
+   the clients themselves perform the DNS updates, conflicts can arise.
+   To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 1]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+   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 . . . . . . . . . . . . . . . . . . . .  4
+     3.2   DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
+     3.3   The DHCID RR Type Codes  . . . . . . . . . . . . . . . . .  4
+     3.4   Computation of the RDATA . . . . . . . . . . . . . . . . .  4
+     3.5   Examples . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       3.5.1   Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
+       3.5.2   Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  6
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     9.1   Normative References . . . . . . . . . . . . . . . . . . .  8
+     9.2   Informative References . . . . . . . . . . . . . . . . . .  8
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
+       Intellectual Property and Copyright Statements . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 2]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+2.  Introduction
+
+   A set of procedures to allow DHCP [7] clients and servers to
+   automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
+   in "Resolution of DNS Name Conflicts" [1].
+
+   Conflicts can arise if multiple DHCP clients wish to use the same DNS
+   name.  To resolve such conflicts, "Resolution of DNS Name Conflicts"
+   [1] proposes storing client identifiers in the DNS to unambiguously
+   associate domain names with the DHCP clients using them.  In the
+   interest of clarity, it is preferable for this DHCP information to
+   use a distinct RR type.  This memo defines a distinct RR for this
+   purpose for use by DHCP clients or servers, the "DHCID" RR.
+
+   In order to avoid exposing potentially sensitive identifying
+   information, the data stored is the result of a one-way MD5 [5] hash
+   computation.  The hash includes information from the DHCP client's
+   REQUEST message as well as the domain name itself, so that the data
+   stored in the DHCID RR will be dependent on both the client
+   identification used in the DHCP protocol interaction and the domain
+   name.  This means that the DHCID RDATA will vary if a single client
+   is associated over time with more than one name.  This makes it
+   difficult to 'track' a client as it is associated with various domain
+   names.
+
+   The MD5 hash algorithm has been shown to be weaker than the SHA-1
+   algorithm; it could therefore be argued that SHA-1 is a better
+   choice.  However, SHA-1 is significantly slower than MD5.  A
+   successful attack of MD5's weakness does not reveal the original data
+   that was used to generate the signature, but rather provides a new
+   set of input data that will produce the same signature.  Because we
+   are using the MD5 hash to conceal the original data, the fact that an
+   attacker could produce a different plaintext resulting in the same
+   MD5 output is not significant concern.
+
+3.  The DHCID RR
+
+   The DHCID RR is defined with mnemonic DHCID and type code [TBD].  The
+   DHCID RR is only defined in the IN class.  DHCID RRs cause no
+   additional section processing.  The DHCID RR is not a singleton type.
+
+
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 3]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+3.1  DHCID RDATA format
+
+   The RDATA section of a DHCID RR in transmission contains RDLENGTH
+   bytes of binary data.  The format of this data and its interpretation
+   by DHCP servers and clients are described below.
+
+   DNS software should consider the RDATA section to be opaque.  DHCP
+   clients or servers use the DHCID RR to associate a DHCP client's
+   identity with a DNS name, so that multiple DHCP clients and servers
+   may deterministically perform dynamic DNS updates to the same zone.
+   From the updater's perspective, the DHCID resource record RDATA
+   consists of a 16-bit identifier type, in network byte order, followed
+   by one or more bytes representing the actual identifier:
+
+     	< 16 bits >	DHCP identifier used
+     	< n bytes >	MD5 digest
+
+
+3.2  DHCID Presentation Format
+
+   In DNS master files, the RDATA is represented as a single block in
+   base 64 encoding identical to that used for representing binary data
+   in RFC 2535 [8].  The data may be divided up into any number of white
+   space separated substrings, down to single base 64 digits, which are
+   concatenated to form the complete RDATA.  These substrings can span
+   lines using the standard parentheses.
+
+3.3  The DHCID RR Type Codes
+
+   The DHCID RR Type Code specifies what data from the DHCP client's
+   request was used as input into the hash function.  The type codes are
+   defined in a registry maintained by IANA, as specified in Section 7.
+   The initial list of assigned values for the type code is:
+
+   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
+   0x0001 = The data portion from a DHCPv4 client's Client Identifier
+      option [9].
+   0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
+      client's Client Identifier option [10] or the DUID field from a
+      DHCPv4 client's Client Identifier option [12]).
+
+   0x0003 - 0xfffe = Available to be assigned by IANA.
+
+   0xffff = RESERVED
+
+3.4  Computation of the RDATA
+
+   The DHCID RDATA is formed by concatenating the two type bytes with
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 4]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+   some variable-length identifying data.
+
+       < type > < data >
+
+   The RDATA for all type codes other than 0xffff, which is reserved for
+   future expansion, is formed by concatenating the two type bytes and a
+   16-byte MD5 hash value.  The input to the hash function is defined to
+   be:
+
+       data = MD5(< identifier > < FQDN >)
+
+   The FQDN is represented in the buffer in unambiguous canonical form
+   as described in RFC 2535 [8], section 8.1.  The type code and the
+   identifier are related as specified in Section 3.3: the type code
+   describes the source of the identifier.
+
+   When the updater is using the client's link-layer address as the
+   identifier, the first two bytes of the DHCID RDATA MUST be zero.  To
+   generate the rest of the resource record, the updater computes a
+   one-way hash using the MD5 algorithm across a buffer containing the
+   client's network hardware type, link-layer address, and the FQDN
+   data.  Specifically, the first byte of the buffer contains the
+   network hardware type as it appeared in the DHCP 'htype' field of the
+   client's DHCPREQUEST message.  All of the significant bytes of the
+   chaddr field in the client's DHCPREQUEST message follow, in the same
+   order in which the bytes appear in the DHCPREQUEST message.  The
+   number of significant bytes in the 'chaddr' field is specified in the
+   'hlen' field of the DHCPREQUEST message.  The FQDN data, as specified
+   above, follows.
+
+   When the updater is using the DHCPv4 Client Identifier option sent by
+   the client in its DHCPREQUEST message, the first two bytes of the
+   DHCID RR MUST be 0x0001, in network byte order.  The rest of the
+   DHCID RR MUST contain the results of computing an MD5 hash across the
+   payload of the option, followed by the FQDN.  The payload of the
+   option consists of the bytes of the option following the option code
+   and length.
+
+   When the updater is using the DHCPv6 DUID sent by the client in its
+   REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
+   in network byte order.  The rest of the DHCID RR MUST contain the
+   results of computing an MD5 hash across the payload of the option,
+   followed by the FQDN.  The payload of the option consists of the
+   bytes of the option following the option code and length.
+
+3.5  Examples
+
+
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 5]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+3.5.1  Example 1
+
+   A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
+   Ethernet MAC address 01:02:03:04:05:06 using domain name
+   "client.example.com" uses the client's link-layer address to identify
+   the client.  The DHCID RDATA is composed by setting the two type
+   bytes to zero, and performing an MD5 hash computation across a buffer
+   containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
+   address, and the domain name (represented as specified in
+   Section 3.4).
+
+     client.example.com.	A   	10.0.0.1
+     client.example.com. 	DHCID 	AAAUMru0ZM5OK/PdVAJgZ/HU
+
+
+3.5.2  Example 2
+
+   A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
+   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
+   in its DHCP request.  The server updates the name "chi.example.com"
+   on the client's behalf, and uses the DHCP client identifier option
+   data as input in forming a DHCID RR.  The DHCID RDATA is formed by
+   setting the two type bytes to the value 0x0001, and performing an MD5
+   hash computation across a buffer containing the seven bytes from the
+   client-id option and the FQDN (represented as specified in
+   Section 3.4).
+
+     chi.example.com.	A    	10.0.12.99
+     chi.example.com.	DHCID 	AAHdd5jiQ3kEjANDm82cbObk\012
+
+
+4.  Use of the DHCID RR
+
+   This RR MUST NOT be used for any purpose other than that detailed in
+   "Resolution of DNS Name Conflicts" [1].  Although this RR contains
+   data that is opaque to DNS servers, the data must be consistent
+   across all entities that update and interpret this record.
+   Therefore, new data formats may only be defined through actions of
+   the DHC Working Group, as a result of revising [1].
+
+5.  Updater Behavior
+
+   The data in the DHCID RR allows updaters to determine whether more
+   than one DHCP client desires to use a particular FQDN.  This allows
+   site administrators to establish policy about DNS updates.  The DHCID
+   RR does not establish any policy itself.
+
+   Updaters use data from a DHCP client's request and the domain name
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 6]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+   that the client desires to use to compute a client identity hash, and
+   then compare that hash to the data in any DHCID RRs on the name that
+   they wish to associate with the client's IP address.  If an updater
+   discovers DHCID RRs whose RDATA does not match the client identity
+   that they have computed, the updater SHOULD conclude that a different
+   client is currently associated with the name in question.  The
+   updater SHOULD then proceed according to the site's administrative
+   policy.  That policy might dictate that a different name be selected,
+   or it might permit the updater to continue.
+
+6.  Security Considerations
+
+   The DHCID record as such does not introduce any new security problems
+   into the DNS.  In order to avoid exposing private information about
+   DHCP clients to public scrutiny, a one-way hash is used to obscure
+   all client information.  In order to make it difficult to 'track' a
+   client by examining the names associated with a particular hash
+   value, the FQDN is included in the hash computation.  Thus, the RDATA
+   is dependent on both the DHCP client identification data and on each
+   FQDN associated with the client.
+
+   Administrators should be wary of permitting unsecured DNS updates to
+   zones which are exposed to the global Internet.  Both DHCP clients
+   and servers SHOULD use some form of update authentication (e.g., TSIG
+   [11]) when performing DNS updates.
+
+7.  IANA Considerations
+
+   IANA is requested to allocate an RR type number for the DHCID record
+   type.
+
+   This specification defines a new number-space for the 16-bit type
+   codes associated with the DHCID RR.  IANA is requested to establish a
+   registry of the values for this number-space.
+
+   Three initial values are assigned in Section 3.3, and the value
+   0xFFFF is reserved for future use.  New DHCID RR type codes are
+   tentatively assigned after the specification for the associated type
+   code, published as an Internet Draft, has received expert review by a
+   designated expert.  The final assignment of DHCID RR type codes is
+   through Standards Action, as defined in RFC 2434 [6].
+
+8.  Acknowledgements
+
+   Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
+   Ralph Droms for their review and suggestions.
+
+
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 7]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+9.  References
+
+9.1  Normative References
+
+   [1]  Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
+        DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Mockapetris, P., "Domain names - concepts and facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [4]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [5]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+        1992.
+
+   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+9.2  Informative References
+
+   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+         March 1997.
+
+   [8]   Eastlake, D., "Domain Name System Security Extensions",
+         RFC 2535, March 1999.
+
+   [9]   Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+         Extensions", RFC 2132, March 1997.
+
+   [10]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
+         Carney, "Dynamic Host Configuration Protocol for IPv6
+         (DHCPv6)", RFC 3315, July 2003.
+
+   [11]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+         "Secret Key Transaction Authentication for DNS (TSIG)",
+         RFC 2845, May 2000.
+
+   [12]  Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
+         for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
+
+
+
+
+
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 8]
+
+Internet-Draft                The DHCID RR                 February 2005
+
+
+Authors' Addresses
+
+   Mark Stapp
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   USA
+
+   Phone: 978.936.1535
+   Email: mjs@cisco.com
+
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   USA
+
+   Email: mellon@nominum.com
+
+
+   Andreas Gustafsson
+   Nominum, Inc.
+   950 Charter St.
+   Redwood City, CA  94063
+   USA
+
+   Email: gson@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al.            Expires August 13, 2005                [Page 9]
+
+Internet-Draft                The DHCID RR                 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.
+
+
+
+
+Stapp, et al.            Expires August 13, 2005               [Page 10]
+
+

doc/draft/draft-ietf-dnsext-dns-tcp-requirements-03.txt

@@ -1,504 +0,0 @@
-
-
-
-DNSEXT                                                         R. Bellis
-Internet-Draft                                                Nominet UK
-Updates: 1035, 1123                                       March 22, 2010
-(if approved)
-Intended status: Standards Track
-Expires: September 23, 2010
-
-
-          DNS Transport over TCP - Implementation Requirements
-               draft-ietf-dnsext-dns-tcp-requirements-03
-
-Abstract
-
-   This document updates the requirements for the support of TCP as a
-   transport protocol for DNS implementations.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 23, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Bellis                 Expires September 23, 2010               [Page 1]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   2.  Terminology used in this document . . . . . . . . . . . . . . . 3
-
-   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   4.  Transport Protocol Selection  . . . . . . . . . . . . . . . . . 4
-
-   5.  Connection Handling . . . . . . . . . . . . . . . . . . . . . . 5
-
-   6.  Response re-ordering  . . . . . . . . . . . . . . . . . . . . . 6
-
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-
-   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
-
-   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 7
-     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
-
-   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 8
-
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 2]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-1.  Introduction
-
-   Most DNS [RFC1035] transactions take place over UDP [RFC0768].  TCP
-   [RFC0793] is always used for zone transfers and is often used for
-   messages whose sizes exceed the DNS protocol's original 512 byte
-   limit.
-
-   Section 6.1.3.2 of [RFC1123] states:
-
-      DNS resolvers and recursive servers MUST support UDP, and SHOULD
-      support TCP, for sending (non-zone-transfer) queries.
-
-   However, some implementors have taken the text quoted above to mean
-   that TCP support is an optional feature of the DNS protocol.
-
-   The majority of DNS server operators already support TCP and the
-   default configuration for most software implementations is to support
-   TCP.  The primary audience for this document is those implementors
-   whose failure to support TCP restricts interoperability and limits
-   deployment of new DNS features.
-
-   This document therefore updates the core DNS protocol specifications
-   such that support for TCP is henceforth a REQUIRED part of a full DNS
-   protocol implementation.
-
-   Whilst this document makes no specific recommendations to operators
-   of DNS servers, it should be noted that failure to support TCP (or
-   blocking of DNS over TCP at the network layer) may result in
-   resolution failure and/or application-level timeouts.
-
-
-2.  Terminology used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Discussion
-
-   In the absence of EDNS0 (see below) the normal behaviour of any DNS
-   server needing to send a UDP response that would exceed the 512 byte
-   limit is for the server to truncate the response so that it fits
-   within that limit and then set the TC flag in the response header.
-   When the client receives such a response it takes the TC flag as an
-   indication that it should retry over TCP instead.
-
-   RFC 1123 also says:
-
-
-
-Bellis                 Expires September 23, 2010               [Page 3]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-
-      ... it is also clear that some new DNS record types defined in the
-      future will contain information exceeding the 512 byte limit that
-      applies to UDP, and hence will require TCP.  Thus, resolvers and
-      name servers should implement TCP services as a backup to UDP
-      today, with the knowledge that they will require the TCP service
-      in the future.
-
-   Existing deployments of DNSSEC [RFC4033] have shown that truncation
-   at the 512 byte boundary is now commonplace.  For example an NXDOMAIN
-   (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
-   is almost invariably larger than 512 bytes.
-
-   Since the original core specifications for DNS were written, the
-   Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
-   These extensions can be used to indicate that the client is prepared
-   to receive UDP responses larger than 512 bytes.  An EDNS0 compatible
-   server receiving a request from an EDNS0 compatible client may send
-   UDP packets up to that client's announced buffer size without
-   truncation.
-
-   However, transport of UDP packets that exceed the size of the path
-   MTU causes IP packet fragmentation, which has been found to be
-   unreliable in some circumstances.  Many firewalls routinely block
-   fragmented IP packets, and some do not implement the algorithms
-   necessary to reassemble fragmented packets.  Worse still, some
-   network devices deliberately refuse to handle DNS packets containing
-   EDNS0 options.  Other issues relating to UDP transport and packet
-   size are discussed in [RFC5625].
-
-   The MTU most commonly found in the core of the Internet is around
-   1500 bytes, and even that limit is routinely exceeded by DNSSEC
-   signed responses.
-
-   The future that was anticipated in RFC 1123 has arrived, and the only
-   standardised UDP-based mechanism which may have resolved the packet
-   size issue has been found inadequate.
-
-
-4.  Transport Protocol Selection
-
-   All general purpose DNS implementations MUST support both UDP and TCP
-   transport.
-
-   o  Authoritative server implementations MUST support TCP so that they
-      do not limit the size of responses.
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 4]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   o  Recursive resolver (or forwarder) implementations MUST support TCP
-      so that the do not prevent large responses from a TCP-capable
-      server from reaching its TCP-capable clients.
-   o  Stub resolver implementations (e.g. an operating system's DNS
-      resolution library) MUST support TCP since to do otherwise would
-      limit their interoperability with their own clients and with
-      upstream servers.
-
-   An exception may be made for proprietary stub resolver
-   implementations.  These MAY omit support for TCP if operating in an
-   environment where truncation can never occur, or where DNS lookup
-   failure is acceptable should truncation occur.
-
-   Regarding the choice of when to use UDP or TCP, RFC 1123 says:
-
-      ... a DNS resolver or server that is sending a non-zone-transfer
-      query MUST send a UDP query first.
-
-   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
-   query first, but MAY elect to send a TCP query instead if it has good
-   reason to expect the response would be truncated if it were sent over
-   UDP (with or without EDNS0) or for other operational reasons, in
-   particular if it already has an open TCP connection to the server.
-
-
-5.  Connection Handling
-
-   Section 4.2.2 of [RFC1035] says:
-
-      If the server needs to close a dormant connection to reclaim
-      resources, it should wait until the connection has been idle for a
-      period on the order of two minutes.  In particular, the server
-      should allow the SOA and AXFR request sequence (which begins a
-      refresh operation) to be made on a single connection.  Since the
-      server would be unable to answer queries anyway, a unilateral
-      close or reset may be used instead of a graceful close.
-
-   Other more modern protocols (e.g.  HTTP [RFC2616]) have support for
-   persistent TCP connections and operational experience has shown that
-   long timeouts can easily cause resource exhaustion and poor response
-   under heavy load.  Intentionally opening many connections and leaving
-   them dormant can trivially create a "denial of service" attack.
-
-   This document therefore RECOMMENDS that the default application-level
-   idle period should be of the order of seconds, but does not specify
-   any particular value.  In practise the idle period may vary
-   dynamically, and servers MAY allow dormant connections to remain open
-   for longer periods as resources permit.
-
-
-
-Bellis                 Expires September 23, 2010               [Page 5]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   To mitigate the risk of unintentional server overload, DNS clients
-   MUST take care to minimize the number of concurrent TCP connections
-   made to any individual server.  Similarly servers MAY impose limits
-   on the number of concurrent TCP connections being handled for any
-   particular client.
-
-   Further recommendations for the tuning of TCP stacks to allow higher
-   throughput or improved resiliency against denial of service attacks
-   are outside the scope of this document.
-
-
-6.  Response re-ordering
-
-   RFC 1035 is ambiguous on the question of whether TCP queries may be
-   re-ordered - the only relevant text is in Section 4.2.1 which relates
-   to UDP:
-
-      Queries or their responses may be reordered by the network, or by
-      processing in name servers, so resolvers should not depend on them
-      being returned in order.
-
-   For the avoidance of future doubt, this requirement is clarified.
-   Client resolvers MUST be able to process responses which arrive in a
-   different order to that in which the requests were sent, regardless
-   of the transport protocol in use.
-
-
-7.  Security Considerations
-
-   Some DNS server operators have expressed concern that wider use of
-   DNS over TCP will expose them to a higher risk of denial of service
-   (DoS) attacks.
-
-   Although there is a higher risk of such attacks against TCP-enabled
-   servers, techniques for the mitigation of DoS attacks at the network
-   level have improved substantially since DNS was first designed.
-
-   At the time of writing the vast majority of TLD authority servers and
-   all of the root name servers support TCP and the author knows of no
-   evidence to suggest that TCP-based DoS attacks against existing DNS
-   infrastructure are commonplace.
-
-   That notwithstanding, readers are advised to familiarise themselves
-   with [CPNI-TCP].
-
-   Operators of recursive servers should ensure that they only accept
-   connections from expected clients, and do not accept them from
-   unknown sources.  In the case of UDP traffic this will help protect
-
-
-
-Bellis                 Expires September 23, 2010               [Page 6]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-   against reflector attacks [RFC5358] and in the case of TCP traffic it
-   will prevent an unknown client from exhausting the server's limits on
-   the number of concurrent connections.
-
-
-8.  IANA Considerations
-
-   This document requests no IANA actions.
-
-
-9.  Acknowledgements
-
-   The author would like to thank the document reviewers from the DNSEXT
-   Working Group, and in particular George Barwood, Alex Bligh, Alfred
-   Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
-              August 1980.
-
-   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
-              RFC 793, September 1981.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
-              and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-10.2.  Informative References
-
-   [CPNI-TCP]
-              CPNI, "Security Assessment of the Transmission Control
-              Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
-              tn-03-09-security-assessment-TCP.pdf>.
-
-   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
-              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
-
-
-
-Bellis                 Expires September 23, 2010               [Page 7]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
-              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
-              October 2008.
-
-   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
-              BCP 152, RFC 5625, August 2009.
-
-
-Appendix A.  Change Log
-
-   NB: to be removed by the RFC Editor before publication.
-
-   draft-ietf-dnsext-dns-tcp-requirements-03
-      Editorial nits from WGLC
-      Clarification on "general purpose"
-      Fixed ref to UDP (RFC 768)
-      Included more S.4.2.2 text from RFC 1035 and removed some from
-      this draft relating to connection resets.
-      s/long/large/ for packet sizes
-
-   draft-ietf-dnsext-dns-tcp-requirements-02
-      Change of title - more focus on implementation and not operation
-      Re-write of some of the security section
-      Added recommendation for minimal concurrent connections
-      Minor editorial nits from Alfred Hoenes
-
-   draft-ietf-dnsext-dns-tcp-requirements-01
-      Addition of response ordering section
-      Various minor editorial changes from WG reviewers
-
-   draft-ietf-dnsext-dns-tcp-requirements-00
-      Initial draft
-
-
-
-
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 8]
-
-Internet-Draft                DNS over TCP                    March 2010
-
-
-Author's Address
-
-   Ray Bellis
-   Nominet UK
-   Edmund Halley Road
-   Oxford  OX4 4DQ
-   United Kingdom
-
-   Phone: +44 1865 332211
-   Email: ray.bellis@nominet.org.uk
-   URI:   http://www.nominet.org.uk/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                 Expires September 23, 2010               [Page 9]
-

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
+

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]
+

doc/draft/draft-ietf-dnsext-dnssec-bis-updates-12.txt

@@ -1,785 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                              SPARTA, Inc.
-Updates: 4033, 4034, 4035, 5155                                D. Blacka
-(if approved)                                             VeriSign, Inc.
-Intended status: Standards Track                       November 10, 2010
-Expires: May 14, 2011
-
-
-         Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-12
-
-Abstract
-
-   This document is a collection of technical clarifications to the
-   DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as a repository of DNSSECbis errata.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   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."
-
-   This Internet-Draft will expire on May 14, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 1]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  3
-     1.1.  Structure of this Document . . . . . . . . . . . . . . . .  3
-     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Important Additions to DNSSSECbis  . . . . . . . . . . . . . .  3
-     2.1.  NSEC3 Support  . . . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  SHA-2 Support  . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Implement a BAD cache  . . . . . . . . . . . . . . . . . .  4
-   4.  Security Concerns  . . . . . . . . . . . . . . . . . . . . . .  4
-     4.1.  Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     4.2.  Validating Responses to an ANY Query . . . . . . . . . . .  5
-     4.3.  Check for CNAME  . . . . . . . . . . . . . . . . . . . . .  5
-     4.4.  Insecure Delegation Proofs . . . . . . . . . . . . . . . .  5
-   5.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
-     5.1.  Errors in Canonical Form Type Code List  . . . . . . . . .  6
-     5.2.  Unknown DS Message Digest Algorithms . . . . . . . . . . .  6
-     5.3.  Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
-     5.4.  Caution About Local Policy and Multiple RRSIGs . . . . . .  7
-     5.5.  Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
-     5.6.  Setting the DO Bit on Replies  . . . . . . . . . . . . . .  8
-     5.7.  Setting the AD Bit on Queries  . . . . . . . . . . . . . .  8
-     5.8.  Setting the AD Bit on Replies  . . . . . . . . . . . . . .  8
-     5.9.  Handling Queries With the CD Bit Set . . . . . . . . . . .  8
-     5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . .  9
-       5.10.1.  Closest Encloser  . . . . . . . . . . . . . . . . . .  9
-       5.10.2.  Accept Any Success  . . . . . . . . . . . . . . . . .  9
-       5.10.3.  Preference Based on Source  . . . . . . . . . . . . . 10
-   6.  Minor Corrections and Clarifications . . . . . . . . . . . . . 10
-     6.1.  Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . . 10
-     6.2.  Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11
-     6.3.  Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
-     6.4.  Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 13
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 2]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-1.  Introduction and Terminology
-
-   This document lists some additions, clarifications and corrections to
-   the core DNSSECbis specification, as originally described in
-   [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
-   (See section Section 2 for more recent additions to that core
-   document set.)
-
-   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.
-
-1.1.  Structure of this Document
-
-   The clarifications to DNSSECbis are sorted according to their
-   importance, starting with ones which could, if ignored, lead to
-   security problems and progressing down to clarifications that are
-   expected to have little operational impact.
-
-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 [RFC2119].
-
-
-2.  Important Additions to DNSSSECbis
-
-   This section lists some documents that should be considered core
-   DNSSEC protocol documents in addition to those originally specified
-   in Section 10 of [RFC4033].
-
-2.1.  NSEC3 Support
-
-   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
-   records for hashed denial of existence.  Validator implementations
-   are strongly encouraged to include support for NSEC3 because a number
-   of highly visible zones are expected to use it.  Validators that do
-   not support validation of responses using NSEC3 will likely be
-   hampered in validating large portions of the DNS space.
-
-   [RFC5155] should be considered part of the DNS Security Document
-   Family as described by [RFC4033], Section 10.
-
-   Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
-   SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
-   signal that a zone MAY be using NSEC3, rather than NSEC.  The zone
-   MAY indeed be using either and validators supporting these algorithms
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 3]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   MUST support both NSEC3 and NSEC responses.
-
-2.2.  SHA-2 Support
-
-   [RFC4509] describes the use of SHA-256 as a digest algorithm in
-   Delegation Signer (DS) RRs.  [RFC5702] describes the use of the
-   RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
-   Validator implementations are strongly encouraged to include support
-   for these algorithms for DS, DNSKEY, and RRSIG records.
-
-   Both [RFC4509] and [RFC5702] should also be considered part of the
-   DNS Security Document Family as described by [RFC4033], Section 10.
-
-
-3.  Scaling Concerns
-
-3.1.  Implement a BAD cache
-
-   Section 4.7 of RFC4035 permits security-aware resolvers to implement
-   a BAD cache.  Because of scaling concerns not discussed in this
-   document, that guidance has changed: security-aware resolvers SHOULD
-   implement a BAD cache, as described in RFC4035.
-
-
-4.  Security Concerns
-
-   This section provides clarifications that, if overlooked, could lead
-   to security issues.
-
-4.1.  Clarifications on Non-Existence Proofs
-
-   [RFC4035] Section 5.4 under-specifies the algorithm for checking non-
-   existence proofs.  In particular, the algorithm as presented would
-   incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove
-   the non-existence of RRs in the child zone.
-
-   An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
-
-   o  the NS bit set,
-   o  the SOA bit clear, and
-   o  a signer field that is shorter than the owner name of the NSEC RR,
-      or the original owner name for the NSEC3 RR.
-
-   Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non-
-   existence of any RRs below that zone cut, which include all RRs at
-   that (original) owner name other than DS RRs, and all RRs below that
-   owner name regardless of type.
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   Similarly, the algorithm would also allow an NSEC RR at the same
-   owner name as a DNAME RR, or an NSEC3 RR at the same original owner
-   name as a DNAME, to prove the non-existence of names beneath that
-   DNAME.  An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
-   to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
-   (original) owner name.
-
-4.2.  Validating Responses to an ANY Query
-
-   [RFC4035] does not address how 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.  That is,
-   it is not necessary to include all RRsets at the QNAME in the
-   response.
-
-   When validating a response to QTYPE=*, all received RRsets that match
-   QNAME and QCLASS MUST be validated.  If any of those RRsets fail
-   validation, the answer is considered Bogus.  If there are no RRsets
-   matching QNAME and QCLASS, that fact MUST be validated according to
-   the rules in [RFC4035] Section 5.4 (as clarified in this document).
-   To be clear, a validator must not expect to receive all records at
-   the QNAME in response to QTYPE=*.
-
-4.3.  Check for CNAME
-
-   Section 5 of [RFC4035] says little about validating responses based
-   on (or that should be based on) CNAMEs.  When validating a NOERROR/
-   NODATA response, validators MUST check the CNAME bit in the matching
-   NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
-   type.  Without this check, an attacker could successfully transform a
-   positive CNAME response into a NOERROR/NODATA response.
-
-4.4.  Insecure Delegation Proofs
-
-   [RFC4035] Section 5.2 specifies that a validator, when proving a
-   delegation is not secure, needs to check for the absence of the DS
-   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
-   needs to check for the presence of the NS bit in the matching NSEC
-   (or NSEC3) RR (proving that there is, indeed, a delegation), or
-   alternately make sure that the delegation is covered by an NSEC3 RR
-   with the Opt-Out flag set.  If this is not checked, spoofed unsigned
-   delegations might be used to claim that an existing signed record is
-   not signed.
-
-
-5.  Interoperability Concerns
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-5.1.  Errors in Canonical Form Type Code List
-
-   When canonicalizing DNS names, DNS names in the RDATA section of NSEC
-   and RRSIG resource records are not downcased.
-
-   [RFC4034] Section 6.2 item 3 has a list of resource record types for
-   which DNS names in the RDATA are downcased for purposes of DNSSEC
-   canonical form (for both ordering and signing).  That list
-   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
-   names in the RDATA of NSEC and RRSIG should not be downcased.
-
-   The same section also erroneously lists HINFO, and twice at that.
-   Since HINFO records contain no domain names, they are not subject to
-   downcasing.
-
-5.2.  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 public key
-   algorithms, as indicated by the key 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 public key 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.
-
-   To paraphrase the above, when determining the security status of a
-   zone, a validator disregards 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
-   disregards any DS records using unknown or unsupported message digest
-   algorithms.
-
-5.3.  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
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   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 5.2).  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 Bogus data, as
-   discussed in [RFC4035].
-
-   This clarification facilitates the broader use of private algorithms,
-   as suggested by [RFC4955].
-
-5.4.  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
-   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 [RFC4641] might not work
-   reliably.
-
-5.5.  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
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
-
-5.6.  Setting the DO Bit on Replies
-
-   As stated in [RFC3225], the DO bit of the query MUST be copied in the
-   response.  At least one implementation has done something different,
-   so it may be wise for resolvers to be liberal in what they accept.
-
-5.7.  Setting the AD Bit on Queries
-
-   The use of the AD bit in the query was previously undefined.  This
-   document defines it as a signal indicating that the requester
-   understands and is interested in the value of the AD bit in the
-   response.  This allows a requestor to indicate that it understands
-   the AD bit without also requesting DNSSEC data via the DO bit.
-
-5.8.  Setting the AD Bit on Replies
-
-   Section 3.2.3 of [RFC4035] describes under which conditions a
-   validating resolver should set or clear the AD bit in a response.  In
-   order to protect legacy stub resolvers and middleboxes, validating
-   resolvers SHOULD only set the AD bit when a response both meets the
-   conditions listed in RFC 4035, section 3.2.3, and the request
-   contained either a set DO bit or a set AD bit.
-
-5.9.  Handling Queries With the CD Bit Set
-
-   When processing a request with the CD bit set, a resolver SHOULD
-   attempt to return all responsive data, even data that has failed
-   DNSSEC validation.  RFC4035 section 3.2.2 requires a resolver
-   processing a request with the CD bit set to set the CD bit on its
-   upstream queries.
-
-   The guidance in RFC4035 is ambiguous about what to do when a cached
-   response was obtained with the CD bit not set.  In the typical case,
-   no new query is required, nor does the cache need to track the state
-   of the CD bit used to make a given query.  The problem arises when
-   the cached response is a server failure (RCODE 2), which may indicate
-   that the requested data failed DNSSEC validation at an upstream
-   validating resolver.  (RFC2308 permits caching of server failures for
-   up to five minutes.)  In these cases, a new query with the CD bit set
-   is required.
-
-   For efficiency, a validator SHOULD set the CD bit on upstream queries
-   when it has a trust anchor at or above the QNAME (and thus can
-   reasonably expect to be able to validate the response).
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-5.10.  Nested Trust Anchors
-
-   A DNSSEC validator may be configured such that, for a given response,
-   more than one trust anchor could be used to validate the chain of
-   trust to the response zone.  For example, imagine a validator
-   configured with trust anchors for "example." and "zone.example."
-   When the validator is asked to validate a response to
-   "www.sub.zone.example.", either trust anchor could apply.
-
-   When presented with this situation, DNSSEC validators have a choice
-   of which trust anchor(s) to use.  Which to use is a matter of
-   implementation choice.  It is possible and perhaps advisable to
-   expose the choice of policy as a configuration option.  The rest of
-   this section discusses some possible policies.  As a default, we
-   suggest that validators implement the "Accept Any Success" policy
-   described below in Section 5.10.2 while exposing other policies as
-   configuration options.
-
-5.10.1.  Closest Encloser
-
-   One policy is to choose the trust anchor closest to the QNAME of the
-   response.  In our example, that would be the "zone.example." trust
-   anchor.
-
-   This policy has the advantage of allowing the operator to trivially
-   override a parent zone's trust anchor with one that the operator can
-   validate in a stronger way, perhaps because the resolver operator is
-   affiliated with the zone in question.  This policy also minimizes the
-   number of public key operations needed, which may be of benefit in
-   resource-constrained environments.
-
-   This policy has the disadvantage of possibly giving the user some
-   unexpected and unnecessary validation failures when sub-zone trust
-   anchors are neglected.  As a concrete example, consider a validator
-   that configured a trust anchor for "zone.example." in 2009 and one
-   for "example." in 2011.  In 2012, "zone.example." rolls its KSK and
-   updates its DS records, but the validator operator doesn't update its
-   trust anchor.  With the "closest encloser" policy, the validator gets
-   validation failures.
-
-5.10.2.  Accept Any Success
-
-   Another policy is to try all applicable trust anchors until one gives
-   a validation result of Secure, in which case the final validation
-   result is Secure.  If and only if all applicable trust anchors give a
-   result of Insecure, the final validation result is Insecure.  If one
-   or more trust anchors lead to a Bogus result and there is no Secure
-   result, then the final validation result is Bogus.
-
-
-
-Weiler & Blacka           Expires May 14, 2011                  [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   This has the advantage of causing the fewer validation failures,
-   which may deliver a better user experience.  If one trust anchor is
-   out of date (as in our above example), the user may still be able to
-   get a Secure validation result (and see DNS responses).
-
-   This policy has the disadvantage of making the validator subject to
-   compromise of the weakest of these trust anchors while making its
-   relatively painless to keep old trust anchors configured in
-   perpetuity.
-
-5.10.3.  Preference Based on Source
-
-   When the trust anchors have come from different sources (e.g.
-   automated updates ([RFC5011]), one or more DLV registries
-   ([RFC5074]), and manually configured), a validator may wish to choose
-   between them based on the perceived reliability of those sources.
-   The order of precedence might be exposed as a configuration option.
-
-   For example, a validator might choose to prefer trust anchors found
-   in a DLV registry over those manually configured on the theory that
-   the manually configured ones will not be as aggressively maintained.
-
-   Conversely, a validator might choose to prefer manually configured
-   trust anchors over those obtained from a DLV registry on the theory
-   that the manually configured ones have been more carefully
-   authenticated.
-
-   Or the validator might do something more complicated: prefer a sub-
-   set of manually configured trust anchors (based on a configuration
-   option), then trust anchors that have been updated using the RFC5011
-   mechanism, then trust anchors from one DLV registry, then trust
-   anchors from a different DLV registry, then the rest of the manually
-   configured trust anchors.
-
-
-6.  Minor Corrections and Clarifications
-
-6.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
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 10]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   [RFC4035] specifies a mechanism for doing that.
-
-6.2.  Clarifications on DNSKEY Usage
-
-   Questions of the form "can I use a different DNSKEY for signing this
-   RRset" 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 is
-   possible to use a DNSKEY without the SEP bit set as the sole secure
-   entry 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.
-
-6.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.
-
-6.4.  Errors in RFC 5155
-
-   A NSEC3 record that matches an Empty Non-Terminal effectively has no
-   type associated with it.  This NSEC3 record has an empty type bit
-   map.  Section 3.2.1 of [RFC5155] contains the statement:
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 11]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-      Blocks with no types present MUST NOT be included.
-
-   However, the same section contains a regular expression:
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
-   The plus sign in the regular expression indicates that there is one
-   or more of the preceding element.  This means that there must be at
-   least one window block.  If this window block has no types, it
-   contradicts with the first statement.  Therefore, the correct text in
-   RFC 5155 3.2.1 should be:
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
-
-
-7.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-
-8.  Security Considerations
-
-   This document adds two cryptographic features to the core DNSSEC
-   protocol.  Additionally, it addresses some ambiguities and omissions
-   in the core DNSSEC documents that, if not recognized and addressed in
-   implementations, could lead to security failures.  In particular, the
-   validation algorithm clarifications in Section 4 are critical for
-   preserving the security properties DNSSEC offers.  Furthermore,
-   failure to address some of the interoperability concerns in Section 5
-   could limit the ability to later change or expand DNSSEC, including
-   adding new algorithms.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
-              RFC 3225, December 2001.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 12]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
-              and RRSIG Resource Records for DNSSEC", RFC 5702,
-              October 2009.
-
-9.2.  Informative References
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
-              RFC 4641, September 2006.
-
-   [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
-              July 2007.
-
-   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
-              Trust Anchors", RFC 5011, September 2007.
-
-   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
-              November 2007.
-
-
-Appendix A.  Acknowledgments
-
-   The editors would like the thank Rob Austein for his previous work as
-   an editor of this document.
-
-   The editors are 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.
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 13]
-
-Internet-Draft       DNSSECbis Implementation Notes        November 2010
-
-
-   The lack of specificity about handling private algorithms, as
-   described in Section 5.3, and the lack of specificity in handling ANY
-   queries, as described in Section 4.2, were discovered by David
-   Blacka.
-
-   The error in algorithm 1 key tag calculation, as described in
-   Section 5.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
-   contributed text for Section 5.5.
-
-   The bug relating to delegation NSEC RR's in Section 4.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 6.3 of this document.
-
-   The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
-   Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
-   and Scott Rose for their substantive comments on the text of this
-   document.
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7110 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-
-   David Blacka
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Email: davidb@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka           Expires May 14, 2011                 [Page 14]
-
-

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]
+

doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt

@@ -0,0 +1,560 @@
+
+
+
+Network Working Group                                          S. Weiler
+Internet-Draft                                               SPARTA, Inc
+Updates: 4034, 4035 (if approved)                               J. Ihren
+Expires: November 13, 2005                                 Autonomica AB
+                                                            May 12, 2005
+
+
+       Minimally Covering NSEC Records and DNSSEC On-line Signing
+               draft-ietf-dnsext-dnssec-online-signing-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 November 13, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+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 November 13, 2005               [Page 1]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+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 November 13, 2005               [Page 2]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+Table of Contents
+
+   1.   Introduction and Terminology . . . . . . . . . . . . . . . .   4
+   2.   Minimally Covering NSEC Records  . . . . . . . . . . . . . .   4
+   3.   Better Increment & Decrement Functions . . . . . . . . . . .   6
+   4.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   7
+   5.   Security Considerations  . . . . . . . . . . . . . . . . . .   7
+   6.   Normative References . . . . . . . . . . . . . . . . . . . .   8
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   8
+   A.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .   8
+        Intellectual Property and Copyright Statements . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren          Expires November 13, 2005               [Page 3]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+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 5.
+
+   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.
+
+   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.  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.2.  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).
+
+
+
+Weiler & Ihren          Expires November 13, 2005               [Page 4]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+   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 SHOULD 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 wsa 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.
+
+   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:
+
+             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 increment or decrement 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
+
+
+
+Weiler & Ihren          Expires November 13, 2005               [Page 5]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+   signatures that must be generated, a zone may wish to limit the
+   number of algorithms in its DNSKEY RRset.
+
+3.  Better Increment & Decrement Functions
+
+   Section 6.2 of RFC4034 defines a strict ordering of DNS names.
+   Working backwards from that definition, it should be possible to
+   define increment and decrement 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:
+
+     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 increment or decrement functions: it is
+   sufficient to test whether any instantiated names fall into the span
+
+
+
+Weiler & Ihren          Expires November 13, 2005               [Page 6]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+   covered by the generated NSEC and, if so, substitute those
+   instantiated owner names for the NSEC owner name or next name, as
+   appropriate.
+
+4.  IANA Considerations
+
+   Per RFC4041, IANA should think carefully about the protection of
+   their immortal souls.
+
+5.  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 public key 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 increment and decrement 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 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 increment and decrement
+   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
+   increment and decrement 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 3
+   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
+
+
+
+Weiler & Ihren          Expires November 13, 2005               [Page 7]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+   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 [-bis].  The techniques described here actually decrease
+   the danger, since the span covered by any NSEC record is smaller than
+   before.  Choosing better increment and decrement functions will
+   further reduce this danger.
+
+6.  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.
+
+
+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
+
+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 November 13, 2005               [Page 8]
+
+Internet-Draft                NSEC Epsilon                      May 2005
+
+
+   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
+   Jakob Schlyter, Bill Manning, and Joao Damas.
+
+   The key innovation of this document, namely that perfect increment
+   and decrement functions are not necessary, arose during a discussion
+   among the above-listed people at the RIPE49 meeting in September
+   2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren          Expires November 13, 2005               [Page 9]
+
+Internet-Draft                NSEC Epsilon                      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 & Ihren          Expires November 13, 2005              [Page 10]
+

doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-06.txt

@@ -1,448 +0,0 @@
-
-
-
-DNS Extensions Working Group                                     S. Rose
-Internet-Draft                                                      NIST
-Updates: 2536, 2539, 3110, 4034,                         August 11, 2010
-4398, 5155, 5702, 5933
-(if approved)
-Intended status: Standards Track
-Expires: February 12, 2011
-
-
-  Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
-                                Registry
-               draft-ietf-dnsext-dnssec-registry-fixes-06
-
-Abstract
-
-   The DNS Security Extensions (DNSSEC) requires the use of
-   cryptographic algorithm suites for generating digital signatures over
-   DNS data.  There is currently an IANA registry for these algorithms
-   that is incomplete in that it lacks the implementation status of each
-   algorithm.  This document provides an applicability statement on
-   algorithm status for DNSSEC implementations.  This document replaces
-   that registry table with a new IANA registry table for Domain Name
-   System Security (DNSSEC) Algorithm Numbers which lists each
-   algorithm's status based on the current reference.  If that status is
-   not defined in the original specification, this document assigns a
-   status.
-
-Status of This Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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.
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 1]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-   This Internet-Draft will expire on February 12, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
-
-   2.  The DNS Security Algorithm Number Subregistry . . . . . . . . . 3
-     2.1.  Individual Changes  . . . . . . . . . . . . . . . . . . . . 3
-     2.2.  Domain Name System (DNS) Security Algorithm Number
-           Registry Table  . . . . . . . . . . . . . . . . . . . . . . 5
-     2.3.  Specifying New Algorithms and Updating Status of
-           Existing Entries  . . . . . . . . . . . . . . . . . . . . . 6
-
-   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-
-   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 2]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-1.  Introduction
-
-   The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
-   [RFC4034], and [RFC4035] uses digital signatures over DNS data to
-   provide source authentication and integrity protection.  DNSSEC uses
-   an IANA registry to allocate codes for digital signature algorithms
-   (consisting of a cryptographic algorithm and one-way hash function).
-
-   The original list of algorithm status is found in [RFC4034].  Other
-   DNSSEC documents have added new algorithms or changed the status of
-   algorithms in the registry.  However, currently implementors must
-   read through all the documents in order to discover the current
-   status of each algorithm in the registry.
-
-   This document replaces the current IANA registry for Domain Name
-   System Security (DNSSEC) Algorithm Numbers with a newly defined
-   registry table.  This new table (Section 2.2 below) contains a column
-   that will list the current status of each digital signature algorithm
-   in the registry at the time of writing and assigns status for some
-   algorithms used with DNSSEC that did not have an identified status in
-   their specification.  This document updates the following: [RFC2536],
-   [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and
-   [RFC5933].
-
-1.1.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  The DNS Security Algorithm Number Subregistry
-
-   The DNS Security Algorithm Number subregistry (part of the Domain
-   Name System (DNS) Security Number registry) will be replaced with the
-   table below.  This table contains a column that contains the current
-   implementation requirements of the given algorithm.
-
-   There are additional differences to entries that are described in
-   sub-section 2.1.  The overall new registry table is in sub-section
-   2.2.  The values for the status were obtained from [RFC4034] with
-   updates for algorithms specified after the original DNSSEC
-   specification.  If no status was listed in the original
-   specification, this document assigns one.
-
-2.1.  Individual Changes
-
-   This document changes three entries in the Domain Name System
-   Security (DNSSEC) Algorithm Registry.  They are:
-
-
-
-Rose                    Expires February 12, 2011               [Page 3]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-   The description for assignment number 4 is changed to "Reserved until
-   2020".
-
-   The description for assignment number 9 is changed to "Reserved until
-   2020".
-
-   The description for assignment number 11 is changed to "Reserved
-   until 2020".
-
-   Registry entries 13-251 remains Unassigned.
-
-   The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are set to
-   RECOMMENDED and OPTIONAL respectively.  The difference is due to the
-   fact that RSA/SHA-1 is REQUIRED and DSA/SHA-1 is only OPTIONAL.  The
-   status of RSA/SHA-256 and RSA/SHA-512 are set to RECOMMENDED as it is
-   believed that these algorithms will replace older algorithms (e.g.
-   RSA/SHA-1) that have a perceived weakness in their hash algorithm
-   (SHA-1).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 4]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-2.2.  Domain Name System (DNS) Security Algorithm Number Registry Table
-
-   The Domain Name System (DNS) Security Algorithm Number registry is
-   hereby specified as follows:
-
-                                  Zone  Transaction
-Number  Description    Mnemonic   Sign  Sign     Status       Reference
-------  -----------     ------    ----  -----  ------------   ---------
-  0      Reserved                                             [RFC4398]
-  1      RSA/MD5         RSAMD5     N     Y     MUST NOT      [RFC4034],
-                                                IMPLEMENT     [RFC3110]
-                                                             (this memo)
-  2      Diffie-Hellman   DH        N     Y                   [RFC2539]
-                                                             (this memo)
-  3      DSA/SHA-1       DSASHA1    Y     Y                   [RFC2536],
-                                                              [RFC4034],
-                                                             FIPS 186-3,
-                                                             FIPS 180-3
-                                                             (this memo)
-  4      Reserved until   ECC                                (this memo)
-         2020
-  5      RSA/SHA-1       RSASHA1    Y     Y     REQUIRED      [RFC4034]
-                                                             (this memo)
-  6      DSA-NSEC3-SHA1  DSA-NSEC3  Y     Y                   [RFC5155]
-                         -SHA1                               (this memo)
-  7      RSASHA1-NSEC3   RSASHA1-   Y     Y    RECOMMENDED    [RFC5155]
-         -SHA1           NSEC3-                              (this memo)
-                         SHA1
-  8      RSA/SHA-256     RSASHA256  Y     *    RECOMMENDED     [RFC5702]
-                                                             (this memo)
-  9      Reserved until                                      (this memo)
-         2020
- 10      RSA/SHA-512     RSASHA512  Y     *    RECOMMENDED    [RFC5702]
-                                                             (this memo)
- 11      Reserved until                                      (this memo)
-         2020
- 12      GOST R          GOST-ECC   Y     *                   [RFC5933]
-         34.10-2001                                          (this memo)
-13-251   Unassigned
- 252     Reserved for    INDIRECT   N     N                   [RFC4034]
-         Indirect keys                                       (this memo)
- 253     private         PRIVATE    Y     Y                   [RFC4034]
-         algorithm                                           (this memo)
- 254     private         PRIVATEOID Y     Y                   [RFC4034]
-         algorithm OID                                       (this memo)
- 255     Reserved
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 5]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-2.3.  Specifying New Algorithms and Updating Status of Existing Entries
-
-   [I-D.ietf-dnsext-dnssec-alg-allocation] establishes a parallel
-   procedure for obtaining an algorithm number for new algorithms other
-   than a standards track document.  Algorithms entered into the
-   registry using that procedure do not have a listed status.
-   Specifications that follow this path do not need to obsolete or
-   update this document.
-
-   Adding a newly specified algorithm to the registry with a status
-   SHALL entail obsoleting this document and replacing the registry
-   table (with the new algorithm entry).  Altering the status column
-   value of any existing algorithm in the registry SHALL entail
-   obsoleting this document and replacing the registry table.
-
-   This document cannot be updated, only made obsolete and replaced by a
-   successor document.
-
-3.  IANA Considerations
-
-   This document replaces the Domain Name System (DNS) Security
-   Algorithm Numbers registry.  The new registry table is in Section
-   2.2.
-
-   The original Domain Name System (DNS) Security Algorithm Number
-   registry is available at http://www.iana.org/assignments/
-   dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.
-
-4.  Security Considerations
-
-   This document replaces the Domain Name System (DNS) Security
-   Algorithm Numbers registry.  It is not meant to be a discussion on
-   algorithm superiority.  No new security considerations are raised in
-   this document.
-
-5.  References
-
-5.1.  Normative References
-
-   [I-D.ietf-dnsext-dnssec-alg-allocation]  Hoffman, P., "Cryptographic
-                                            Algorithm Identifier
-                                            Allocation for DNSSEC", draf
-                                            t-ietf-dnsext-dnssec-alg-
-                                            allocation-03 (work in
-                                            progress), March 2010.
-
-   [RFC2119]                                Bradner, S., "Key words for
-                                            use in RFCs to Indicate
-
-
-
-Rose                    Expires February 12, 2011               [Page 6]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-                                            Requirement Levels", BCP 14,
-                                            RFC 2119, March 1997.
-
-   [RFC2536]                                Eastlake, D., "DSA KEYs and
-                                            SIGs in the Domain Name
-                                            System (DNS)", RFC 2536,
-                                            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.
-
-   [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.
-
-   [RFC4398]                                Josefsson, S., "Storing
-                                            Certificates in the Domain
-                                            Name System (DNS)",
-                                            RFC 4398, March 2006.
-
-   [RFC5155]                                Laurie, B., Sisson, G.,
-                                            Arends, R., and D. Blacka,
-                                            "DNS Security (DNSSEC)
-                                            Hashed Authenticated Denial
-
-
-
-Rose                    Expires February 12, 2011               [Page 7]
-
-Internet-Draft             IANA Registry Fixes               August 2010
-
-
-                                            of Existence", RFC 5155,
-                                            March 2008.
-
-   [RFC5702]                                Jansen, J., "Use of SHA-2
-                                            Algorithms with RSA in
-                                            DNSKEY and RRSIG Resource
-                                            Records for DNSSEC",
-                                            RFC 5702, October 2009.
-
-   [RFC5933]                                Dolmatov, V., Chuprina, A.,
-                                            and I. Ustinov, "Use of GOST
-                                            Signature Algorithms in
-                                            DNSKEY and RRSIG Resource
-                                            Records for DNSSEC",
-                                            RFC 5933, July 2010.
-
-5.2.  Informative References
-
-   [FIPS.180-3.2008]                        National Institute of
-                                            Standards and Technology,
-                                            "Secure Hash Standard",
-                                            FIPS PUB 180-3,
-                                            October 2008, <http://
-                                            csrc.nist.gov/publications/
-                                            fips/fips180-3/
-                                            fips180-3.pdf>.
-
-   [FIPS.186-3.2009]                        National Institute of
-                                            Standards and Technology,
-                                            "Digital Signature
-                                            Standard", FIPS PUB 186-3,
-                                            June 2009, <http://
-                                            csrc.nist.gov/publications/
-                                            fips/fips186-3/
-                                            fips_186-3.pdf>.
-
-Author's Address
-
-   Scott Rose
-   NIST
-   100 Bureau Dr.
-   Gaithersburg, MD  20899
-   USA
-
-   Phone: +1-301-975-8439
-   EMail: scottr.nist@gmail.com
-
-
-
-
-
-Rose                    Expires February 12, 2011               [Page 8]
-

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]
+
+

doc/draft/draft-ietf-dnsext-insensitive-06.txt

@@ -0,0 +1,754 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+Updates RFC 1034, 1035                             Motorola Laboratories
+Expires January 2006                                           July 2005
+
+
+
+       Domain Name System (DNS) Case Insensitivity Clarification
+       ------ ---- ------ ----- ---- ------------- -------------
+                 <draft-ietf-dnsext-insensitive-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 DNSEXT working group at 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
+
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+
+
+Abstract
+
+   Domain Name System (DNS) names are "case insensitive". This document
+   explains exactly what that means and provides a clear specification
+   of the rules. This clarification updates RFCs 1034 and 1035.
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+Acknowledgements
+
+   The contributions to this document of Rob Austein, Olafur
+   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
+   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
+   are gratefully acknowledged.
+
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Copyright Notice...........................................1
+      Abstract...................................................1
+
+      Acknowledgements...........................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. Case Insensitivity of DNS Labels........................3
+      2.1 Escaping Unusual DNS Label Octets......................3
+      2.2 Example Labels with Escapes............................4
+      3. Name Lookup, Label Types, and CLASS.....................4
+      3.1 Original DNS Label Types...............................5
+      3.2 Extended Label Type Case Insensitivity Considerations..5
+      3.3 CLASS Case Insensitivity Considerations................5
+      4. Case on Input and Output................................6
+      4.1 DNS Output Case Preservation...........................6
+      4.2 DNS Input Case Preservation............................6
+      5. Internationalized Domain Names..........................7
+      6. Security Considerations.................................8
+
+      Copyright and Disclaimer...................................9
+      Normative References.......................................9
+      Informative References....................................10
+
+      Changes Between Draft Version.............................11
+      -02 to -03 Changes........................................11
+      -03 to -04 Changes........................................11
+      -04 to -05 Changes........................................11
+      -05 to -06 Changes........................................12
+
+      Author's Address..........................................13
+      Expiration and File Name..................................13
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. Each node in the DNS tree has a name consisting of
+   zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
+   case insensitive fashion. This document clarifies the meaning of
+   "case insensitive" for the DNS. This clarification updates RFCs 1034
+   and 1035 [STD 13].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+2. Case Insensitivity of DNS Labels
+
+   DNS was specified in the era of [ASCII]. DNS names were expected to
+   look like most host names or Internet email address right halves (the
+   part after the at-sign, "@") or be numeric as in the in-addr.arpa
+   part of the DNS name space. For example,
+
+       foo.example.net.
+       aol.com.
+       www.gnu.ai.mit.edu.
+   or  69.2.0.192.in-addr.arpa.
+
+   Case varied alternatives to the above would be DNS names like
+
+       Foo.ExamplE.net.
+       AOL.COM.
+       WWW.gnu.AI.mit.EDU.
+   or  69.2.0.192.in-ADDR.ARPA.
+
+   However, the individual octets of which DNS names consist are not
+   limited to valid ASCII character codes. They are 8-bit bytes and all
+   values are allowed. Many applications, however, interpret them as
+   ASCII characters.
+
+
+
+2.1 Escaping Unusual DNS Label Octets
+
+   In Master Files [STD 13] and other human readable and writable ASCII
+   contexts, an escape is needed for the byte value for period (0x2E,
+   ".") and all octet values outside of the inclusive range of 0x21
+   ("!")  to 0x7E ("~"). That is to say, 0x2E and all octet values in
+   the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
+
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   One typographic convention for octets that do not correspond to an
+   ASCII printing graphic is to use a back-slash followed by the value
+   of the octet as an unsigned integer represented by exactly three
+   decimal digits.
+
+   The same convention can be used for printing ASCII characters so that
+   they will be treated as a normal label character.  This includes the
+   back-slash character used in this convention itself which can be
+   expressed as \092 or \\ and the special label separator period (".")
+   which can be expressed as and \046 or \.  respectively. It is
+   advisable to avoid using a backslash to quote an immediately
+   following non-printing ASCII character code to avoid implementation
+   difficulties.
+
+   A back-slash followed by only one or two decimal digits is undefined.
+   A back-slash followed by four decimal digits produces two octets, the
+   first octet having the value of the first three digits considered as
+   a decimal number and the second octet being the character code for
+   the fourth decimal digit.
+
+
+
+2.2 Example Labels with Escapes
+
+   The first example below shows embedded spaces and a period (".")
+   within a label. The second one show a 5-octet label where the second
+   octet has all bits zero, the third is a backslash, and the fourth
+   octet has all bits one.
+
+         Donald\032E\.\032Eastlake\0323rd.example.
+   and   a\000\\\255z.example.
+
+
+
+3. Name Lookup, Label Types, and CLASS
+
+   The original DNS design decision was made that comparisons on name
+   lookup for DNS queries should be case insensitive [STD 13]. That is
+   to say, a lookup string octet with a value in the inclusive range of
+   0x41 to 0x5A, the upper case ASCII letters, MUST match the identical
+   value and also match the corresponding value in the inclusive range
+   0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet
+   with a lower case ASCII letter value MUST similarly match the
+   identical value and also match the corresponding value in the upper
+   case ASCII letter range.
+
+   (Historical Note: the terms "upper case" and "lower case" were
+   invented after movable type.  The terms originally referred to the
+   two font trays for storing, in partitioned areas, the different
+   physical type elements.  Before movable type, the nearest equivalent
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   terms were "majuscule" and "minuscule".)
+
+   One way to implement this rule would be, when comparing octets, to
+   subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
+   before the comparison. Such an operation is commonly known as "case
+   folding" but implementation via case folding is not required. Note
+   that the DNS case insensitivity does NOT correspond to the case
+   folding specified in [iso-8859-1] or [iso-8859-2]. For example, the
+   octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
+   contexts, where they are interpreted as the upper and lower case
+   version of "Y" with an acute accent, they might.
+
+
+
+3.1 Original DNS Label Types
+
+   DNS labels in wire-encoded names have a type associated with them.
+   The original DNS standard [RFC 1035] had only two types. ASCII
+   labels, with a length of from zero to 63 octets, and indirect (or
+   compression) labels which consist of an offset pointer to a name
+   location elsewhere in the wire encoding on a DNS message. (The ASCII
+   label of length zero is reserved for use as the name of the root node
+   of the name tree.) ASCII labels follow the ASCII case conventions
+   described herein and, as stated above, can actually contain arbitrary
+   byte values. Indirect labels are, in effect, replaced by the name to
+   which they point which is then treated with the case insensitivity
+   rules in this document.
+
+
+
+3.2 Extended Label Type Case Insensitivity Considerations
+
+   DNS was extended by [RFC 2671] to have additional label type numbers
+   available. (The only such type defined so far is the BINARY type [RFC
+   2673] which is now Experimental [RFC 3363].)
+
+   The ASCII case insensitivity conventions only apply to ASCII labels,
+   that is to say, label type 0x0, whether appearing directly or invoked
+   by indirect labels.
+
+
+
+3.3 CLASS Case Insensitivity Considerations
+
+   As described in [STD 13] and [RFC 2929], DNS has an additional axis
+   for data location called CLASS. The only CLASS in global use at this
+   time is the "IN" or Internet CLASS.
+
+   The handling of DNS label case is not CLASS dependent. With the
+   original design of DNS, it was intended that a recursive DNS resolver
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   be able to handle new CLASSes that were unknown at the time of its
+   implementation. This requires uniform handling of label case
+   insensitivity. Should it become desireable, for example, to allocate
+   a CLASS with "case sensitive ASCII labels" for example, it would be
+   necessary to allocate a new label type for these labels.
+
+
+
+4. Case on Input and Output
+
+   While ASCII label comparisons are case insensitive, [STD 13] says
+   case MUST be preserved on output, and preserved when convenient on
+   input. However, this means less than it would appear since the
+   preservation of case on output is NOT required when output is
+   optimized by the use of indirect labels, as explained below.
+
+
+
+4.1 DNS Output Case Preservation
+
+   [STD 13] views the DNS namespace as a node tree. ASCII output is as
+   if a name was marshaled by taking the label on the node whose name is
+   to be output, converting it to a typographically encoded ASCII
+   string, walking up the tree outputting each label encountered, and
+   preceding all labels but the first with a period ("."). Wire output
+   follows the same sequence but each label is wire encoded and no
+   periods inserted. No "case conversion" or "case folding" is done
+   during such output operations, thus "preserving" case.  However, to
+   optimize output, indirect labels may be used to point to names
+   elsewhere in the DNS answer. In determining whether the name to be
+   pointed to, for example the QNAME, is the "same" as the remainder of
+   the name being optimized, the case insensitive comparison specified
+   above is done. Thus such optimization may easily destroy the output
+   preservation of case. This type of optimization is commonly called
+   "name compression".
+
+
+
+4.2 DNS Input Case Preservation
+
+   Originally, DNS data came from an ASCII Master File as defined in
+   [STD 13] or a zone transfer.  DNS Dynamic update and incremental zone
+   transfers [RFC 1995] have been added as a source of DNS data [RFC
+   2136, 3007]. When a node in the DNS name tree is created by any of
+   such inputs, no case conversion is done. Thus the case of ASCII
+   labels is preserved if they are for nodes being created. However,
+   when a name label is input for a node that already exist in DNS data
+   being held, the situation is more complex. Implementations are free
+   to retain the case first loaded for such a label or allow new input
+   to override the old case or even maintain separate copies preserving
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+   the input case.
+
+   For example, if data with owner name "foo.bar.example" is loaded and
+   then later data with owner name "xyz.BAR.example" is input, the name
+   of the label on the "bar.example" node, i.e. "bar", might or might
+   not be changed to "BAR" in the DNS stored data or the actual input
+   case could be preserved.  Thus later retrieval of data stored under
+   "xyz.bar.example" in this case can return all data with
+   "xyz.BAR.example" or all data with "xyz.bar.example" or even, when
+   more than one RR is being returned, a mixture of these two cases.
+   This last case is unlikely because optimization of answer length
+   through indirect labels tends to cause only copy of the name tail
+   ("bar.example" or "BAR.example") to be used for all returned RRs.
+   Note that none of this has any effect on the number of completeness
+   of the RR set returned, only on the case of the names in the RR set
+   returned.
+
+   The same considerations apply when inputting multiple data records
+   with owner names differing only in case. For example, if an "A"
+   record is the first resourced record stored under owner name
+   "xyz.BAR.example" and then a second "A" record is stored under
+   "XYZ.BAR.example", the second MAY be stored with the first (lower
+   case initial label) name or the second MAY override the first so that
+   only an upper case initial label is retained or both capitalizations
+   MAY be kept in the DNS stored data. In any case, a retrieval with
+   either capitalization will retrieve all RRs with either
+   capitalization.
+
+   Note that the order of insertion into a server database of the DNS
+   name tree nodes that appear in a Master File is not defined so that
+   the results of inconsistent capitalization in a Master File are
+   unpredictable output capitalization.
+
+
+
+5. Internationalized Domain Names
+
+   A scheme has been adopted for "internationalized domain names" and
+   "internationalized labels" as described in [RFC 3490, 3454, 3491, and
+   3492]. It makes most of [UNICODE] available through a separate
+   application level transformation from internationalized domain name
+   to DNS domain name and from DNS domain name to internationalized
+   domain name. Any case insensitivity that internationalized domain
+   names and labels have varies depending on the script and is handled
+   entirely as part of the transformation described in [RFC 3454] and
+   [RFC 3491] which should be seen for further details.  This is not a
+   part of the DNS as standardized in STD 13.
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+6. Security Considerations
+
+   The equivalence of certain DNS label types with case differences, as
+   clarified in this document, can lead to security problems. For
+   example, a user could be confused by believing two domain names
+   differing only in case were actually different names.
+
+   Furthermore, a domain name may be used in contexts other than the
+   DNS.  It could be used as a case sensitive index into some data base
+   or file system. Or it could be interpreted as binary data by some
+   integrity or authentication code system. These problems can usually
+   be handled by using a standardized or "canonical" form of the DNS
+   ASCII type labels, that is, always mapping the ASCII letter value
+   octets in ASCII labels to some specific pre-chosen case, either upper
+   case or lower case. An example of a canonical form for domain names
+   (and also a canonical ordering for them) appears in Section 6 of [RFC
+   4034]. See also [RFC 3597].
+
+   Finally, a non-DNS name may be stored into DNS with the false
+   expectation that case will always be preserved. For example, although
+   this would be quite rare, on a system with case sensitive email
+   address local parts, an attempt to store two "RP" records that
+   differed only in case would probably produce unexpected results that
+   might have security implications. That is because the entire email
+   address, including the possibly case sensitive local or left hand
+   part, is encoded into a DNS name in a readable fashion where the case
+   of some letters might be changed on output as described above.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (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
+
+   [ASCII] - ANSI, "USA Standard Code for Information Interchange",
+   X3.4, American National Standards Institute: New York, 1968.
+
+   [RFC 1034, 1035] - See [STD 13].
+
+   [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
+   1996.
+
+   [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels", March 1997.
+
+   [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
+   "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
+
+   [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
+   Update", November 2000.
+
+   [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
+   draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
+
+   [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+   [STD 13]
+       - P. Mockapetris, "Domain names - concepts and facilities", RFC
+   1034, November 1987.
+       - P. Mockapetris, "Domain names - implementation and
+   specification", RFC 1035, November 1987.
+
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+Informative References
+
+   [ISO 8859-1] - International Standards Organization, Standard for
+   Character Encodings, Latin-1.
+
+   [ISO 8859-2] - International Standards Organization, Standard for
+   Character Encodings, Latin-2.
+
+   [RFC 1591] - J. Postel, "Domain Name System Structure and
+   Delegation", March 1994.
+
+   [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
+   June 1999.
+
+   [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
+   Name System (DNS) IANA Considerations", September 2000.
+
+   [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
+   1999.
+
+   [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
+   August 1999.
+
+   [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
+   Foo", 1 April 2001.
+
+   [RFC 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 3454] - P. Hoffman, M. Blanchet, "Preparation of
+   Internationalized String ("stringprep")", December 2002.
+
+   [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
+   "Internationalizing Domain Names in Applications (IDNA)", March 2003.
+
+   [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
+   for Internationalized Domain Names (IDN)", March 2003.
+
+   [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
+   for Internationalized Domain Names in Applications (IDNA)", March
+   2003.
+
+   [UNICODE] - The Unicode Consortium, "The Unicode Standard",
+   <http://www.unicode.org/unicode/standard/standard.html>.
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 10]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+Changes Between Draft Version
+
+   RFC Editor: The following summaries of changes between draft versions
+   are to be removed before publication.
+
+
+
+-02 to -03 Changes
+
+   The following changes were made between draft version -02 and -03:
+
+   1. Add internationalized domain name section and references.
+
+   2. Change to indicate that later input of a label for an existing DNS
+   name tree node may or may not be normalized to the earlier input or
+   override it or both may be preserved.
+
+   3. Numerous minor wording changes.
+
+
+
+-03 to -04 Changes
+
+   The following changes were made between draft versions -03 and -04:
+
+   1. Change to conform to the new IPR, Copyright, etc., notice
+   requirements.
+
+   2. Change in some section headers for clarity.
+
+   3. Drop section on wildcards.
+
+   4. Add emphasis on loss of case preservation due to name compression.
+
+   5. Add references to RFCs 1995 and 3092.
+
+
+
+-04 to -05 Changes
+
+   The following changes were made between draft versions -04 and -05:
+
+   1. More clearly state that this draft updates RFCs 1034, 1035 [STD
+   13].
+
+   2. Add informative references to ISO 8859-1 and ISO 8859-2.
+
+   3. Fix hyphenation and capitalization nits.
+
+
+
+
+D. Eastlake 3rd                                                [Page 11]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+-05 to -06 Changes
+
+   The following changes were made between draft version -05 and -06.
+
+   1. Add notation to the RFC Editor that the draft version change
+   summaries are to be removed before RFC publication.
+
+   2. Additional text explaining why labe case insensitivity is CLASS
+   independent.
+
+   3. Changes and additional text clarifying that the fact that
+   inconsistent case in data loaded into DNS may result in
+   unpredicatable or inconsistent case in DNS storage but has no effect
+   on the completeness of RR sets retrieved.
+
+   4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
+   be to [RFC 4034].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 12]
+
+
+INTERNET-DRAFT                                    DNS Case Insensitivity
+
+
+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
+
+
+
+Expiration and File Name
+
+   This draft expires January 2006.
+
+   Its file name is draft-ietf-dnsext-insensitive-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 13]
+

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]
+
+

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]
+

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]
+

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]
+

doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt

@@ -1,616 +0,0 @@
-
-
-
-DNSEXT Working Group                                            M. Graff
-Internet-Draft                                                  P. Vixie
-Obsoletes: 2671 (if approved)                Internet Systems Consortium
-Intended status: Standards Track                           July 28, 2009
-Expires: January 29, 2010
-
-
-                  Extension Mechanisms for DNS (EDNS0)
-                 draft-ietf-dnsext-rfc2671bis-edns0-02
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 29, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   The Domain Name System's wire protocol includes a number of fixed
-   fields whose range has been or soon will be exhausted and does not
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 1]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-   allow requestors to advertise their capabilities to responders.  This
-   document describes backward compatible mechanisms for allowing the
-   protocol to grow.
-
-   This document updates the EDNS0 specification based on 10 years of
-   operational experience.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
-   3.  EDNS Support Requirement . . . . . . . . . . . . . . . . . . .  3
-   4.  Affected Protocol Elements . . . . . . . . . . . . . . . . . .  3
-     4.1.  Message Header . . . . . . . . . . . . . . . . . . . . . .  3
-     4.2.  Label Types  . . . . . . . . . . . . . . . . . . . . . . .  4
-     4.3.  UDP Message Size . . . . . . . . . . . . . . . . . . . . .  4
-   5.  Extended Label Types . . . . . . . . . . . . . . . . . . . . .  4
-   6.  OPT pseudo-RR  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     6.1.  OPT Record Behavior  . . . . . . . . . . . . . . . . . . .  4
-     6.2.  OPT Record Format  . . . . . . . . . . . . . . . . . . . .  5
-     6.3.  Requestor's Payload Size . . . . . . . . . . . . . . . . .  6
-     6.4.  Responder's Payload Size . . . . . . . . . . . . . . . . .  6
-     6.5.  Payload Size Selection . . . . . . . . . . . . . . . . . .  7
-     6.6.  Middleware Boxes . . . . . . . . . . . . . . . . . . . . .  7
-     6.7.  Extended RCODE . . . . . . . . . . . . . . . . . . . . . .  7
-     6.8.  OPT Options Type Allocation Procedure  . . . . . . . . . .  8
-   7.  Transport Considerations . . . . . . . . . . . . . . . . . . .  8
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 10
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 2]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-1.  Introduction
-
-   DNS [RFC1035] specifies a Message Format and within such messages
-   there are standard formats for encoding options, errors, and name
-   compression.  The maximum allowable size of a DNS Message is fixed.
-   Many of DNS's protocol limits are too small for uses which are or
-   which are desired to become common.  There is no way for
-   implementations to advertise their capabilities.
-
-   Unextended agents will not know how to interpret the protocol
-   extensions detailed here.  In practice, these clients will be
-   upgraded when they have need of a new feature, and only new features
-   will make use of the extensions.  Extended agents must be prepared
-   for behaviour of unextended clients in the face of new protocol
-   elements, and fall back gracefully to unextended DNS.  [RFC2671]
-   originally proposed extensions to the basic DNS protocol to overcome
-   these deficiencies.  This memo refines that specification and
-   obsoletes [RFC2671].
-
-
-2.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-
-3.  EDNS Support Requirement
-
-   EDNS support is manditory in a modern world.  DNSSEC requires EDNS
-   support, and many other featres are made possible only by EDNS
-   support to request or advertise them.
-
-
-4.  Affected Protocol Elements
-
-4.1.  Message Header
-
-   The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full
-   16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a
-   number of 1-bit flags.  The original reserved Z bits have been
-   allocated to various purposes, and most of the RCODE values are now
-   in use.  More flags and more possible RCODEs are needed.  The OPT
-   pseudo-RR specified below contains subfields that carry a bit field
-   extension of the RCODE field and additional flag bits, respectively.
-
-
-
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 3]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-4.2.  Label Types
-
-   The first two bits of a wire format domain label are used to denote
-   the type of the label. ,section 4.1.4 [RFC1035] allocates two of the
-   four possible types and reserves the other two.  More label types
-   were proposed in [RFC2671] section 3.
-
-4.3.  UDP Message Size
-
-   DNS Messages are limited to 512 octets in size when sent over UDP.
-   While the minimum maximum reassembly buffer size still allows a limit
-   of 512 octets of UDP payload, most of the hosts now connected to the
-   Internet are able to reassemble larger datagrams.  Some mechanism
-   must be created to allow requestors to advertise larger buffer sizes
-   to responders.  To this end, the OPT pseudo-RR specified below
-   contains a maximum payload size field.
-
-
-5.  Extended Label Types
-
-   The first octet in the on-the-wire representation of a DNS label
-   specifies the label type; the basic DNS specification [RFC1035]
-   dedicates the two most significant bits of that octet for this
-   purpose.
-
-   This document reserves DNS label type 0b01 for use as an indication
-   for Extended Label Types.  A specific extended label type is selected
-   by the 6 least significant bits of the first octet.  Thus, Extended
-   Label Types are indicated by the values 64-127 (0b01xxxxxx) in the
-   first octet of the label.
-
-   This document does not describe any specific Extended Label Type.
-
-   In practice, Extended Label Types are difficult to use due to support
-   in clients and intermediate gateways.  Therefore, the registry of
-   Extended Label Types is requested to be closed.  They cause
-   interoperability problems and at present no defined label types are
-   in use.
-
-
-6.  OPT pseudo-RR
-
-6.1.  OPT Record Behavior
-
-   One OPT pseudo-RR (RR type 41) MAY be added to the additional data
-   section of a request.  If present in requests, compliant responders
-   which implement EDNS MUST include an OPT record in non-truncated
-   responses, and SHOULD attempt to include them in all responses.  An
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 4]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-   OPT is called a pseudo-RR because it pertains to a particular
-   transport level message and not to any actual DNS data.  OPT RRs MUST
-   NOT be cached, forwarded, or stored in or loaded from master files.
-   The quantity of OPT pseudo-RRs per message MUST be either zero or
-   one, but not greater.
-
-6.2.  OPT Record Format
-
-   An OPT RR has a fixed part and a variable set of options expressed as
-   {attribute, value} pairs.  The fixed part holds some DNS meta data
-   and also a small collection of basic extension elements which we
-   expect to be so popular that it would be a waste of wire space to
-   encode them as {attribute, value} pairs.
-
-   The fixed part of an OPT RR is structured as follows:
-
-       +------------+--------------+------------------------------+
-       | Field Name | Field Type   | Description                  |
-       +------------+--------------+------------------------------+
-       | NAME       | domain name  | empty (root domain)          |
-       | TYPE       | u_int16_t    | OPT                          |
-       | CLASS      | u_int16_t    | requestor's UDP payload size |
-       | TTL        | u_int32_t    | extended RCODE and flags     |
-       | RDLEN      | u_int16_t    | describes RDATA              |
-       | RDATA      | octet stream | {attribute,value} pairs      |
-       +------------+--------------+------------------------------+
-
-                               OPT RR Format
-
-   The variable part of an OPT RR is encoded in its RDATA and is
-   structured as zero or more of the following:
-
-
-                  +0 (MSB)                            +1 (LSB)
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    0: |                          OPTION-CODE                          |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    2: |                         OPTION-LENGTH                         |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    4: |                                                               |
-       /                          OPTION-DATA                          /
-       /                                                               /
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-
-
-
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 5]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-   OPTION-CODE
-         Assigned by Expert Review.
-
-   OPTION-LENGTH
-         Size (in octets) of OPTION-DATA.
-
-   OPTION-DATA
-         Varies per OPTION-CODE.
-
-   Order of appearance of option tuples is never relevant.  Any option
-   whose meaning is affected by other options is so affected no matter
-   which one comes first in the OPT RDATA.
-
-   Any OPTION-CODE values not understood by a responder or requestor
-   MUST be ignored.  Specifications of such options might wish to
-   include some kind of signalled acknowledgement.  For example, an
-   option specification might say that if a responder sees option XYZ,
-   it SHOULD include option XYZ in its response.
-
-6.3.  Requestor's Payload Size
-
-   The requestor's UDP payload size (which OPT stores in the RR CLASS
-   field) is the number of octets of the largest UDP payload that can be
-   reassembled and delivered in the requestor's network stack.  Note
-   that path MTU, with or without fragmentation, may be smaller than
-   this.  Values lower than 512 MUST be treated as equal to 512.
-
-   Note that a 512-octet UDP payload requires a 576-octet IP reassembly
-   buffer.  Choosing 1280 for IPv4 over Ethernet would be reasonable.
-   The consequence of choosing too large a value may be an ICMP message
-   from an intermediate gateway, or even a silent drop of the response
-   message.
-
-   The requestor's maximum payload size can change over time, and MUST
-   therefore not be cached for use beyond the transaction in which it is
-   advertised.
-
-6.4.  Responder's Payload Size
-
-   The responder's maximum payload size can change over time, but can be
-   reasonably expected to remain constant between two sequential
-   transactions; for example, a meaningless QUERY to discover a
-   responder's maximum UDP payload size, followed immediately by an
-   UPDATE which takes advantage of this size.  (This is considered
-   preferrable to the outright use of TCP for oversized requests, if
-   there is any reason to suspect that the responder implements EDNS,
-   and if a request will not fit in the default 512 payload size limit.)
-
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 6]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-6.5.  Payload Size Selection
-
-   Due to transaction overhead, it is unwise to advertise an
-   architectural limit as a maximum UDP payload size.  Just because your
-   stack can reassemble 64KB datagrams, don't assume that you want to
-   spend more than about 4KB of state memory per ongoing transaction.
-
-   A requestor MAY choose to implement a fallback to smaller advertised
-   sizes to work around firewall or other network limitations.  A
-   requestor SHOULD choose to use a fallback mechanism which begins with
-   a large size, such as 4096.  If that fails, a fallback around the
-   1220 byte range SHOULD be tried, as it has a reasonable chance to fit
-   within a single Ethernet frame.  Failing that, a requestor MAY choose
-   a 512 byte packet, which with large answers may cause a TCP retry.
-
-6.6.  Middleware Boxes
-
-   Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes.
-
-   Middleware boxes which simply forward requests to a recursive
-   resolver MUST NOT modify the OPT record contents in either direction.
-
-6.7.  Extended RCODE
-
-   The extended RCODE and flags (which OPT stores in the RR TTL field)
-   are structured as follows:
-
-                  +0 (MSB)                            +1 (LSB)
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    0: |         EXTENDED-RCODE        |            VERSION            |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-    2: | DO|                           Z                               |
-       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   EXTENDED-RCODE
-         Forms upper 8 bits of extended 12-bit RCODE.  Note that
-         EXTENDED-RCODE value "0" indicates that an unextended RCODE is
-         in use (values "0" through "15").
-
-   VERSION
-         Indicates the implementation level of whoever sets it.  Full
-         conformance with this specification is indicated by version
-         ``0.''  Requestors are encouraged to set this to the lowest
-         implemented level capable of expressing a transaction, to
-         minimize the responder and network load of discovering the
-         greatest common implementation level between requestor and
-         responder.  A requestor's version numbering strategy MAY
-         ideally be a run time configuration option.
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 7]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-         If a responder does not implement the VERSION level of the
-         request, then it answers with RCODE=BADVERS.  All responses
-         MUST be limited in format to the VERSION level of the request,
-         but the VERSION of each response SHOULD be the highest
-         implementation level of the responder.  In this way a requestor
-         will learn the implementation level of a responder as a side
-         effect of every response, including error responses and
-         including RCODE=BADVERS.
-
-   DO
-         DNSSEC OK bit as defined by [RFC3225].
-
-   Z
-         Set to zero by senders and ignored by receivers, unless
-         modified in a subsequent specification.
-
-6.8.  OPT Options Type Allocation Procedure
-
-   Allocations assigned by expert review.  TBD
-
-
-7.  Transport Considerations
-
-   The presence of an OPT pseudo-RR in a request should be taken as an
-   indication that the requestor fully implements the given version of
-   EDNS, and can correctly understand any response that conforms to that
-   feature's specification.
-
-   Lack of presence of an OPT record in a request MUST be taken as an
-   indication that the requestor does not implement any part of this
-   specification and that the responder MUST NOT use any protocol
-   extension described here in its response.
-
-   Responders who do not implement these protocol extensions MUST
-   respond with FORMERR messages without any OPT record.
-
-   If there is a problem with processing the OPT record itself, such as
-   an option value that is badly formatted or includes out of range
-   values, a FORMERR MAY be retured.  If this occurs the response MUST
-   include an OPT record.  This MAY be used to distinguish between
-   servers whcih do not implement EDNS and format errors within EDNS.
-
-   If EDNS is used in a request, and the response arrives with TC set
-   and with no EDNS OPT RR, a requestor SHOULD assume that truncation
-   prevented the OPT RR from being appended by the responder, and
-   further, that EDNS is not used in the response.  Correspondingly, an
-   EDNS responder who cannot fit all necessary elements (including an
-   OPT RR) into a response, SHOULD respond with a normal (unextended)
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 8]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-   DNS response, possibly setting TC if the response will not fit in the
-   unextended response message's 512-octet size.
-
-
-8.  Security Considerations
-
-   Requestor-side specification of the maximum buffer size may open a
-   new DNS denial of service attack if responders can be made to send
-   messages which are too large for intermediate gateways to forward,
-   thus leading to potential ICMP storms between gateways and
-   responders.
-
-   Announcing very large UDP buffer sizes may result in dropping by
-   firewalls.  This could cause retransmissions with no hope of success.
-   Some devices reject fragmented UDP packets.
-
-   Announcing too small UDP buffer sizes may result in fallback to TCP.
-   This is especially important with DNSSEC, where answers are much
-   larger.
-
-
-9.  IANA Considerations
-
-   The IANA has assigned RR type code 41 for OPT.
-
-   [RFC2671] specified a number of IANA sub-registries within "DOMAIN
-   NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option
-   Codes", "EDNS Version Numbers", and "Domain System Response Code."
-   IANA is advised to re-parent these subregistries to this document.
-
-   RFC 2671 created an extended label type registry.  We request that
-   this registry be closed.
-
-   This document assigns extended label type 0bxx111111 as "Reserved for
-   future extended label types."  We request that IANA record this
-   assignment.
-
-   This document assigns option code 65535 to "Reserved for future
-   expansion."
-
-   This document expands the RCODE space from 4 bits to 12 bits.  This
-   will allow IANA to assign more than the 16 distinct RCODE values
-   allowed in RFC 1035 [RFC1035].
-
-   This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-   IESG approval should be required to create new entries in the EDNS
-   Extended Label Type or EDNS Version Number registries, while any
-
-
-
-Graff & Vixie           Expires January 29, 2010                [Page 9]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-   published RFC (including Informational, Experimental, or BCP) should
-   be grounds for allocation of an EDNS Option Code.
-
-
-10.  Acknowledgements
-
-   Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-   Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
-   Narten were each instrumental in creating and refining this
-   specification.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
-              RFC 3225, December 2001.
-
-11.2.  Informative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-Authors' Addresses
-
-   Michael Graff
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, California  94063
-   US
-
-   Phone: +1 650.423.1304
-   Email: mgraff@isc.org
-
-
-
-
-
-
-
-
-
-
-Graff & Vixie           Expires January 29, 2010               [Page 10]
-
-Internet-Draft              EDNS0 Extensions                   July 2009
-
-
-   Paul Vixie
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, California  94063
-   US
-
-   Phone: +1 650.423.1301
-   Email: vixie@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Graff & Vixie           Expires January 29, 2010               [Page 11]
-

doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt

@@ -1,451 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                             A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                       February 24, 2010
-
-Intended status: Draft Standard
-Obsoletes: RFC3597
-
-           Handling of Unknown DNS Resource Record (RR) Types
-                  draft-ietf-dnsext-rfc3597-bis-02.txt
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types should not requires changes to name server software.  This
-   document specifies how new RR types are transparently handled by DNS
-   software.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document. Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document. Code Components extracted from this document must
-
-
-
-Expires August 2010          Standards Track                    [Page 1]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-1.  Introduction
-
-   The DNS [RFC1034] is designed to be extensible to support new
-   services through the introduction of new resource record (RR) types.
-   Nevertheless, DNS implementations have historically required software
-   changes to support new RR types, not only at the authoritative DNS
-   server providing the new information and the client making use of it,
-   but also at all slave servers for the zone containing it, and in some
-   cases also at caching name servers and forwarders used by the client.
-   Because the deployment of new DNS software is slow and expensive,
-   this has been a significant impediment to supporting new services in
-   the DNS.
-
-   [RFC3597] defined DNS implementation behavior and procedures for
-   defining new RR types aimed at simplifying the deployment of new RR
-   types by allowing them to be treated transparently by existing
-   implementations.  Thanks to the widespread adoption of that
-   specification, much of the DNS is now capable of handling new record
-   types without software changes.  Another development that has
-   simplified the introduction of new DNS RR types is the adoption of a
-   simpler IANA allocation procedure for RR types [RFC5395].
-
-   This document is a self-contained revised specification supplanting
-   and obsoleting RFC 3597, with the aim of allowing the specification
-   to advance on the Standards Track.
-
-2.  Definitions
-
-   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].
-
-   An "RR of unknown type" is an RR whose RDATA format is not known to
-   the DNS implementation at hand, and whose type is not an assigned
-   QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within
-   the range reserved in that section for assignment only to QTYPEs and
-   Meta-TYPEs.  Such an RR cannot be converted to a type-specific text
-   format, compressed, or otherwise handled in a type-specific way.
-
-   In the case of a type whose RDATA format is known to be class
-   specific, an RR is considered to be of unknown type when the RDATA
-   format for that combination of type and class is not known.
-
-3.  Transparency
-
-
-
-Expires August 2010          Standards Track                    [Page 2]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   To enable new RR types to be deployed without server changes, name
-   servers and resolvers MUST handle RRs of unknown type transparently.
-   The RDATA section of RRs of unknown type must be treated as
-   unstructured binary data, and must be stored and transmitted without
-   change ([RFC1123], section 6.1.3.5).
-
-   To ensure the correct operation of equality comparison (section 6)
-   and of the DNSSEC canonical form (section 7) when an RR type is known
-   to some but not all of the servers involved, servers MUST also
-   exactly preserve the RDATA of RRs of known type, except for changes
-   due to compression or decompression where allowed by section 4 of
-   this document.  In particular, the character case of domain names
-   that are not subject to compression MUST be preserved.
-
-4.  Domain Name Compression
-
-   RRs containing compression pointers in the RDATA part cannot be
-   treated transparently, as the compression pointers are only
-   meaningful within the context of a DNS message.  Transparently
-   copying the RDATA into a new DNS message would cause the compression
-   pointers to point at the corresponding location in the new message,
-   which now contains unrelated data.  This would cause the compressed
-   name to be corrupted.
-
-   To avoid such corruption, servers MUST NOT compress domain names
-   embedded in the RDATA of types that are class-specific or not well-
-   known.  This requirement was stated in [RFC1123] without defining the
-   term "well-known"; it is hereby specified that only the RR types
-   defined in [RFC1035] are to be considered "well-known".
-
-   Receiving servers MUST decompress domain names in RRs of well-known
-   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
-   NXT, SRV, and NAPTR to ensure interoperability with implementations
-   predating [RFC3597].
-
-   Specifications for new RR types that contain domain names within
-   their RDATA MUST NOT allow the use of name compression for those
-   names, and SHOULD explicitly state that the embedded domain names
-   MUST NOT be compressed.
-
-   As noted in [RFC1123], the owner name of an RR is always eligible for
-   compression.
-
-5.  Text Representation
-
-   In the "type" field of a master file line, an unknown RR type is
-   represented by the word "TYPE" immediately followed by the decimal RR
-   type number, with no intervening whitespace.  In the "class" field,
-
-
-
-Expires August 2010          Standards Track                    [Page 3]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   an unknown class is similarly represented as the word "CLASS"
-   immediately followed by the decimal class number.
-
-   This convention allows types and classes to be distinguished from
-   each other and from TTL values, allowing the "[<TTL>] [<class>]
-   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-   [RFC1035] section 5.1 to both be unambiguously parsed.
-
-   The RDATA section of an RR of unknown type is represented as a
-   sequence of items separated by any combination of tabs and spaces, as
-   follows:
-
-     - The special token \# (a backslash immediately followed by a hash
-       sign), which identifies the RDATA as having the generic encoding
-       defined herein rather than a traditional type-specific encoding.
-
-     - An unsigned decimal integer specifying the RDATA length in
-       octets.
-
-     - Zero or more items of hexadecimal data encoding the actual RDATA
-       field, each item containing an even number of hexadecimal digits.
-
-   If the RDATA is of zero length, the text representation contains only
-   the \# token and the single zero representing the length.
-
-   An implementation MAY also choose to represent some RRs of known type
-   using the above generic representations for the type, class and/or
-   RDATA, which carries the benefit of making the resulting master file
-   portable to servers where these types are unknown.  Using the generic
-   representation for the RDATA of an RR of known type can also be
-   useful in the case of an RR type where the text format varies
-   depending on a version, protocol, or similar field (or several)
-   embedded in the RDATA when such a field has a value for which no text
-   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
-   0.
-
-   Even though an RR of known type represented in the \# format is
-   effectively treated as an unknown type for the purpose of parsing the
-   RDATA text representation, all further processing by the server MUST
-   treat it as a known type and take into account any applicable type-
-   specific rules regarding compression, canonicalization, etc.
-
-   The following are examples of RRs represented in this manner,
-   illustrating various combinations of generic and type-specific
-   encodings for the different fields of the master file format:
-
-      a.example.   CLASS32     TYPE731         \# 6 abcd (
-                                               ef 01 23 45 )
-
-
-
-Expires August 2010          Standards Track                    [Page 4]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-      b.example.   HS          TYPE62347       \# 0
-      e.example.   IN          A               \# 4 C0000201
-      e.example.   CLASS1      TYPE1           192.0.2.1
-
-6.  Equality Comparison
-
-   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
-   to be compared for equality.  Two RRs of the same unknown type are
-   considered equal when their RDATA is bitwise equal.  To ensure that
-   the outcome of the comparison is identical whether the RR is known to
-   the server or not, specifications for new RR types MUST NOT specify
-   type-specific comparison rules.
-
-   This implies that embedded domain names, being included in the
-   overall bitwise comparison, are compared in a case-sensitive manner.
-
-   As a result, when a new RR type contains one or more embedded domain
-   names, it is possible to have multiple RRs owned by the same name
-   that differ only in the character case of the embedded domain
-   name(s).  This is similar to the existing possibility of multiple TXT
-   records differing only in character case, and not expected to cause
-   any problems in practice.
-
-7.  DNSSEC Considerations
-
-   The rules for the DNSSEC canonical form and ordering were updated to
-   support transparent treatment of unknown types in [RFC3597].  Those
-   updates have subsequently been integrated into the base DNSSEC
-   specification, such that the DNSSEC canonical form and ordering are
-   now specified in [RFC4034] or its successors rather than in this
-   document.
-
-8.  Additional Section Processing
-
-   Unknown RR types cause no additional section processing.  Future RR
-   type specifications MAY specify type-specific additional section
-   processing rules, but any such processing MUST be optional as it can
-   only be performed by servers for which the RR type in case is known.
-
-9.  IANA Considerations
-
-   This document does not require any IANA actions.
-
-10.  Security Considerations
-
-   This specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-
-
-
-Expires August 2010          Standards Track                    [Page 5]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-11.  Normative References
-
-   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
-               Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC5395]   Eastlake, D., "Domain Name System (DNS) IANA
-               Considerations", BCP 42, RFC 5395, November 2008.
-
-12.  Informative References
-
-   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
-               Means for Expressing Location Information in the Domain
-               Name System", RFC 1876, January 1996.
-
-   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC3597]   Gustafsson, A., "Handling of Unknown DNS Resource Record
-               (RR) Types", RFC 3597, September 2003.
-
-   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
-               Rose, "Resource Records for the DNS Security Extensions",
-               RFC 4034, March 2005.
-
-14.  Author's Address
-
-   Andreas Gustafsson
-   Araneus Information Systems Oy
-   PL 110
-   02321 Espoo
-   Finland
-
-   Phone: +358 40 547 2099
-   EMail: gson@araneus.fi
-
-Appendix A. Summary of Changes Since RFC3597
-
-   This section summarizes the major changes between RFC3597 and this
-
-
-
-Expires August 2010          Standards Track                    [Page 6]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   document.  In addition to the changes listed below, there has also
-   been a number of editorial changes, such as updates to the text in
-   the Abstract and Introduction to better reflect the current state of
-   implementation, updates to boilerplate text, and minor
-   clarifications.
-
-   The reference to the DNS IANA Considerations BCP (BCP42) has been
-   changed from RFC2929 to the current version, RFC5395.
-
-   Downward references have been eliminated; specifically, the document
-   no longer refers to RFC2163 or RFC2535.
-
-   IP addresses in examples have been changed to use the 192.0.2.0/24
-   range per RFC3330.
-
-   The document no longer specifies changes to the DNSSEC canonical form
-   and ordering, as those changes have now been incorporated into the
-   base DNSSEC specification.
-
-Appendix B. Detailed Change Log
-
-   [NOTE TO RFC EDITOR:  PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
-
-B.1.  Changes between RFC3597 and -00
-
-   The reference to the DNS IANA Considerations BCP (BCP42) has been
-   changed from RFC2929 to the current version, RFC5395.
-
-   Downward references have been eliminated; specifically, the document
-   no longer refers to RFC2163 or RFC2535.
-
-   IP addresses in examples have been changed to use the 192.0.2.0/24
-   range per RFC3330.
-
-   The document no longer specifies changes to the DNSSEC canonical form
-   and ordering, as those changes have now been incorporated into the
-   base DNSSEC specification.
-
-   There has also been a number of editorial changes, such as updates to
-   the text in the Abstract and Introduction to better reflect the
-   current state of implementation.
-
-B.2.  Changes between -00 and -01
-
-   Moved the Abstract to immediately following the document title.
-
-   Updated boilerplate to the current version.
-
-
-
-
-Expires August 2010          Standards Track                    [Page 7]
-
-draft-ietf-dnsext-rfc3597-bis-02.txt                       February 2010
-
-
-   In the Introduction, the text "Another development that has
-   simplified the introduction of new DNS RR types is the adoption of a
-   simpler IANA allocation procedure for RR types" and a reference to
-   [RFC5395] were added.
-
-   In the Introduction, the text "with the aim of allowing the
-   specification to advance on the Standards Track" was added to explain
-   the motivation for the draft.
-
-   In section 2, the text "is class specific" was replaced by "is known
-   to be class specific".
-
-   In section 3, the words "That is" were removed so as not to imply
-   that the transparent treatment of RRs of unknown type is only a
-   matter of how the RDATA field is handled.  The remainder of the
-   sentence was rephrased.
-
-   In section 4, the entries for SRV and NAPTR in the list of RR types
-   to decompress were swapped to make the list consistently ordered by
-   ascending numerical RR type.
-
-   References to RFC 1035 and RFC 1123 now include the specific section
-   numbers being referenced.
-
-   A Change History was added as Appendix A.
-
-B.3. Changes between -01 and -02
-
-   In section 5, the term "white space" was replaced by "any combination
-   of tabs and spaces", and the term "word" was replaced by "item", for
-   consistency with RFC1035 terminology.
-
-   In section 5, hyphens were added to mark the beginning of each item
-   in the the list of items comprising the RDATA text representation.
-
-   The Change History was split into a Summary of Changes Since RFC3597
-   (Appendix A) intended to remain in the document when published as an
-   RFC, and a Detailed Change Log (Appendix B) to be deleted on
-   publication.
-
-
-
-
-
-
-
-
-
-
-
-
-Expires August 2010          Standards Track                    [Page 8]
-

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]

doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt

@@ -0,0 +1,730 @@
+
+
+
+
+Network Working Group                                         M. StJohns
+Internet-Draft                                             Nominum, Inc.
+Expires: February 16, 2006                               August 15, 2005
+
+
+               Automated Updates of DNSSEC Trust Anchors
+                draft-ietf-dnsext-trustupdate-timers-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 February 16, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+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 February 16, 2006               [Page 1]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+   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  . . . . . . . . . . . . . . . . . . . . . .  4
+     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  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     4.1   Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.2   States . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     5.1   Adding A Trust Anchor  . . . . . . . . . . . . . . . . . .  8
+     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 . . . . . . . . . . . . . . . . .  9
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+     6.1   Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
+     6.2   Multiple Key Compromise  . . . . . . . . . . . . . . . . . 10
+     6.3   Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 10
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
+       Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
+       Intellectual Property and Copyright Statements . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                 Expires February 16, 2006               [Page 2]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+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 February 16, 2006               [Page 3]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+   resolvers view of the trust anchor key RRSet.
+
+   Re-submitted expired draft as -01.  Updated DNSSEC RFC References.
+
+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 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
+   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
+
+
+
+StJohns                 Expires February 16, 2006               [Page 4]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+   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
+   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.
+
+
+
+
+
+StJohns                 Expires February 16, 2006               [Page 5]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+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.
+
+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'.
+
+
+
+StJohns                 Expires February 16, 2006               [Page 6]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+   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.
+
+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.
+
+
+
+
+
+StJohns                 Expires February 16, 2006               [Page 7]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+   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.
+
+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.
+
+   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.
+
+
+
+
+
+StJohns                 Expires February 16, 2006               [Page 8]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+   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.
+
+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.
+
+
+
+StJohns                 Expires February 16, 2006               [Page 9]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+6.  Security Considerations
+
+6.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.
+
+6.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.
+
+6.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.
+
+7.  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.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+
+
+StJohns                 Expires February 16, 2006              [Page 10]
+
+Internet-Draft             trustanchor-update                August 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.
+
+
+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 February 16, 2006              [Page 11]
+
+Internet-Draft             trustanchor-update                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.
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+
+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.
+
+
+
+
+
+StJohns                 Expires February 16, 2006              [Page 12]
+
+Internet-Draft             trustanchor-update                August 2005
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                 Expires February 16, 2006              [Page 13]
+
+

doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt

@@ -1,336 +0,0 @@
-
-
-
-DNSext Working Group                                           F. Dupont
-Internet-Draft                                                       ISC
-Updates: 2845,2930,4635                                      May 8, 2009
-(if approved)
-Intended status: Standards Track
-Expires: November 9, 2009
-
-
-     Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
-              draft-ietf-dnsext-tsig-md5-deprecated-03.txt
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.  This document may contain material
-   from IETF Documents or IETF Contributions published or made publicly
-   available before November 10, 2008.  The person(s) controlling the
-   copyright in some of this material may not have granted the IETF
-   Trust the right to allow modifications of such material outside the
-   IETF Standards Process.  Without obtaining an adequate license from
-   the person(s) controlling the copyright in such materials, this
-   document may not be modified outside the IETF Standards Process, and
-   derivative works of it may not be created outside the IETF Standards
-   Process, except to format it for publication as an RFC or to
-   translate it into languages other than English.
-
-   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 9, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-Dupont                  Expires November 9, 2009                [Page 1]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   The main purpose of this document is to deprecate the use of HMAC-MD5
-   as an algorithm for the TSIG (secret key transaction authentication)
-   resource record in the DNS (domain name system), and the use of MD5
-   in TKEY (secret key establishment for DNS).
-
-
-1.  Introduction
-
-   The secret key transaction authentication for DNS (TSIG, [RFC2845])
-   was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm.
-   When the MD5 [RFC1321] security came to be considered lower than
-   expected, [RFC4635] standardized new TSIG algorithms based on SHA
-   [RFC3174][RFC3874][RFC4634] digests.
-
-   But [RFC4635] did not deprecate the HMAC-MD5 algorithm.  This
-   document is targeted to complete the process, in detail:
-   1.  Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
-       name registry managed by the IANA under the IETF Review Policy
-       [RFC5226]
-   2.  Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for
-       implementations
-   3.  Provide a keying material derivation for the secret key
-       establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman
-       exchange with SHA256 [RFC4634] in place of MD5 [RFC1321]
-   4.  Finally recommend the use of HMAC-SHA256.
-
-   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.  Implementation Requirements
-
-   The table of section 3 of [RFC4635] is replaced by:
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 2]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-             +-------------------+--------------------------+
-             | Requirement Level | Algorithm Name           |
-             +-------------------+--------------------------+
-             | Optional          | HMAC-MD5.SIG-ALG.REG.INT |
-             | Optional          | gss-tsig                 |
-             | Mandatory         | hmac-sha1                |
-             | Optional          | hmac-sha224              |
-             | Mandatory         | hmac-sha256              |
-             | Optional          | hmac-sha384              |
-             | Optional          | hmac-sha512              |
-             +-------------------+--------------------------+
-
-   Implementations that support TSIG MUST also implement HMAC-SHA1 and
-   HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level)
-   and MAY implement GSS-TSIG and the other algorithms listed above
-   (i.e., algorithms at a "not Mandatory" requirement level).
-
-
-3.  TKEY keying material derivation
-
-   When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
-   material is derived from the shared secret and TKEY resource record
-   data using MD5 [RFC1321] at the end of section 4.1 page 9.
-
-   This is amended into:
-
-         keying material =
-              XOR ( DH value, SHA256 ( query data | DH value ) |
-                              SHA256 ( server data | DH value ) )
-
-   using the same conventions.
-
-
-4.  IANA Consideration
-
-   This document extends the "TSIG Algorithm Names - per [] and
-   [RFC2845]" located at
-   http://www.iana.org/assignments/tsig-algorithm-names by adding a new
-   column to the registry "Compliance Requirement".
-
-   The registry should contain the following:
-
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 3]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-    +--------------------------+------------------------+-------------+
-    | Algorithm Name           | Compliance Requirement | Reference   |
-    +--------------------------+------------------------+-------------+
-    | gss-tsig                 | Optional               | [RFC3645]   |
-    | HMAC-MD5.SIG-ALG.REG.INT | Optional               | [][RFC2845] |
-    | hmac-sha1                | Mandatory              | [RFC4635]   |
-    | hmac-sha224              | Optional               | [RFC4635]   |
-    | hmac-sha256              | Mandatory              | [RFC4635]   |
-    | hmac-sha384              | Optional               | [RFC4635]   |
-    | hmac-sha512              | Optional               | [RFC4635]   |
-    +--------------------------+------------------------+-------------+
-
-   where [] is this document.
-
-
-5.  Availability Considerations
-
-   MD5 is no longer universally available and its use may lead to
-   increasing operation issues.  SHA1 is likely to suffer from the same
-   kind of problem.  In summary MD5 has reached end-of-life and SHA1
-   will likely follow in the near term.
-
-   According to [RFC4635], implementations which support TSIG are
-   REQUIRED to implement HMAC-SHA256.
-
-
-6.  Security Considerations
-
-   This document does not assume anything about the cryptographic
-   security of different hash algorithms.  Its purpose is a better
-   availability of some security mechanisms in a predictable time frame.
-
-   Requirement levels are adjusted for TSIG and related specifications
-   (i.e., TKEY):
-      The support of HMAC-MD5 is changed from mandatory to optional.
-      The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.
-      The use of HMAC-SHA256 is RECOMMENDED.
-
-
-7.  Acknowledgments
-
-   Olafur Gudmundsson kindly helped in the procedure to deprecate the
-   MD5 use in TSIG, i.e., the procedure which led to this memo.  Alfred
-   Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some
-   improvements.
-
-
-8.  References
-
-
-
-Dupont                  Expires November 9, 2009                [Page 4]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC4635]  Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers",
-              RFC 4635, August 2006.
-
-8.2.  Informative References
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
-              (SHA1)", RFC 3174, September 2001.
-
-   [RFC3645]  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.
-
-   [RFC3874]  Housley, R., "A 224-bit One-way Hash Function: SHA-224",
-              RFC 3874, September 2004.
-
-   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
-              (SHA and HMAC-SHA)", RFC 4634, July 2006.
-
-   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", RFC 5226, BCP 26,
-              May 2008.
-
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 5]
-
-Internet-Draft        Deprecating HMAC-MD5 in TSIG              May 2009
-
-
-Author's Address
-
-   Francis Dupont
-   ISC
-
-   Email: Francis.Dupont@fdupont.fr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dupont                  Expires November 9, 2009                [Page 6]
-

doc/draft/draft-ietf-dnsext-tsig-sha-04.txt

@@ -0,0 +1,580 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+UPDATES RFC 2845                                   Motorola Laboratories
+Expires: December 2005                                         June 2005
+
+
+                  HMAC SHA TSIG Algorithm Identifiers
+                  ---- --- ---- --------- -----------
+                  <draft-ietf-dnsext-tsig-sha-04.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 a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   Use of the TSIG DNS resource record requires specification of a
+   cryptographic message authentication code.  Currently identifiers
+   have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
+   This document standardizes identifiers and implementation
+   requirements for additional HMAC SHA TSIG algorithms and standardizes
+   how to specify and handle the truncation of HMAC values.
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society 2005. All Rights Reserved.
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+      Copyright Notice...........................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+
+      2. Algorithms and Identifiers..............................4
+
+      3. Specifying Truncation...................................5
+      3.1 Truncation Specification...............................5
+
+      4. TSIG Policy Provisions and Truncation Error.............7
+
+      5. IANA Considerations.....................................8
+      6. Security Considerations.................................8
+      6. Copyright and Disclaimer................................8
+
+      7. Normative References....................................9
+      8. Informative References..................................9
+
+      Author's Address..........................................10
+      Expiration and File Name..................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+1. Introduction
+
+   [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
+   authenticate DNS queries and responses. This RR contains a domain
+   name syntax data item which names the authentication algorithm used.
+   [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
+   authentication codes using the HMAC [RFC 2104] algorithm with the MD5
+   [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
+   identifier for TSIG authentication where the cryptographic operations
+   are delegated to GSS [RFC 3645].
+
+   In Section 2, this document specifies additional names for TSIG
+   authentication algorithms based on US NIST SHA algorithms and HMAC
+   and specifies the implementation requirements for those algorithms.
+
+   In Section 3, this document specifies the meaning of inequality
+   between the normal output size of the specified hash function and the
+   length of MAC (message authentication code) data given in the TSIG
+   RR. In particular, it specifies that a shorter length field value
+   specifies truncation and a longer length field is an error.
+
+   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 may specify policies as to which algorithms
+   and truncations are acceptable subject to the restrication and
+   guidelines in Section 3 and 4 below.
+
+   The current HMAC-MD5.SIG-ALG.REG.INT identifier is 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
+         Mandatory      hmac-sha1
+         Optional       hmac-sha224
+         Mandatory      hmac-sha256
+         Optional       hamc-sha384
+         Optional       hmac-sha512
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 trucated 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
+
+
+   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+4. TSIG Policy Provisions and Truncation Error
+
+   Use of TSIG is by mutual agreement between a resolver and server.
+   Implicit in such "agreement" are policies as to acceptable keys and
+   algorithms and, with the extensions in this doucment, truncations. In
+   particular note the following:
+
+      Such policies MAY require the rejection of TSIGs even though they
+   use an algorithm for which implementation is mandatory.
+
+      When a policy calls for the acceptance of a TSIG with a particular
+   algorithm and a particular non-zero amount of trunction 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
+   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 policies with 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 treatred as spearate 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 policy in force, an
+   RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+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) Section 4 allocates the BADTRUNC RCODE TBA [22
+   suggested].
+
+
+
+
+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 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.
+
+
+
+6. 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.
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
+
+
+7. 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.
+
+
+
+8. Informative References.
+
+   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
+   Signatures ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+   1 (SHA1)", RFC 3174, September 2001.
+
+   [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
+   J., and R. Hall, "Generic Security Service Algorithm for Secret Key
+   Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
+   2003.
+
+   [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)", work in progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+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
+
+
+
+Expiration and File Name
+
+   This draft expires in December 2005.
+
+   Its file name is draft-ietf-dnsext-tsig-sha-04.txt
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 10]
+

doc/draft/draft-ietf-dnsext-wcard-clarify-08.txt

@@ -0,0 +1,956 @@
+DNSEXT Working Group                                          E. Lewis
+INTERNET DRAFT                                                 NeuStar
+Expiration Date: January 6, 2006                          July 6, 2005
+Updates RFC 1034, RFC 2672
+
+                             The Role of Wildcards
+                           in the Domain Name System
+                     draft-ietf-dnsext-wcard-clarify-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 January 6, 2006.
+
+Copyright Notice
+
+     Copyright (C) The Internet Society (2005).
+
+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.
+
+Table of Contents
+
+1.    Introduction
+1.1   Motivation
+1.2   The Original Definition
+1.3   Roadmap to This Document
+1.3.1 New Terms
+1.3.2 Changed Text
+1.3.3 Considerations with Special Types
+1.4   Standards Terminology
+2.    Wildcard Syntax
+2.1   Identifying a Wildcard
+2.1.1 Wild Card Domain Name and Asterisk Label
+2.1.2 Asterisks and Other Characters
+2.1.3 Non-terminal Wild Card Domain Names
+2.2   Existence Rules
+2.2.1 An Example
+2.2.2 Empty Non-terminals
+2.2.3 Yet Another Definition of Existence
+2.3   When is a Wild Card Domain Name Not Special
+3.    Impact of a Wild Card Domain Name On a Response
+3.1   Step 2
+3.2   Step 3
+3.3   Part 'c'
+3.3.1 Closest Encloser and the Source of Synthesis
+3.3.2 Closest Encloser and Source of Synthesis Examples
+3.3.3 Type Matching
+4.    Considerations with Special Types
+4.1   SOA RRSet at a Wild Card Domain Name
+4.2   NS RRSet at a Wild Card Domain Name
+4.2.1 Discarded Notions
+4.3   CNAME RRSet at a Wild Card Domain Name
+4.4   DNAME RRSet at a Wild Card Domain Name
+4.5   SRV RRSet at a Wild Card Domain Name
+4.6   DS RRSet at a Wild Card Domain Name
+4.7   NSEC RRSet at a Wild Card Domain Name
+4.8   RRSIG at a Wild Card Domain Name
+4.9   Empty Non-terminal Wild Card Domain Name
+5.    Security Considerations
+6.    IANA Considerations
+7.    References
+8.    Editor
+9.    Others Contributing to the Document
+10.   Trailing Boilerplate
+
+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 defintion 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.
+
+# 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.
+
+     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."
+
+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 underappreciated 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......................
+
+     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 unlcear.  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:
+
+       $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
+
+         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.
+
+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 the 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.
+
+     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."
+
+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
+
+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.
+
+     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 reason is that the asterisk
+     label only becomes significant when section's 4.3.2, step 3
+     part 'c' in 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) become unclear.
+
+     After some lengthy discussions, there has been no clear "best
+     answer" on how to document the semantics of such a situation.
+     Barring such records from the DNS would require definition of
+     rules for that, as well as introducing a restriction on records
+     that were once legal.  Allowing such records and amending the
+     process of signature management would entail complicating the
+     DNSSEC definition.
+
+     There is one more ingredient to the discussion, that being the
+     utility of a wild card domain name owned NS RRSet.  Although
+     there are cases of this use, it is an operational rarity.
+     Expending effort to close this topic has proven to be an
+     exercise in diminishing returns.
+
+     In summary, 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 specificaion 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.
+
+     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, cacheing 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.
+
+     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 it 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
+     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.
+
+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
+
+     [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
+
+     [RFC2181] Clarifications to the DNS Specification, R. Elz and
+               R. Bush, July 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
+
+     [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
+               August 1999
+
+     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.
+
+10. Trailing Boilerplate
+
+     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.
+
+     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 January 6, 2006.

doc/draft/draft-ietf-dnsop-bad-dns-res-04.txt

@@ -3,12 +3,12 @@
 
 DNS Operations                                                 M. Larson
 Internet-Draft                                                 P. Barber
-Expires: August 14, 2006                                        VeriSign
-                                                       February 10, 2006
+Expires: January 18, 2006                                       VeriSign
+                                                           July 17, 2005
 
 
                   Observed DNS Resolution Misbehavior
-                    draft-ietf-dnsop-bad-dns-res-05
+                    draft-ietf-dnsop-bad-dns-res-04
 
 Status of this Memo
 
@@ -33,11 +33,11 @@ Status of this Memo
    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.
+   This Internet-Draft will expire on January 18, 2006.
 
 Copyright Notice
 
-   Copyright (C) The Internet Society (2006).
+   Copyright (C) The Internet Society (2005).
 
 Abstract
 
@@ -52,50 +52,48 @@ Abstract
 
 
 
-Larson & Barber          Expires August 14, 2006                [Page 1]
+Larson & Barber         Expires January 18, 2006                [Page 1]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    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
+   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.   IANA considerations  . . . . . . . . . . . . . . . . . . . .  17
+   4.   Security considerations  . . . . . . . . . . . . . . . . . .  18
+   5.   Internationalization considerations  . . . . . . . . . . . .  19
+   6.   Informative References . . . . . . . . . . . . . . . . . . .  19
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  19
+        Intellectual Property and Copyright Statements . . . . . . .  21
 
 
 
@@ -108,9 +106,11 @@ Table of Contents
 
 
 
-Larson & Barber          Expires August 14, 2006                [Page 2]
+
+
+Larson & Barber         Expires January 18, 2006                [Page 2]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
 1.  Introduction
@@ -142,7 +142,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    specification; instead, this document consists of guidelines to
    implementors of iterative resolvers.
 
-1.1.  A note about terminology in this memo
+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
@@ -164,9 +164,9 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006                [Page 3]
+Larson & Barber         Expires January 18, 2006                [Page 3]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    because the focus is usually on that component.  In instances where
@@ -220,14 +220,14 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006                [Page 4]
+Larson & Barber         Expires January 18, 2006                [Page 4]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
 2.  Observed iterative resolver misbehavior
 
-2.1.  Aggressive requerying for delegation information
+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
@@ -276,9 +276,9 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006                [Page 5]
+Larson & Barber         Expires January 18, 2006                [Page 5]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    to contain the same list of name servers.  The chance of discovering
@@ -325,16 +325,16 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    Note, however, that such a query would not have QTYPE=NS according to
    the standard resolution algorithm.
 
-2.1.1.  Recommendation
+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]
+Larson & Barber         Expires January 18, 2006                [Page 6]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    zone.  For the purposes of this injunction, a non-responsive zone is
@@ -347,7 +347,8 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
    3.  is dead or unreachable according to section 7.2 of RFC 2308 [4].
 
-2.2.  Repeated queries to lame servers
+
+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.
@@ -377,22 +378,22 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    the "lame" servers for other types of queries, particularly when all
    known authoritative name servers appear to be "lame".
 
-2.2.1.  Recommendation
+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]
+Larson & Barber         Expires January 18, 2006                [Page 7]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
+   referenced to query the name server that was discovered to be lame.
    Implementations that perform lame server caching MUST refrain from
    sending queries to known lame servers based on a time interval from
    when the server is discovered to be lame.  A minimum interval of
@@ -413,7 +414,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    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
+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
@@ -443,13 +444,12 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-
-Larson & Barber          Expires August 14, 2006                [Page 8]
+Larson & Barber         Expires January 18, 2006                [Page 8]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
-2.3.1.  Recommendation
+2.3.1  Recommendation
 
    Clearly constructing a delegation that relies on multiple levels of
    indirection is not a good administrative practice.  However, the
@@ -465,7 +465,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    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
+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.
@@ -500,9 +500,9 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006                [Page 9]
+Larson & Barber         Expires January 18, 2006                [Page 9]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    prevents it from receiving responses.  If this is the case, all glue-
@@ -515,14 +515,14 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    specific queries received and based on additional analysis, we
    believe these queries result from overly aggressive glue fetching.
 
-2.4.1.  Recommendation
+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
+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
@@ -556,15 +556,15 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 10]
+Larson & Barber         Expires January 18, 2006               [Page 10]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    servers, which could explain how such a situation could persist
    without being detected.
 
-2.5.1.  Recommendation
+2.5.1  Recommendation
 
    The most obvious recommendation is that administrators SHOULD take
    care not to place iterative resolvers behind a firewall that allows
@@ -574,7 +574,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    excessive rates.  Implementations SHOULD support throttling logic to
    detect when queries are sent but no responses are received.
 
-2.6.  Misconfigured NS records
+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
@@ -612,9 +612,9 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 11]
+Larson & Barber         Expires January 18, 2006               [Page 11]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    authoritative server.
@@ -633,7 +633,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    obviously bogus glue address records occur frequently at the com/net
    name servers.
 
-2.6.1.  Recommendation
+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
@@ -647,7 +647,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    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
+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
@@ -668,9 +668,9 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 12]
+Larson & Barber         Expires January 18, 2006               [Page 12]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    zone parent/child relationships we are aware of, there is typically
@@ -684,14 +684,14 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    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
+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
+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
@@ -724,9 +724,9 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 13]
+Larson & Barber         Expires January 18, 2006               [Page 13]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    public TLD or root zones that would be the appropriate targets for a
@@ -746,7 +746,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    up the tree with queries yields cacheable information, whereas
    walking up the tree by sending UPDATE messages does not.
 
-2.8.1.  Recommendation
+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
@@ -755,7 +755,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    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
+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
@@ -773,16 +773,16 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    domain name "192.0.2.1" does not prevent a subsequent query for the
    domain name "192.0.2.2".
 
-2.9.1.  Recommendation
+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]
+Larson & Barber         Expires January 18, 2006               [Page 14]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    bandwidth.  A possible solution is to delegate these numeric TLDs
@@ -794,7 +794,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    change procedures would have to be followed to make such a change to
    the root zone.
 
-2.10.  Misdirected recursive queries
+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
@@ -809,7 +809,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    stub resolver implementation that offers any feedback to the user
    when so configured, aside from simply "not working".
 
-2.10.1.  Recommendation
+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,
@@ -824,7 +824,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    notification or log message for every response from a non-recursive
    server.
 
-2.11.  Suboptimal name server selection algorithm
+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
@@ -836,9 +836,9 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 15]
+Larson & Barber         Expires January 18, 2006               [Page 15]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
    Some deficiencies cause significant operational impact and are
@@ -850,7 +850,7 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    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
+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
@@ -892,68 +892,12 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 16]
+Larson & Barber         Expires January 18, 2006               [Page 16]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
-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
+3.  IANA considerations
 
    There are no new IANA considerations introduced by this memo.
 
@@ -1004,12 +948,12 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 18]
+Larson & Barber         Expires January 18, 2006               [Page 17]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
-5.  Security considerations
+4.  Security considerations
 
    The iterative resolver misbehavior discussed in this document exposes
    the root and TLD name servers to increased risk of both intentional
@@ -1060,17 +1004,17 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 19]
+Larson & Barber         Expires January 18, 2006               [Page 18]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
-6.  Internationalization considerations
+5.  Internationalization considerations
 
    There are no new internationalization considerations introduced by
    this memo.
 
-7.  Informative References
+6.  Informative References
 
    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.
@@ -1098,29 +1042,6 @@ Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
    [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
@@ -1132,6 +1053,18 @@ Authors' Addresses
    Email: mlarson@verisign.com
 
 
+
+
+
+
+
+
+
+Larson & Barber         Expires January 18, 2006               [Page 19]
+
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
+
+
    Piet Barber
    VeriSign, Inc.
    21345 Ridgetop Circle
@@ -1172,9 +1105,20 @@ Authors' Addresses
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 21]
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber         Expires January 18, 2006               [Page 20]
 
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
+Internet-Draft     Observed DNS Resolution Misbehavior         July 2005
 
 
 Intellectual Property Statement
@@ -1215,7 +1159,7 @@ Disclaimer of Validity
 
 Copyright Statement
 
-   Copyright (C) The Internet Society (2006).  This document is subject
+   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.
 
@@ -1228,5 +1172,5 @@ Acknowledgment
 
 
 
-Larson & Barber          Expires August 14, 2006               [Page 22]
+Larson & Barber         Expires January 18, 2006               [Page 21]
 

doc/draft/draft-ietf-dnsop-default-local-zones-10.txt

@@ -1,728 +0,0 @@
-
-
-
-Network Working Group                                         M. Andrews
-Internet-Draft                                                       ISC
-Intended status: BCP                                      March 25, 2010
-Expires: September 26, 2010
-
-
-                        Locally-served DNS Zones
-                draft-ietf-dnsop-default-local-zones-10
-
-Abstract
-
-   Experience with the Domain Name System (DNS) has shown that there are
-   a number of DNS zones all iterative resolvers and recursive
-   nameservers should automatically serve, unless configured otherwise.
-   RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This
-   document extends the practice to cover the IN-ADDR.ARPA zones for RFC
-   1918 address space and other well known zones with similar
-   characteristics.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 26, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-
-
-
-Andrews                Expires September 26, 2010               [Page 1]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-   This document may contain material from IETF Documents or IETF
-   Contributions published or made publicly available before November
-   10, 2008.  The person(s) controlling the copyright in some of this
-   material may not have granted the IETF Trust the right to allow
-   modifications of such material outside the IETF Standards Process.
-   Without obtaining an adequate license from the person(s) controlling
-   the copyright in such materials, this document may not be modified
-   outside the IETF Standards Process, and derivative works of it may
-   not be created outside the IETF Standards Process, except to format
-   it for publication as an RFC or to translate it into languages other
-   than English.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                Expires September 26, 2010               [Page 2]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Effects on sites using RFC 1918 addresses. . . . . . . . . . .  4
-   3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
-   4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
-     4.1.  RFC1918 Zones  . . . . . . . . . . . . . . . . . . . . . .  5
-     4.2.  RFC3330 and RFC5737 Zones  . . . . . . . . . . . . . . . .  6
-     4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
-     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  7
-     4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
-     4.6.  IPv6 Example Prefix  . . . . . . . . . . . . . . . . . . .  7
-   5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Appendix A.  Change History [To Be Removed on Publication] . . . . 10
-     A.1.  draft-ietf-dnsop-default-local-zones-10.txt  . . . . . . . 10
-     A.2.  draft-ietf-dnsop-default-local-zones-09.txt  . . . . . . . 10
-     A.3.  draft-ietf-dnsop-default-local-zones-08.txt  . . . . . . . 11
-     A.4.  draft-ietf-dnsop-default-local-zones-07.txt  . . . . . . . 11
-     A.5.  draft-ietf-dnsop-default-local-zones-06.txt  . . . . . . . 11
-     A.6.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 11
-     A.7.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 11
-     A.8.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 11
-     A.9.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 11
-     A.10. draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
-     A.11. draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
-     A.12. draft-andrews-full-service-resolvers-03.txt  . . . . . . . 12
-     A.13. draft-andrews-full-service-resolvers-02.txt  . . . . . . . 12
-   Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 12
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                Expires September 26, 2010               [Page 3]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-1.  Introduction
-
-   Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035])
-   has shown that there are a number of DNS zones that all iterative
-   resolvers and recursive nameservers SHOULD automatically serve,
-   unless intentionally configured otherwise.  These zones include, but
-   are not limited to, the IN-ADDR.ARPA zones for the address space
-   allocated by [RFC1918] and the IP6.ARPA zones for locally assigned
-   unique local IPv6 addresses defined in [RFC4193].
-
-   This recommendation is made because data has shown that significant
-   leakage of queries for these name spaces is occurring, despite
-   instructions to restrict them, and because it has therefore become
-   necessary to deploy sacrificial name servers to protect the immediate
-   parent name servers for these zones from excessive, unintentional,
-   query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
-   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].  There is every
-   expectation that the query load will continue to increase unless
-   steps are taken as outlined here.
-
-   Additionally, queries from clients behind badly configured firewalls
-   that allow outgoing queries for these name spaces but drop the
-   responses, put a significant load on the root servers (forward but no
-   reverse zones configured).  They also cause operational load for the
-   root server operators as they have to reply to enquiries about why
-   the root servers are "attacking" these clients.  Changing the default
-   configuration will address all these issues for the zones listed in
-   Section 4.
-
-   [RFC4193] recommends that queries for D.F.IP6.ARPA be handled
-   locally.  This document extends the recommendation to cover the IN-
-   ADDR.ARPA zones for [RFC1918] and other well known IN-ADDR.ARPA and
-   IP6.ARPA zones for which queries should not appear on the public
-   Internet.
-
-   It is hoped that by doing this the number of sacrificial servers
-   [AS112] will not have to be increased, and may in time be reduced.
-
-   This recommendation should also help DNS responsiveness for sites
-   which are using [RFC1918] addresses but do not follow the last
-   paragraph in Section 3 of [RFC1918].
-
-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].
-
-
-
-
-Andrews                Expires September 26, 2010               [Page 4]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-2.  Effects on sites using RFC 1918 addresses.
-
-   For most sites using [RFC1918] addresses, the changes here will have
-   little or no detrimental effect.  If the site does not already have
-   the reverse tree populated the only effect will be that the name
-   error responses will be generated locally rather than remotely.
-
-   For sites that do have the reverse tree populated, most will either
-   have a local copy of the zones or will be forwarding the queries to
-   servers which have local copies of the zone.  Therefore this
-   recommendation will not be relevant.
-
-   The most significant impact will be felt at sites that make use of
-   delegations for [RFC1918] addresses and have populated these zones.
-   These sites will need to override the default configuration expressed
-   in this document to allow resolution to continue.  Typically, such
-   sites will be fully disconnected from the Internet and have their own
-   root servers for their own non-Internet DNS tree.
-
-
-3.  Changes to Iterative Resolver Behaviour.
-
-   Unless configured otherwise, an iterative resolver will now return
-   authoritatively (aa=1) name errors (RCODE=3) for queries within the
-   zones in Section 4, with the obvious exception of queries for the
-   zone name itself where SOA, NS and "no data" responses will be
-   returned as appropriate to the query type.  One common way to do this
-   all at once is to serve empty (SOA and NS only) zones.
-
-   An implementation of this recommendation MUST provide a mechanism to
-   disable this new behaviour, and SHOULD allow this decision on a zone
-   by zone basis.
-
-   If using empty zones one SHOULD NOT use the same NS and SOA records
-   as used on the public Internet servers as that will make it harder to
-   detect the origin of the responses and thus any leakage to the public
-   Internet servers.  This document recommends that the NS record
-   defaults to the name of the zone and the SOA MNAME defaults to the
-   name of the only NS RR's target.  The SOA RNAME should default to
-   "nobody.invalid."  [RFC2606].  Implementations SHOULD provide a
-   mechanism to set these values.  No address records need to be
-   provided for the name server.
-
-   Below is an example of a generic empty zone in master file format.
-   It will produce a negative cache TTL of 3 hours.
-
-   @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
-   @ 10800 IN NS @
-
-
-
-Andrews                Expires September 26, 2010               [Page 5]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-   The SOA RR is needed to support negative caching [RFC2308] of name
-   error responses and to point clients to the primary master for DNS
-   dynamic updates.
-
-   SOA values of particular importance are the MNAME, the SOA RR's TTL
-   and the negTTL value.  Both TTL values SHOULD match.  The rest of the
-   SOA timer values MAY be chosen arbitrarily since they are not
-   intended to control any zone transfer activity.
-
-   The NS RR is needed as some UPDATE [RFC2136] clients use NS queries
-   to discover the zone to be updated.  Having no address records for
-   the name server is expected to abort UPDATE processing in the client.
-
-
-4.  Lists Of Zones Covered
-
-   The following subsections are intended to seed the IANA registry as
-   requested in the IANA Considerations Section.  The zone name is the
-   entity to be registered.
-
-4.1.  RFC1918 Zones
-
-   The following zones correspond to the IPv4 address space reserved in
-   [RFC1918].
-
-                         +----------------------+
-                         | Zone                 |
-                         +----------------------+
-                         | 10.IN-ADDR.ARPA      |
-                         | 16.172.IN-ADDR.ARPA  |
-                         | 17.172.IN-ADDR.ARPA  |
-                         | 18.172.IN-ADDR.ARPA  |
-                         | 19.172.IN-ADDR.ARPA  |
-                         | 20.172.IN-ADDR.ARPA  |
-                         | 21.172.IN-ADDR.ARPA  |
-                         | 22.172.IN-ADDR.ARPA  |
-                         | 23.172.IN-ADDR.ARPA  |
-                         | 24.172.IN-ADDR.ARPA  |
-                         | 25.172.IN-ADDR.ARPA  |
-                         | 26.172.IN-ADDR.ARPA  |
-                         | 27.172.IN-ADDR.ARPA  |
-                         | 28.172.IN-ADDR.ARPA  |
-                         | 29.172.IN-ADDR.ARPA  |
-                         | 30.172.IN-ADDR.ARPA  |
-                         | 31.172.IN-ADDR.ARPA  |
-                         | 168.192.IN-ADDR.ARPA |
-                         +----------------------+
-
-
-
-
-Andrews                Expires September 26, 2010               [Page 6]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-4.2.  RFC3330 and RFC5737 Zones
-
-   The following zones correspond to those address ranges from [RFC3330]
-   and [RFC5737] that are not expected to appear as source or
-   destination addresses on the public Internet and to not have a unique
-   name to associate with.
-
-   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
-   attempt to discourage any practice to provide a PTR RR for
-   1.0.0.127.IN-ADDR.ARPA locally.  In fact, a meaningful reverse
-   mapping should exist, but the exact setup is out of the scope of this
-   document.  Similar logic applies to the reverse mapping for ::1
-   (Section 4.3).  The recommendations made here simply assume no other
-   coverage for these domains exists.
-
-         +------------------------------+------------------------+
-         | Zone                         | Description            |
-         +------------------------------+------------------------+
-         | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK    |
-         | 127.IN-ADDR.ARPA             | IPv4 LOOP-BACK NETWORK |
-         | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL        |
-         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET 1        |
-         | 100.51.198.IN-ADDR.ARPA      | IPv4 TEST NET 2        |
-         | 113.0.203.IN-ADDR.ARPA       | IPv4 TEST NET 3        |
-         | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
-         +------------------------------+------------------------+
-
-4.3.  Local IPv6 Unicast Addresses
-
-   The reverse mappings ([RFC3596], Section 2.5 IP6.ARPA Domain) for the
-   IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291],
-   Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
-
-               +-------------------------------------------+
-               | Zone                                      |
-               +-------------------------------------------+
-               | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
-               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
-               | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
-               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
-               +-------------------------------------------+
-
-   Note: Line breaks and a escapes '\' have been inserted above for
-   readability and to adhere to line width constraints.  They are not
-   parts of the zone names.
-
-
-
-
-
-
-Andrews                Expires September 26, 2010               [Page 7]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-4.4.  IPv6 Locally Assigned Local Addresses
-
-   Section 4.4 of [RFC4193] already required special treatment of:
-
-                             +--------------+
-                             | Zone         |
-                             +--------------+
-                             | D.F.IP6.ARPA |
-                             +--------------+
-
-4.5.  IPv6 Link Local Addresses
-
-   IPv6 Link-Local Addresses as of [RFC4291], Section 2.5.6 are covered
-   by four distinct reverse DNS zones:
-
-                            +----------------+
-                            | Zone           |
-                            +----------------+
-                            | 8.E.F.IP6.ARPA |
-                            | 9.E.F.IP6.ARPA |
-                            | A.E.F.IP6.ARPA |
-                            | B.E.F.IP6.ARPA |
-                            +----------------+
-
-4.6.  IPv6 Example Prefix
-
-   IPv6 example prefix [RFC3849].
-
-                       +--------------------------+
-                       | Zone                     |
-                       +--------------------------+
-                       | 8.B.D.0.1.0.0.2.IP6.ARPA |
-                       +--------------------------+
-
-   Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as a example here.
-
-
-5.  Zones that are Out-Of-Scope
-
-   IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and
-   2.5.7), and IPv6 Non-Locally Assigned Local addresses ([RFC4193]) are
-   not covered here.
-
-   It is expected that IPv6 site-local addresses will be self correcting
-   as IPv6 implementations remove support for site-local addresses.
-   However, sacrificial servers for the zones C.E.F.IP6.ARPA through
-   F.E.F.IP6.ARPA may still need to be deployed in the short term if the
-   traffic becomes excessive.
-
-
-
-Andrews                Expires September 26, 2010               [Page 8]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-   For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193],
-   there has been no decision made about whether the Regional Internet
-   Registries (RIRs) will provide delegations in this space or not.  If
-   they don't, then C.F.IP6.ARPA will need to be added to the list in
-   Section 4.4.  If they do, then registries will need to take steps to
-   ensure that name servers are provided for these addresses.
-
-   This document also ignores IP6.INT.  IP6.INT has been wound up with
-   only legacy resolvers now generating reverse queries under IP6.INT
-   [RFC4159].
-
-   This document has also deliberately ignored names immediately under
-   the root domain.  While there is a subset of queries to the root name
-   servers which could be addressed using the techniques described here
-   (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
-   amount of traffic that requires a different strategy (e.g. lookups
-   for unqualified hostnames, IPv6 addresses).
-
-
-6.  IANA Considerations
-
-   This document requests that IANA establish a registry of zones which
-   require this default behaviour.  The initial contents of this
-   registry are defined in Section 4.  Implementors are encouraged to
-   periodically check this registry and adjust their implementations to
-   reflect changes therein.
-
-   This registry can be amended through "IETF Review" as per [RFC5226].
-
-   IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
-   deployed in the reverse tree, delegations for these zones are made in
-   the manner described in Section 7.
-
-
-7.  Security Considerations
-
-   During the initial deployment phase, particularly where [RFC1918]
-   addresses are in use, there may be some clients that unexpectedly
-   receive a name error rather than a PTR record.  This may cause some
-   service disruption until their recursive name server(s) have been re-
-   configured.
-
-   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
-   namespaces, the zones listed above will need to be delegated as
-   insecure delegations, or be within insecure zones.  This will allow
-   DNSSEC validation to succeed for queries in these spaces despite not
-   being answered from the delegated servers.
-
-
-
-
-Andrews                Expires September 26, 2010               [Page 9]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-   It is recommended that sites actively using these namespaces secure
-   them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
-   anchors.  This will protect the clients from accidental import of
-   unsigned responses from the Internet.
-
-
-8.  Acknowledgements
-
-   This work was supported by the US National Science Foundation
-   (research grant SCI-0427144) and DNS-OARC.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [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.
-
-   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
-              and E. Lear, "Address Allocation for Private Internets",
-              BCP 5, RFC 1918, February 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2398, March 1998.
-
-   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-              Names", BCP 32, RFC 2606, June 1999.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IPv6", RFC 3596, October 2003.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
-              August 2005.
-
-
-
-Andrews                Expires September 26, 2010              [Page 10]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", RFC 4193, October 2005.
-
-   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-              Architecture", RFC 4291, February 2006.
-
-   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
-              October 2008.
-
-9.2.  Informative References
-
-   [AS112]    "AS112 Project", <http://www.as112.net/>.
-
-   [I-D.draft-ietf-dnsop-as112-ops]
-              Abley, J. and W. Maton, "AS112 Nameserver Operations",
-              draft-ietf-dnsop-as112-ops-01 (work in progress),
-              November 2007.
-
-   [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
-              Abley, J. and W. Maton, "I'm Being Attacked by
-              PRISONER.IANA.ORG!",
-              draft-ietf-dnsop-as112-under-attack-help-help-01 (work in
-              progress), November 2007.
-
-   [RFC3330]  "Special-Use IPv4 Addresses", RFC 3330, September 2002.
-
-   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
-              Reserved for Documentation", RFC 3849, July 2004.
-
-   [RFC5737]  Arkko, J., Cotton, M., and L. Vergoda, "IPv4 Address
-              Blocks Reserved for Documentation", RFC 5737,
-              January 2010.
-
-
-Appendix A.  Change History [To Be Removed on Publication]
-
-A.1.  draft-ietf-dnsop-default-local-zones-10.txt
-
-   added RFC 5737 zones
-
-A.2.  draft-ietf-dnsop-default-local-zones-09.txt
-
-   refresh awaiting writeup
-
-
-
-
-
-
-
-Andrews                Expires September 26, 2010              [Page 11]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-A.3.  draft-ietf-dnsop-default-local-zones-08.txt
-
-   editorial, reference updates
-
-A.4.  draft-ietf-dnsop-default-local-zones-07.txt
-
-   none, expiry prevention
-
-A.5.  draft-ietf-dnsop-default-local-zones-06.txt
-
-   add IPv6 example prefix
-
-A.6.  draft-ietf-dnsop-default-local-zones-05.txt
-
-   none, expiry prevention
-
-A.7.  draft-ietf-dnsop-default-local-zones-04.txt
-
-   Centrally Assigned Local addresses -> Non-Locally Assigned Local
-   address
-
-A.8.  draft-ietf-dnsop-default-local-zones-03.txt
-
-   expanded section 4 descriptions
-
-   Added references [RFC2136], [RFC3596],
-   [I-D.draft-ietf-dnsop-as112-ops] and
-   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
-
-   Revised language.
-
-A.9.  draft-ietf-dnsop-default-local-zones-02.txt
-
-   RNAME now "nobody.invalid."
-
-   Revised language.
-
-A.10.  draft-ietf-dnsop-default-local-zones-01.txt
-
-   Revised impact description.
-
-   Updated to reflect change in IP6.INT status.
-
-A.11.  draft-ietf-dnsop-default-local-zones-00.txt
-
-   Adopted by DNSOP.
-
-   "Author's Note" re-titled "Zones that are Out-Of-Scope"
-
-
-
-Andrews                Expires September 26, 2010              [Page 12]
-
-Internet-Draft          Locally-served DNS Zones              March 2010
-
-
-   Add note that these zone are expected to seed the IANA registry.
-
-   Title changed.
-
-A.12.  draft-andrews-full-service-resolvers-03.txt
-
-   Added "Proposed Status".
-
-A.13.  draft-andrews-full-service-resolvers-02.txt
-
-   Added 0.IN-ADDR.ARPA.
-
-
-Appendix B.  Proposed Status [To Be Removed on Publication]
-
-   This Internet-Draft is being submitted for eventual publication as an
-   RFC with a proposed status of Best Current Practice.
-
-
-Author's Address
-
-   Mark P. Andrews
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA  94063
-   US
-
-   Email: marka@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                Expires September 26, 2010              [Page 13]
-

doc/draft/draft-ietf-dnsop-dnssec-trust-history-01.txt

@@ -1,504 +0,0 @@
-
-
-
-Domain Name System Operations                              W. Wijngaards
-Internet-Draft                                                O. Kolkman
-Intended status: Standards Track                              NLnet Labs
-Expires: August 26, 2010                               February 22, 2010
-
-
-                  DNSSEC Trust Anchor History Service
-                draft-ietf-dnsop-dnssec-trust-history-01
-
-Abstract
-
-   When DNS validators have trusted keys, but have been offline for a
-   longer period, key rollover will fail and they are stuck with stale
-   trust anchors.  History service allows validators to query for older
-   DNSKEY RRsets and pick up the rollover trail where they left off.
-
-Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-Status of This Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 26, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 1]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-1.  Introduction
-
-   This memo defines a trust history service for DNS validators -- the
-   component in a resolver that performs DNSSEC [RFC4034] validation,
-   validator for short.
-
-   A validator that has been offline or missed an (emergency) rollover
-   can use this service to reconfigure themselves with the current
-   trust-anchor.  Using a newly defined resource record (RR) that links
-   old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
-   RRsets and checks they form a chain to the latest key (see
-   Section 2).  The lists of old DNSKEYS, linked with the TALINK RRs, do
-   not necessarily need to be published in the zone for which the DNSKEY
-   history is being maintained but can be published in any DNS domain.
-   We will call the entity that offers the trust history the History
-   Provider.  The choice of the History Provider is made by the
-   maintainer of the validator, possibly based on a hint provided, using
-   the TALINK, by the zone owner.
-
-   The algorithm that the validator uses to construct a history and
-   reconfigure a new key is detailed in Section 3.  The algorithms for
-   how providers of trust history can fetch the DNSKEY data as published
-   by the zone they track and publish that are explained in Section 4.
-
-2.  The  TALINK Resource Record
-
-   The DNS Resource Record type TALINK (decimal 58) ties the elements of
-   a linked list of DNSKEY RRs together.
-
-   The rdata consists of two domain names.  The first name is the start,
-   or previous name, and the other name the end or next name in the
-   list.  The empty label '.' is used at the endpoints of the list.
-
-   The presentation format is the two domain names.  The wire encoding
-   is the two domain names, with no compression so the type can be
-   treated according to [RFC3597].  The list is a double linked list,
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 2]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   because this empowers low memory hosts to perform consistency checks.
-
-3.  Trust History Lookup
-
-   This is the algorithm that a validator uses to detect and resolve the
-   situation in which a trust-anchor is out of sync with the DNSKEYs
-   published by a zone owner.  The algorithm uses the TALINK RR type
-   which is used to link various old DNSKEYs as published by the History
-   Provider, to arrive from the outdated configured Trust Anchor to one
-   that matches the current DNSKEY.  The TALINK RR type is defined in
-   Section 2.
-
-   When the algorithm below results in failure the trust history cannot
-   be build and a new trust anchor will need to be re-configured using
-   another mechanism.
-
-   Step 1:  The validator performs a DNSKEY lookup to the target zone,
-      which looks like any other initial DNSKEY lookup that the
-      validator needs to match a trust anchor to the currently used
-      DNSKEY RR set.  If the keyset verifies with the trust anchor
-      currently held, the trust-anchor is not out of sync.  Otherwise,
-      store the DNSKEY RR set as result.  The algorithm will
-      successfully build a linked list to this DNSKEY RR, or delete the
-      trust point, or fail.
-
-      All nameservers (the ones authoritative for the zone or the
-      upstream resolver caches when the validator is not full resolver)
-      SHOULD be checked to make sure the DNSKEY RR sets are the same.
-      The results can differ if a key-rollover is in progress and not
-      all nameservers are in sync yet.  This case can be detected by
-      checking that the older keyset signs the newer and take the newer
-      as result keyset.  The keysets are distinguished by the average
-      over the middle of the inception and expiration dates of the
-      signatures that are validated by the keyset itself.  Otherwise,
-      the history lookup fails.  If the check fails then the
-      inconsistency may be the result of spoofing, or compromise of
-      (DNS) infrastructure elements.
-
-   Step 2:  Fetch the trust history list end points.  Perform a query of
-      QTYPE TALINK and QNAME the domain name that is configured to be
-      the History Provider for the particular domain you are trying to
-      update the trust-anchor for.
-
-   Step 3:  Go backwards through the trust history list as provided by
-      the TALINK linked list.  Verify that the keyset validly signs the
-      next keyset.  This is [RFC4034] validation, but the RRSIG
-      expiration date is ignored.  [Editor note: Are we shure that there
-      are no server implementations that will not serve expired RRSIG,
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 3]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-      are such 'smart' servers allowed by the specs?  In other words do
-      we need clarification in the DNSSEC-updates document?]  Replace
-      the owner domain name with the target zone name for verification.
-      One of the keys that signs the next keyset MUST have the SEP bit
-      set.  The middle of inception and expiration date from the valid
-      signature MUST be older than that of the signature that validates
-      the next keys in the list.  Query type TALINK to get previous and
-      next locations.
-
-      If all SEP keys have the REVOKE flag set at this step, and the
-      keyset is signed by all SEP keys, then continue but store that the
-      end result is that the trust point is deleted, see Section 5
-      [RFC5011].
-
-      If all SEP keys are of an unknown algorithm at this step, continue
-      and at the next step, when you verify if the keyset signs validly:
-      if false, continue with result a failure, if true, continue with
-      the end result that the trust point is deleted.  Thus, the keysets
-      with unknown algorithms are stepped over with an end result of
-      failure because the validator cannot determine if unknown
-      algorithm signatures are valid, until the oldest keyset with
-      unknown algorithms is signed by a known algorithm and the result
-      is set to deletion and step 3 continues to a known key.
-
-   Step 4:  When the trust anchor currently held by the validator
-      verifies the keyset, the algorithm is done.  The validator SHOULD
-      store the result on stable storage.  Use the new trust anchor for
-      validation (if using [RFC5011], put it in state VALID).
-
-4.  Trust History Tracker
-
-   External trackers can poll the target zone DNSKEY RRset regularly.
-   Ignore date changes in the RRSIG.  Ignore changes to keys with no SEP
-   flag.  Copy the newly polled DNSKEY RRset and RRSIGs, change the
-   owner name to a new name at the history location.  Publish the new
-   RRset and TALINK records to make it the last element in the list.
-   Update the TALINK that advertises the first and last name.
-
-   Integrated into the rollover, the keys are stored in the history and
-   the TALINK is updated when a new key is used in the rollover process.
-   This gives the TALINK and new historical key time to propagate.
-
-   The signer can support trust history.  Trust history key sets need
-   only contain SEP keys.  To use older signers, move historical RRSIGs
-   to another file.  Sign the zone, including the TALINK and DNSKEY
-   records.  Append the historical RRSIGs to the result.  Signing the
-   zone like this obviates the need for changes to signer and server
-   software.
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 4]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-5.  Example
-
-   In this example example.com is the History Provider for example.net.
-   The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
-   and paste of the data from example.net.
-
-   $ORIGIN example.com.
-   example.com. TALINK h0.example.com. h2.example.com.
-
-   h0 TALINK . h1.example.com.
-   h0 DNSKEY ...
-   h0 RRSIG ...
-
-   h1 TALINK h0.example.com. h2.example.com.
-   h1 DNSKEY ...
-   h1 RRSIG ...
-
-   h2 TALINK h1.example.com. .
-   h2 DNSKEY ...
-   h2 RRSIG ...
-
-   The example.net zone can advertise the example.com History Provider
-   by providing the TALINK shown here at example.com at the apex of the
-   example.net zone.  The TALINK at example.com is then not needed.
-
-6.  Deployment
-
-   The trust history is advertised with TALINK RRs at the zone apex.
-   These represent alternative history sources, that can be searched in
-   turn.  The TALINK at the zone apex contains the first and last name
-   of the list of historical keys.
-
-   The historical list of keys grows perpetually.  Since most validators
-   have recent keys, their processing time remains similar as the list
-   grows.  If validators no longer have trust in the keys then they need
-   no longer be published.  The oldest key entries can be omitted from
-   the list to shorten it.
-
-   The validator decides how long it trusts a key.  A recommendation
-   from the zone owner can be configured for keys of that zone, or
-   recommendations per algorithm and key size can be used (e.g. see
-   [NIST800-57]).  If a key is older than that, trust history lookup
-   fails with it and the trust point can be considered deleted.  This
-   assumes the validator has decided on a security policy and also can
-   take actions when the update of the trust anchor fails.  Without such
-   policy, or if the alternative is no DNSSEC, the approach below can be
-   used.
-
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 5]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   In general, the decision can be that any key - no matter how old or
-   how small - is better than no security.  The validator then never
-   considers a key too old, and the lookup algorithm becomes an
-   unsecured update mechanism at the time where the key can be trivially
-   broken.  The history provider SHOULD provide these broken keys to
-   facilitate clients performing the unsecured update.  If a key can not
-   be trivially broken then it provides a non-trivial amount of security
-   that the history lookup algorithm uses to get the current keys.
-   Conceivably after the update the result is stored on stable storage
-   and the client is thereafter safe - it performs a leap of faith.  The
-   validator operator can opt for this set up after considering the
-   trade-off between loss of DNSSEC, loss of connectivity, and the
-   argument that perceived security is worse than no security.
-
-   The history lookup can be used on its own.  Then, the trust history
-   is used whenever the key rolls over and no polling is performed.
-   This has associated risks, in that the immediate rollover without
-   timeout that it provides could be abused, and certainly when taken
-   together with leap-of-faith such systems SHOULD inform their user
-   that the key has changed and urge them to do immediate checks.
-   Initially we put a hold down timer on such rollovers to mitigate the
-   abuse risks but these make following normal rollovers impossible.
-
-   If a validator is also using [RFC5011] for the target zone, then the
-   trust history algorithm SHOULD only be invoked if the [RFC5011]
-   algorithm failed due to the inability to perform probes.  This is the
-   case when the last [RFC5011] successful probe was more than 30 days
-   ago.  If a new key has been announced, invoke the history if no 2
-   probes succeeded during the add hold-down time and there was no
-   successful probe after the add hold-down time passed.  Therefore the
-   time of the last successful probe MUST be stored on stable storage.
-
-   For testing the potentially very infrequently used lookup, the
-   following SHOULD be implemented.  For the test the lookup is
-   triggered manually by allowing the system to be given a particular
-   keyset with a last successful lookup date in the past and a test
-   History Provider.  The test History Provider provides access to a
-   generated back-dated test history.
-
-7.  Security Considerations
-
-   The History Provider only provides copies of old data.  If that
-   historic data is altered or withheld the lookup algorithm fails
-   because of validation errors in Step 3 of the algorithm.  If the
-   History provider or a Man in the Middle Adversary (MIMA) has access
-   to the original private keys (through theft, cryptanalisis, or
-   otherwise), history can be altered without failure of the algorithm.
-   Below we only consider MIMAs and assume the History Provider is a
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 6]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   trusted party.
-
-   Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
-   TALINK and DNSKEY data, can present some alternate history.  However
-   the DNSKEY RR set trusted that the history should arrive at is
-   already fixed by step 1.  If an attempt is made to subvert the
-   algorithm at step 2 or 3, then the result keyset can not be replaced
-   by another keyset unnoticed.
-
-   To change the keyset trusted as the outcome, the step 1 data has to
-   be spoofed and the key held by the validator (or a newer historic
-   key) has to be compromised.  Unless such spoof is targeted to a
-   specific victim, a spoof of the step 1 result has a high visibility.
-   Since most of the validators that receive the spoof have an up-to-
-   date trust anchor most validators that would receive this spoof
-   return validation failure for data from the zone that contains the
-   DNSKEYs.  An adversary will therefore have to target the attack to
-   validators that are in the process of an update.  Since validators do
-   not announce that they use trust history lookup until step 2
-   adversaries will not be able to select the validators.
-
-   A spoof of data in steps 2 and 3, together with a compromised (old)
-   key, can result in a downgrade.  At steps 2 and 3 a faked trust point
-   deletion or algorithm rollover can be inserted in a fake history.
-   This avoids the high visibility of spoofing the current key (see
-   previous paragraph) and downgrades to insecure.
-
-   Finally there is the case that one of the keys published by the
-   History Providers has been compromised.  Since someone spoofing at
-   step 1 of the lookup algorithm and presenting some fake history to a
-   compromised key, of course does not include key revocations and does
-   extend the history to contain the compromised key, it therefore is
-   not really useful for a History Provider to remove the key from the
-   published history.  That only makes lookups fail for those validators
-   who are not under attack.  Useful action could be to update
-   validators using some other means.
-
-   Rollover with [RFC5011] revokes keys after use.  If a History
-   Provider is used, then such revoked keys SHOULD be used to perform
-   history tracking and history lookup.  The old keys that the validator
-   starts with and final current keys MUST NOT be trusted if they are
-   revoked.
-
-   Depending on choices by the validator operator, it may accept a leap-
-   of-faith, and possibly allow non-hold-down rollovers.  Although this
-   allows very fast emergency rollover if all clients are known to do
-   trust-history lookups without the RFC5011-algorithm, it also allows
-   an attacker with the private key to attempt to take over a zone
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 7]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   quickly and get validators to roll to a trust anchor of the
-   attacker's choosing.
-
-   The SEP bit is checked to make sure that control over the KSK is
-   necessary to change the keyset for the target zone.
-
-   The algorithm can be used to get the inception and expiration times
-   of signatures on the current keyset, a clock.  A MIMA can attempt to
-   shorten history and put back that clock, but the algorithm attempts
-   to make this difficult to target and highly visible to others.
-
-   If the clock of the validator can be influenced, then setting it
-   forward is unlikely to give advantage, but setting it backward
-   enables a replay attack of old DNSSEC data and signatures.  This
-   vulnerability exists also in plain DNSSEC.
-
-8.  IANA Considerations
-
-   Resource record type TALINK has been defined using RFC5395 expert
-   review, it has RR type number 58 (decimal).
-
-9.  Acknowledgments
-
-   Thanks to the people who provided review and suggestions, Joe Abley,
-   George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
-   Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
-   Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
-   Matthijs Mekking.
-
-10.  References
-
-10.1.  Informative References
-
-   [NIST800-57]  Barker, E., Barker, W., Burr, W., Polk, W., and M.
-                 Smid, "Recommendations for Key Management", NIST
-                 SP 800-57, March 2007.
-
-   [RFC5011]     StJohns, M., "Automated Updates of DNS Security
-                 (DNSSEC) Trust Anchors", RFC 5011, September 2007.
-
-10.2.  Normative References
-
-   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3597]     Gustafsson, A., "Handling of Unknown DNS Resource
-                 Record (RR) Types", RFC 3597, September 2003.
-
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 8]
-
-Internet-Draft            Trust History Service            February 2010
-
-
-   [RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                 Rose, "Resource Records for the DNS Security
-                 Extensions", RFC 4034, March 2005.
-
-Authors' Addresses
-
-   Wouter Wijngaards
-   NLnet Labs
-   Science Park 140
-   Amsterdam  1098 XG
-   The Netherlands
-
-   EMail: wouter@nlnetlabs.nl
-
-
-   Olaf Kolkman
-   NLnet Labs
-   Science Park 140
-   Amsterdam  1098 XG
-   The Netherlands
-
-   EMail: olaf@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wijngaards & Kolkman     Expires August 26, 2010                [Page 9]
-

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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

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]

doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt

@@ -1,952 +0,0 @@
-
-
-
-DNSOP                                                        W. Hardaker
-Internet-Draft                                              Sparta, Inc.
-Intended status: Informational                         February 12, 2009
-Expires: August 16, 2009
-
-
-        Requirements for Management of Name Servers for the DNS
-          draft-ietf-dnsop-name-server-management-reqs-02.txt
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 16, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.
-
-Abstract
-
-   Management of name servers for the Domain Name Service (DNS) has
-   traditionally been done using vendor-specific monitoring,
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 1]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   configuration and control methods.  Although some service monitoring
-   platforms can test the functionality of the DNS itself there is not a
-   interoperable way to manage (monitor, control and configure) the
-   internal aspects of a name server itself.
-
-   This document discusses the requirements of a management system for
-   DNS name servers.  A management solution that is designed to manage
-   the DNS can use this document as a shopping list of needed features.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  4
-       1.1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . .  5
-       1.1.2.  Document Layout and Requirements . . . . . . . . . . .  5
-   2.  Management Architecture Requirements . . . . . . . . . . . . .  5
-     2.1.  Expected Deployment Scenarios  . . . . . . . . . . . . . .  5
-       2.1.1.  Zone Size Constraints  . . . . . . . . . . . . . . . .  5
-       2.1.2.  Name Server Discovery  . . . . . . . . . . . . . . . .  6
-       2.1.3.  Configuration Data Volatility  . . . . . . . . . . . .  6
-       2.1.4.  Protocol Selection . . . . . . . . . . . . . . . . . .  6
-       2.1.5.  Common Data Model  . . . . . . . . . . . . . . . . . .  6
-       2.1.6.  Operational Impact . . . . . . . . . . . . . . . . . .  7
-     2.2.  Name Server Types  . . . . . . . . . . . . . . . . . . . .  7
-   3.  Management Operation Types . . . . . . . . . . . . . . . . . .  7
-     3.1.  Control Requirements . . . . . . . . . . . . . . . . . . .  8
-       3.1.1.  Needed Control Operations  . . . . . . . . . . . . . .  8
-       3.1.2.  Asynchronous Status Notifications  . . . . . . . . . .  8
-     3.2.  Configuration Requirements . . . . . . . . . . . . . . . .  9
-       3.2.1.  Served Zone Modification . . . . . . . . . . . . . . .  9
-       3.2.2.  Trust Anchor Management  . . . . . . . . . . . . . . .  9
-       3.2.3.  Security Expectations  . . . . . . . . . . . . . . . .  9
-       3.2.4.  TSIG Key Management  . . . . . . . . . . . . . . . . .  9
-       3.2.5.  DNS Protocol Authorization Management  . . . . . . . .  9
-     3.3.  Monitoring Requirements  . . . . . . . . . . . . . . . . . 10
-     3.4.  Alarm and Event Requirements . . . . . . . . . . . . . . . 10
-   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 11
-     4.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 11
-     4.2.  Integrity Protection . . . . . . . . . . . . . . . . . . . 11
-     4.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 11
-     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 11
-     4.5.  Solution Impacts on Security . . . . . . . . . . . . . . . 12
-   5.  Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . 12
-       5.1.1.  Vendor Extensions  . . . . . . . . . . . . . . . . . . 13
-       5.1.2.  Extension Identification . . . . . . . . . . . . . . . 13
-       5.1.3.  Name-Space Collision Protection  . . . . . . . . . . . 13
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 2]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   8.  Document History . . . . . . . . . . . . . . . . . . . . . . . 13
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
-   Appendix A.  Deployment Scenarios  . . . . . . . . . . . . . . . . 15
-     A.1.  Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
-     A.2.  Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
-     A.3.  DNSSEC Management  . . . . . . . . . . . . . . . . . . . . 16
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 3]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-1.  Introduction
-
-   Management of name servers for the Domain Name Service (DNS)
-   [RFC1034] [RFC1035] has traditionally been done using vendor-specific
-   monitoring, configuration and control methods.  Although some service
-   monitoring platforms can test the functionality of the DNS itself
-   there is not a interoperable way to manage (monitor, control and
-   configure) the internal aspects of a name server itself.
-
-   Previous standardization work within the IETF resulted in the
-   creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
-   to achieve significant implementation and deployment.  The perceived
-   reasons behind the failure for the two MIB modules are further
-   documented in [RFC3197].
-
-   This document discusses the requirements of a management system for
-   DNS name servers.  A management solution that is designed to manage
-   the DNS can use this document as a shopping list of needed features.
-
-   Specifically out of scope for this document are requirements
-   associated with management of stub resolvers.  It is not the intent
-   of this document to document stub resolver requirements, although
-   some of the requirements listed are applicable to stub resolvers as
-   well.
-
-   Also out of scope for this document is management of the host or
-   other components of the host upon which the name server software is
-   running.  This document only discusses requirements for managing the
-   name server component of a system.
-
-   The task of creating a management system for managing DNS servers is
-   not expected to be a small one.  It is likely that components of the
-   solution will need to be designed in parts over time and these
-   requirements take this into consideration.  In particular,
-   Section 5.1 discusses the need for future extensibility of the base
-   management solution.  This document is intended to be a road-map
-   towards a desired outcome and is not intended to define an "all-or-
-   nothing" system.  Successful interoperable management of name servers
-   even in part is expected to be beneficial to network operators
-   compared to the entirely custom solutions that are used at the time
-   of this writing.
-
-1.1.  Requirements notation
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 4]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-1.1.1.  Terminology
-
-   This document is consistent with the terminology defined in Section 2
-   of [RFC4033].  Additional terminology needed for this document is
-   described below:
-
-   Name Server:  When we are discussing servers that don't fall into a
-      more specific type of server category defined in other documents,
-      this document will refer to them generically as "name servers".
-      In particular "name servers" can be considered to be any valid
-      combination of authoritative, recursive, validating, or security-
-      aware.  The more specific name server labels will be used when
-      this document refers only to a specific type of server.  However,
-      the term "name server", in this document, will not include stub
-      resolvers.
-
-1.1.2.  Document Layout and Requirements
-
-   The document is written so that each numbered section will contain
-   only a single requirement if it contains one at all.  Each
-   requirement will contain needed wording from the terminology
-   described in Section 1.1.  Subsections, however, might exist with
-   additional related requirements.  The document is laid out in this
-   way so that a specific requirement can be uniquely referred to using
-   the section number itself and the document version from which it
-   came.
-
-
-2.  Management Architecture Requirements
-
-   This section discusses requirements that reflect the needs of the
-   expected deployment environments.
-
-2.1.  Expected Deployment Scenarios
-
-   DNS zones vary greatly in the type of content published within them.
-   Name Servers, too, are deployed with a wide variety of configurations
-   to support the diversity of the deployed content.  It is important
-   that a management solution trying to meet the criteria specified in
-   this document consider supporting the largest number of potential
-   deployment cases as possible.  Further deployment scenarios that are
-   not used as direct examples of specific requirements are listed in
-   Appendix A.
-
-2.1.1.  Zone Size Constraints
-
-   The management solution MUST support both name servers that are
-   serving a small number of potentially very large zones (e.g.  Top
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 5]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   Level Domains (TLDs)) as well as name servers that are serving a very
-   large number of small zones.  These scenarios are both commonly seen
-   deployments.
-
-2.1.2.  Name Server Discovery
-
-   Large enterprise network deployments may contain multiple name
-   servers operating within the boundaries of the enterprise network.
-   These name servers may each be serving multiple zones both in and out
-   of the parent enterprise's zone.  Finding and managing large
-   quantities of name servers would be a useful feature of the resulting
-   management solution.  The management solution MAY support the ability
-   to discover previously unknown instances of name servers operating
-   within a deployed network.
-
-2.1.3.  Configuration Data Volatility
-
-   Configuration data is defined as data that relates only to the
-   configuration of a server and the zones it serves.  It specifically
-   does not include data from the zone contents that is served through
-   DNS itself.  The solution MUST support servers that remain fairly
-   statically configured over time as well as servers that have numerous
-   zones being added and removed within an hour.  Both of these
-   scenarios are also commonly seen deployments.
-
-2.1.4.  Protocol Selection
-
-   There are many requirements in this document for many different types
-   of management operations (see Section 3 for further details).  It is
-   possible that no one protocol will ideally fill all the needs of the
-   requirements listed in this document and thus multiple protocols
-   might be needed to produce a completely functional management system.
-   Multiple protocols might be used to create the complete management
-   solution, but the number of protocols used SHOULD be reduced to a
-   reasonable minimum number.
-
-2.1.5.  Common Data Model
-
-   Defining a standardized protocol (or set of protocols) to use for
-   managing name servers would be a step forward in achieving an
-   interoperable management solution.  However, just defining a protocol
-   to use by itself would not achieve the complete end goal of a
-   complete interoperable management solution.  Devices also need to
-   represent their internal management interface using a common
-   management data model.  The solution MUST create a common data model
-   that management stations can make use of when sending or collecting
-   data from a managed device so it can successfully manage equipment
-   from vendors as if they were generic DNS servers.  This common data
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 6]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   model is needed for of the operations discussion in Section 3.  Note
-   that this does not preclude the fact that name server vendors might
-   provide additional management infrastructure beyond a base management
-   specification, as discussed further in Section 5.1.
-
-2.1.6.  Operational Impact
-
-   It is impossible to add new features to an existing server (such as
-   the inclusion of a management infrastructure) and not impact the
-   existing service and/or server in some fashion.  At a minimum, for
-   example, more memory, disk and/or CPU resources will be required to
-   implement a new management system.  However, the impact to the
-   existing DNS service MUST be minimized since the DNS service itself
-   is still the primary service to be offered by the modified name
-   server.
-
-2.2.  Name Server Types
-
-   There are multiple ways in which name servers can be deployed.  Name
-   servers can take on any of the following roles:
-
-   o  Master Servers
-
-   o  Slave Servers
-
-   o  Recursive Servers
-
-   The management solution SHOULD support all of these types of name
-   servers as they are all equally important.  Note that "Recursive
-   Servers" can be further broken down by the security sub-roles they
-   might implement, as defined in section 2 of [RFC4033].  These sub-
-   roles are also important to support within any management solution.
-
-   As stated earlier, the management of stub resolvers is considered out
-   of scope for this documents.
-
-
-3.  Management Operation Types
-
-   Management operations can traditionally be broken into four
-   categories:
-
-   o  Control
-
-   o  Configuration
-
-   o  Health and Monitoring
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 7]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   o  Alarms and Events
-
-   This section discusses requirements for each of these four management
-   types in detail.
-
-3.1.  Control Requirements
-
-   The management solution MUST be capable of performing basic service
-   control operations.
-
-3.1.1.  Needed Control Operations
-
-   These operations SHOULD include, at a minimum, the following
-   operations:
-
-   o  Starting the name server
-
-   o  Reloading the service configuration
-
-   o  Reloading zone data
-
-   o  Restarting the name server
-
-   o  Stopping the name server
-
-   Note that no restriction is placed on how the management system
-   implements these operations.  In particular, at least "starting the
-   name server" will require a minimal management system component to
-   exist independently of the name server itself.
-
-3.1.2.  Asynchronous Status Notifications
-
-   Some control operations might take a long time to complete.  As an
-   example, some name servers take a long time to perform reloads of
-   large zones.  Because of these timing issues, the management solution
-   SHOULD take this into consideration and offer a mechanism to ease the
-   burden associated with awaiting the status of a long-running command.
-   This could, for example, result in the use of asynchronous
-   notifications for returning the status of a long-running task or it
-   might require the management station to poll for the status of a
-   given task using monitoring commands.  These and other potential
-   solutions need to be evaluated carefully to select one that balances
-   the result delivery needs with the perceived implementation costs.
-
-   Also, see the related discussion in Section 3.4 on notification
-   messages for supporting delivery of alarm and event messages.
-
-
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 8]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-3.2.  Configuration Requirements
-
-   Many features of name servers need to be configured before the server
-   can be considered functional.  The management solution MUST be able
-   to provide name servers with configuration data.  The most important
-   data to be configured, for example, is the served zone data itself.
-
-3.2.1.  Served Zone Modification
-
-   The ability to add, modify and delete zones being served by name
-   servers is needed.  Although there are already solutions for zone
-   content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
-   AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
-   might be used as part of the final management solution, the
-   management system SHOULD still be able to natively create a new zone
-   (with enough minimal data to allow the other mechanisms to function
-   as well) as well as delete a zone.  This might be, for example, a
-   management operation that at least allows for the creation of the
-   initial SOA record for a new zone as that's the minimum amount of
-   zone data needed for the other operations to function.
-
-3.2.2.  Trust Anchor Management
-
-   The solution SHOULD support the ability to add, modify and delete
-   trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
-   [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155].  These trust
-   anchors might be configured using the data from the DNSKEY Resource
-   Records (RRs) themselves or by using Delegation Signer (DS)
-   fingerprints.
-
-3.2.3.  Security Expectations
-
-   DNSSEC Validating resolvers need to make policy decisions about the
-   requests being processed.  For example, they need to be configured
-   with a list of zones expected to be secured by DNSSEC.  The
-   management solution SHOULD be able to add, modify and delete
-   attributes of DNSSEC security policies.
-
-3.2.4.  TSIG Key Management
-
-   TSIG [RFC2845] allows transaction level authentication of DNS
-   traffic.  The management solution SHOULD be able to add, modify and
-   delete TSIG keys known to the name server.
-
-3.2.5.  DNS Protocol Authorization Management
-
-   The management solution SHOULD have the ability to add, modify and
-   delete authorization settings for the DNS protocols itself.  Do not
-
-
-
-Hardaker                 Expires August 16, 2009                [Page 9]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   confuse this with the ability to manage the authorization associated
-   with the management protocol itself, which is discussed later in
-   Section 4.4.  There are a number of authorization settings that are
-   used by a name server.  Example authorization settings that the
-   solution might need to cover are:
-
-   o  Access to operations on zone data (e.g.  DDNS)
-
-   o  Access to certain zone data from certain sources (e.g. from
-      particular network subnets)
-
-   o  Access to specific DNS protocol services (e.g. recursive service)
-
-   Note: the above list is expected to be used as a collection of
-   examples and is not a complete list of needed authorization
-   protections.
-
-3.3.  Monitoring Requirements
-
-   Monitoring is the process of collecting aspects of the internal state
-   of a name server at a given moment in time.  The solution MUST be
-   able to monitor the health of a name server to determine its
-   operational status, load and other internal attributes.  Example
-   management tasks that the solution might need to cover are:
-
-   o  Number of requests sent, responses sent, average response latency
-      and other performance counters
-
-   o  Server status (e.g. "serving data", "starting up", "shutting
-      down", ...)
-
-   o  Access control violations
-
-   o  List of zones being served
-
-   o  Detailed statistics about clients interacting with the name server
-      (e.g. top 10 clients requesting data).
-
-   Note: the above list is expected to be used as a collection of
-   examples and is not a complete list of needed monitoring operations.
-   In particular, some monitoring statistics are expected to be
-   computationally or resource expensive and are considered to be "nice
-   to haves" as opposed to "necessary to have".
-
-3.4.  Alarm and Event Requirements
-
-   Events occurring at the name server that trigger alarm notifications
-   can quickly inform a management station about critical issues.  A
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 10]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   management solution SHOULD include support for delivery of alarm
-   conditions.
-
-   Example alarm conditions might include:
-
-   o  The server's status is changing. (e.g it is starting up, reloading
-      configuration, restarting or shutting down)
-
-   o  A needed resource (e.g. memory or disk space) is exhausted or
-      nearing exhaustion
-
-   o  An authorization violation was detected
-
-   o  The server has not received any data traffic (e.g.  DNS requests
-      or NOTIFYs) recently (AKA the "lonely warning").  This condition
-      might indicate a problem with its deployment.
-
-
-4.  Security Requirements
-
-   The management solution will need to be appropriately secured against
-   attacks on the management infrastructure.
-
-4.1.  Authentication
-
-   The solution MUST support mutual authentication.  The management
-   client needs to be assured that the management operations are being
-   transferred to and from the correct name server.  The managed name
-   server needs to authenticate the system that is accessing the
-   management infrastructure within itself.
-
-4.2.  Integrity Protection
-
-   Management operations MUST be protected from modification while in
-   transit from the management client to the server.
-
-4.3.  Confidentiality
-
-   The management solution MUST support message confidentiality.  The
-   potential transfer of sensitive configuration is expected (such as
-   TSIG keys or security policies).  The solution does not, however,
-   necessarily need to provide confidentiality to data that would
-   normally be carried without confidentiality by the DNS system itself.
-
-4.4.  Authorization
-
-   The solution SHOULD be capable of providing a fine-grained
-   authorization model for any management protocols it introduces to the
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 11]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   completed system.  This authorization differs from the authorization
-   previously discussed in Section 3.2.5 in that this requirement is
-   concerned solely with authorization of the management system itself.
-
-   There are a number of authorization settings that might be used by a
-   managed system to determine whether the managing entity has
-   authorization to perform the given management task.  Example
-   authorization settings that the solution might need to cover are:
-
-   o  Access to the configuration that specifies which zones are to be
-      served
-
-   o  Access to the management system infrastructure
-
-   o  Access to other control operations
-
-   o  Access to other configuration operations
-
-   o  Access to monitoring operations
-
-   Note: the above list is expected to be used as a collection of
-   examples and is not a complete list of needed authorization
-   protections.
-
-4.5.  Solution Impacts on Security
-
-   The solution MUST minimize the security risks introduced to the
-   complete name server system.  It is impossible to add new
-   infrastructure to a server and not impact the security in some
-   fashion as the introduction of a management protocol alone will
-   provide a new avenue for potential attack.  Although the added
-   management benefits will be worth the increased risks, the solution
-   still needs to minimize this impact as much as possible.
-
-
-5.  Other Requirements
-
-5.1.  Extensibility
-
-   The management solution is expected to change and expand over time as
-   lessons are learned and new DNS features are deployed.  Thus, the
-   solution MUST be flexible and be able to accommodate new future
-   management operations.  The solution might, for example, make use of
-   protocol versioning or capability description exchanges to ensure
-   that management stations and name servers that weren't written to the
-   same specification version can still interoperate to the best of
-   their combined ability.
-
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 12]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-5.1.1.  Vendor Extensions
-
-   It MUST be possible for vendors to extend the standardized management
-   model with vendor-specific extensions to support additional features
-   offered by their products.
-
-5.1.2.  Extension Identification
-
-   It MUST be possible for a management station to understand which
-   parts of returned data are specific to a given vendor or other
-   standardized extension.  The data returned needs to be appropriately
-   marked through the use of name spaces or similar mechanisms to ensure
-   that the base management model data can be logically separated from
-   extension data without needing to understand the extension data
-   itself.
-
-5.1.3.  Name-Space Collision Protection
-
-   It MUST be possible to protect against multiple extensions
-   conflicting with each other.  The use of name-space protection
-   mechanisms for communicated management variables is common practice
-   to protect against problems.  Name-space identification techniques
-   also frequently solve the "Extension Identification" requirement
-   discussed in Section 5.1.2 as well.
-
-
-6.  Security Considerations
-
-   Any management protocol that meets the criteria discussed in this
-   document needs to support the criteria discussed in Section 4 in
-   order to protect the management infrastructure itself.  The DNS is a
-   core Internet service and management traffic that protects it could
-   be the target of attacks designed to subvert that service.  Because
-   the management infrastructure will be adding additional interfaces to
-   that service, it is critical that the management infrastructure
-   support adequate protections against network attacks.
-
-
-7.  IANA Considerations
-
-   No action is required from IANA for this document.
-
-
-8.  Document History
-
-   A requirement gathering discussion was held at the December 2007 IETF
-   meeting in Vancouver, BC, Canada and a follow up meeting was held at
-   the March 2008 IETF meeting in Philadelphia.  This document is a
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 13]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   compilation of the results of those discussions as well as
-   discussions on the DCOMA mailing list.
-
-
-9.  Acknowledgments
-
-   This draft is the result of discussions within the DCOMA design team
-   chaired by Jaap Akkerhuis.  This team consisted of a large number of
-   people all of whom provided valuable insight and input into the
-   discussions surrounding name server management.  The text of this
-   document was written from notes taken during meetings as well as from
-   contributions sent to the DCOMA mailing list.  This work documents
-   the consensus of the DCOMA design team.
-
-   In particular, the following team members contributed significantly
-   to the text in the document:
-
-      Stephane Bortzmeyer
-
-      Stephen Morris
-
-      Phil Regnauld
-
-   Further editing contributions and wording suggestions were made by:
-   Alfred Hoenes.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 14]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
-              Trust Anchors", RFC 5011, September 2007.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-10.2.  Informative References
-
-   [RFC1611]  Austein, R. and J. Saperia, "DNS Server MIB Extensions",
-              RFC 1611, May 1994.
-
-   [RFC1612]  Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
-              RFC 1612, May 1994.
-
-   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
-              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
-              July 1997.
-
-   [RFC3197]  Austein, R., "Applicability Statement for DNS MIB
-              Extensions", RFC 3197, November 2001.
-
-
-Appendix A.  Deployment Scenarios
-
-   This appendix documents some additional deployment scenarios that
-   have been traditionally difficult to manage.  They are provided as
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 15]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   guidance to protocol developers as data points of real-world name
-   server management problems.
-
-A.1.  Non-Standard Zones
-
-   If an organization uses non-standard zones (for example a purely-
-   local TLD), synchronizing all the name servers for these zones is
-   usually a time-consuming task.  It is made worse when two
-   organizations with conflicting zones merge.  This situation is not a
-   recommended deployment scenario (and is even heavily discouraged) but
-   it is, unfortunately, seen in the wild.
-
-   It is typically implemented using "forwarding" zones.  But there is
-   no way to ensure automatically that all the resolvers have the same
-   set of zones to forward at any given time.  New zones might be added
-   to a local forwarding recursive server, for example, without
-   modifying the rest of the deployed forwarding servers.  It is hoped
-   that a management solution which could handle the configuration of
-   zone forwarding would finally allow management of servers deployed in
-   this fashion.
-
-A.2.  Redundancy Sharing
-
-   For reliability reasons it is recommended that zone operators follow
-   the guidelines documented in [RFC2182] which recommends that multiple
-   name servers be configured for each zone and that the name servers
-   are separated both physically and via connectivity routes.  A common
-   solution is to establish DNS-serving partnerships: "I'll host your
-   zones and you'll host mine".  Both entities benefit from increased
-   DNS reliability via the wider service distribution.  This frequently
-   occurs between cooperating but otherwise unrelated entities (such as
-   between two distinct companies) as well as between affiliated
-   organizations (such as between branch offices within a single
-   company).
-
-   The configuration of these relationships are currently required to be
-   manually configured and maintained.  Changes to the list of zones
-   that are cross-hosted are manually negotiated between the cooperating
-   network administrators and configured by hand.  A management protocol
-   with the ability to provide selective authorization, as discussed in
-   Section 4.4, would solve many of the management difficulties between
-   cooperating organizations.
-
-A.3.  DNSSEC Management
-
-   There are many different DNSSEC deployment strategies that may be
-   used for mission-critical zones.  The following list describes some
-   example deployment scenarios that might warrant different management
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 16]
-
-Internet-Draft     Name Server Management Requirements     February 2009
-
-
-   strategies.
-
-      All contents and DNSSEC keying information controlled and operated
-      by a single organization
-
-      Zone contents controlled and operated by one organization, all
-      DNSSEC keying information controlled and operated by a second
-      organization.
-
-      Zone contents controlled and operated by one organization, zone
-      signing keys (ZSKs) controlled and operated by a second
-      organization, and key signing keys (KSKs) controlled and operated
-      by a third organization.
-
-   Although this list is not exhaustive in the potential ways that zone
-   data can be divided up, it should be sufficient to illustrate the
-   potential ways in which zone data can be controlled by multiple
-   entities.
-
-   The end result of all of these strategies, however, will be the same:
-   a live zone containing DNSSEC related resource records.  Many of the
-   above strategies are merely different ways of preparing a zone for
-   serving.  A management solution that includes support for managing
-   DNSSEC zone data may wish to take into account these potential
-   management scenarios.
-
-
-Author's Address
-
-   Wes Hardaker
-   Sparta, Inc.
-   P.O. Box 382
-   Davis, CA  95617
-   US
-
-   Phone: +1 530 792 1913
-   Email: ietf@hardakers.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 16, 2009               [Page 17]
-

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]
+

doc/draft/draft-ietf-dnsop-respsize-06.txt

@@ -1,640 +0,0 @@
-
-
-
-
-
-
-   DNSOP Working Group                                     Paul Vixie, ISC
-   INTERNET-DRAFT                                         Akira Kato, WIDE
-   <draft-ietf-dnsop-respsize-06.txt>                          August 2006
-
-                      DNS Referral Response Size Issues
-
-   Status of this Memo
-      By submitting this Internet-Draft, each author represents that any
-      applicable patent or other IPR claims of which he or she is aware
-      have been or will be disclosed, and any of which he or she becomes
-      aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-      Internet-Drafts are working documents of the Internet Engineering
-      Task Force (IETF), its areas, and its working groups.  Note that
-      other groups may also distribute working documents as Internet-
-      Drafts.
-
-      Internet-Drafts are draft documents valid for a maximum of six months
-      and may be updated, replaced, or obsoleted by other documents at any
-      time.  It is inappropriate to use Internet-Drafts as reference
-      material or to cite them other than as "work in progress."
-
-      The list of current Internet-Drafts can be accessed at
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-      The list of Internet-Draft Shadow Directories can be accessed at
-      http://www.ietf.org/shadow.html.
-
-   Copyright Notice
-
-      Copyright (C) The Internet Society (2006).  All Rights Reserved.
-
-
-
-
-                                    Abstract
-
-      With a mandated default minimum maximum message size of 512 octets,
-      the DNS protocol presents some special problems for zones wishing to
-      expose a moderate or high number of authority servers (NS RRs).  This
-      document explains the operational issues caused by, or related to
-      this response size limit, and suggests ways to optimize the use of
-      this limited space.  Guidance is offered to DNS server implementors
-      and to DNS zone operators.
-
-
-
-
-   Expires January 2007                                            [Page 1]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   1 - Introduction and Overview
-
-   1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
-   octets.  Even though this limitation was due to the required minimum IP
-   reassembly limit for IPv4, it became a hard DNS protocol limit and is
-   not implicitly relaxed by changes in transport, for example to IPv6.
-
-   1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
-   larger responses by mutual agreement of the requester and responder.
-   The 512 octet message size limit will remain in practical effect until
-   there is widespread deployment of EDNS0 in DNS resolvers on the
-   Internet.
-
-   1.3. Since DNS responses include a copy of the request, the space
-   available for response data is somewhat less than the full 512 octets.
-   Negative responses are quite small, but for positive and delegation
-   responses, every octet must be carefully and sparingly allocated.  This
-   document specifically addresses delegation response sizes.
-
-   2 - Delegation Details
-
-   2.1. RELEVANT PROTOCOL ELEMENTS
-
-   2.1.1. A delegation response will include the following elements:
-
-      Header Section: fixed length (12 octets)
-      Question Section: original query (name, class, type)
-      Answer Section: empty, or a CNAME/DNAME chain
-      Authority Section: NS RRset (nameserver names)
-      Additional Section: A and AAAA RRsets (nameserver addresses)
-
-   2.1.2. If the total response size exceeds 512 octets, and if the data
-   that does not fit was "required", then the TC bit will be set
-   (indicating truncation).  This will usually cause the requester to retry
-   using TCP, depending on what information was desired and what
-   information was omitted.  For example, truncation in the authority
-   section is of no interest to a stub resolver who only plans to consume
-   the answer section.  If a retry using TCP is needed, the total cost of
-   the transaction is much higher.  See [RFC1123 6.1.3.2] for details on
-   the requirement that UDP be attempted before falling back to TCP.
-
-   2.1.3. RRsets are never sent partially unless TC bit set to indicate
-   truncation.  When TC bit is set, the final apparent RRset in the final
-   non-empty section must be considered "possibly damaged" (see [RFC1035
-   6.2], [RFC2181 9]).
-
-
-
-   Expires January 2007                                            [Page 2]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   2.1.4. With or without truncation, the glue present in the additional
-   data section should be considered "possibly incomplete", and requesters
-   should be prepared to re-query for any damaged or missing RRsets.  Note
-   that truncation of the additional data section might not be signalled
-   via the TC bit since additional data is often optional (see discussion
-   in [RFC4472 B]).
-
-   2.1.5. DNS label compression allows a domain name to be instantiated
-   only once per DNS message, and then referenced with a two-octet
-   "pointer" from other locations in that same DNS message (see [RFC1035
-   4.1.4]).  If all nameserver names in a message share a common parent
-   (for example, all ending in ".ROOT-SERVERS.NET"), then more space will
-   be available for incompressable data (such as nameserver addresses).
-
-   2.1.6. The query name can be as long as 255 octets of network data.  In
-   this worst case scenario, the question section will be 259 octets in
-   size, which would leave only 240 octets for the authority and additional
-   sections (after deducting 12 octets for the fixed length header.)
-
-   2.2. ADVICE TO ZONE OWNERS
-
-   2.2.1. Average and maximum question section sizes can be predicted by
-   the zone owner, since they will know what names actually exist, and can
-   measure which ones are queried for most often.  Note that if the zone
-   contains any wildcards, it is possible for maximum length queries to
-   require positive responses, but that it is reasonable to expect
-   truncation and TCP retry in that case.  For cost and performance
-   reasons, the majority of requests should be satisfied without truncation
-   or TCP retry.
-
-   2.2.2. Some queries to non-existing names can be large, but this is not
-   a problem because negative responses need not contain any answer,
-   authority or additional records.  See [RFC2308 2.1] for more information
-   about the format of negative responses.
-
-   2.2.3. The minimum useful number of name servers is two, for redundancy
-   (see [RFC1034 4.1]).  A zone's name servers should be reachable by all
-   IP transport protocols (e.g., IPv4 and IPv6) in common use.
-
-   2.2.4. The best case is no truncation at all.  This is because many
-   requesters will retry using TCP immediately, or will automatically re-
-   query for RRsets that are possibly truncated, without considering
-   whether the omitted data was actually necessary.
-
-
-
-
-
-   Expires January 2007                                            [Page 3]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   2.3. ADVICE TO SERVER IMPLEMENTORS
-
-   2.3.1. In case of multi-homed name servers, it is advantageous to
-   include an address record from each of several name servers before
-   including several address records for any one name server.  If address
-   records for more than one transport (for example, A and AAAA) are
-   available, then it is advantageous to include records of both types
-   early on, before the message is full.
-
-   2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
-   class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
-   Each A RR will require 16 octets, and each AAAA RR will require 28
-   octets.
-
-   2.3.3. While DNS distinguishes between necessary and optional resource
-   records, this distinction is according to protocol elements necessary to
-   signify facts, and takes no official notice of protocol content
-   necessary to ensure correct operation.  For example, a nameserver name
-   that is in or below the zone cut being described by a delegation is
-   "necessary content," since there is no way to reach that zone unless the
-   parent zone's delegation includes "glue records" describing that name
-   server's addresses.
-
-   2.3.4. It is also necessary to distinguish between "explicit truncation"
-   where a message could not contain enough records to convey its intended
-   meaning, and so the TC bit has been set, and "silent truncation", where
-   the message was not large enough to contain some records which were "not
-   required", and so the TC bit was not set.
-
-   2.3.5. A delegation response should prioritize glue records as follows.
-
-   first
-      All glue RRsets for one name server whose name is in or below the
-      zone being delegated, or which has multiple address RRsets (currently
-      A and AAAA), or preferably both;
-
-   second
-      Alternate between adding all glue RRsets for any name servers whose
-      names are in or below the zone being delegated, and all glue RRsets
-      for any name servers who have multiple address RRsets (currently A
-      and AAAA);
-
-   thence
-      All other glue RRsets, in any order.
-
-
-
-
-   Expires January 2007                                            [Page 4]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   Whenever there are multiple candidates for a position in this priority
-   scheme, one should be chosen on a round-robin or fully random basis.
-
-   The goal of this priority scheme is to offer "necessary" glue first,
-   avoiding silent truncation for this glue if possible.
-
-   2.3.6. If any "necessary content" is silently truncated, then it is
-   advisable that the TC bit be set in order to force a TCP retry, rather
-   than have the zone be unreachable.  Note that a parent server's proper
-   response to a query for in-child glue or below-child glue is a referral
-   rather than an answer, and that this referral MUST be able to contain
-   the in-child or below-child glue, and that in outlying cases, only EDNS
-   or TCP will be large enough to contain that data.
-
-   3 - Analysis
-
-   3.1. An instrumented protocol trace of a best case delegation response
-   follows.  Note that 13 servers are named, and 13 addresses are given.
-   This query was artificially designed to exactly reach the 512 octet
-   limit.
-
-      ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
-      ;; QUERY SECTION:
-      ;;  [23456789.123456789.123456789.\
-           123456789.123456789.123456789.com A IN]        ;; @80
-
-      ;; AUTHORITY SECTION:
-      com.                 86400 NS  E.GTLD-SERVERS.NET.  ;; @112
-      com.                 86400 NS  F.GTLD-SERVERS.NET.  ;; @128
-      com.                 86400 NS  G.GTLD-SERVERS.NET.  ;; @144
-      com.                 86400 NS  H.GTLD-SERVERS.NET.  ;; @160
-      com.                 86400 NS  I.GTLD-SERVERS.NET.  ;; @176
-      com.                 86400 NS  J.GTLD-SERVERS.NET.  ;; @192
-      com.                 86400 NS  K.GTLD-SERVERS.NET.  ;; @208
-      com.                 86400 NS  L.GTLD-SERVERS.NET.  ;; @224
-      com.                 86400 NS  M.GTLD-SERVERS.NET.  ;; @240
-      com.                 86400 NS  A.GTLD-SERVERS.NET.  ;; @256
-      com.                 86400 NS  B.GTLD-SERVERS.NET.  ;; @272
-      com.                 86400 NS  C.GTLD-SERVERS.NET.  ;; @288
-      com.                 86400 NS  D.GTLD-SERVERS.NET.  ;; @304
-
-
-
-
-
-
-
-
-   Expires January 2007                                            [Page 5]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-      ;; ADDITIONAL SECTION:
-      A.GTLD-SERVERS.NET.  86400 A   192.5.6.30           ;; @320
-      B.GTLD-SERVERS.NET.  86400 A   192.33.14.30         ;; @336
-      C.GTLD-SERVERS.NET.  86400 A   192.26.92.30         ;; @352
-      D.GTLD-SERVERS.NET.  86400 A   192.31.80.30         ;; @368
-      E.GTLD-SERVERS.NET.  86400 A   192.12.94.30         ;; @384
-      F.GTLD-SERVERS.NET.  86400 A   192.35.51.30         ;; @400
-      G.GTLD-SERVERS.NET.  86400 A   192.42.93.30         ;; @416
-      H.GTLD-SERVERS.NET.  86400 A   192.54.112.30        ;; @432
-      I.GTLD-SERVERS.NET.  86400 A   192.43.172.30        ;; @448
-      J.GTLD-SERVERS.NET.  86400 A   192.48.79.30         ;; @464
-      K.GTLD-SERVERS.NET.  86400 A   192.52.178.30        ;; @480
-      L.GTLD-SERVERS.NET.  86400 A   192.41.162.30        ;; @496
-      M.GTLD-SERVERS.NET.  86400 A   192.55.83.30         ;; @512
-
-      ;; MSG SIZE  sent: 80  rcvd: 512
-
-   3.2. For longer query names, the number of address records supplied will
-   be lower.  Furthermore, it is only by using a common parent name (which
-   is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
-   fit, due to the use of DNS compression pointers in the last 12
-   occurances of the parent domain name.  The following output from a
-   response simulator demonstrates these properties.
-
-      % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
-      a.dns.br requires 10 bytes
-      b.dns.br requires 4 bytes
-      c.dns.br requires 4 bytes
-      d.dns.br requires 4 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 3 (yellow)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
-      For average size query (64 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 4 (green)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-
-
-
-
-
-
-
-
-
-   Expires January 2007                                            [Page 6]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
-      ns-ext.isc.org requires 16 bytes
-      ns.psg.com requires 12 bytes
-      ns.ripe.net requires 13 bytes
-      ns.eu.int requires 11 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 3 (yellow)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
-      For average size query (64 byte):
-          only A is considered:        # of A is 4 (green)
-          A and AAAA are considered:   # of A+AAAA is 4 (green)
-          preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-   (Note: The response simulator program is shown in Section 5.)
-
-   Here we use the term "green" if all address records could fit, or
-   "yellow" if two or more could fit, or "orange" if only one could fit, or
-   "red" if no address record could fit.  It's clear that without a common
-   parent for nameserver names, much space would be lost.  For these
-   examples we use an average/common name size of 15 octets, befitting our
-   assumption of GTLD-SERVERS.NET as our common parent name.
-
-   We're assuming a medium query name size of 64 since that is the typical
-   size seen in trace data at the time of this writing.  If
-   Internationalized Domain Name (IDN) or any other technology which
-   results in larger query names be deployed significantly in advance of
-   EDNS, then new measurements and new estimates will have to be made.
-
-   4 - Conclusions
-
-   4.1. The current practice of giving all nameserver names a common parent
-   (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
-   responses and allows for more nameservers to be enumerated than would
-   otherwise be possible, since the common parent domain name only appears
-   once in a DNS message and is referred to via "compression pointers"
-   thereafter.
-
-   4.2. If all nameserver names for a zone share a common parent, then it
-   is operationally advisable to make all servers for the zone thus served
-   also be authoritative for the zone of that common parent.  For example,
-   the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
-   for the ROOT-SERVERS.NET.  This is to ensure that the zone's servers
-   always have the zone's nameservers' glue available when delegating, and
-
-
-
-   Expires January 2007                                            [Page 7]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   will be able to respond with answers rather than referrals if a
-   requester who wants that glue comes back asking for it.  In this case
-   the name server will likely be a "stealth server" -- authoritative but
-   unadvertised in the glue zone's NS RRset.  See [RFC1996 2] for more
-   information about stealth servers.
-
-   4.3. Thirteen (13) is the effective maximum number of nameserver names
-   usable traditional (non-extended) DNS, assuming a common parent domain
-   name, and given that implicit referral response truncation is
-   undesirable in the average case.
-
-   4.4. Multi-homing of name servers within a protocol family is
-   inadvisable since the necessary glue RRsets (A or AAAA) are atomically
-   indivisible, and will be larger than a single resource record.  Larger
-   RRsets are more likely to lead to or encounter truncation.
-
-   4.5. Multi-homing of name servers across protocol families is less
-   likely to lead to or encounter truncation, partly because multiprotocol
-   clients are more likely to speak EDNS which can use a larger response
-   size limit, and partly because the resource records (A and AAAA) are in
-   different RRsets and are therefore divisible from each other.
-
-   4.6. Name server names which are at or below the zone they serve are
-   more sensitive to referral response truncation, and glue records for
-   them should be considered "less optional" than other glue records, in
-   the assembly of referral responses.
-
-   4.7. If a zone is served by thirteen (13) name servers having a common
-   parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
-   single address record in some protocol family (e.g., an A RR), then all
-   thirteen name servers or any subset thereof could multi-home in a second
-   protocol family by adding a second address record (e.g., an AAAA RR)
-   without reducing the reachability of the zone thus served.
-
-   5 - Source Code
-
-   #!/usr/bin/perl
-   #
-   # SYNOPSIS
-   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
-   #        if all queries are assumed to have a same zone suffix,
-   #     such as "jp" in JP TLD servers, specify it in -z option
-   #
-   use strict;
-   use Getopt::Std;
-
-
-
-   Expires January 2007                                            [Page 8]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   my ($sz_msg) = (512);
-   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
-   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
-   my (%namedb, $name, $nssect, %opts, $optz);
-   my $n_ns = 0;
-
-   getopt('z', %opts);
-   if (defined($opts{'z'})) {
-       server_name_len($opts{'z'}); # just register it
-   }
-
-   foreach $name (@ARGV) {
-       my $len;
-       $n_ns++;
-       $len = server_name_len($name);
-       print "$name requires $len bytes\n";
-       $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
-               +  $sz_rdlen + $len;
-   }
-   print "# of NS: $n_ns\n";
-   arsect(255, $nssect, $n_ns, "maximum");
-   arsect(64, $nssect, $n_ns, "average");
-
-   sub server_name_len {
-       my ($name) = @_;
-       my (@labels, $len, $n, $suffix);
-
-       $name =~ tr/A-Z/a-z/;
-       @labels = split(/\./, $name);
-       $len = length(join('.', @labels)) + 2;
-       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
-           $suffix = join('.', @labels);
-           return length($name) - length($suffix) + $sz_ptr
-               if (defined($namedb{$suffix}));
-           $namedb{$suffix} = 1;
-       }
-       return $len;
-   }
-
-   sub arsect {
-       my ($sz_query, $nssect, $n_ns, $cond) = @_;
-       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
-       $ansect = $sz_query + 1 + $sz_type + $sz_class;
-       $space = $sz_msg - $sz_header - $ansect - $nssect;
-       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-
-
-
-   Expires January 2007                                            [Page 9]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-       $n_a_aaaa = atmost(int($space
-                              / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
-       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
-                              / $sz_rr_aaaa), $n_ns);
-       printf "For %s size query (%d byte):\n", $cond, $sz_query;
-       printf "    only A is considered:        ";
-       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
-       printf "    A and AAAA are considered:   ";
-       printf "# of A+AAAA is %d (%s)\n",
-              $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-       printf "    preferred-glue A is assumed: ";
-       printf "# of A is %d, # of AAAA is %d (%s)\n",
-           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
-   }
-
-   sub judge {
-       my ($n, $n_ns) = @_;
-       return "green" if ($n >= $n_ns);
-       return "yellow" if ($n >= 2);
-       return "orange" if ($n == 1);
-       return "red";
-   }
-
-   sub atmost {
-       my ($a, $b) = @_;
-       return 0 if ($a < 0);
-       return $b if ($a > $b);
-       return $a;
-   }
-
-   6 - Security Considerations
-
-   The recommendations contained in this document have no known security
-   implications.
-
-   7 - IANA Considerations
-
-   This document does not call for changes or additions to any IANA
-   registry.
-
-   8 - Acknowledgement
-
-   The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
-   for their valuable comments and suggestions.
-
-
-
-
-   Expires January 2007                                           [Page 10]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   This work was supported by the US National Science Foundation (research
-   grant SCI-0427144) and DNS-OARC.
-
-   9 - References
-
-   [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
-      RFC1034, November 1987.
-
-   [RFC1035] Mockapetris, P.V., "Domain names - Implementation and
-      Specification", RFC1035, November 1987.
-
-   [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
-      Application and Support", RFC1123, October 1989.
-
-   [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
-      Changes (DNS NOTIFY)", RFC1996, August 1996.
-
-   [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
-      RFC2181, July 1997.
-
-   [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-      RFC2308, March 1998.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
-      August 1999.
-
-   [RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
-      and Issues with IPV6 DNS", April 2006.
-
-   10 - Authors' Addresses
-
-   Paul Vixie
-      Internet Systems Consortium, Inc.
-      950 Charter Street
-      Redwood City, CA 94063
-      +1 650 423 1301
-      vixie@isc.org
-
-   Akira Kato
-      University of Tokyo, Information Technology Center
-      2-11-16 Yayoi Bunkyo
-      Tokyo 113-8658, JAPAN
-      +81 3 5841 2750
-      kato@wide.ad.jp
-
-
-
-
-   Expires January 2007                                           [Page 11]
-
-   INTERNET-DRAFT                 August 2006                      RESPSIZE
-
-
-   Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors retain
-   all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-   IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-   Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in this
-   document or the extent to which any license under such rights might or
-   might not be available; nor does it represent that it has made any
-   independent effort to identify any such rights.  Information on the
-   procedures with respect to rights in RFC documents can be found in BCP
-   78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an attempt
-   made to obtain a general license or permission for the use of such
-   proprietary rights by implementers or users of this specification can be
-   obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary rights
-   that may cover technology that may be required to implement this
-   standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-   Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-   Expires January 2007                                           [Page 12]
-
-

doc/draft/draft-ietf-dnsop-serverid-04.txt

@@ -0,0 +1,616 @@
+
+
+Network Working Group                                           S. Woolf
+Internet-Draft                         Internet Systems Consortium, Inc.
+Expires: September 14, 2005                                    D. Conrad
+                                                           Nominum, Inc.
+                                                          March 13, 2005
+
+
+                Identifying an Authoritative Name Server
+                      draft-ietf-dnsop-serverid-04
+
+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 September 14, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+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
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 1]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+   query would be useful, particularly as a diagnostic aid.  Existing ad
+   hoc mechanisms for addressing this concern are not adequate.  This
+   document attempts to describe the common ad hoc solution to this
+   problem, including its advantages and disadvantages, and to
+   characterize an improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 2]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+1.  Introduction
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  A standardized mechanism to
+   determine the identity of a name server responding to a particular
+   query would be useful, particularly as a diagnostic aid.
+
+   Unfortunately, existing ad-hoc mechanisms for providing such
+   identification have some shortcomings, not the least of which is the
+   lack of prior analysis of exactly how such a mechanism should be
+   designed and deployed.  This document describes the existing
+   convention used in one widely deployed implementation of the DNS
+   protocol and discusses requirements for an improved solution to the
+   problem.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 3]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+2.  Rationale
+
+   Identifying which name server is responding to queries is often
+   useful, particularly in attempting to diagnose name server
+   difficulties.  However, relying on the IP address of the name server
+   has become more problematic due the deployment of various load
+   balancing solutions, including the use of shared unicast addresses as
+   documented in [RFC3258].
+
+   An unfortunate side effect of these load balancing solutions, and
+   some changes in management practices as the public Internet has
+   evolved, is that traditional methods of determining which server is
+   responding can be unreliable.  Specifically, non-DNS methods such as
+   ICMP ping, TCP connections, or non-DNS UDP packets (such as those
+   generated by tools such as "traceroute"), etc., can end up going to a
+   different server than that 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 my query".  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 14, 2005               [Page 4]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+3.  Existing Conventions
+
+   Recent versions of the commonly deployed Berkeley Internet Name
+   Domain implementation of the DNS protocol suite from the Internet
+   Software Consortium [BIND] support a way of identifying a particular
+   server via the use of a standard, if somewhat unusual, DNS query.
+   Specifically, a query to a late model BIND server for a TXT resource
+   record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
+   return a string that can be configured by the name server
+   administrator to provide a unique identifier for the responding
+   server (defaulting to the value of a gethostname() call).  This
+   mechanism, which is an extension of the BIND convention of using
+   CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
+   version information, has been copied by several name server vendors.
+
+   For reference, the other well-known name used by recent versions of
+   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
+   query for a TXT RR for this name will return an administratively
+   defined string which defaults to the version of the server
+   responding.  This is, however, not generally implemented by other
+   vendors.
+
+3.1  Advantages
+
+   There are several valuable attributes to this mechanism, which
+   account for its usefulness.
+   1.  The "hostname.bind" 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 machine 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 does not require
+       any special exceptions to site security policy.
+   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.
+
+3.2  Disadvantages
+
+   At the same time, there are some forbidding drawbacks to the
+   VERSION.BIND mechanism that argue against standardizing it as it
+   currently operates.
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 5]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+   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.  It 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.
+
+   The first of the listed disadvantages is technically the most
+   serious.  It argues for an attempt to design a good answer to the
+   problem that "I need to know what nameserver is answering my
+   queries", not simply a convenient one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 6]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+4.  Characteristics of an Implementation Neutral Convention
+
+   The discussion above of advantages and disadvantages to the
+   HOSTNAME.BIND mechanism suggest some requirements for a better
+   solution to the server identification problem.  These are summarized
+   here as guidelines for any effort to provide appropriate protocol
+   extensions:
+   1.  The mechanism adopted MUST be in-band for the DNS protocol.  That
+       is, it needs to allow the query for the server's identifying
+       information to be part of a normal, operational query.  It SHOULD
+       also permit a separate, dedicated query for the server's
+       identifying information.
+   2.  The new mechanism SHOULD not require dedicated namespaces or
+       other reserved values outside of the existing protocol mechanisms
+       for these, i.e.  the OPT pseudo-RR.  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.  The identification mechanism SHOULD NOT be
+       implementation-specific.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 7]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+5.  IANA Considerations
+
+   This document proposes no specific IANA action.  Protocol extensions,
+   if any, to meet the requirements described are out of scope for this
+   document.  Should such extensions be specified and adopted by normal
+   IETF process, the specification will include appropriate guidance to
+   IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 8]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+6.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005               [Page 9]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 2005
+
+
+7.  Acknowledgements
+
+   The technique for host identification documented here was initially
+   implemented by Paul Vixie of the Internet Software Consortium in the
+   Berkeley Internet Name Daemon package.  Comments and questions on
+   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+   ICANN Root Server System Advisory Committee.  The newest 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005              [Page 10]
+
+Internet-Draft    Identifying an Authoritative Name Server    March 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.
+
+
+
+
+Woolf & Conrad         Expires September 14, 2005              [Page 11]
+
+

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]
+

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

doc/draft/draft-kerr-ixfr-only-01.txt

@@ -1,336 +0,0 @@
-
-
-
-DNSext Working Group                                             O. Sury
-Internet-Draft                                                    CZ.NIC
-Updates: 1995 (if approved)                                 S. Kerr, Ed.
-Intended status: Standards Track                                     ISC
-Expires: August 30, 2010                               February 26, 2010
-
-
-               IXFR-ONLY to Prevent IXFR Fallback to AXFR
-                        draft-kerr-ixfr-only-01
-
-Abstract
-
-   This documents proposes a new QTYPE (Query pseudo RRtype) for the
-   Domain Name System (DNS).  IXFR-ONLY is a variant of IXFR (RFC 1995)
-   that allows an authoritative server to incrementally update zone
-   content from another (primary) server without falling back from IXFR
-   to AXFR.  This way, alternate peers can be contacted more quickly and
-   convergence of zone content may be achieved much faster in important,
-   resilient operational scenarios.
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and 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 30, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 1]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
-   2.  IXFR Server Side  . . . . . . . . . . . . . . . . . . . . . . . 4
-   3.  IXFR Client Side  . . . . . . . . . . . . . . . . . . . . . . . 4
-   4.  Applicability of IXFR-ONLY  . . . . . . . . . . . . . . . . . . 5
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 2]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-1.  Introduction
-
-   For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
-   Transfer (IXFR), which allows only to transfer the changed portion(s)
-   of a zone.
-
-   In the document, an IXFR client and an IXFR server is defined as in
-   RFC 1995 [RFC1995], a secondary name server which requests IXFR is
-   called an IXFR client and a primary or secondary name server which
-   responds to the request is called an IXFR server.
-
-   IXFR is an efficient way to transfer changes in zones from IXFR
-   servers to IXFR clients.  However, when an IXFR client has multiple
-   IXFR servers for a single zone, it is possible that not all IXFR
-   servers have the zone with same serial number for that zone.  In this
-   case, if an IXFR client attempts an IXFR from an IXFR server which
-   does not have zone with the serial number used by the IXFR client,
-   the IXFR server will fall back to a full zone transfer (AXFR) when it
-   has a version of the zone with serial number greater than the serial
-   requested by the IXFR client.
-
-   For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
-   a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
-   same zone.  An IXFR client that has the zone with serial number 2
-   which sends an IXFR request to IXFR server NS2 will get a full zone
-   transfer (AXFR) of the zone at serial number 3.  This is because NS2
-   does not know the zone with serial number 2, and therefore does not
-   know what the differences are between zone with serial number 2 and
-   3.
-
-   If the IXFR client in this example had known to send the query to
-   IXFR server NS1, then it could have gotten an incremental transfer
-   (IXFR).  But IXFR clients can only know what the latest version of
-   the zone is at a IXFR server (this information is available via an
-   SOA query).
-
-   The IXFR-ONLY query type provides a way for the IXFR client to ask
-   each IXFR server to return an error instead of sending the current
-   version of the zone via full zone transfer (AXFR).  By using this, a
-   IXFR client can check each IXFR server until it finds one able to
-   provide IXFR.
-
-1.1.  Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 3]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-2.  IXFR Server Side
-
-   A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
-   as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
-   for the serial number requested.
-
-   If the IXFR server is is not able to reply with an IXFR it MUST NOT
-   reply with an AXFR unless AXFR result is smaller than IXFR result.
-   Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
-
-   If the IXFR result is larger than an AXFR, then an IXFR server MAY
-   reply with an AXFR result instead.  This is an optimization, and IXFR
-   servers MAY only reply with AXFR if they are certain that the reply
-   using AXFR is smaller than an equivalent IXFR reply.
-
-
-3.  IXFR Client Side
-
-   An IXFR client who wishes to use IXFR-ONLY will send a message to one
-   of the IXFR servers.  The format is exactly the same as for IXFR,
-   except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
-   code.
-
-   If the IXFR server replies with IXFR, then the IXFR client is done.
-
-   If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
-   client proceeds on to a different IXFR server.  In this case the IXFR
-   server implements IXFR-ONLY, but does not have information about zone
-   with the serial number requested.
-
-   If the IXFR server replies with any RCODE other than CannotIXFR or
-   NoError, then the IXFR client proceeds on to a different IXFR server.
-   In this case the IXFR server does not implement IXFR-ONLY.
-
-   If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
-   them reply with an incremental transfer (IXFR), then it should
-   attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
-   IXFR servers which replied with an RCODE other than CannotIXFR or
-   NoError.
-
-   The method described above allows IXFR clients to operate normally in
-   situatians where some of the IXFR servers do support IXFR-ONLY, and
-   some who do not.  IXFR clients MAY remember which IXFR servers
-   support IXFR-ONLY and query those IXFR servers first.  However since
-   IXFR servers may change software or even run a mix of software, IXFR
-   clients MUST attempt to query each IXFR server periodically when they
-   attempt to get new versions of a zone.
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 4]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
-   given IXFR server, if this is known in advance.  These IXFR servers
-   are treated as if they replied with an RCODE other than CannotIXFR or
-   NoError, although no query with IXFR-ONLY is actually sent.
-
-
-4.  Applicability of IXFR-ONLY
-
-   Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
-   completely.
-
-   Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
-   specific zone.  This may be useful for small zones, where fallback to
-   AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
-
-   Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
-   servers, by shifting load to ones that support IXFR-ONLY.  If this a
-   problem, then administrators can disable IXFR-ONLY in implementations
-   that allow it.
-
-   If a IXFR client has a single IXFR server for a zone, it SHOULD use
-   IXFR rather than IXFR-ONLY.
-
-
-5.  IANA Considerations
-
-   IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
-   transfer only".  IANA allocates the CannotIXFR RCODE, which means
-   "Server cannot provide IXFR for zone".
-
-
-6.  Security Considerations
-
-   IXFR-ONLY may be used by someone to get information about the state
-   of IXFR servers by providing a quick and efficient way to check which
-   versions of a zone each IXFR server supports.  Zones should be
-   secured via TSIG [RFC2845] to prevent unauthorized information
-   exposure.  However, even administrators of IXFR servers may not want
-   this information given to IXFR clients, in which case they will need
-   to disable IXFR-ONLY.
-
-
-7.  Normative References
-
-   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 5]
-
-Internet-Draft                  IXFR-ONLY                  February 2010
-
-
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-
-Authors' Addresses
-
-   Ondrej Sury
-   CZ.NIC
-   Americka 23
-   120 00 Praha 2
-   CZ
-
-   Phone: +420 222 745 110
-   Email: ondrej.sury@nic.cz
-
-
-   Shane Kerr (editor)
-   ISC
-   Bennebrokestraat 17-I
-   1015 PE Amsterdam
-   NL
-
-   Phone: +31 64 6336297
-   Email: shane@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sury & Kerr              Expires August 30, 2010                [Page 6]
-

doc/draft/draft-mekking-dnsop-auto-cpsync-00.txt

@@ -1,336 +0,0 @@
-
-
-
-Domain Name System Operations                                 W. Mekking
-Internet-Draft                                                NLnet Labs
-Intended status: Standards Track                           June 29, 2010
-Expires: December 31, 2010
-
-
-    Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
-                   draft-mekking-dnsop-auto-cpsync-00
-
-Abstract
-
-   This document proposes a way to synchronise existing trust anchors
-   automatically between a child zone and its parent.  The algorithm can
-   be used for other Resource Records that are required to delegate from
-   a parent to a child such as NS and glue records.
-
-Requirements Language
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-Status of This Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   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."
-
-   This Internet-Draft will expire on December 31, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Mekking                 Expires December 31, 2010               [Page 1]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-1.  Introduction
-
-   This memo defines a way to synchronise existing trust anchors
-   automatically between a child zone and its parent.  The algorithm can
-   be used for other Resource Records that are required to delegate from
-   a parent to a child such as NS and glue records.
-
-   To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
-   must submit their DNSKEYs, or hashes of their DNSKEYs, to their
-   parent zone.  The parent zone publishes the hashes of the DNSKEYs in
-   the form of a DS record.  The DNSKEY RRset at the child may change
-   over time.  In order to keep the chain of trust intact, the DS
-   records at the parent zone also needs to be updated.  The rolling of
-   the keys with the SEP bit on is one of the few tasks in DNSSEC that
-   yet has to be fully automated.
-
-   The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
-   changes to the parent.
-
-   To bootstrap the direct communication channel, information must be
-   exchanged in order to detect service location and granting update
-   privileges.  A new or existing child zone can request a direct
-   communication channel with the parent.  If the parent allows for
-   direct communication with child zones, the parent can share the
-   required data to set up the channel to the child zone.  Once the
-   child has the required credentials, it can use the direct
-   communication channel with the parent to request zone changes related
-   to its delegation.
-
-   If a third party is involved, the third party can act on behalf of
-   the parent.  In this case, the third party will give out the required
-   credentials to set up the communication channel.
-
-   It is RECOMMENDED that the direct communication channel is secured
-   with TSIG [RFC2845] or SIG0 [RFC2931].
-
-2.  Access and Update Control
-
-   The DNS UPDATE normally is used for granting update permissions to a
-   machine that is within the boundary of the same organization.  This
-   document proposes to grant child zones the same permissions.
-   However, it MUST NOT be possible that a child zone updates
-
-
-
-Mekking                 Expires December 31, 2010               [Page 2]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   information in the parent zone that falls outside the administrative
-   domain of the corresponding delegation.  For example, it MUST NOT be
-   possible for a child zone to update the data that the parent is
-   authoritative for, or update a delegation that is pointed to a
-   different child zone.  It MUST only be able to update records that
-   match one of the following:
-
-   Or:   The owner name is equal the child zone name and RRtype is
-      delegation specific.  Currently those are records with RRtype NS
-      or DS.
-
-   Or:   The owner name is a subdomain of the child zone name and RRtype
-      is glue specific.  Currently those are records with RRtype A or
-      AAAA.
-
-   This list may be expanded in the future, if there is need for more
-   delegation related zone content.
-
-   In case of adding or deleting delegation specific records, the DNSSEC
-   related RRs in the parent zone might need to be updated.
-
-   The service location may be handed out by the registrar during
-   bootstrap If this information is missing, the normal guidelines for
-   sending DNS UPDATE messages SHOULD be followed.
-
-3.  Update Mechanism
-
-3.1.  Child Duties
-
-   Updating the NS RRset or corresponding glue at the parent, an update
-   can be sent at any time.  Updating the DS RRset is part of key
-   rollover, as described in RFC 4641 [RFC4641].  When performing a key
-   rollover that involves updating the RRset at the parent, the child
-   introduces a new DNSKEY in its zone that represents the security
-   entry point for determining the chain of trust.  After a while, it
-   will revoke and/or remove the previous security entry point.  The
-   timings when to update the DS RRset at the parent are described in
-   draft-dnsop-morris-dnssec-key-timing [keytiming].  When updating the
-   DS RRset at the parent automatically, these timing specifications
-   SHOULD be followed.  To determine the propagation delays described in
-   this document, the child should poll the parent zone for a short
-   time, until the DS is visible at all parent name servers.
-
-   To discuss: A child zone might be unable to reach all parent name
-   servers.
-
-   The child notifies the parent of the requested changes by sending a
-   DNS UPDATE message.  If it receives a NOERROR reply in return, the
-
-
-
-Mekking                 Expires December 31, 2010               [Page 3]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   update is acknowledged by the parent zone.  Otherwise, the child MAY
-   retry transmitting the update.  In order to prevent duplicate
-   updates, it SHOULD follow the guidelines described in RFC 2136
-   [RFC2136].
-
-3.2.  Parent Duties
-
-   When the master DNS server of the parent receives a DNS UPDATE from
-   one of its children the following must be done:
-
-   Step 1:  Check the TSIG/SIG0 credentials.  In case of TSIG, the
-      parent should follow the TSIG processing described in section 3.2
-      of RFC 2845.  In case of SIG0, the parent should follow the SIG0
-      processing described in section 3.2 of RFC 2931.
-
-   Step 2:  Verify that the updates matches the update policy for child
-      zones.
-
-   Step 3:  If verified, send back DNS UPDATE OK.  Otherwise, send back
-      DNS UPDATE REFUSED.
-
-   Step 4:  If verified, apply changes.  How that is done is a matter of
-      policy.
-
-3.3.  Proxy considerations
-
-   Some environments don't allow for direct communication between parent
-   and child zone.  In these case, the parent duties can be performed by
-   a different party (for example, the registar).  The third party will
-   forward the update to the parent zone.  In what format depends on
-   local policy.
-
-4.  Example BIND9 Configuration
-
-   This is how a parent zone can configure a policy to enable a child
-   zone synchronize delegation specific records.  The first rule of the
-   update policy grants children to update their DS and NS records in
-   the parent zone, in this case example.com.  The second rule of the
-   update policy grants children to update the corresponding glue
-   records.
-
-   key cs.example.com. {
-   algorithm HMAC-MD5;
-   secret "secretforcs";
-   }
-
-   key math.example.com. {
-   algorithm HMAC-MD5;
-
-
-
-Mekking                 Expires December 31, 2010               [Page 4]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-   secret "secretformath";
-   }
-
-   ...
-
-   zone "example.com" {
-   type master;
-   file "example.com";
-   update-policy { grant *.example.com. self *.example.com.  DS NS; };
-   update-policy { grant *.example.com. selfsub *.example.com.  A AAAA;
-   };
-   };
-
-5.  Security Considerations
-
-   Automating the synchronization of (DNSSEC) records between the parent
-   and child created a new channel.  We have recommended that this
-   channel should be secured with TSIG or SIG0.  There is an advantage
-   and a disadvantage of the new security channel.  The disadvantage is
-   that you create a new attack window for your DNSSEC credentials.  If
-   the automated synchronization is used for updating DS records at the
-   parent, you SHOULD pick a cryptographically an equally strong or
-   stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
-
-   The advantage is that if somehow your DNSSEC keys are compromised,
-   you can still use this channel to perform an emergency key rollover.
-
-6.  IANA Considerations
-
-   None.
-
-7.  Acknowledgments
-
-   Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
-
-8.  References
-
-8.1.  Informative References
-
-   [RFC2136]    Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-                "Dynamic Updates in the Domain Name System (DNS
-                UPDATE)", RFC 2136, April 1997.
-
-   [RFC4641]    Kolkman, O. and R. Gieben, "DNSSEC Operational
-                Practices", RFC 4641, September 2006.
-
-   [keytiming]  Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
-                Timing Considerations", March 2010.
-
-
-
-Mekking                 Expires December 31, 2010               [Page 5]
-
-Internet-Draft        Child Parent Synchronization             June 2010
-
-
-8.2.  Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [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.
-
-   [RFC4035]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "Protocol Modifications for the DNS Security
-                Extensions", RFC 4035, March 2005.
-
-Author's Address
-
-   Matthijs Mekking
-   NLnet Labs
-   Science Park 140
-   Amsterdam  1098 XG
-   The Netherlands
-
-   EMail: matthijs@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mekking                 Expires December 31, 2010               [Page 6]
-

doc/draft/draft-yao-dnsext-bname-04.txt

@@ -1,729 +0,0 @@
-
-
-Network Working Group                                             J. Yao
-Internet-Draft                                                    X. Lee
-Intended status: Standards Track                                   CNNIC
-Expires: February 12, 2011                                      P. Vixie
-                                            Internet Software Consortium
-                                                         August 11, 2010
-
-
-                      Bundle DNS Name Redirection
-                     draft-yao-dnsext-bname-04.txt
-
-Abstract
-
-   This document defines a new DNS Resource Record called "BNAME", which
-   provides the capability to map itself and its subtree of the DNS name
-   space to another domain.  It differs from the CNAME record which only
-   maps a single node of the DNS name space, from the DNAME which only
-   maps the subtree of the DNS name space to another domain.
-
-Status of this Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at http://datatracker.ietf.org/drafts/current/.
-
-   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."
-
-   This Internet-Draft will expire on February 12, 2011.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 1]
-
-Internet-Draft                    bname                      August 2010
-
-
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-   This document may contain material from IETF Documents or IETF
-   Contributions published or made publicly available before November
-   10, 2008.  The person(s) controlling the copyright in some of this
-   material may not have granted the IETF Trust the right to allow
-   modifications of such material outside the IETF Standards Process.
-   Without obtaining an adequate license from the person(s) controlling
-   the copyright in such materials, this document may not be modified
-   outside the IETF Standards Process, and derivative works of it may
-   not be created outside the IETF Standards Process, except to format
-   it for publication as an RFC or to translate it into languages other
-   than English.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  The BNAME Resource Record  . . . . . . . . . . . . . . . . . .  4
-     3.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.2.  The BNAME Substitution . . . . . . . . . . . . . . . . . .  4
-     3.3.  The BNAME Rules  . . . . . . . . . . . . . . . . . . . . .  4
-   4.  Query Processing . . . . . . . . . . . . . . . . . . . . . . .  4
-     4.1.  Processing by Servers  . . . . . . . . . . . . . . . . . .  5
-     4.2.  Processing by Resolvers  . . . . . . . . . . . . . . . . .  8
-   5.  BNAME in DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  9
-     5.1.  BNAME validating . . . . . . . . . . . . . . . . . . . . .  9
-     5.2.  BNAME alias algorithm identifiers  . . . . . . . . . . . . 10
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
-   9.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
-     9.1.  draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 11
-     9.2.  draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 11
-     9.3.  draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 11
-     9.4.  draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 11
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 2]
-
-Internet-Draft                    bname                      August 2010
-
-
-1.  Introduction
-
-   More and more internationalized domain name labels [RFC3490] appear
-   in the DNS trees.  Some labels [RFC3743] are equivalent in some
-   languages.  The internet users want them to be identical in the DNS
-   resolution.  For example, color.exmaple.com==colour.example.com.  The
-   BNAME represents for bundle names.  This document defines a new DNS
-   Resource Record called "BNAME", which provides the capability to map
-   an entire tree of the DNS name space to another domain.  It means
-   that the BNAME redirects both itself and its descendants to its
-   owner.  The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,
-   only the descendants.  The domain name that owns a DNAME record is
-   allowed to have other resource record types at that domain name.  The
-   domain name that owns a BNAME record is not allowed to have other
-   resource record types at that domain name unless they are the DNSSEC
-   related resource record types defined in [RFC4033], [RFC4034],
-   [RFC4035] and [RFC5155].  A server MAY refuse to load a zone that has
-   data at a sub-domain of a domain name owning a BNAME RR or that has
-   other data except the DNSSEC related resource record types and BNAME
-   at that name.  BNAME is a singleton type, meaning only one BNAME is
-   allowed per name except the DNSSEC related resource record types.
-   Resolvers, servers and zone content administrators should be cautious
-   that usage of BNAME or its combination with CNAME or DNAME may lead
-   to form loops.  The loops should be avoided.
-
-1.1.  Terminology
-
-   All the basic terms used in this specification are defined in the
-   documents [RFC1034], [RFC1035] and [RFC2672].
-
-
-2.  Motivation
-
-   In some languages, some characters have the variants, which look
-   differently or very similar but are identical in the meaning.  For
-   example, Chinese character U+56FD and its variant U+570B look
-   differently, but are identical in the meaning.  If Internationalized
-   Domain Label" or "IDL" [RFC3743] are composed of variant characters,
-   we regard this kind of IDL as the IDL variant.  If these IDL variants
-   are put into the DNS for resolution, they are expected to be
-   identical in the DNS resolution.  More comprehensible example is that
-   we expect color.exmaple.com to be equivalent with the
-   colour.exmaple.com in the DNS resolution.  The BNAME Resource Record
-   and its processing rules are conceived as a solution to this
-   equivalence problem.  Without the BNAME mechanism, current mechanisms
-   such as DNAME or CNAME are not enough capable to solve all the
-   problems with the emergence of internationalized domain names.  The
-   internationalized domain names may have alias or equivalence of the
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 3]
-
-Internet-Draft                    bname                      August 2010
-
-
-   original one.  The BNAME solution provides the solution to both ASCII
-   alias names and internationalized domain alias names.
-
-
-3.  The BNAME Resource Record
-
-3.1.  Format
-
-   The BNAME RR has mnemonic BNAME and type code xx (decimal).  It is
-   not class-sensitive.  Its RDATA is comprised of a single field,
-   <target>, which contains a fully qualified domain name that must be
-   sent in uncompressed form [RFC1035], [RFC3597].  The <target> field
-   MUST be present.  The presentation format of <target> is that of a
-   domain name [RFC1035].  The wildcards in the BNAME RR SHOULD NOT be
-   used.
-
-     <owner> <ttl> <class> BNAME <target>
-
-   The effect of the BNAME RR is the substitution of the record's
-   <target> for its owner name, as a suffix of a domain name.  This
-   substitution has to be applied for every BNAME RR found in the
-   resolution process, which allows fairly lengthy valid chains of BNAME
-   RRs.
-
-3.2.  The BNAME Substitution
-
-   A BNAME substitution is performed by replacing the suffix labels of
-   the name being sought matching the owner name of the BNAME resource
-   record with the string of labels in the RDATA field.  The matching
-   labels end with the root label in all cases.  Only whole labels are
-   replaced.
-
-3.3.  The BNAME Rules
-
-   There are two rules which governs the use of BNAMEs in a zone file.
-   The first one is that there SHOULD be no descendants under the owner
-   of the BNAME.  The second one is that no resource records can co-
-   exist with the BNAME for the same name except the DNSSEC related
-   resource record types.  It means that if a BNAME RR is present at a
-   node N, there MUST be no other data except the DNSSEC related
-   resource record types at N and no data at any descendant of N. This
-   restriction applies only to records of the same class as the BNAME
-   record.
-
-
-4.  Query Processing
-
-   To exploit the BNAME mechanism the name resolution algorithms
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 4]
-
-Internet-Draft                    bname                      August 2010
-
-
-   [RFC1034] must be modified slightly for both servers and resolvers.
-   Both modified algorithms incorporate the operation of making a
-   substitution on a name (either QNAME or SNAME) under control of a
-   BNAME record.  This operation will be referred to as "the BNAME
-   substitution".
-
-4.1.  Processing by Servers
-
-   For a server performing non-recursive service steps 3.a, 3.c and 4 of
-   section 4.3.2 [RFC1034] are changed to check for a BNAME record, and
-   to return certain BNAME records from zone data and the cache.
-
-   If the owner name of the bname is the suffix of the name queryed but
-   different, when preparing a response, a server performing a BNAME
-   substitution will in all cases include the relevant BNAME RR in the
-   answer section.  A CNAME RR is synthesized and included in the answer
-   section.  This will help the client to reach the correct DNS data.
-
-   If the owner name of the bname is same with the name queryed, when
-   preparing a response, a server performing a BNAME substitution will
-   not include the relevant BNAME RR in the answer section unless the
-   type queryed is BNAME.  A CNAME RR will be synthesized and included
-   in the answer section unless the type queryed is BNAME or the query
-   is the DNSSEC query.
-
-   The provided synthesized CNAME RR if there has one, MUST have
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 5]
-
-Internet-Draft                    bname                      August 2010
-
-
-      The same CLASS as the QCLASS of the query,
-
-      TTL equal to the corresponding BNAME RR,
-
-      An <owner> equal to the QNAME in effect at the moment the BNAME RR
-      was encountered, and
-
-      An RDATA field containing the new QNAME formed by the action of
-      the BNAME substitution.
-
-
-   The revised server algorithm is:
-
-
-   1. Set or clear the value of recursion available in the response
-      depending on whether the name server is willing to provide
-      recursive service.  If recursive service is available and
-      requested via the RD bit in the query, go to step 5, otherwise
-      step 2.
-
-   2. Search the available zones for the zone which is the nearest
-      ancestor to QNAME.  If such a zone is found, go to step 3,
-      otherwise step 4.
-
-   3. Start matching down, label by label, in the zone.  The matching
-      process can terminate several ways:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 6]
-
-Internet-Draft                    bname                      August 2010
-
-
-     a. If the whole of QNAME is matched, we have found the node.
-
-         If the data at the node is a CNAME, and QTYPE doesn't match
-         CNAME, copy the CNAME RR into the answer section of the
-         response, change QNAME to the canonical name in the CNAME RR,
-         and go back to step 1.
-
-         If the data at the node is a BNAME, and QTYPE doesn't
-         match BNAME, copy the BNAME RR and also a corresponding,
-         synthesized CNAME RR into the answer section of the
-         response, change QNAME to the name carried as RDATA in
-         the BNAME RR, and go back to step 1.
-
-         Otherwise, copy all RRs which match QTYPE into the answer
-         section and go to step 6.
-
-      b. If a match would take us out of the authoritative data, we have
-         a referral.  This happens when we encounter a node with NS RRs
-         marking cuts along the bottom of a zone.
-
-         Copy the NS RRs for the subzone into the authority section of
-         the reply.  Put whatever addresses are available into the
-         additional section, using glue RRs if the addresses are not
-         available from authoritative data or the cache.  Go to step 4.
-
-      c. If at some label, a match is impossible (i.e., the
-         corresponding label does not exist), look to see whether the
-         last label matched has a BNAME record.
-
-
-         If a BNAME record exists at that point, copy that record into
-         the answer section.  If substitution of its <target> for its
-         <owner> in QNAME would overflow the legal size for a <domain-
-         name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
-         perform the substitution and continue.  The server SHOULD
-         synthesize a corresponding CNAME record as described above and
-         include it in the answer section.  Go back to step 1.
-
-         If there was no BNAME record, look to see if the "*" label
-         exists.
-
-         If the "*" label does not exist, check whether the name we are
-         looking for is the original QNAME in the query or a name we
-         have followed due to a CNAME.  If the name is original, set an
-         authoritative name error in the response and exit.  Otherwise
-         just exit.
-
-
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 7]
-
-Internet-Draft                    bname                      August 2010
-
-
-
-         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.
-
-
-   4. Start matching down in the cache.  If QNAME is found in the cache,
-      copy all RRs attached to it that match QTYPE into the answer
-      section.  If QNAME is not found in the cache but a BNAME record is
-      present at QNAME, copy that BNAME record into the
-      answer section.  If there was no delegation from authoritative
-      data, look for the best one from the cache, and put it in the
-      authority section.  Go to step 6.
-
-   5. Use the local resolver or a copy of its algorithm (see resolver
-      section of this memo) to answer the query.  Store the results,
-      including any intermediate CNAMEs and BNAMEs, in the answer
-      section of the response.
-
-   6. Using local data only, attempt to add other RRs which may be
-      useful to the additional section of the query.  Exit.
-
-
-
-   Note that there will be at most one ancestor with a BNAME as
-   described in step 4 unless some zone's data is in violation of the
-   no-descendants limitation in section 3.  An implementation might take
-   advantage of this limitation by stopping the search of step 3c or
-   step 4 when a BNAME record is encountered.
-
-
-4.2.  Processing by Resolvers
-
-   A resolver or a server providing recursive service must be modified
-   to treat a BNAME as somewhat analogous to a CNAME.  The resolver
-   algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d
-   as 4.e and insert a new 4.d.  The complete algorithm becomes:
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 8]
-
-Internet-Draft                    bname                      August 2010
-
-
-   1. See if the answer is in local information, and if so return it to
-      the client.
-
-   2. Find the best servers to ask.
-
-   3. Send them queries until one returns a response.
-
-   4. Analyze the response, either:
-
-      a. if the response answers the question or contains a name error,
-         cache the data as well as returning it back to the client.
-
-      b. if the response contains a better delegation to other servers,
-         cache the delegation information, and go to step 2.
-
-      c. if the response shows a CNAME and that is not the answer
-         itself, cache the CNAME, change the SNAME to the canonical name
-         in the CNAME RR and go to step 1.
-
-      d. if the response shows a BNAME and that is not the answer
-         itself, cache the BNAME.  If substitution of the BNAME's
-         <target> for its <owner> in the SNAME would overflow the legal
-         size for a <domain-name>, return an implementation-dependent
-         error to the application; otherwise perform the substitution
-         and go to step 1.
-
-      e. if the response shows a server failure or other bizarre
-         contents, delete the server from the SLIST and go back to step
-         3.
-
-
-   A resolver or recursive server which understands BNAME records but
-   sends non-extended queries MUST augment step 4.c by deleting from the
-   reply any CNAME records which have an <owner> which is a subdomain of
-   the <owner> of any BNAME record in the response.
-
-
-5.  BNAME in DNSSEC
-
-5.1.  BNAME validating
-
-   With the deployment of DNSSEC, more and more servers and resolvers
-   will support DNSSEC.  In order to make BNAME valid in DNSSEC
-   verification, the DNSSEC enabled resolvers and servers MUST support
-   BNAME.  The synthesized CNAME in the answer section for the BNAME
-   will never be signed if there has one.
-
-   If the owner name of the bname is the suffix of the name queryed but
-
-
-
-Yao, et al.             Expires February 12, 2011               [Page 9]
-
-Internet-Draft                    bname                      August 2010
-
-
-   different, DNSSEC validators MUST understand BNAME, verify the BNAME
-   and then checking that the CNAME was properly synthesized in order to
-   verify the synthesized CNAME.
-
-   If the owner name of the bname is same with the name queryed, DNSSEC
-   validators MUST understand BNAME and verify the BNAME.  The BNAME
-   enabled resolver (validator) should do somewhat analogous to a CNAME
-   for further query.
-
-   In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
-   map SHOULD be checked to see that there was no BNAME that could have
-   been applied.  If the BNAME bit in the type bit map is set and the
-   query type is not BNAME, then BNAME substitution should have been
-   done.
-
-5.2.  BNAME alias algorithm identifiers
-
-   In order to prevent BNAME-unaware resolvers from attempting to
-   validate responses from BNAME-signed zones, this specification
-   allocates two new DNSKEY algorithm identifiers.  Algorithm Y, DSA-
-   BNAME-SHA1 is an alias for algorithm 3, DSA.  Algorithm Z, RSASHA1-
-   BNAME-SHA1 is an alias for algorithm 5, RSASHA1.  These are not new
-   algorithms, they are additional identifiers for the existing
-   algorithms.  Zones signed according to this specification MUST only
-   use these algorithm identifiers for their DNSKEY RRs.  The BNAME-
-   unaware resolvers will not know these new identifiers and treat
-   responses from the BNAME signed zone as insecure, otherwise the bname
-   RR will be regarded as bogus if there is no such a mechanism.  These
-   algorithm identifiers are used with the BNAME hash algorithm SHA1.
-   Using other BNAME hash algorithms requires allocation of a new alias.
-   Validating resolvers which follow the BNAME specification MUST
-   recognize the new alias algorithm identifier.
-
-
-6.  IANA Considerations
-
-   IANA is requested to assign the number to XX.  This document updates
-   the IANA registry "DNS SECURITY ALGORITHM NUMBERS".  IANA is
-   requested to assign the number to Y and Z.
-
-   [[anchor14: Note in draft: before this document goes to WG Last call,
-   it is better that we list all DNSSEC algorithms that need to be
-   aliased to reflect compatibility with this extension.]]
-
-
-7.  Security Considerations
-
-   Both ASCII domain name labels and non-ASCII ones have some aliases.
-
-
-
-Yao, et al.             Expires February 12, 2011              [Page 10]
-
-Internet-Draft                    bname                      August 2010
-
-
-   We can bundle the domain name labels and their aliases through BNAME
-   in the DNS resolutions.  The name labels and their aliases in the
-   particular languages are only known by those who know these
-   languages.  Those labels may be regarded as different ones by those
-   who don't know those languages.  Those who do not know the aliases
-   should only use the familar ones.  The applications will not know the
-   aliases unless they are properly configured.
-
-
-8.  Acknowledgements
-
-   Because the BNAME is very similar to DNAME, the authors learn a lot
-   from [RFC2672].  Many ideas are from the discussion in the DNSOP and
-   DNSEXT mailling list.  Thanks a lot to all in the list.  Many
-   important comments and suggestions are contributed by many members of
-   the DNSEXT and DNSOP WGs.  The authors especially thanks the
-   following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George
-   Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving
-   this document.
-
-
-9.  Change History
-
-   [[anchor17: RFC Editor: Please remove this section.]]
-
-9.1.  draft-yao-dnsext-bname: Version 00
-
-   o  Bundle DNS Name Redirection
-
-9.2.  draft-yao-dnsext-bname: Version 01
-
-   o  Improve the algorithm
-   o  Improve the text
-
-9.3.  draft-yao-dnsext-bname: Version 02
-
-   o  Add the DNSSEC discussion
-   o  Improve the text
-
-9.4.  draft-yao-dnsext-bname: Version 03
-
-   o  Update the DNSSEC discussion
-   o  Update the IANA consideration
-
-
-10.  References
-
-
-
-
-
-Yao, et al.             Expires February 12, 2011              [Page 11]
-
-Internet-Draft                    bname                      August 2010
-
-
-10.1.  Normative References
-
-   [ASCII]    American National Standards Institute (formerly United
-              States of America Standards Institute), "USA Code for
-              Information Interchange", ANSI X3.4-1968, 1968.
-
-   [EDNS0]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
-              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-              RFC 2136, April 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
-              RFC 2672, August 1999.
-
-   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
-              "Internationalizing Domain Names in Applications (IDNA)",
-              RFC 3490, March 2003.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", RFC 3629, November 2003.
-
-   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
-              Engineering Team (JET) Guidelines for Internationalized
-              Domain Names (IDN) Registration and Administration for
-              Chinese, Japanese, and Korean", RFC 3743, April 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.
-
-
-
-Yao, et al.             Expires February 12, 2011              [Page 12]
-
-Internet-Draft                    bname                      August 2010
-
-
-              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.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-10.2.  Informative References
-
-   [RFC2672bis]
-              Rose, S. and W. Wijngaards, "Update to DNAME Redirection
-              in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
-              17.txt, 6 2009.
-
-
-Authors' Addresses
-
-   Jiankang YAO
-   CNNIC
-   No.4 South 4th Street, Zhongguancun
-   Beijing
-
-   Phone: +86 10 58813007
-   Email: yaojk@cnnic.cn
-
-
-   Xiaodong LEE
-   CNNIC
-   No.4 South 4th Street, Zhongguancun
-   Beijing
-
-   Phone: +86 10 58813020
-   Email: lee@cnnic.cn
-
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA
-
-   Phone: +1 650 779 7001
-   Email: vixie@isc.org
-
-
-
-
-
-Yao, et al.             Expires February 12, 2011              [Page 13]
-
-
-

doc/private/SRCID

@@ -1,6 +0,0 @@
-# $Id: SRCID,v 1.17.2.40 2010/11/11 01:15:03 tbox Exp $
-# 
-# This file must follow /bin/sh rules.  It is imported directly via
-# configure.
-#
-SRCID="( $Date: 2010/11/11 01:15:03 $ )"

doc/rfc/index

@@ -20,7 +20,6 @@
 1750:	Randomness Recommendations for Security
 1876:	A Means for Expressing Location Information in the Domain Name System
 1886:	DNS Extensions to support IP version 6
-1912:	Common DNS Operational and Configuration Errors
 1982:	Serial Number Arithmetic
 1995:	Incremental Zone Transfer in DNS
 1996:	A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
@@ -92,7 +91,6 @@
 	 Secret Key Transaction Authentication for DNS (GSS-TSIG)
 3655:	Redefinition of DNS Authenticated Data (AD) bit
 3658:	Delegation Signer (DS) Resource Record (RR)
-3755:	Legacy Resolver Compatibility for Delegation Signer (DS)
 3757:	Domain Name System KEY (DNSKEY) Resource Record (RR)
 	 Secure Entry Point (SEP) Flag
 3833:	Threat Analysis of the Domain Name System (DNS)
@@ -106,8 +104,6 @@
 4159:	Deprecation of "ip6.int"
 4193:	Unique Local IPv6 Unicast Addresses
 4255:	Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
-4294:	IPv6 Node Requirements
-4339:	IPv6 Host Configuration of DNS Server Information Approaches
 4343:	Domain Name System (DNS) Case Insensitivity Clarification
 4367:	What's in a Name: False Assumptions about DNS Names
 4398:	Storing Certificates in the Domain Name System (DNS)
@@ -115,29 +111,9 @@
 4408:	Sender Policy Framework (SPF) for Authorizing Use of Domains
 	 in E-Mail, Version 1
 4470:	Minimally Covering NSEC Records and DNSSEC On-line Signing
-4471:	Derivation of DNS Name Predecessor and Successor
-4472:	Operational Considerations and Issues with IPv6 DNS
-4509:	Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
 4634:	US Secure Hash Algorithms (SHA and HMAC-SHA)
-4635:	HMAC SHA TSIG Algorithm Identifiers
 4641:	DNSSEC Operational Practices
 4648:	The Base16, Base32, and Base64 Data Encodings
-4697:	Observed DNS Resolution Misbehavior
 4701:	A DNS Resource Record (RR) for Encoding
          Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-4892:	Requirements for a Mechanism Identifying a Name Server Instance
-4955:	DNS Security (DNSSEC) Experiments
-4956:	DNS Security (DNSSEC) Opt-In
-5001:	DNS Name Server Identifier (NSID) Option
-5011:	Automated Updates of DNS Security (DNSSEC) Trust Anchors
 5155:	DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
-5205:	Host Identity Protocol (HIP) Domain Name System (DNS) Extension
-5395:	Domain Name System (DNS) IANA Considerations
-5452:	Measures for Making DNS More Resilient against Forged Answers
-5507:	Design Choices When Expanding the DNS
-5625:	DNS Proxy Implementation Guidelines
-5702:   Use of SHA-2 Algorithms with RSA in
-         DNSKEY and RRSIG Resource Records for DNSSEC
-5933:	Use of GOST Signature Algorithms in DNSKEY
-         and RRSIG Resource Records for DNSSEC
-

doc/rfc/rfc1912.txt

@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            D. Barr
-Request for Comments: 1912             The Pennsylvania State University
-Obsoletes: 1537                                            February 1996
-Category: Informational
-
-
-            Common DNS Operational and Configuration Errors
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   This memo describes errors often found in both the operation of
-   Domain Name System (DNS) servers, and in the data that these DNS
-   servers contain.  This memo tries to summarize current Internet
-   requirements as well as common practice in the operation and
-   configuration of the DNS.  This memo also tries to summarize or
-   expand upon issues raised in [RFC 1537].
-
-1. Introduction
-
-   Running a nameserver is not a trivial task.  There are many things
-   that can go wrong, and many decisions have to be made about what data
-   to put in the DNS and how to set up servers.  This memo attempts to
-   address many of the common mistakes and pitfalls that are made in DNS
-   data as well as in the operation of nameservers.  Discussions are
-   also made regarding some other relevant issues such as server or
-   resolver bugs, and a few political issues with respect to the
-   operation of DNS on the Internet.
-
-2. DNS Data
-
-   This section discusses problems people typically have with the DNS
-   data in their nameserver, as found in the zone data files that the
-   nameserver loads into memory.
-
-2.1 Inconsistent, Missing, or Bad Data
-
-   Every Internet-reachable host should have a name.  The consequences
-   of this are becoming more and more obvious.  Many services available
-   on the Internet will not talk to you if you aren't correctly
-   registered in the DNS.
-
-
-
-
-
-Barr                         Informational                      [Page 1]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Make sure your PTR and A records match.  For every IP address, there
-   should be a matching PTR record in the in-addr.arpa domain.  If a
-   host is multi-homed, (more than one IP address) make sure that all IP
-   addresses have a corresponding PTR record (not just the first one).
-   Failure to have matching PTR and A records can cause loss of Internet
-   services similar to not being registered in the DNS at all.  Also,
-   PTR records must point back to a valid A record, not a alias defined
-   by a CNAME.  It is highly recommended that you use some software
-   which automates this checking, or generate your DNS data from a
-   database which automatically creates consistent data.
-
-   DNS domain names consist of "labels" separated by single dots.  The
-   DNS is very liberal in its rules for the allowable characters in a
-   domain name.  However, if a domain name is used to name a host, it
-   should follow rules restricting host names.  Further if a name is
-   used for mail, it must follow the naming rules for names in mail
-   addresses.
-
-   Allowable characters in a label for a host name are only ASCII
-   letters, digits, and the `-' character.  Labels may not be all
-   numbers, but may have a leading digit  (e.g., 3com.com).  Labels must
-   end and begin only with a letter or digit.  See [RFC 1035] and [RFC
-   1123].  (Labels were initially restricted in [RFC 1035] to start with
-   a letter, and some older hosts still reportedly have problems with
-   the relaxation in [RFC 1123].)  Note there are some Internet
-   hostnames which violate this rule (411.org, 1776.com).  The presence
-   of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
-   is informational only and was not defining a standard.  There is at
-   least one popular TCP/IP implementation which currently refuses to
-   talk to hosts named with underscores in them.  It must be noted that
-   the language in [1035] is such that these rules are voluntary -- they
-   are there for those who wish to minimize problems.  Note that the
-   rules for Internet host names also apply to hosts and addresses used
-   in SMTP (See RFC 821).
-
-   If a domain name is to be used for mail (not involving SMTP), it must
-   follow the rules for mail in [RFC 822], which is actually more
-   liberal than the above rules.  Labels for mail can be any ASCII
-   character except "specials", control characters, and whitespace
-   characters.  "Specials" are specific symbols used in the parsing of
-   addresses.  They are the characters "()<>@,;:\".[]".  (The "!"
-   character wasn't in [RFC 822], however it also shouldn't be used due
-   to the conflict with UUCP mail as defined in RFC 976)  However, since
-   today almost all names which are used for mail on the Internet are
-   also names used for hostnames, one rarely sees addresses using these
-   relaxed standard, but mail software should be made liberal and robust
-   enough to accept them.
-
-
-
-
-Barr                         Informational                      [Page 2]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   You should also be careful to not have addresses which are valid
-   alternate syntaxes to the inet_ntoa() library call.  For example 0xe
-   is a valid name, but if you were to type "telnet 0xe", it would try
-   to connect to IP address 0.0.0.14.  It is also rumored that there
-   exists some broken inet_ntoa() routines that treat an address like
-   x400 as an IP address.
-
-   Certain operating systems have limitations on the length of their own
-   hostname.  While not strictly of issue to the DNS, you should be
-   aware of your operating system's length limits before choosing the
-   name of a host.
-
-   Remember that many resource records (abbreviated RR) take on more
-   than one argument.  HINFO requires two arguments, as does RP.  If you
-   don't supply enough arguments, servers sometime return garbage for
-   the missing fields.  If you need to include whitespace within any
-   data, you must put the string in quotes.
-
-2.2 SOA records
-
-   In the SOA record of every zone, remember to fill in the e-mail
-   address that will get to the person who maintains the DNS at your
-   site (commonly referred to as "hostmaster").  The `@' in the e-mail
-   must be replaced by a `.' first.  Do not try to put an `@' sign in
-   this address.  If the local part of the address already contains a
-   `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
-   preceding it with `\' character.  (e.g., to become
-   John\.Smith.widget.xx) Alternately (and preferred), you can just use
-   the generic name `hostmaster', and use a mail alias to redirect it to
-   the appropriate persons.  There exists software which uses this field
-   to automatically generate the e-mail address for the zone contact.
-   This software will break if this field is improperly formatted.  It
-   is imperative that this address get to one or more real persons,
-   because it is often used for everything from reporting bad DNS data
-   to reporting security incidents.
-
-   Even though some BIND versions allow you to use a decimal in a serial
-   number, don't.  A decimal serial number is converted to an unsigned
-   32-bit integer internally anyway.  The formula for a n.m serial
-   number is n*10^(3+int(0.9+log10(m))) + m which translates to
-   something rather unexpected.  For example it's routinely possible
-   with a decimal serial number (perhaps automatically generated by
-   SCCS) to be incremented such that it is numerically larger, but after
-   the above conversion yield a serial number which is LOWER than
-   before.  Decimal serial numbers have been officially deprecated in
-   recent BIND versions.  The recommended syntax is YYYYMMDDnn
-   (YYYY=year, MM=month, DD=day, nn=revision number.  This won't
-   overflow until the year 4294.
-
-
-
-Barr                         Informational                      [Page 3]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Choose logical values for the timer values in the SOA record (note
-   values below must be expressed as seconds in the zone data):
-
-      Refresh: How often a secondary will poll the primary server to see
-          if the serial number for the zone has increased (so it knows
-          to request a new copy of the data for the zone).  Set this to
-          how long your secondaries can comfortably contain out-of-date
-          data.  You can keep it short (20 mins to 2 hours) if you
-          aren't worried about a small increase in bandwidth used, or
-          longer (2-12 hours) if your Internet connection is slow or is
-          started on demand.  Recent BIND versions (4.9.3) have optional
-          code to automatically notify secondaries that data has
-          changed, allowing you to set this TTL to a long value (one
-          day, or more).
-
-      Retry: If a secondary was unable to contact the primary at the
-          last refresh, wait the retry value before trying again.  This
-          value isn't as important as others, unless the secondary is on
-          a distant network from the primary or the primary is more
-          prone to outages.  It's typically some fraction of the refresh
-          interval.
-
-
-      Expire: How long a secondary will still treat its copy of the zone
-          data as valid if it can't contact the primary.  This value
-          should be greater than how long a major outage would typically
-          last, and must be greater than the minimum and retry
-          intervals, to avoid having a secondary expire the data before
-          it gets a chance to get a new copy.  After a zone is expired a
-          secondary will still continue to try to contact the primary,
-          but it will no longer provide nameservice for the zone.  2-4
-          weeks are suggested values.
-
-      Minimum: The default TTL (time-to-live) for resource records --
-          how long data will remain in other nameservers' cache.  ([RFC
-          1035] defines this to be the minimum value, but servers seem
-          to always implement this as the default value)  This is by far
-          the most important timer.  Set this as large as is comfortable
-          given how often you update your nameserver.  If you plan to
-          make major changes, it's a good idea to turn this value down
-          temporarily beforehand.  Then wait the previous minimum value,
-          make your changes, verify their correctness, and turn this
-          value back up.  1-5 days are typical values.  Remember this
-          value can be overridden on individual resource records.
-
-
-
-
-
-
-
-Barr                         Informational                      [Page 4]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   As you can see, the typical values above for the timers vary widely.
-   Popular documentation like [RFC 1033] recommended a day for the
-   minimum TTL, which is now considered too low except for zones with
-   data that vary regularly.  Once a DNS stabilizes, values on the order
-   of 3 or more days are recommended.  It is also recommended that you
-   individually override the TTL on certain RRs which are often
-   referenced and don't often change to have very large values (1-2
-   weeks).  Good examples of this are the MX, A, and PTR records of your
-   mail host(s), the NS records of your zone, and the A records of your
-   nameservers.
-
-2.3 Glue A Records
-
-   Glue records are A records that are associated with NS records to
-   provide "bootstrapping" information to the nameserver.  For example:
-
-           podunk.xx.      in      ns      ns1.podunk.xx.
-                           in      ns      ns2.podunk.xx.
-           ns1.podunk.xx.  in      a       1.2.3.4
-           ns2.podunk.xx.  in      a       1.2.3.5
-
-   Here, the A records are referred to as "Glue records".
-
-   Glue records are required only in forward zone files for nameservers
-   that are located in the subdomain of the current zone that is being
-   delegated.  You shouldn't have any A records in an in-addr.arpa zone
-   file (unless you're using RFC 1101-style encoding of subnet masks).
-
-   If your nameserver is multi-homed (has more than one IP address), you
-   must list all of its addresses in the glue to avoid cache
-   inconsistency due to differing TTL values, causing some lookups to
-   not find all addresses for your nameserver.
-
-   Some people get in the bad habit of putting in a glue record whenever
-   they add an NS record "just to make sure".  Having duplicate glue
-   records in your zone files just makes it harder when a nameserver
-   moves to a new IP address, or is removed. You'll spend hours trying
-   to figure out why random people still see the old IP address for some
-   host, because someone forgot to change or remove a glue record in
-   some other file.  Newer BIND versions will ignore these extra glue
-   records in local zone files.
-
-   Older BIND versions (4.8.3 and previous) have a problem where it
-   inserts these extra glue records in the zone transfer data to
-   secondaries.  If one of these glues is wrong, the error can be
-   propagated to other nameservers.  If two nameservers are secondaries
-   for other zones of each other, it's possible for one to continually
-   pass old glue records back to the other.  The only way to get rid of
-
-
-
-Barr                         Informational                      [Page 5]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   the old data is to kill both of them, remove the saved backup files,
-   and restart them.  Combined with that those same versions also tend
-   to become infected more easily with bogus data found in other non-
-   secondary nameservers (like the root zone data).
-
-2.4 CNAME records
-
-   A CNAME record is not allowed to coexist with any other data.  In
-   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
-   can't also have an MX record for suzy.podunk.edu, or an A record, or
-   even a TXT record.  Especially do not try to combine CNAMEs and NS
-   records like this!:
-
-
-           podunk.xx.      IN      NS      ns1
-                           IN      NS      ns2
-                           IN      CNAME   mary
-           mary            IN      A       1.2.3.4
-
-
-   This is often attempted by inexperienced administrators as an obvious
-   way to allow your domain name to also be a host.  However, DNS
-   servers like BIND will see the CNAME and refuse to add any other
-   resources for that name.  Since no other records are allowed to
-   coexist with a CNAME, the NS entries are ignored.  Therefore all the
-   hosts in the podunk.xx domain are ignored as well!
-
-   If you want to have your domain also be a host, do the following:
-
-           podunk.xx.      IN      NS      ns1
-                           IN      NS      ns2
-                           IN      A       1.2.3.4
-           mary            IN      A       1.2.3.4
-
-   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
-   plan to get rid of them (and inform your users).  However CNAMEs are
-   useful (and encouraged) for generalized names for servers -- `ftp'
-   for your ftp server, `www' for your Web server, `gopher' for your
-   Gopher server, `news' for your Usenet news server, etc.
-
-   Don't forget to delete the CNAMEs associated with a host if you
-   delete the host it is an alias for.  Such "stale CNAMEs" are a waste
-   of resources.
-
-
-
-
-
-
-
-
-Barr                         Informational                      [Page 6]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Don't use CNAMEs in combination with RRs which point to other names
-   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
-   implement classless in-addr delegation.)  For example, this is
-   strongly discouraged:
-
-           podunk.xx.      IN      MX      mailhost
-           mailhost        IN      CNAME   mary
-           mary            IN      A       1.2.3.4
-
-
-   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
-   974] explicitly states that MX records shall not point to an alias
-   defined by a CNAME.  This results in unnecessary indirection in
-   accessing the data, and DNS resolvers and servers need to work more
-   to get the answer.  If you really want to do this, you can accomplish
-   the same thing by using a preprocessor such as m4 on your host files.
-
-   Also, having chained records such as CNAMEs pointing to CNAMEs may
-   make administration issues easier, but is known to tickle bugs in
-   some resolvers that fail to check loops correctly.  As a result some
-   hosts may not be able to resolve such names.
-
-   Having NS records pointing to a CNAME is bad and may conflict badly
-   with current BIND servers.  In fact, current BIND implementations
-   will ignore such records, possibly leading to a lame delegation.
-   There is a certain amount of security checking done in BIND to
-   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
-   will get caught in an infinite query loop trying to figure out the
-   address for the aliased nameserver, causing a continuous stream of
-   DNS requests to be sent.
-
-2.5 MX records
-
-   It is a good idea to give every host an MX record, even if it points
-   to itself!  Some mailers will cache MX records, but will always need
-   to check for an MX before sending mail.  If a site does not have an
-   MX, then every piece of mail may result in one more resolver query,
-   since the answer to the MX query often also contains the IP addresses
-   of the MX hosts.  Internet SMTP mailers are required by [RFC 1123] to
-   support the MX mechanism.
-
-   Put MX records even on hosts that aren't intended to send or receive
-   e-mail.  If there is a security problem involving one of these hosts,
-   some people will mistakenly send mail to postmaster or root at the
-   site without checking first to see if it is a "real" host or just a
-   terminal or personal computer that's not set up to accept e-mail.  If
-   you give it an MX record, then the e-mail can be redirected to a real
-   person.  Otherwise mail can just sit in a queue for hours or days
-
-
-
-Barr                         Informational                      [Page 7]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   until the mailer gives up trying to send it.
-
-   Don't forget that whenever you add an MX record, you need to inform
-   the target mailer if it is to treat the first host as "local".  (The
-   "Cw" flag in sendmail, for example)
-
-   If you add an MX record which points to an external host (e.g., for
-   the purposes of backup mail routing) be sure to ask permission from
-   that site first.  Otherwise that site could get rather upset and take
-   action (like throw your mail away, or appeal to higher authorities
-   like your parent DNS administrator or network provider.)
-
-2.6 Other Resource Records
-
-2.6.1 WKS
-
-   WKS records are deprecated in [RFC 1123].  They serve no known useful
-   function, except internally among LISP machines.  Don't use them.
-
-2.6.2 HINFO
-
-   On the issue HINFO records, some will argue that these is a security
-   problem (by broadcasting what vendor hardware and operating system
-   you so people can run systematic attacks on known vendor security
-   holes).  If you do use them, you should keep up to date with known
-   vendor security problems.  However, they serve a useful purpose.
-   Don't forget that HINFO requires two arguments, the hardware type,
-   and the operating system.
-
-   HINFO is sometimes abused to provide other information.  The record
-   is meant to provide specific information about the machine itself.
-   If you need to express other information about the host in the DNS,
-   use TXT.
-
-2.6.3 TXT
-
-   TXT records have no specific definition.  You can put most anything
-   in them.  Some use it for a generic description of the host, some put
-   specific information like its location, primary user, or maybe even a
-   phone number.
-
-2.6.4 RP
-
-   RP records are relatively new.  They are used to specify an e-mail
-   address (see first paragraph of section 2.2)  of the "Responsible
-   Person" of the host, and the name of a TXT record where you can get
-   more information.  See [RFC 1183].
-
-
-
-
-Barr                         Informational                      [Page 8]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-2.7 Wildcard records
-
-   Wildcard MXs are useful mostly for non IP-connected sites.  A common
-   mistake is thinking that a wildcard MX for a zone will apply to all
-   hosts in the zone.  A wildcard MX will apply only to names in the
-   zone which aren't listed in the DNS at all.  e.g.,
-
-           podunk.xx.      IN      NS      ns1
-                           IN      NS      ns2
-           mary            IN      A       1.2.3.4
-           *.podunk.xx.    IN      MX      5 sue
-
-   Mail for mary.podunk.xx will be sent to itself for delivery.  Only
-   mail for jane.podunk.xx or any hosts you don't see above will be sent
-   to the MX.  For most Internet sites, wildcard MX records are not
-   useful.  You need to put explicit MX records on every host.
-
-   Wildcard MXs can be bad, because they make some operations succeed
-   when they should fail instead.  Consider the case where someone in
-   the domain "widget.com" tries to send mail to "joe@larry".  If the
-   host "larry" doesn't actually exist, the mail should in fact bounce
-   immediately.  But because of domain searching the address gets
-   resolved to "larry.widget.com", and because of the wildcard MX this
-   is a valid address according to DNS.  Or perhaps someone simply made
-   a typo in the hostname portion of the address.  The mail message then
-   gets routed to the mail host, which then rejects the mail with
-   strange error messages like "I refuse to talk to myself" or "Local
-   configuration error".
-
-   Wildcard MX records are good for when you have a large number of
-   hosts which are not directly Internet-connected (for example, behind
-   a firewall) and for administrative or political reasons it is too
-   difficult to have individual MX records for every host, or to force
-   all e-mail addresses to be "hidden" behind one or more domain names.
-   In that case, you must divide your DNS into two parts, an internal
-   DNS, and an external DNS.  The external DNS will have only a few
-   hosts and explicit MX records, and one or more wildcard MXs for each
-   internal domain.  Internally the DNS will be complete, with all
-   explicit MX records and no wildcards.
-
-   Wildcard As and CNAMEs are possible too, and are really confusing to
-   users, and a potential nightmare if used without thinking first.  It
-   could result (due again to domain searching) in any telnet/ftp
-   attempts from within the domain to unknown hosts to be directed to
-   one address.  One such wildcard CNAME (in *.edu.com) caused
-   Internet-wide loss of services and potential security nightmares due
-   to unexpected interactions with domain searching.  It resulted in
-   swift fixes, and even an RFC ([RFC 1535]) documenting the problem.
-
-
-
-Barr                         Informational                      [Page 9]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-2.8 Authority and Delegation Errors (NS records)
-
-   You are required to have at least two nameservers for every domain,
-   though more is preferred.  Have secondaries outside your network.  If
-   the secondary isn't under your control, periodically check up on them
-   and make sure they're getting current zone data from you.  Queries to
-   their nameserver about your hosts should always result in an
-   "authoritative" response.  If not, this is called a "lame
-   delegation".  A lame delegations exists when a nameserver is
-   delegated responsibility for providing nameservice for a zone (via NS
-   records) but is not performing nameservice for that zone (usually
-   because it is not set up as a primary or secondary for the zone).
-
-   The "classic" lame delegation can be illustrated in this example:
-
-           podunk.xx.      IN      NS      ns1.podunk.xx.
-                           IN      NS      ns0.widget.com.
-
-   "podunk.xx" is a new domain which has recently been created, and
-   "ns1.podunk.xx" has been set up to perform nameservice for the zone.
-   They haven't quite finished everything yet and haven't made sure that
-   the hostmaster at "ns0.widget.com" has set up to be a proper
-   secondary, and thus has no information about the podunk.xx domain,
-   even though the DNS says it is supposed to.  Various things can
-   happen depending on which nameserver is used.  At best, extra DNS
-   traffic will result from a lame delegation.  At worst, you can get
-   unresolved hosts and bounced e-mail.
-
-   Also, sometimes a nameserver is moved to another host or removed from
-   the list of secondaries.  Unfortunately due to caching of NS records,
-   many sites will still think that a host is a secondary after that
-   host has stopped providing nameservice.  In order to prevent lame
-   delegations while the cache is being aged, continue to provide
-   nameservice on the old nameserver for the length of the maximum of
-   the minimum plus refresh times for the zone and the parent zone.
-   (See section 2.2)
-
-   Whenever a primary or secondary is removed or changed, it takes a
-   fair amount of human coordination among the parties involved.  (The
-   site itself, it's parent, and the site hosting the secondary)  When a
-   primary moves, make sure all secondaries have their named.boot files
-   updated and their servers reloaded.  When a secondary moves, make
-   sure the address records at both the primary and parent level are
-   changed.
-
-   It's also been reported that some distant sites like to pick popular
-   nameservers like "ns.uu.net" and just add it to their list of NS
-   records in hopes that they will magically perform additional
-
-
-
-Barr                         Informational                     [Page 10]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   nameservice for them.  This is an even worse form of lame delegation,
-   since this adds traffic to an already busy nameserver.  Please
-   contact the hostmasters of sites which have lame delegations.
-   Various tools can be used to detect or actively find lame
-   delegations.  See the list of contributed software in the BIND
-   distribution.
-
-   Make sure your parent domain has the same NS records for your zone as
-   you do.  (Don't forget your in-addr.arpa zones too!).  Do not list
-   too many (7 is the recommended maximum), as this just makes things
-   harder to manage and is only really necessary for very popular top-
-   level or root zones.  You also run the risk of overflowing the 512-
-   byte limit of a UDP packet in the response to an NS query.  If this
-   happens, resolvers will "fall back" to using TCP requests, resulting
-   in increased load on your nameserver.
-
-   It's important when picking geographic locations for secondary
-   nameservers to minimize latency as well as increase reliability.
-   Keep in mind network topologies.  For example if your site is on the
-   other end of a slow local or international link, consider a secondary
-   on the other side of the link to decrease average latency.  Contact
-   your Internet service provider or parent domain contact for more
-   information about secondaries which may be available to you.
-
-3. BIND operation
-
-   This section discusses common problems people have in the actual
-   operation of the nameserver (specifically, BIND).  Not only must the
-   data be correct as explained above, but the nameserver must be
-   operated correctly for the data to be made available.
-
-3.1 Serial numbers
-
-   Each zone has a serial number associated with it.  Its use is for
-   keeping track of who has the most current data.  If and only if the
-   primary's serial number of the zone is greater will the secondary ask
-   the primary for a copy of the new zone data (see special case below).
-
-   Don't forget to change the serial number when you change data!  If
-   you don't, your secondaries will not transfer the new zone
-   information.  Automating the incrementing of the serial number with
-   software is also a good idea.
-
-   If you make a mistake and increment the serial number too high, and
-   you want to reset the serial number to a lower value, use the
-   following procedure:
-
-
-
-
-
-Barr                         Informational                     [Page 11]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-      Take the `incorrect' serial number and add 2147483647 to it.  If
-      the number exceeds 4294967296, subtract 4294967296.  Load the
-      resulting number.  Then wait 2 refresh periods to allow the zone
-      to propagate to all servers.
-
-      Repeat above until the resulting serial number is less than the
-      target serial number.
-
-      Up the serial number to the target serial number.
-
-   This procedure won't work if one of your secondaries is running an
-   old version of BIND (4.8.3 or earlier).  In this case you'll have to
-   contact the hostmaster for that secondary and have them kill the
-   secondary servers, remove the saved backup file, and restart the
-   server.  Be careful when editing the serial number -- DNS admins
-   don't like to kill and restart nameservers because you lose all that
-   cached data.
-
-3.2 Zone file style guide
-
-   Here are some useful tips in structuring your zone files.  Following
-   these will help you spot mistakes, and avoid making more.
-
-   Be consistent with the style of entries in your DNS files. If your
-   $ORIGIN is podunk.xx., try not to write entries like:
-
-           mary            IN      A       1.2.3.1
-           sue.podunk.xx.  IN      A       1.2.3.2
-
-   or:
-
-           bobbi           IN      A       1.2.3.2
-                           IN      MX      mary.podunk.xx.
-
-
-   Either use all FQDNs (Fully Qualified Domain Names) everywhere or
-   used unqualified names everywhere.  Or have FQDNs all on the right-
-   hand side but unqualified names on the left.  Above all, be
-   consistent.
-
-   Use tabs between fields, and try to keep columns lined up.  It makes
-   it easier to spot missing fields (note some fields such as "IN" are
-   inherited from the previous record and may be left out in certain
-   circumstances.)
-
-
-
-
-
-
-
-Barr                         Informational                     [Page 12]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   Remember you don't need to repeat the name of the host when you are
-   defining multiple records for one host.  Be sure also to keep all
-   records associated with a host together in the file.  It will make
-   things more straightforward when it comes time to remove or rename a
-   host.
-
-   Always remember your $ORIGIN.  If you don't put a `.' at the end of
-   an FQDN, it's not recognized as an FQDN.  If it is not an FQDN, then
-   the nameserver will append $ORIGIN to the name.  Double check, triple
-   check, those trailing dots, especially in in-addr.arpa zone files,
-   where they are needed the most.
-
-   Be careful with the syntax of the SOA and WKS records (the records
-   which use parentheses).  BIND is not very flexible in how it parses
-   these records.  See the documentation for BIND.
-
-3.3 Verifying data
-
-   Verify the data you just entered or changed by querying the resolver
-   with dig (or your favorite DNS tool, many are included in the BIND
-   distribution) after a change.  A few seconds spent double checking
-   can save hours of trouble, lost mail, and general headaches.  Also be
-   sure to check syslog output when you reload the nameserver.  If you
-   have grievous errors in your DNS data or boot file, named will report
-   it via syslog.
-
-   It is also highly recommended that you automate this checking, either
-   with software which runs sanity checks on the data files before they
-   are loaded into the nameserver, or with software which checks the
-   data already loaded in the nameserver.  Some contributed software to
-   do this is included in the BIND distribution.
-
-4. Miscellaneous Topics
-
-4.1 Boot file setup
-
-   Certain zones should always be present in nameserver configurations:
-
-           primary         localhost               localhost
-           primary         0.0.127.in-addr.arpa    127.0
-           primary         255.in-addr.arpa        255
-           primary         0.in-addr.arpa          0
-
-   These are set up to either provide nameservice for "special"
-   addresses, or to help eliminate accidental queries for broadcast or
-   local address to be sent off to the root nameservers.  All of these
-   files will contain NS and SOA records just like the other zone files
-   you maintain, the exception being that you can probably make the SOA
-
-
-
-Barr                         Informational                     [Page 13]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   timers very long, since this data will never change.
-
-   The "localhost" address is a "special" address which always refers to
-   the local host.  It should contain the following line:
-
-           localhost.      IN      A       127.0.0.1
-
-   The "127.0" file should contain the line:
-
-           1    PTR     localhost.
-
-   There has been some extensive discussion about whether or not to
-   append the local domain to it.  The conclusion is that "localhost."
-   would be the best solution.  The reasons given include:
-
-      "localhost" by itself is used and expected to work in some
-      systems.
-
-      Translating 127.0.0.1 into "localhost.dom.ain" can cause some
-      software to connect back to the loopback interface when it didn't
-      want to because "localhost" is not equal to "localhost.dom.ain".
-
-   The "255" and "0" files should not contain any additional data beyond
-   the NS and SOA records.
-
-   Note that future BIND versions may include all or some of this data
-   automatically without additional configuration.
-
-4.2 Other Resolver and Server bugs
-
-   Very old versions of the DNS resolver have a bug that cause queries
-   for names that look like IP addresses to go out, because the user
-   supplied an IP address and the software didn't realize that it didn't
-   need to be resolved.  This has been fixed but occasionally it still
-   pops up.  It's important because this bug means that these queries
-   will be sent directly to the root nameservers, adding to an already
-   heavy DNS load.
-
-   While running a secondary nameserver off another secondary nameserver
-   is possible, it is not recommended unless necessary due to network
-   topologies.  There are known cases where it has led to problems like
-   bogus TTL values.  While this may be caused by older or flawed DNS
-   implementations, you should not chain secondaries off of one another
-   since this builds up additional reliability dependencies as well as
-   adds additional delays in updates of new zone data.
-
-
-
-
-
-
-Barr                         Informational                     [Page 14]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-4.3 Server issues
-
-   DNS operates primarily via UDP (User Datagram Protocol) messages.
-   Some UNIX operating systems, in an effort to save CPU cycles, run
-   with UDP checksums turned off.  The relative merits of this have long
-   been debated.  However, with the increase in CPU speeds, the
-   performance considerations become less and less important.  It is
-   strongly encouraged that you turn on UDP checksumming to avoid
-   corrupted data not only with DNS but with other services that use UDP
-   (like NFS).  Check with your operating system documentation to verify
-   that UDP checksumming is enabled.
-
-References
-
-   [RFC 974] Partridge, C., "Mail routing and the domain system", STD
-              14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
-
-   [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
-              1033, USC/Information Sciences Institute, November 1987.
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, USC/Information Sciences Institute,
-              November 1987.
-
-   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, USC/Information Sciences
-              Institute, November 1987.
-
-   [RFC 1123] Braden, R., "Requirements for Internet Hosts --
-              Application and Support", STD 3, RFC 1123, IETF, October
-              1989.
-
-   [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
-              1178, Integrated Systems Group/NIST, August 1990.
-
-   [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
-              "New DNS RR Definitions", RFC 1183, October 1990.
-
-   [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
-              With Widely Deployed DNS Software", RFC 1535, ACES
-              Research Inc., October 1993.
-
-   [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
-              Miller, "Common DNS Implementation Errors and Suggested
-              Fixes", RFC 1536, USC/Information Sciences Institute, USC,
-              October 1993.
-
-
-
-
-
-Barr                         Informational                     [Page 15]
-
-RFC 1912                   Common DNS Errors               February 1996
-
-
-   [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
-              RFC 1537, CWI, October 1993.
-
-   [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
-              November 1994.
-
-   [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
-              Vixie Enterprises, July 1994.
-
-5. Security Considerations
-
-   Security issues are not discussed in this memo.
-
-6. Author's Address
-
-   David Barr
-   The Pennsylvania State University
-   Department of Mathematics
-   334 Whitmore Building
-   University Park, PA 16802
-
-   Voice: +1 814 863 7374
-   Fax: +1 814 863-8311
-   EMail: barr@math.psu.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barr                         Informational                     [Page 16]
-

doc/rfc/rfc3755.txt

@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          S. Weiler
-Request for Comments: 3755                                  SPARTA, Inc.
-Updates: 3658, 2535                                             May 2004
-Category: Standards Track
-
-
-        Legacy Resolver Compatibility for Delegation Signer (DS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-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.
-
-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 specifications have
-   been through, has resulted in fielded code with a wide variety of
-
-
-
-Weiler                      Standards Track                     [Page 1]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-   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) [RFC3658] introduction of new semantics for the NXT RR
-   that are incompatible with the semantics in [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 (DS) 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 RCODE=0, AA=0, and both an NS and an NXT in the
-   authority section.  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.
-
-
-
-
-Weiler                      Standards Track                     [Page 2]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-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 [RFC3225].
-
-   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.
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 3]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-2.4.  Increment the EDNS version
-
-   Another possible solution is to increment the EDNS version number as
-   defined in [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 [RFC2065] 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 RFC 3658.  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.
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 4]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-   The new types will have exactly the same syntax and semantics as
-   specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 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.
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 5]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-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 except for Indirect (algorithm 252)
-   remain usable for transaction security mechanisms.  Only RSA/SHA-1
-   [RFC3110], DSA/SHA-1 [RFC2536], 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.
-
-
-
-
-
-Weiler                      Standards Track                     [Page 6]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-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.  References
-
-6.1.  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.
-
-   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-             (DNS)", RFC 2536, March 1999.
-
-   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
-             RFC 2930, September 2000.
-
-   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-             (SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-             Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
-             (RR)", RFC 3658, December 2003.
-
-
-
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 7]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-6.2.  Informative References
-
-   [RFC2065] Eastlake, 3rd, 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.
-
-   [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.
-
-7.  Acknowledgments
-
-   The changes introduced here and the analysis of alternatives had many
-   contributors.  With apologies to anyone overlooked, those include:
-   Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis,
-   Bill Manning, Paul Vixie, 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.
-
-8.  Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, MD 21046
-   USA
-
-   EMail: weiler@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 8]
-
-RFC 3755          Legacy Resolver Compatibility for DS          May 2004
-
-
-9.  Full 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.
-
-   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.
-
-
-
-
-
-
-
-
-
-Weiler                      Standards Track                     [Page 9]
-

doc/rfc/rfc4509.txt

@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        W. Hardaker
-Request for Comments: 4509                                        Sparta
-Category: Standards Track                                       May 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
-
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-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 DNSKEYs in a child zone.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Implementing the SHA-256 Algorithm for DS Record Support ........2
-      2.1. DS Record Field Values .....................................2
-      2.2. DS Record with SHA-256 Wire Format .........................3
-      2.3. Example DS Record Using SHA-256 ............................3
-   3. Implementation Requirements .....................................3
-   4. Deployment Considerations .......................................4
-   5. IANA Considerations .............................................4
-   6. Security Considerations .........................................4
-      6.1. Potential Digest Type Downgrade Attacks ....................4
-      6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5
-   7. Acknowledgements ................................................5
-   8. References ......................................................6
-      8.1. Normative References .......................................6
-      8.2. Informative References .....................................6
-
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 1]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-1.  Introduction
-
-   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
-   zones to distribute a cryptographic digest of one key in a child's
-   DNSKEY RRset.  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, with a type covered of DS.
-
-   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
-   and "OPTIONAL" 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 2 has been 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: 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 be 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.
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 2]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-2.2.  DS Record with SHA-256 Wire Format
-
-   The resulting on-the-wire format for the resulting DS record will be
-   as follows:
-
-                          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:
-
-   dskey.example.com. 86400 IN DS 60485 5 2   ( 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.
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 3]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-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
-   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 cannot 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
-   has been assigned by IANA.
-
-   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 uses a different digest type.
-
-   o  A validator accepts a weaker digest even if a stronger one is
-      present but invalid.
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 4]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-   For example, if the following conditions are all true:
-
-   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
-   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.  Acknowledgements
-
-   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                    Standards Track                     [Page 5]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 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)", Work in
-                Progress.
-
-Author's Address
-
-   Wes Hardaker
-   Sparta
-   P.O. Box 382
-   Davis, CA  95617
-   USA
-
-   EMail: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 6]
-
-RFC 4509            Use of SHA-256 in DNSSEC DS RRs             May 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Hardaker                    Standards Track                     [Page 7]
-

doc/rfc/rfc4635.txt

@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4635                         Motorola Laboratories
-Category: Standards Track                                    August 2006
-
-
-                  HMAC SHA TSIG Algorithm Identifiers
-
-                          Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-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 HMAC MD5 (Hashed
-   Message Authentication Code, Message Digest 5) 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.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Algorithms and Identifiers ......................................2
-   3. Specifying Truncation ...........................................3
-      3.1. Truncation Specification ...................................4
-   4. TSIG Truncation Policy and Error Provisions .....................4
-   5. IANA Considerations .............................................5
-   6. Security Considerations .........................................5
-   7. Normative References ............................................6
-   8. Informative References. .........................................7
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 1]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-1.  Introduction
-
-   [RFC2845] specifies a TSIG Resource Record (RR) that can be used to
-   authenticate DNS (Domain Name System [STD13]) queries and responses.
-   This RR contains a domain name syntax data item that names the
-   authentication algorithm used.  [RFC2845] defines the
-   HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC
-   (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5
-   (Message Digest 5) [RFC1321] 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) [RFC3645].
-
-   Note 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 that a longer-length field is an error.
-
-   In Section 4, policy restrictions and implications related to
-   truncation are described and specified, as is a new error code to
-   indicate truncation shorter than that permitted by policy.
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in
-   this document are to be interpreted as described in [RFC2119].
-
-2.  Algorithms and Identifiers
-
-   TSIG Resource Records (RRs) [RFC2845] 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 [RFC2931].  In
-   particular, SIG(0) can be used for transaction signatures.)  Used
-   with a strong hash function, HMAC [RFC2104] 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 [RFC1321].
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 2]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-   The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as
-   compared with the 128 bits for MD5, and additional hash algorithms in
-   the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and
-   512 bits may be preferred in some cases.  This is because
-   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 Sections 3 and 4 below.
-   Key agreement can be by the TKEY mechanism [RFC2930] or some 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 that
-   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.
-
-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 [RFC2845] includes a "MAC size" field, which gives the
-   size of the MAC field in octets.  However, [RFC2845] 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.
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 3]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-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 [RFC2845], and the entire output
-      HMAC output is 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 are 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.
-
-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
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 4]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-   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 that is permitted under
-   Section 3 above but the MAC is too short for the local policy in
-   force, an RCODE of 22 (BADTRUNC) MUST be returned.
-
-5.  IANA Considerations
-
-   This document (1) registers the new TSIG algorithm identifiers listed
-   in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in
-   Section 4 [RFC2845].
-
-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 [RFC2104].
-
-   Significant progress has been made recently in cryptanalysis of hash
-   function of the types used herein, all of which ultimately derive
-   from the design of MD4.  While the results so far should not effect
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 5]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-   HMAC, the stronger SHA-1 and SHA-256 algorithms are being made
-   mandatory due to caution.
-
-   See the Security Considerations section of [RFC2845].  See also the
-   Security Considerations section of [RFC2104] from which the limits on
-   truncation in this RFC were taken.
-
-7.  Normative References
-
-   [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US
-               Federal Information Processing Standard, with Change
-               Notice 1, February 2004.
-
-   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
-               1321, April 1992.
-
-   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
-               Keyed-Hashing for Message Authentication", RFC 2104,
-               February 1997.
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2845]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-               Wellington, "Secret Key Transaction Authentication for
-               DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC3174]   Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-               1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC3874]   Housley, R., "A 224-bit One-way Hash Function: SHA-224",
-               RFC 3874, September 2004.
-
-   [RFC4634]   Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
-               (SHA)", RFC 4634, July 2006.
-
-   [STD13]     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.
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 6]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-8.  Informative References.
-
-   [RFC2930]   Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-               RR)", RFC 2930, September 2000.
-
-   [RFC2931]   Eastlake 3rd, D., "DNS Request and Transaction Signatures
-               ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3645]   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.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone: +1-508-786-7554 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 7]
-
-RFC 4635          HMAC SHA TSIG Algorithm Identifiers        August 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 8]
-

doc/rfc/rfc4892.txt

@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           S. Woolf
-Request for Comments: 4892             Internet Systems Consortium, Inc.
-Category: Informational                                        D. Conrad
-                                                                   ICANN
-                                                               June 2007
-
-
-    Requirements for a Mechanism Identifying a Name Server Instance
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-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
-   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.
-
-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.
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 1]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   The conventional 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 associated with DNS (or any other) service somewhat
-   problematic.  Specifically, multiple dedicated DNS queries may not go
-   to the same server 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 A.B.C.D".
-   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.
-
-2.  Existing Conventions
-
-   For some time, the commonly deployed Berkeley Internet Name Domain
-   (BIND) 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 label, replaces "BIND." with "SERVER.".  Thus
-   the query label to learn the unique name of a server may appear 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
-
-
-
-Woolf & Conrad               Informational                      [Page 2]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   administratively defined string which defaults to the software
-   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.
-
-   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.
-
-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.
-
-
-
-
-Woolf & Conrad               Informational                      [Page 3]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   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 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 aforementioned refinement changes
-       the query label 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 contain, including a possible encoding or
-       authentication mechanism.
-
-   5.  Hypothetically, since DNSSEC has been defined to cover all DNS
-       classes, the TXT RRs returned in response to the "ID.SERVER."
-       query could be signed, which has the advantages described in
-       [RFC4033].  However, since DNSSEC deployment for the CHAOS class
-       is neither existent nor foreseeable, and since the "ID.SERVER."
-       TXT RR is expected to be unique per server, this would be
-       impossible in practice.
-
-   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, "I need to know what nameserver is answering my queries",
-   not simply a convenient one.
-
-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
-
-
-
-
-Woolf & Conrad               Informational                      [Page 4]
-
-RFC 4892                        Serverid                       June 2007
-
-
-       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.
-
-4.  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.
-
-5.  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 server identification 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 the DNS is a
-   critically important infrastructure service for the production
-   Internet, extra care needs to be taken against this risk for
-   designers, implementors, and operators of a new mechanism for server
-   identification.
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 5]
-
-RFC 4892                        Serverid                       June 2007
-
-
-   Both authentication and confidentiality of server identification data
-   are potentially of interest to administrators -- that is, operators
-   may wish to make such data available and reliable to themselves and
-   their chosen associates only.  This constraint would imply both an
-   ability to authenticate it to themselves and to keep it private from
-   arbitrary other parties, which leads to characteristics 4 and 5 of an
-   improved solution.
-
-6.  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 versions 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.
-
-7.  References
-
-7.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.
-
-   [RFC3258]  Hardie, T., "Distributing Authoritative Name Servers via
-              Shared Unicast Addresses", RFC 3258, April 2002.
-
-7.2.  Informative References
-
-   [BIND]     ISC, "BIND 9 Configuration Reference".
-
-   [NSID]     Austein, R., "DNS Name Server Identifier Option (NSID)",
-              Work in Progress, June 2006.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 6]
-
-RFC 4892                        Serverid                       June 2007
-
-
-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
-   ICANN
-   4676 Admiralty Way
-   Marina del Rey, CA  90292
-   US
-
-   Phone: +1 310 823 9358
-   EMail: david.conrad@icann.org
-   URI:   http://www.iana.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 7]
-
-RFC 4892                        Serverid                       June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Woolf & Conrad               Informational                      [Page 8]
-

doc/rfc/rfc4955.txt

@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Blacka
-Request for Comments: 4955                                VeriSign, Inc.
-Category: Standards Track                                      July 2007
-
-
-                   DNS Security (DNSSEC) Experiments
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document describes a methodology for deploying alternate, non-
-   backwards-compatible, DNS Security (DNSSEC) methodologies in an
-   experimental fashion without disrupting the deployment of standard
-   DNSSEC.
-
-Table of Contents
-
-   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
-   3.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   4.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   5.  Defining an Experiment  . . . . . . . . . . . . . . . . . . . . 4
-   6.  Considerations  . . . . . . . . . . . . . . . . . . . . . . . . 5
-   7.  Use in Non-Experiments  . . . . . . . . . . . . . . . . . . . . 5
-   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                      Standards Track                     [Page 1]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-1.  Overview
-
-   Historically, experimentation with DNSSEC alternatives has been a
-   problematic endeavor.  There has typically been a desire to both
-   introduce non-backwards-compatible changes to DNSSEC and to try these
-   changes on real zones in the public DNS.  This creates a problem when
-   the change to DNSSEC would make all or part of the zone using those
-   changes appear bogus (bad) or otherwise broken to existing security-
-   aware resolvers.
-
-   This document describes a standard methodology for setting up DNSSEC
-   experiments.  This methodology addresses the issue of coexistence
-   with standard DNSSEC and DNS by using unknown algorithm identifiers
-   to hide the experimental DNSSEC protocol modifications from standard
-   security-aware resolvers.
-
-2.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and
-   RFC 4035 [4]) is assumed.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-3.  Experiments
-
-   When discussing DNSSEC experiments, it is necessary to classify these
-   experiments into two broad categories:
-
-   Backwards-Compatible:  describes experimental changes that, while not
-      strictly adhering to the DNSSEC standard, are nonetheless
-      interoperable with clients and servers that do implement the
-      DNSSEC standard.
-
-   Non-Backwards-Compatible:  describes experiments that would cause a
-      standard security-aware resolver to (incorrectly) determine that
-      all or part of a zone is bogus, or to otherwise not interoperate
-      with standard DNSSEC clients and servers.
-
-   Not included in these terms are experiments with the core DNS
-   protocol itself.
-
-   The methodology described in this document is not necessary for
-   backwards-compatible experiments, although it certainly may be used
-   if desired.
-
-
-
-
-Blacka                      Standards Track                     [Page 2]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-4.  Method
-
-   The core of the methodology is the use of strictly unknown algorithm
-   identifiers when signing the experimental zone, and more importantly,
-   having only unknown algorithm identifiers in the DS records for the
-   delegation to the zone at the parent.
-
-   This technique works because of the way DNSSEC-compliant validators
-   are expected to work in the presence of a DS set with only unknown
-   algorithm identifiers.  From RFC 4035 [4], Section 5.2:
-
-      If the validator does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver has no supported
-      authentication path leading from the parent to the child.  The
-      resolver should treat this case as it would the case of an
-      authenticated NSEC RRset proving that no DS RRset exists, as
-      described above.
-
-   And further:
-
-      If the resolver does not support any of the algorithms listed in
-      an authenticated DS RRset, then the resolver will not be able to
-      verify the authentication path to the child zone.  In this case,
-      the resolver SHOULD treat the child zone as if it were unsigned.
-
-   Although this behavior isn't strictly mandatory (as marked by MUST),
-   it is unlikely for a validator to implement a substantially different
-   behavior.  Essentially, if the validator does not have a usable chain
-   of trust to a child zone, then it can only do one of two things:
-   treat responses from the zone as insecure (the recommended behavior),
-   or treat the responses as bogus.  If the validator chooses the
-   latter, this will both violate the expectation of the zone owner and
-   defeat the purpose of the above rule.  However, with local policy, it
-   is within the right of a validator to refuse to trust certain zones
-   based on any criteria, including the use of unknown signing
-   algorithms.
-
-   Because we are talking about experiments, it is RECOMMENDED that
-   private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1.
-   Note that secure handling of private algorithms requires special
-   handing by the validator logic.  See "Clarifications and
-   Implementation Notes for DNSSECbis" [6] for further details.)
-   Normally, instead of actually inventing new signing algorithms, the
-   recommended path is to create alternate algorithm identifiers that
-   are aliases for the existing, known algorithms.  While, strictly
-   speaking, it is only necessary to create an alternate identifier for
-   the mandatory algorithms, it is suggested that all optional defined
-   algorithms be aliased as well.
-
-
-
-Blacka                      Standards Track                     [Page 3]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-   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 suffice.
-
-   Using this method, resolvers (or, more specifically, DNSSEC
-   validators) essentially indicate their ability to understand the
-   DNSSEC experiment's semantics by understanding what the new algorithm
-   identifiers signify.
-
-   This method creates two classes of security-aware servers and
-   resolvers: servers and resolvers that are aware of the experiment
-   (and thus recognize the experiment's algorithm identifiers and
-   experimental semantics), and servers and resolvers that are unaware
-   of the experiment.
-
-   This method also precludes any zone from being both in an experiment
-   and in a classic DNSSEC island of security.  That is, a zone is
-   either in an experiment and only possible to validate experimentally,
-   or it is not.
-
-5.  Defining an Experiment
-
-   The DNSSEC experiment MUST define the particular set of (previously
-   unknown) algorithm identifiers that identify the experiment and
-   define what each unknown algorithm identifier means.  Typically,
-   unless the experiment is actually experimenting with a new DNSSEC
-   algorithm, this will be a mapping of private algorithm identifiers to
-   existing, known algorithms.
-
-   Normally the experiment will choose a DNS name as the algorithm
-   identifier base.  This DNS name SHOULD be under the control of the
-   authors of the experiment.  Then the experiment will define a mapping
-   between known mandatory and optional algorithms into this private
-   algorithm identifier space.  Alternately, the experiment MAY use the
-   Object Identifier (OID) private algorithm space instead (using
-   algorithm number 254), or MAY choose non-private algorithm numbers,
-   although this would require an IANA allocation.
-
-   For example, an experiment might specify in its description the DNS
-   name "dnssec-experiment-a.example.com" as the base name, and declare
-   that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
-   algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
-   alias of DNSSEC algorithm 5 (RSASHA1).
-
-
-
-Blacka                      Standards Track                     [Page 4]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-   Resolvers MUST only recognize the experiment's semantics when present
-   in a zone signed by one or more of these algorithm identifiers.  This
-   is necessary to isolate the semantics of one experiment from any
-   others that the resolver might understand.
-
-   In general, resolvers involved in the experiment are expected to
-   understand both standard DNSSEC and the defined experimental DNSSEC
-   protocol, although this isn't required.
-
-6.  Considerations
-
-   There are a number of considerations with using this methodology.
-
-   1.  If an unaware validator does not correctly follow the rules laid
-       out in RFC 4035 (e.g., the validator interprets a DNSSEC record
-       prior to validating it), or if the experiment is broader in scope
-       that just modifying the DNSSEC semantics, the experiment may not
-       be sufficiently masked by this technique.  This may cause
-       unintended resolution failures.
-
-   2.  It will not be possible for security-aware resolvers unaware of
-       the experiment to build a chain of trust through an experimental
-       zone.
-
-7.  Use in Non-Experiments
-
-   This general methodology MAY be used for non-backwards compatible
-   DNSSEC protocol changes that start out as or become standards.  In
-   this case:
-
-   o  The protocol change SHOULD use public IANA allocated algorithm
-      identifiers instead of private algorithm identifiers.  This will
-      help identify the protocol change as a standard, rather than an
-      experiment.
-
-   o  Resolvers MAY recognize the protocol change in zones not signed
-      (or not solely signed) using the new algorithm identifiers.
-
-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.
-
-   Implementers should take into account any security issues that may
-   result from environments being configured to trust both experimental
-   and non-experimental zones.  If the experimental zone is more
-
-
-
-Blacka                      Standards Track                     [Page 5]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-   vulnerable to attacks, it could, for example, be used to promote
-   trust in zones not part of the experiment, possibly under the control
-   of an attacker.
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-9.2.  Informative References
-
-   [5]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [6]  Weiler, S. and R. Austein, "Clarifications and Implementation
-        Notes for DNSSECbis", Work in Progress, March 2007.
-
-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                      Standards Track                     [Page 6]
-
-RFC 4955           DNS Security (DNSSEC) Experiments           July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Blacka                      Standards Track                     [Page 7]
-

doc/rfc/rfc5001.txt

@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 5001                                           ISC
-Category: Standards Track                                    August 2007
-
-
-                DNS Name Server Identifier (NSID) Option
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-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
-   mechanisms 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 that 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                     Standards Track                     [Page 1]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  3
-     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
-     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  4
-   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  4
-     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  7
-     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  7
-     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  8
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-
-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 that 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.
-
-
-
-
-
-
-
-
-Austein                     Standards Track                     [Page 2]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-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].
-
-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 that 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.
-
-
-
-
-
-Austein                     Standards Track                     [Page 3]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   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 3.
-
-   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 contents 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.
-
-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 are
-   deliberately left outside the scope of this specification.
-
-   Choosing the NSID content is a prerogative of the server
-   administrator.  The server administrator might choose to encode the
-   NSID content in such a way that the server operator (or clients
-   authorized by the server operator) can decode the NSID content to
-   obtain more information than other clients can.  Alternatively, the
-   server operator might choose unencoded NSID content that is equally
-   meaningful to any client.
-
-   This section describes 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 specifying a simple opaque
-   byte string in Section 2.3.
-
-
-
-Austein                     Standards Track                     [Page 4]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   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 probabilistically 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 dynamically 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.
-
-   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
-
-
-
-Austein                     Standards Track                     [Page 5]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-      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  Probabilistically unique identifiers have properties similar 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 probabilistically unique
-      identifier across reboots, but this does not appear to be a
-      serious restriction, since authoritative nameservers almost always
-      have some form of non-volatile storage.  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
-      generates a new identifier every time it reboots.
-
-   o  Using an arbitrary octet string gives name server operators yet
-      another setting 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.
-
-   o  A signed blob is not particularly useful as an NSID payload unless
-      the signed data is dynamic and includes some kind of replay
-      protection, such as a timestamp or some kind of data identifying
-      the requestor.  Signed blobs that meet these criteria could
-      conceivably be useful in some situations but would require
-      detailed security analysis beyond the scope of this document.
-
-   o  A static encrypted blob would not be particularly useful, as it
-      would be subject to replay attacks and would, in effect, just be a
-      random number to any party that does not possess the decryption
-      key.  Dynamic encrypted blobs could conceivably be useful in some
-      situations but, as with signed blobs, dynamic encrypted blobs
-      would require detailed security analysis beyond the scope of this
-      document.
-
-   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 of payload up to the implementor and name server operator.
-
-
-
-Austein                     Standards Track                     [Page 6]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   The following guidelines may be useful to implementors and server
-   operators:
-
-   o  Operators for whom divulging the unicast address is an issue could
-      use the raw binary representation of a probabilistically 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,
-
-
-
-Austein                     Standards Track                     [Page 7]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   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
-   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 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.
-
-4.  IANA Considerations
-
-   IANA has allocated EDNS option code 3 for the NSID option
-   (Section 2.3).
-
-
-
-Austein                     Standards Track                     [Page 8]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-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.
-
-   Two of the possible kinds of payload data discussed in Section 3.1
-   involve a digital signature and encryption, respectively.  While this
-   specification discusses some of the pitfalls that might lurk for
-   careless users of these kinds of payload data, full analysis of the
-   issues that would be involved in these kinds of payload data would
-   require knowledge of the content to be signed or encrypted,
-   algorithms to be used, and so forth, which is beyond the scope of
-   this document.  Implementors should seek competent advice before
-   attempting to use these kinds of NSID payloads.
-
-6.  Acknowledgements
-
-   Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews,
-   Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad,
-   John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter
-   Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey
-   Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam
-   Weiler, and Suzanne Woolf, none of whom are responsible for what the
-   author did with their comments and suggestions.  Apologies to anyone
-   inadvertently omitted from the above list.
-
-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.
-
-
-
-
-
-
-Austein                     Standards Track                     [Page 9]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-   [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.
-
-Author's Address
-
-   Rob Austein
-   ISC
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   EMail: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                     Standards Track                    [Page 10]
-
-RFC 5001                        DNS NSID                     August 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Austein                     Standards Track                    [Page 11]
-

doc/rfc/rfc5011.txt

@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. StJohns
-Request for Comments: 5011                                   Independent
-Category: Standards Track                                 September 2007
-
-
-        Automated Updates of DNS Security (DNSSEC) Trust Anchors
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes a means for automated, authenticated, and
-   authorized updating of DNSSEC "trust anchors".  The method provides
-   protection against N-1 key compromises of N keys in the trust point
-   key set.  Based on the trust established by the presence of a current
-   anchor, other anchors may be added at the same place in the
-   hierarchy, and, ultimately, supplant the existing anchor(s).
-
-   This mechanism will require changes to resolver management behavior
-   (but not resolver resolution behavior), and the addition of a single
-   flag bit to the DNSKEY record.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 1]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Compliance Nomenclature ....................................3
-   2. Theory of Operation .............................................3
-      2.1. Revocation .................................................4
-      2.2. Add Hold-Down ..............................................4
-      2.3. Active Refresh .............................................5
-      2.4. Resolver Parameters ........................................6
-           2.4.1. Add Hold-Down Time ..................................6
-           2.4.2. Remove Hold-Down Time ...............................6
-           2.4.3. Minimum Trust Anchors per Trust Point ...............6
-   3. Changes to DNSKEY RDATA Wire Format .............................6
-   4. State Table .....................................................6
-      4.1. Events .....................................................7
-      4.2. States .....................................................7
-   5. Trust Point Deletion ............................................8
-   6. Scenarios - Informative .........................................9
-      6.1. Adding a Trust Anchor ......................................9
-      6.2. Deleting a Trust Anchor ....................................9
-      6.3. Key Roll-Over .............................................10
-      6.4. Active Key Compromised ....................................10
-      6.5. Stand-by Key Compromised ..................................10
-      6.6. Trust Point Deletion ......................................10
-   7. IANA Considerations ............................................11
-   8. Security Considerations ........................................11
-      8.1. Key Ownership vs. Acceptance Policy .......................11
-      8.2. Multiple Key Compromise ...................................12
-      8.3. Dynamic Updates ...........................................12
-   9. Normative References ...........................................12
-   10. Informative References ........................................12
-
-1.  Introduction
-
-   As part of the reality of fielding DNSSEC (Domain Name System
-   Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
-   come to the realization that there will not be one signed name space,
-   but rather islands of signed name spaces 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
-
-
-
-StJohns                     Standards Track                     [Page 2]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   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 these 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].
-
-2.  Theory of Operation
-
-   The general concept of this mechanism is that existing trust anchors
-   can be used to authenticate new trust anchors at the same point in
-   the DNS hierarchy.  When a zone operator adds a new SEP key (i.e., a
-   DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
-   2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
-   validated by an existing trust anchor, then the resolver can add the
-   new key to its set of valid trust anchors for that trust point.
-
-   There are some issues with this approach that need to be mitigated.
-   For example, a compromise of one of the existing keys could allow an
-   attacker to add their own 'valid' data.  This implies a need for a
-   method to revoke an existing key regardless of whether or not that
-   key is compromised.  As another example, assuming a single key
-   compromise, we need to prevent an attacker from adding a new key and
-   revoking all the other old keys.
-
-
-
-
-
-StJohns                     Standards Track                     [Page 3]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-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 that didn't
-   contain A.  To fix this, we add a mechanism that requires knowledge
-   of the private key of a DNSKEY to revoke that DNSKEY.
-
-   A key is considered revoked when the resolver sees the key in a
-   self-signed RRSet and the key has the REVOKE bit (see Section 7
-   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
-   NOT use this key as a trust anchor or for any other purpose except to
-   validate the RRSIG it signed over the DNSKEY RRSet specifically for
-   the purpose of validating the revocation.  Unlike the 'Add' operation
-   below, revocation is immediate and permanent upon receipt of a valid
-   revocation at the resolver.
-
-   A self-signed RRSet is a DNSKEY RRSet that contains the specific
-   DNSKEY and for which there is a corresponding validated RRSIG record.
-   It's not a special DNSKEY RRSet, just a way of describing the
-   validation requirements for that RRSet.
-
-   N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
-   than one without the bit set.  This affects the matching of a DNSKEY
-   to DS records in the parent [RFC3755], or the fingerprint stored at a
-   resolver used to configure a trust point.
-
-   In the given example, the attacker could revoke B because it has
-   knowledge of B's private key, but could not revoke A.
-
-2.2.  Add Hold-Down
-
-   Assume two trust point keys A and B.  Assume that B has been
-   compromised.  An attacker could generate and add a new trust anchor
-   key C (by adding C to the DNSKEY RRSet and signing it with B), and
-   then invalidate the compromised key.  This would result in both the
-   attacker and owner being able to sign data in the zone and have it
-   accepted as valid by resolvers.
-
-   To mitigate but not completely solve this problem, we add a hold-down
-   time to the addition of the trust anchor.  When the resolver sees a
-   new SEP key in a validated trust point DNSKEY RRSet, the resolver
-   starts an acceptance timer, and remembers all the keys that validated
-   the RRSet.  If the resolver ever sees the DNSKEY RRSet without the
-   new key but validly signed, it stops the acceptance process for that
-   key and resets the acceptance timer.  If all of the keys that were
-
-
-
-
-
-StJohns                     Standards Track                     [Page 4]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   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 that 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
-   explicitly 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 the key had been compromised by
-   intercepting 'real' data from the originating zone and substituting
-   their own (e.g., using the example, signed only by B).  This is no
-   worse than the current situation assuming a compromised key.
-
-2.3.  Active Refresh
-
-   A resolver that has been configured for an 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, half the original TTL for the DNSKEY
-   RRSet, or half the RRSIG expiration interval and no more often than
-   once per hour.  The expiration interval is the amount of time from
-   when the RRSIG was last retrieved until the expiration time in the
-   RRSIG.  That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
-   1/2*RRSigExpirationInterval))
-
-   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, 10% of the original TTL, or 10% of the original
-   expiration interval.  That is, retryTime = MAX (1 hour, MIN (1 day,
-   .1 * origTTL, .1 * expireInterval)).
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 5]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-2.4.  Resolver Parameters
-
-2.4.1.  Add Hold-Down Time
-
-   The add hold-down time is 30 days or the expiration time of the
-   original TTL of the first trust point DNSKEY RRSet that contained the
-   new key, whichever is greater.  This ensures that at least two
-   validated DNSKEY RRSets that contain the new key MUST be seen by the
-   resolver prior to the key's acceptance.
-
-2.4.2.  Remove Hold-Down Time
-
-   The remove hold-down time is 30 days.  This parameter is solely a key
-   management database bookeeping parameter.  Failure to remove
-   information about the state of defunct keys from the database will
-   not adversely impact the security of this protocol, but may end up
-   with a database cluttered with obsolete key information.
-
-2.4.3.  Minimum Trust Anchors per Trust Point
-
-   A compliant resolver MUST be able to manage at least five SEP keys
-   per trust point.
-
-3.  Changes to DNSKEY RDATA Wire Format
-
-   Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
-   If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
-   signed by the associated key, then the resolver MUST consider this
-   key permanently invalid for all purposes except for validating the
-   revocation.
-
-4.  State Table
-
-   The most important thing to understand is the resolver's view of any
-   key at a trust point.  The following state table describes this 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.
-
-   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.
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 6]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-                             NEXT STATE
-           --------------------------------------------------
-    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
-   ----------------------------------------------------------
-   Start   |       |NewKey  |       |       |       |       |
-   ----------------------------------------------------------
-   AddPend |KeyRem |        |AddTime|       |       |       |
-   ----------------------------------------------------------
-   Valid   |       |        |       |KeyRem |Revbit |       |
-   ----------------------------------------------------------
-   Missing |       |        |KeyPres|       |Revbit |       |
-   ----------------------------------------------------------
-   Revoked |       |        |       |       |       |RemTime|
-   ----------------------------------------------------------
-   Removed |       |        |       |       |       |       |
-   ----------------------------------------------------------
-
-                           State Table
-
-4.1.  Events
-
-   NewKey   The resolver sees a valid DNSKEY RRSet with a new SEP key.
-            That key will become a new trust anchor for the named trust
-            point after it's been present in the RRSet for at least 'add
-            time'.
-
-   KeyPres  The key has returned to the valid DNSKEY RRSet.
-
-   KeyRem   The resolver sees a valid DNSKEY RRSet that does not contain
-            this key.
-
-   AddTime  The key has been in every valid DNSKEY RRSet seen for at
-            least the 'add time'.
-
-   RemTime  A revoked key has been missing from the trust-point DNSKEY
-            RRSet for sufficient time to be removed from the trust set.
-
-   RevBit   The key has appeared in the trust anchor DNSKEY RRSet with
-            its "REVOKED" bit set, and there is an RRSig over the DNSKEY
-            RRSet signed by this key.
-
-4.2.  States
-
-   Start    The key doesn't yet exist as a trust anchor at the resolver.
-            It may or may not exist at the zone server, but either
-            hasn't yet been seen at the resolver or was seen but was
-            absent from the last DNSKEY RRSet (e.g., KeyRem event).
-
-
-
-
-StJohns                     Standards Track                     [Page 7]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   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 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 a valid trust-
-            point key, but was not seen at the resolver in the last
-            validated DNSKEY RRSet.  This is an abnormal state because
-            the zone operator should be using the REVOKE bit prior to
-            removal.
-
-   Revoked  This is the state a key moves to once the resolver sees an
-            RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
-            contains this key with its REVOKE bit set to '1'.  Once in
-            this state, this key MUST permanently be considered invalid
-            as a trust anchor.
-
-   Removed  After a fairly long hold-down time, information about this
-            key may be purged from the resolver.  A key in the removed
-            state MUST NOT be considered a valid trust anchor.  (Note:
-            this state is more or less equivalent to the "Start" state,
-            except that it's bad practice to re-introduce previously
-            used keys -- think of this as the holding state for all the
-            old keys for which the resolver no longer needs to track
-            state.)
-
-5.  Trust Point Deletion
-
-   A trust point that has all of its trust anchors revoked is considered
-   deleted and is treated as if the trust point was never configured.
-   If there are no superior configured trust points, data at and below
-   the deleted trust point are considered insecure by the resolver.  If
-   there ARE superior configured trust points, data at and below the
-   deleted trust point are evaluated with respect to the superior trust
-   point(s).
-
-   Alternately, a trust point that is subordinate to another configured
-   trust point MAY be deleted by a resolver after 180 days, where such a
-
-
-
-StJohns                     Standards Track                     [Page 8]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   subordinate trust point validly chains to a superior trust point.
-   The decision to delete the subordinate trust anchor is a local
-   configuration decision.  Once the subordinate trust point is deleted,
-   validation of the subordinate zone is dependent on validating the
-   chain of trust to the superior trust point.
-
-6.  Scenarios - Informative
-
-   The suggested model for operation is to have one active key and one
-   stand-by key at each trust point.  The active key will be used to
-   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
-   RRSet, but the resolver will accept it as a trust anchor if/when it
-   sees the signature on the trust point DNSKEY RRSet.
-
-   Since the stand-by key is not in active signing use, the associated
-   private key may (and should) be provided with additional protections
-   not normally available to a key that must be used frequently (e.g.,
-   locked in a safe, split among many parties, etc).  Notionally, the
-   stand-by key should be less subject to compromise than an active key,
-   but that will be dependent on operational concerns not addressed
-   here.
-
-6.1.  Adding a Trust Anchor
-
-   Assume an existing trust anchor key 'A'.
-
-   1.  Generate a new key pair.
-
-   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
-       Key bits.
-
-   3.  Add the DNSKEY to the RRSet.
-
-   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
-       'A'.
-
-   5.  Wait for various resolvers' timers to go off and for them to
-       retrieve the new DNSKEY RRSet and signatures.
-
-   6.  The new trust anchor will be populated at the resolvers on the
-       schedule described by the state table and update algorithm -- see
-       Sections 2 and 4 above.
-
-6.2.  Deleting a Trust Anchor
-
-   Assume existing trust anchors 'A' and 'B' and that you want to revoke
-   and delete 'A'.
-
-
-
-
-StJohns                     Standards Track                     [Page 9]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   1.  Set the revocation bit on key 'A'.
-
-   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.  'A' is now revoked.
-       The operator should include the revoked 'A' in the RRSet for at
-       least the remove hold-down time, but then may remove it from the
-       DNSKEY RRSet.
-
-6.3.  Key Roll-Over
-
-   Assume existing keys A and B. 'A' is actively in use (i.e. has been
-   signing the DNSKEY RRSet).  'B' was the stand-by key. (i.e. has been
-   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
-   used to sign the RRSet).
-
-      1.  Generate a new key pair 'C'.
-      2.  Add 'C' to the DNSKEY RRSet.
-      3.  Set the revocation bit on key 'A'.
-      4.  Sign the RRSet with 'A' and 'B'.
-
-   'A' is now revoked, 'B' is now the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  The operator should include
-   the revoked 'A' in the RRSet for at least the remove hold-down time,
-   but may then remove it from the DNSKEY RRSet.
-
-6.4.  Active Key Compromised
-
-   This is the same as the mechanism for Key Roll-Over (Section 6.3)
-   above, assuming 'A' is the active key.
-
-6.5.  Stand-by Key Compromised
-
-   Using the same assumptions and naming conventions as Key Roll-Over
-   (Section 6.3) above:
-
-      1.  Generate a new key pair 'C'.
-      2.  Add 'C' to the DNSKEY RRSet.
-      3.  Set the revocation bit on key 'B'.
-      4.  Sign the RRSet with 'A' and 'B'.
-
-   'B' is now revoked, 'A' remains the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  'B' should continue to be
-   included in the RRSet for the remove hold-down time.
-
-6.6.  Trust Point Deletion
-
-   To delete a trust point that is subordinate to another configured
-   trust point (e.g., example.com to .com) requires some juggling of the
-   data.  The specific process is:
-
-
-
-StJohns                     Standards Track                    [Page 10]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   1.  Generate a new DNSKEY and DS record and provide the DS record to
-       the parent along with DS records for the old keys.
-
-   2.  Once the parent has published the DSs, add the new DNSKEY to the
-       RRSet and revoke ALL of the old keys at the same time, while
-       signing the DNSKEY RRSet with all of the old and new keys.
-
-   3.  After 30 days, stop publishing the old, revoked keys and remove
-       any corresponding DS records in the parent.
-
-   Revoking the old trust-point keys at the same time as adding new keys
-   that chain to a superior trust prevents the resolver from adding the
-   new keys as trust anchors.  Adding DS records for the old keys avoids
-   a race condition where either the subordinate zone becomes unsecure
-   (because the trust point was deleted) or becomes bogus (because it
-   didn't chain to the superior zone).
-
-7.  IANA Considerations
-
-   The IANA has assigned a bit in the DNSKEY flags field (see Section 7
-   of [RFC4034]) for the REVOKE bit (8).
-
-8.  Security Considerations
-
-   In addition to the following sections, see also Theory of Operation
-   above (Section 2) and especially Section 2.2 for related discussions.
-
-   Security considerations for trust anchor rollover not specific to
-   this protocol are discussed in [RFC4986].
-
-8.1.  Key Ownership vs. Acceptance Policy
-
-   The reader should note that, while the zone owner is responsible for
-   creating and distributing keys, it's wholly the decision of the
-   resolver owner as to whether to accept such keys for the
-   authentication of the zone information.  This implies the decision to
-   update trust-anchor keys based on trusting 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, which are outside the scope of this document.
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 11]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-8.2.  Multiple Key Compromise
-
-   This scheme permits recovery as long as at least one valid trust-
-   anchor key remains uncompromised, e.g., if there are three keys, you
-   can recover if two of them are compromised.  The zone owner should
-   determine their own level of comfort with respect to the number of
-   active, valid trust anchors in a zone and should be prepared to
-   implement recovery procedures once they detect a compromise.  A
-   manual or other out-of-band update of all resolvers will be required
-   if all trust-anchor keys at a trust point are compromised.
-
-8.3.  Dynamic Updates
-
-   Allowing a resolver to update its trust anchor set based on in-band
-   key information is potentially less secure than a manual process.
-   However, given the nature of the DNS, the number of resolvers that
-   would require update if a trust anchor key were compromised, and the
-   lack of a standard management framework for DNS, this approach is no
-   worse than the existing situation.
-
-9.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.  Informative References
-
-   [RFC4986]  Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
-              "Requirements Related to DNS Security (DNSSEC) Trust
-              Anchor Rollover", RFC 4986, August 2007.
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 12]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Author's Address
-
-   Michael StJohns
-   Independent
-
-   EMail: mstjohns@comcast.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 13]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 14]
-

doc/rfc/rfc5205.txt

@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        P. Nikander
-Request for Comments: 5205                  Ericsson Research NomadicLab
-Category: Experimental                                       J. Laganier
-                                                        DoCoMo Euro-Labs
-                                                              April 2008
-
-
-    Host Identity Protocol (HIP) Domain Name System (DNS) Extension
-
-Status of This Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document specifies a new resource record (RR) for the Domain
-   Name System (DNS), and how to use it with the Host Identity Protocol
-   (HIP).  This RR allows a HIP node to store in the DNS its Host
-   Identity (HI, the public component of the node public-private key
-   pair), Host Identity Tag (HIT, a truncated hash of its public key),
-   and the Domain Names of its rendezvous servers (RVSs).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 1]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Simple Static Singly Homed End-Host  . . . . . . . . . . .  5
-     3.2.  Mobile end-host  . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Overview of Using the DNS with HIP . . . . . . . . . . . . . .  8
-     4.1.  Storing HI, HIT, and RVS in the DNS  . . . . . . . . . . .  8
-     4.2.  Initiating Connections Based on DNS Names  . . . . . . . .  8
-   5.  HIP RR Storage Format  . . . . . . . . . . . . . . . . . . . .  9
-     5.1.  HIT Length Format  . . . . . . . . . . . . . . . . . . . .  9
-     5.2.  PK Algorithm Format  . . . . . . . . . . . . . . . . . . .  9
-     5.3.  PK Length Format . . . . . . . . . . . . . . . . . . . . . 10
-     5.4.  HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10
-     5.5.  Public Key Format  . . . . . . . . . . . . . . . . . . . . 10
-     5.6.  Rendezvous Servers Format  . . . . . . . . . . . . . . . . 10
-   6.  HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10
-   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-     8.1.  Attacker Tampering with an Insecure HIP RR . . . . . . . . 12
-     8.2.  Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13
-     8.3.  DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     11.1. Normative references . . . . . . . . . . . . . . . . . . . 14
-     11.2. Informative references . . . . . . . . . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 2]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-1.  Introduction
-
-   This document specifies a new resource record (RR) for the Domain
-   Name System (DNS) [RFC1034], and how to use it with the Host Identity
-   Protocol (HIP) [RFC5201].  This RR allows a HIP node to store in the
-   DNS its Host Identity (HI, the public component of the node public-
-   private key pair), Host Identity Tag (HIT, a truncated hash of its
-   HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204].
-
-   Currently, most of the Internet applications that need to communicate
-   with a remote host first translate a domain name (often obtained via
-   user input) into one or more IP address(es).  This step occurs prior
-   to communication with the remote host, and relies on a DNS lookup.
-
-   With HIP, IP addresses are intended to be used mostly for on-the-wire
-   communication between end hosts, while most Upper Layer Protocols
-   (ULP) and applications use HIs or HITs instead (ICMP might be an
-   example of an ULP not using them).  Consequently, we need a means to
-   translate a domain name into an HI.  Using the DNS for this
-   translation is pretty straightforward: We define a new HIP resource
-   record.  Upon query by an application or ULP for a name to IP address
-   lookup, the resolver would then additionally perform a name to HI
-   lookup, and use it to construct the resulting HI to IP address
-   mapping (which is internal to the HIP layer).  The HIP layer uses the
-   HI to IP address mapping to translate HIs and HITs into IP addresses
-   and vice versa.
-
-   The HIP Rendezvous Extension [RFC5204] allows a HIP node to be
-   reached via the IP address(es) of a third party, the node's
-   rendezvous server (RVS).  An Initiator willing to establish a HIP
-   association with a Responder served by an RVS would typically
-   initiate a HIP exchange by sending an I1 towards the RVS IP address
-   rather than towards the Responder IP address.  Consequently, we need
-   a means to find the name of a rendezvous server for a given host
-   name.
-
-   This document introduces the new HIP DNS resource record to store the
-   Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag
-   (HIT) information.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 3]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-3.  Usage Scenarios
-
-   In this section, we briefly introduce a number of usage scenarios
-   where the DNS is useful with the Host Identity Protocol.
-
-   With HIP, most applications and ULPs are unaware of the IP addresses
-   used to carry packets on the wire.  Consequently, a HIP node could
-   take advantage of having multiple IP addresses for fail-over,
-   redundancy, mobility, or renumbering, in a manner that is transparent
-   to most ULPs and applications (because they are bound to HIs; hence,
-   they are agnostic to these IP address changes).
-
-   In these situations, for a node to be reachable by reference to its
-   Fully Qualified Domain Name (FQDN), the following information should
-   be stored in the DNS:
-
-   o  A set of IP address(es) via A [RFC1035] and AAAA [RFC3596] RR sets
-      (RRSets [RFC2181]).
-
-   o  A Host Identity (HI), Host Identity Tag (HIT), and possibly a set
-      of rendezvous servers (RVS) through HIP RRs.
-
-   When a HIP node wants to initiate communication with another HIP
-   node, it first needs to perform a HIP base exchange to set up a HIP
-   association towards its peer.  Although such an exchange can be
-   initiated opportunistically, i.e., without prior knowledge of the
-   Responder's HI, by doing so both nodes knowingly risk man-in-the-
-   middle attacks on the HIP exchange.  To prevent these attacks, it is
-   recommended that the Initiator first obtain the HI of the Responder,
-   and then initiate the exchange.  This can be done, for example,
-   through manual configuration or DNS lookups.  Hence, a new HIP RR is
-   introduced.
-
-   When a HIP node is frequently changing its IP address(es), the
-   natural DNS latency for propagating changes may prevent it from
-   publishing its new IP address(es) in the DNS.  For solving this
-   problem, the HIP Architecture [RFC4423] introduces rendezvous servers
-   (RVSs) [RFC5204].  A HIP host uses a rendezvous server as a
-   rendezvous point to maintain reachability with possible HIP
-   initiators while moving [RFC5206].  Such a HIP node would publish in
-   the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up-
-   to-date with its current set of IP addresses.
-
-   When a HIP node wants to initiate a HIP exchange with a Responder, it
-   will perform a number of DNS lookups.  Depending on the type of
-   implementation, the order in which those lookups will be issued may
-   vary.  For instance, implementations using HIT in APIs may typically
-   first query for HIP resource records at the Responder FQDN, while
-
-
-
-Nikander & Laganier           Experimental                      [Page 4]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   those using an IP address in APIs may typically first query for A
-   and/or AAAA resource records.
-
-   In the following, we assume that the Initiator first queries for HIP
-   resource records at the Responder FQDN.
-
-   If the query for the HIP type was responded to with a DNS answer with
-   RCODE=3 (Name Error), then the Responder's information is not present
-   in the DNS and further queries for the same owner name SHOULD NOT be
-   made.
-
-   In case the query for the HIP records returned a DNS answer with
-   RCODE=0 (No Error) and an empty answer section, it means that no HIP
-   information is available at the responder name.  In such a case, if
-   the Initiator has been configured with a policy to fallback to
-   opportunistic HIP (initiating without knowing the Responder's HI) or
-   plain IP, it would send out more queries for A and AAAA types at the
-   Responder's FQDN.
-
-   Depending on the combinations of answers, the situations described in
-   Section 3.1 and Section 3.2 can occur.
-
-   Note that storing HIP RR information in the DNS at an FQDN that is
-   assigned to a non-HIP node might have ill effects on its reachability
-   by HIP nodes.
-
-3.1.  Simple Static Singly Homed End-Host
-
-   A HIP node (R) with a single static network attachment, wishing to be
-   reachable by reference to its FQDN (www.example.com), would store in
-   the DNS, in addition to its IP address(es) (IP-R), its Host Identity
-   (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record.
-
-   An Initiator willing to associate with a node would typically issue
-   the following queries:
-
-   o  QNAME=www.example.com, QTYPE=HIP
-
-   o  (QCLASS=IN is assumed and omitted from the examples)
-
-   Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
-   the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer
-   section, but no RVS.
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 5]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   o  QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
-
-   Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs
-   containing IP address(es) of the Responder (e.g., IP-R) in the answer
-   section.
-
-   Caption: In the remainder of this document, for the sake of keeping
-            diagrams simple and concise, several DNS queries and answers
-            are represented as one single transaction, while in fact
-            there are several queries and answers flowing back and
-            forth, as described in the textual examples.
-
-               [HIP? A?        ]
-               [www.example.com]            +-----+
-          +-------------------------------->|     |
-          |                                 | DNS |
-          | +-------------------------------|     |
-          | |  [HIP? A?        ]            +-----+
-          | |  [www.example.com]
-          | |  [HIP HIT-R HI-R ]
-          | |  [A IP-R         ]
-          | v
-        +-----+                              +-----+
-        |     |--------------I1------------->|     |
-        |  I  |<-------------R1--------------|  R  |
-        |     |--------------I2------------->|     |
-        |     |<-------------R2--------------|     |
-        +-----+                              +-----+
-
-                         Static Singly Homed Host
-
-   The Initiator would then send an I1 to the Responder's IP addresses
-   (IP-R).
-
-3.2.  Mobile end-host
-
-   A mobile HIP node (R) wishing to be reachable by reference to its
-   FQDN (www.example.com) would store in the DNS, possibly in addition
-   to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R), and the
-   domain name(s) of its rendezvous server(s) (e.g., rvs.example.com) in
-   HIP resource record(s).  The mobile HIP node also needs to notify its
-   rendezvous servers of any change in its set of IP address(es).
-
-   An Initiator willing to associate with such a mobile node would
-   typically issue the following queries:
-
-   o  QNAME=www.example.com, QTYPE=HIP
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 6]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   Which returns a DNS packet with RCODE=0 and one or more HIP RRs with
-   the HIT, HI, and RVS domain name(s) (e.g., HIT-R, HI-R, and
-   rvs.example.com) of the Responder in the answer section.
-
-   o  QNAME=rvs.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA
-
-   Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs
-   containing IP address(es) of the Responder's RVS (e.g., IP-RVS) in
-   the answer section.
-
-              [HIP?           ]
-              [www.example.com]
-
-              [A?             ]
-              [rvs.example.com]                     +-----+
-         +----------------------------------------->|     |
-         |                                          | DNS |
-         | +----------------------------------------|     |
-         | |  [HIP?                          ]      +-----+
-         | |  [www.example.com               ]
-         | |  [HIP HIT-R HI-R rvs.example.com]
-         | |
-         | |  [A?             ]
-         | |  [rvs.example.com]
-         | |  [A IP-RVS       ]
-         | |
-         | |                +-----+
-         | | +------I1----->| RVS |-----I1------+
-         | | |              +-----+             |
-         | | |                                  |
-         | | |                                  |
-         | v |                                  v
-        +-----+                              +-----+
-        |     |<---------------R1------------|     |
-        |  I  |----------------I2----------->|  R  |
-        |     |<---------------R2------------|     |
-        +-----+                              +-----+
-
-                              Mobile End-Host
-
-   The Initiator would then send an I1 to the RVS IP address (IP-RVS).
-   Following, the RVS will relay the I1 up to the mobile node's IP
-   address (IP-R), which will complete the HIP exchange.
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 7]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-4.  Overview of Using the DNS with HIP
-
-4.1.  Storing HI, HIT, and RVS in the DNS
-
-   For any HIP node, its Host Identity (HI), the associated Host
-   Identity Tag (HIT), and the FQDN of its possible RVSs can be stored
-   in a DNS HIP RR.  Any conforming implementation may store a Host
-   Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP
-   RDATA format.  HI and HIT are defined in Section 3 of the HIP
-   specification [RFC5201].
-
-   Upon return of a HIP RR, a host MUST always calculate the HI-
-   derivative HIT to be used in the HIP exchange, as specified in
-   Section 3 of the HIP specification [RFC5201], while the HIT possibly
-   embedded along SHOULD only be used as an optimization (e.g., table
-   lookup).
-
-   The HIP resource record may also contain one or more domain name(s)
-   of rendezvous server(s) towards which HIP I1 packets might be sent to
-   trigger the establishment of an association with the entity named by
-   this resource record [RFC5204].
-
-   The rendezvous server field of the HIP resource record stored at a
-   given owner name MAY include the owner name itself.  A semantically
-   equivalent situation occurs if no rendezvous server is present in the
-   HIP resource record stored at that owner name.  Such situations occur
-   in two cases:
-
-   o  The host is mobile, and the A and/or AAAA resource record(s)
-      stored at its host name contain the IP address(es) of its
-      rendezvous server rather than its own one.
-
-   o  The host is stationary, and can be reached directly at the IP
-      address(es) contained in the A and/or AAAA resource record(s)
-      stored at its host name.  This is a degenerated case of rendezvous
-      service where the host somewhat acts as a rendezvous server for
-      itself.
-
-   An RVS receiving such an I1 would then relay it to the appropriate
-   Responder (the owner of the I1 receiver HIT).  The Responder will
-   then complete the exchange with the Initiator, typically without
-   ongoing help from the RVS.
-
-4.2.  Initiating Connections Based on DNS Names
-
-   On a HIP node, a Host Identity Protocol exchange SHOULD be initiated
-   whenever a ULP attempts to communicate with an entity and the DNS
-   lookup returns HIP resource records.
-
-
-
-Nikander & Laganier           Experimental                      [Page 8]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-5.  HIP RR Storage Format
-
-   The RDATA for a HIP RR consists of a public key algorithm type, the
-   HIT length, a HIT, a public key, and optionally one or more
-   rendezvous server(s).
-
-    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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  HIT length   | PK algorithm  |          PK length            |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               |
-   ~                           HIT                                 ~
-   |                                                               |
-   +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                     |                                         |
-   +-+-+-+-+-+-+-+-+-+-+-+                                         +
-   |                           Public Key                          |
-   ~                                                               ~
-   |                                                               |
-   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                               |                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
-   |                                                               |
-   ~                       Rendezvous Servers                      ~
-   |                                                               |
-   +             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |             |
-   +-+-+-+-+-+-+-+
-
-   The HIT length, PK algorithm, PK length, HIT, and Public Key fields
-   are REQUIRED.  The Rendezvous Servers field is OPTIONAL.
-
-5.1.  HIT Length Format
-
-   The HIT length indicates the length in bytes of the HIT field.  This
-   is an 8-bit unsigned integer.
-
-5.2.  PK Algorithm Format
-
-   The PK algorithm field indicates the public key cryptographic
-   algorithm and the implied public key field format.  This is an 8-bit
-   unsigned integer.  This document reuses the values defined for the
-   'algorithm type' of the IPSECKEY RR [RFC4025].
-
-   Presently defined values are listed in Section 9 for reference.
-
-
-
-
-
-Nikander & Laganier           Experimental                      [Page 9]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-5.3.  PK Length Format
-
-   The PK length indicates the length in bytes of the Public key field.
-   This is a 16-bit unsigned integer in network byte order.
-
-5.4.  HIT Format
-
-   The HIT is stored as a binary value in network byte order.
-
-5.5.  Public Key Format
-
-   Both of the public key types defined in this document (RSA and DSA)
-   reuse the public key formats defined for the IPSECKEY RR [RFC4025].
-
-   The DSA key format is defined in RFC 2536 [RFC2536].
-
-   The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key
-   size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025]
-   specification.
-
-5.6.  Rendezvous Servers Format
-
-   The Rendezvous Servers field indicates one or more variable length
-   wire-encoded domain names of rendezvous server(s), as described in
-   Section 3.3 of RFC 1035 [RFC1035].  The wire-encoded format is self-
-   describing, so the length is implicit.  The domain names MUST NOT be
-   compressed.  The rendezvous server(s) are listed in order of
-   preference (i.e., first rendezvous server(s) are preferred), defining
-   an implicit order amongst rendezvous servers of a single RR.  When
-   multiple HIP RRs are present at the same owner name, this implicit
-   order of rendezvous servers within an RR MUST NOT be used to infer a
-   preference order between rendezvous servers stored in different RRs.
-
-6.  HIP RR Presentation Format
-
-   This section specifies the representation of the HIP RR in a zone
-   master file.
-
-   The HIT length field is not represented, as it is implicitly known
-   thanks to the HIT field representation.
-
-   The PK algorithm field is represented as unsigned integers.
-
-   The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a.
-   hex or hexadecimal) of the HIT.  The encoding MUST NOT contain
-   whitespaces to distinguish it from the public key field.
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 10]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   The Public Key field is represented as the Base64 encoding [RFC4648]
-   of the public key.  The encoding MUST NOT contain whitespace(s) to
-   distinguish it from the Rendezvous Servers field.
-
-   The PK length field is not represented, as it is implicitly known
-   thanks to the Public key field representation containing no
-   whitespaces.
-
-   The Rendezvous Servers field is represented by one or more domain
-   name(s) separated by whitespace(s).
-
-   The complete representation of the HPIHI record is:
-
-   IN  HIP   ( pk-algorithm
-               base16-encoded-hit
-               base64-encoded-public-key
-               rendezvous-server[1]
-                       ...
-               rendezvous-server[n] )
-
-   When no RVSs are present, the representation of the HPIHI record is:
-
-   IN  HIP   ( pk-algorithm
-               base16-encoded-hit
-               base64-encoded-public-key )
-
-7.  Examples
-
-   In the examples below, the public key field containing no whitespace
-   is wrapped since it does not fit in a single line of this document.
-
-   Example of a node with HI and HIT but no RVS:
-
-www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
-                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
-9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
-b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D )
-
-   Example of a node with a HI, HIT, and one RVS:
-
-www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
-                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
-9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
-b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
-                                rvs.example.com. )
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 11]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   Example of a node with a HI, HIT, and two RVSs:
-
-www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
-                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
-9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
-b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
-                                rvs1.example.com.
-                                rvs2.example.com. )
-
-8.  Security Considerations
-
-   This section contains a description of the known threats involved
-   with the usage of the HIP DNS Extension.
-
-   In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS
-   Extension allows for the provision of two HIP nodes with the public
-   keying material (HI) of their peer.  These HIs will be subsequently
-   used in a key exchange between the peers.  Hence, the HIP DNS
-   Extension introduces the same kind of threats that IPSECKEY does,
-   plus threats caused by the possibility given to a HIP node to
-   initiate or accept a HIP exchange using "opportunistic" or
-   "unpublished Initiator HI" modes.
-
-   A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure
-   channel ensuring data integrity and authenticity of the RRs.  DNSSEC
-   [RFC4033] [RFC4034] [RFC4035] provides such a secure channel.
-   However, it should be emphasized that DNSSEC only offers data
-   integrity and authenticity guarantees to the channel between the DNS
-   server publishing a zone and the HIP node.  DNSSEC does not ensure
-   that the entity publishing the zone is trusted.  Therefore, the RRSIG
-   signature of the HIP RRSet MUST NOT be misinterpreted as a
-   certificate binding the HI and/or the HIT to the owner name.
-
-   In the absence of a proper secure channel, both parties are
-   vulnerable to MitM and DoS attacks, and unrelated parties might be
-   subject to DoS attacks as well.  These threats are described in the
-   following sections.
-
-8.1.  Attacker Tampering with an Insecure HIP RR
-
-   The HIP RR contains public keying material in the form of the named
-   peer's public key (the HI) and its secure hash (the HIT).  Both of
-   these are not sensitive to attacks where an adversary gains knowledge
-   of them.  However, an attacker that is able to mount an active attack
-   on the DNS, i.e., tampers with this HIP RR (e.g., using DNS
-   spoofing), is able to mount Man-in-the-Middle attacks on the
-   cryptographic core of the eventual HIP exchange (Responder's HIP RR
-   rewritten by the attacker).
-
-
-
-Nikander & Laganier           Experimental                     [Page 12]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   The HIP RR may contain a rendezvous server domain name resolved into
-   a destination IP address where the named peer is reachable by an I1,
-   as per the HIP Rendezvous Extension [RFC5204].  Thus, an attacker
-   able to tamper with this RR is able to redirect I1 packets sent to
-   the named peer to a chosen IP address for DoS or MitM attacks.  Note
-   that this kind of attack is not specific to HIP and exists
-   independently of whether or not HIP and the HIP RR are used.  Such an
-   attacker might tamper with A and AAAA RRs as well.
-
-   An attacker might obviously use these two attacks in conjunction: It
-   will replace the Responder's HI and RVS IP address by its own in a
-   spoofed DNS packet sent to the Initiator HI, then redirect all
-   exchanged packets to him and mount a MitM on HIP.  In this case, HIP
-   won't provide confidentiality nor Initiator HI protection from
-   eavesdroppers.
-
-8.2.  Hash and HITs Collisions
-
-   As with many cryptographic algorithms, some secure hashes (e.g.,
-   SHA1, used by HIP to generate a HIT from an HI) eventually become
-   insecure, because an exploit has been found in which an attacker with
-   reasonable computation power breaks one of the security features of
-   the hash (e.g., its supposed collision resistance).  This is why a
-   HIP end-node implementation SHOULD NOT authenticate its HIP peers
-   based solely on a HIT retrieved from the DNS, but SHOULD rather use
-   HI-based authentication.
-
-8.3.  DNSSEC
-
-   In the absence of DNSSEC, the HIP RR is subject to the threats
-   described in RFC 3833 [RFC3833].
-
-9.  IANA Considerations
-
-   IANA has allocated one new RR type code (55) for the HIP RR from the
-   standard RR type space.
-
-   IANA does not need to open a new registry for public key algorithms
-   of the HIP RR because the HIP RR reuses "algorithms types" defined
-   for the IPSECKEY RR [RFC4025].  Presently defined values are shown
-   here for reference only:
-
-      0 is reserved
-
-      1 is DSA
-
-      2 is RSA
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 13]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   In the future, if a new algorithm is to be used for the HIP RR, a new
-   algorithm type and corresponding public key encoding should be
-   defined for the IPSECKEY RR.  The HIP RR should reuse both the same
-   algorithm type and the same corresponding public key format as the
-   IPSECKEY RR.
-
-10.  Acknowledgments
-
-   As usual in the IETF, this document is the result of a collaboration
-   between many people.  The authors would like to thank the author
-   (Michael Richardson), contributors, and reviewers of the IPSECKEY RR
-   [RFC4025] specification, after which this document was framed.  The
-   authors would also like to thank the following people, who have
-   provided thoughtful and helpful discussions and/or suggestions, that
-   have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu
-   Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman,
-   Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro.
-   Some parts of this document stem from the HIP specification
-   [RFC5201].
-
-11.  References
-
-11.1.  Normative references
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
-              "DNS Extensions to Support IP Version 6", RFC 3596,
-              October 2003.
-
-   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
-              Material in DNS", RFC 4025, March 2005.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 14]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-   [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.
-
-   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 4648, October 2006.
-
-   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
-              Henderson, "Host Identity Protocol", RFC 5201, April 2008.
-
-   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
-              Rendezvous Extension", RFC 5204, April 2008.
-
-11.2.  Informative references
-
-   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-              (DNS)", RFC 2536, March 1999.
-
-   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
-              (HIP) Architecture", RFC 4423, May 2006.
-
-   [RFC5206]  Henderson, T., Ed., "End-Host Mobility and Multihoming
-              with the Host Identity Protocol", RFC 5206, April 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 15]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-Authors' Addresses
-
-   Pekka Nikander
-   Ericsson Research NomadicLab
-   JORVAS  FIN-02420
-   FINLAND
-
-   Phone: +358 9 299 1
-   EMail: pekka.nikander@nomadiclab.com
-
-
-   Julien Laganier
-   DoCoMo Communications Laboratories Europe GmbH
-   Landsberger Strasse 312
-   Munich  80687
-   Germany
-
-   Phone: +49 89 56824 231
-   EMail: julien.ietf@laposte.net
-   URI:   http://www.docomolab-euro.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 16]
-
-RFC 5205                   HIP DNS Extension                  April 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Nikander & Laganier           Experimental                     [Page 17]
-

doc/rfc/rfc5625.txt

@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Bellis
-Request for Comments: 5625                                    Nominet UK
-BCP: 152                                                     August 2009
-Category: Best Current Practice
-
-
-                  DNS Proxy Implementation Guidelines
-
-Abstract
-
-   This document provides guidelines for the implementation of DNS
-   proxies, as found in broadband gateways and other similar network
-   devices.
-
-Status of This Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 1]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Terminology .....................................................3
-   3. The Transparency Principle ......................................3
-   4. Protocol Conformance ............................................4
-      4.1. Unexpected Flags and Data ..................................4
-      4.2. Label Compression ..........................................4
-      4.3. Unknown Resource Record Types ..............................4
-      4.4. Packet Size Limits .........................................4
-           4.4.1. TCP Transport .......................................5
-           4.4.2. Extension Mechanisms for DNS (EDNS0) ................6
-           4.4.3. IP Fragmentation ....................................6
-      4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7
-   5. DHCP's Interaction with DNS .....................................7
-      5.1. Domain Name Server (DHCP Option 6) .........................7
-      5.2. Domain Name (DHCP Option 15) ...............................8
-      5.3. DHCP Leases ................................................8
-   6. Security Considerations .........................................9
-      6.1. Forgery Resilience .........................................9
-      6.2. Interface Binding .........................................10
-      6.3. Packet Filtering ..........................................10
-   7. Acknowledgements ...............................................10
-   8. References .....................................................11
-      8.1. Normative References ......................................11
-      8.2. Informative References ....................................12
-
-1.  Introduction
-
-   Research has found ([SAC035], [DOTSE]) that many commonly used
-   broadband gateways (and similar devices) contain DNS proxies that are
-   incompatible in various ways with current DNS standards.
-
-   These proxies are usually simple DNS forwarders, but typically do not
-   have any caching capabilities.  The proxy serves as a convenient
-   default DNS resolver for clients on the LAN, but relies on an
-   upstream resolver (e.g., at an ISP) to perform recursive DNS lookups.
-
-   Note that to ensure full DNS protocol interoperability it is
-   preferred that client stub resolvers should communicate directly with
-   full-feature, upstream recursive resolvers wherever possible.
-
-   That notwithstanding, this document describes the incompatibilities
-   that have been discovered and offers guidelines to implementors on
-   how to provide better interoperability in those cases where the
-   client must use the broadband gateway's DNS proxy.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 2]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-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 [RFC2119].
-
-3.  The Transparency Principle
-
-   It is not considered practical for a simple DNS proxy to implement
-   all current and future DNS features.
-
-   There are several reasons why this is the case:
-
-   o  Broadband gateways usually have limited hardware resources.
-
-   o  Firmware upgrade cycles are long, and many users do not routinely
-      apply upgrades when they become available.
-
-   o  No one knows what those future DNS features will be or how they
-      might be implemented.
-
-   o  Doing so would substantially complicate the configuration user
-      interface (UI) of the device.
-
-   Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0
-   below) are intended to be used as "hop-by-hop" mechanisms.  If the
-   DNS proxy is considered to be such a "hop" in the resolution chain,
-   then for it to function correctly, it would need to be fully
-   compliant with all such mechanisms.
-
-   [SAC035] shows that the more actively a proxy participates in the DNS
-   protocol, the more likely it is that it will somehow interfere with
-   the flow of messages between the DNS client and the upstream
-   recursive resolvers.
-
-   The role of the proxy should therefore be no more and no less than to
-   receive DNS requests from clients on the LAN side, forward those
-   verbatim to one of the known upstream recursive resolvers on the WAN
-   side, and ensure that the whole response is returned verbatim to the
-   original client.
-
-   It is RECOMMENDED that proxies should be as transparent as possible,
-   such that any "hop-by-hop" mechanisms or newly introduced protocol
-   extensions operate as if the proxy were not there.
-
-   Except when required to enforce an active security or network policy
-   (such as maintaining a pre-authentication "walled garden"), end-users
-   SHOULD be able to send their DNS queries to specified upstream
-
-
-
-Bellis                   Best Current Practice                  [Page 3]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   resolvers, thereby bypassing the proxy altogether.  In this case, the
-   gateway SHOULD NOT modify the DNS request or response packets in any
-   way.
-
-4.  Protocol Conformance
-
-4.1.  Unexpected Flags and Data
-
-   The Transparency Principle above, when combined with Postel's
-   Robustness Principle [RFC0793], suggests that DNS proxies should not
-   arbitrarily reject or otherwise drop requests or responses based on
-   perceived non-compliance with standards.
-
-   For example, some proxies have been observed to drop any packet
-   containing either the "Authentic Data" (AD) or "Checking Disabled"
-   (CD) bits from DNSSEC [RFC4035].  This may be because [RFC1035]
-   originally specified that these unused "Z" flag bits "MUST" be zero.
-   However, these flag bits were always intended to be reserved for
-   future use, so refusing to proxy any packet containing these flags
-   (now that uses for those flags have indeed been defined) is not
-   appropriate.
-
-   Therefore, proxies MUST ignore any unknown DNS flags and proxy those
-   packets as usual.
-
-4.2.  Label Compression
-
-   Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
-
-   Proxies MUST forward packets regardless of the presence or absence of
-   compressed labels therein.
-
-4.3.  Unknown Resource Record Types
-
-   [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
-   of unknown type transparently.
-
-   All requests and responses MUST be proxied regardless of the values
-   of the QTYPE and QCLASS fields.
-
-   Similarly, all responses MUST be proxied regardless of the values of
-   the TYPE and CLASS fields of any Resource Record therein.
-
-4.4.  Packet Size Limits
-
-   [RFC1035] specifies that the maximum size of the DNS payload in a UDP
-   packet is 512 octets.  Where the required portions of a response
-   would not fit inside that limit, the DNS server MUST set the
-
-
-
-Bellis                   Best Current Practice                  [Page 4]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   "TrunCation" (TC) bit in the DNS response header to indicate that
-   truncation has occurred.  There are however two standard mechanisms
-   (described in Sections 4.4.1 and 4.4.2) for transporting responses
-   larger than 512 octets.
-
-   Many proxies have been observed to truncate all responses at 512
-   octets, and others at a packet size related to the WAN MTU, in either
-   case doing so without correctly setting the TC bit.
-
-   Other proxies have been observed to remove the TC bit in server
-   responses that correctly had the TC bit set by the server.
-
-   If a DNS response is truncated but the TC bit is not set, then client
-   failures may result.  In particular, a naive DNS client library might
-   suffer crashes due to reading beyond the end of the data actually
-   received.
-
-   Since UDP packets larger than 512 octets are now expected in normal
-   operation, proxies SHOULD NOT truncate UDP packets that exceed that
-   size.  See Section 4.4.3 for recommendations for packet sizes
-   exceeding the WAN MTU.
-
-   If a proxy must unilaterally truncate a response, then the proxy MUST
-   set the TC bit.  Similarly, proxies MUST NOT remove the TC bit from
-   responses.
-
-4.4.1.  TCP Transport
-
-   Should a UDP query fail because of truncation, the standard fail-over
-   mechanism is to retry the query using TCP, as described in Section
-   6.1.3.2 of [RFC1123].
-
-   Whilst TCP transport is not strictly mandatory, it is supported by
-   the vast majority of stub resolvers and recursive servers.  Lack of
-   support in the proxy prevents this fail-over mechanism from working.
-
-   DNS proxies MUST therefore be prepared to receive and forward queries
-   over TCP.
-
-   Note that it is unlikely that a client would send a request over TCP
-   unless it had already received a truncated UDP response.  Some
-   "smart" proxies have been observed to first forward any request
-   received over TCP to an upstream resolver over UDP, only for the
-   response to be truncated, causing the proxy to retry over TCP.  Such
-   behaviour increases network traffic and causes delay in DNS
-   resolution since the initial UDP request is doomed to fail.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 5]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   Therefore, whenever a proxy receives a request over TCP, the proxy
-   SHOULD forward the query over TCP and SHOULD NOT attempt the same
-   query over UDP first.
-
-4.4.2.  Extension Mechanisms for DNS (EDNS0)
-
-   The "Extension Mechanism for DNS" [RFC2671] was introduced to allow
-   the transport of larger DNS packets over UDP and also to allow for
-   additional request and response flags.
-
-   A client may send an OPT Resource Record (OPT RR) in the Additional
-   Section of a request to indicate that it supports a specific receive
-   buffer size.  The OPT RR also includes the "DNSSEC OK" (DO) flag used
-   by DNSSEC to indicate that DNSSEC-related RRs should be returned to
-   the client.
-
-   However, some proxies have been observed to either reject (with a
-   FORMERR response code) or black-hole any packet containing an OPT RR.
-   As per Section 4.1, proxies MUST NOT refuse to proxy such packets.
-
-4.4.3.  IP Fragmentation
-
-   Support for UDP packet sizes exceeding the WAN MTU depends on the
-   gateway's algorithm for handling fragmented IP packets.  Several
-   methods are possible:
-
-   1.  Fragments are dropped.
-
-   2.  Fragments are forwarded individually as they're received.
-
-   3.  Complete packets are reassembled on the gateway and then re-
-       fragmented (if necessary) as they're forwarded to the client.
-
-   Method 1 above will cause compatibility problems with EDNS0 unless
-   the DNS client is configured to advertise an EDNS0 buffer size
-   limited to the WAN MTU less the size of the IP header.  Note that RFC
-   2671 does recommend that the path MTU should be taken into account
-   when using EDNS0.
-
-   Also, whilst the EDNS0 specification allows for a buffer size of up
-   to 65535 octets, most common DNS server implementations do not
-   support a buffer size above 4096 octets.
-
-   Therefore (irrespective of which of the above methods is in use),
-   proxies SHOULD be capable of forwarding UDP packets up to a payload
-   size of at least 4096 octets.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 6]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   NB: in theory, IP fragmentation may also occur if the LAN MTU is
-   smaller than the WAN MTU, although the author has not observed such a
-   configuration in use on any residential broadband service.
-
-4.5.  Secret Key Transaction Authentication for DNS (TSIG)
-
-   [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
-   requests and responses at the packet level.
-
-   Any modifications made to the DNS portions of a TSIG-signed query or
-   response packet (with the exception of the Query ID) will cause a
-   TSIG authentication failure.
-
-   DNS proxies MUST implement Section 4.7 of [RFC2845] and either
-   forward packets unchanged (as recommended above) or fully implement
-   TSIG.
-
-   As per Section 4.3, DNS proxies MUST be capable of proxying packets
-   containing TKEY [RFC2930] Resource Records.
-
-   NB: any DNS proxy (such as those commonly found in WiFi hotspot
-   "walled gardens") that transparently intercepts all DNS queries and
-   that returns unsigned responses to signed queries, will also cause
-   TSIG authentication failures.
-
-5.  DHCP's Interaction with DNS
-
-   Whilst this document is primarily about DNS proxies, most consumers
-   rely on DHCP [RFC2131] to obtain network configuration settings.
-   Such settings include the client machine's IP address, subnet mask,
-   and default gateway, but also include DNS-related settings.
-
-   It is therefore appropriate to examine how DHCP affects client DNS
-   configuration.
-
-5.1.  Domain Name Server (DHCP Option 6)
-
-   Most gateways default to supplying their own IP address in the DHCP
-   "Domain Name Server" option [RFC2132].  The net result is that
-   without explicit re-configuration many DNS clients will, by default,
-   send queries to the gateway's DNS proxy.  This is understandable
-   behaviour given that the correct upstream settings are not usually
-   known at boot time.
-
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 7]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   Most gateways learn their own DNS settings via values supplied by an
-   ISP via DHCP or PPP over the WAN interface.  However, whilst many
-   gateways do allow the device administrator to override those values,
-   some gateways only use those supplied values to affect the proxy's
-   own forwarding function, and do not offer these values via DHCP.
-
-   When using such a device, the only way to avoid using the DNS proxy
-   is to hard-code the required values in the client operating system.
-   This may be acceptable for a desktop system but it is inappropriate
-   for mobile devices that are regularly used on many different
-   networks.
-
-   As per Section 3, end-users SHOULD be able to send their DNS queries
-   directly to specified upstream resolvers, ideally without hard-coding
-   those settings in their stub resolver.
-
-   It is therefore RECOMMENDED that gateways SHOULD support device-
-   administrator configuration of values for the "Domain Name Server"
-   DHCP option.
-
-5.2.  Domain Name (DHCP Option 15)
-
-   A significant amount of traffic to the DNS Root Name Servers is for
-   invalid top-level domain names, and some of that traffic can be
-   attributed to particular equipment vendors whose firmware defaults
-   this DHCP option to specific values.
-
-   Since no standard exists for a "local" scoped domain name suffix, it
-   is RECOMMENDED that the default value for this option SHOULD be
-   empty, and that this option MUST NOT be sent to clients when no value
-   is configured.
-
-5.3.  DHCP Leases
-
-   It is noted that some DHCP servers in broadband gateways offer, by
-   default, their own IP address for the "Domain Name Server" option (as
-   described above) but then automatically start offering the upstream
-   servers' addresses once they've been learnt over the WAN interface.
-
-   In general, this behaviour is highly desirable, but the effect for
-   the end-user is that the settings used depend on whether the DHCP
-   lease was obtained before or after the WAN link was established.
-
-   If the DHCP lease is obtained whilst the WAN link is down, then the
-   DHCP client (and hence the DNS client) will not receive the correct
-   values until the DHCP lease is renewed.
-
-
-
-
-
-Bellis                   Best Current Practice                  [Page 8]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   Whilst no specific recommendations are given here, vendors may wish
-   to give consideration to the length of DHCP leases and to whether
-   some mechanism for forcing a DHCP lease renewal might be appropriate.
-
-   Another possibility is that the learnt upstream values might be
-   persisted in non-volatile memory such that on reboot the same values
-   can be automatically offered via DHCP.  However, this does run the
-   risk that incorrect values are initially offered if the device is
-   moved or connected to another ISP.
-
-   Alternatively, the DHCP server might only issue very short (i.e., 60
-   second) leases while the WAN link is down, only reverting to more
-   typical lease lengths once the WAN link is up and the upstream DNS
-   servers are known.  Indeed, with such a configuration it may be
-   possible to avoid the need to implement a DNS proxy function in the
-   broadband gateway at all.
-
-6.  Security Considerations
-
-   This document introduces no new protocols.  However, there are some
-   security-related recommendations for vendors that are listed here.
-
-6.1.  Forgery Resilience
-
-   Whilst DNS proxies are not usually full-feature resolvers, they
-   nevertheless share some characteristics with them.
-
-   Notwithstanding the recommendations above about transparency, many
-   DNS proxies are observed to pick a new Query ID for outbound requests
-   to ensure that responses are directed to the correct client.
-
-   NB: changing the Query ID is acceptable and compatible with proxying
-   TSIG-signed packets since the TSIG signature calculation is based on
-   the original message ID, which is carried in the TSIG RR.
-
-   It has been standard guidance for many years that each DNS query
-   should use a randomly generated Query ID.  However, many proxies have
-   been observed picking sequential Query IDs for successive requests.
-
-   It is strongly RECOMMENDED that DNS proxies follow the relevant
-   recommendations in [RFC5452], particularly those in Section 9.2
-   relating to randomisation of Query IDs and source ports.  This also
-   applies to source port selection within any NAT function.
-
-   If a DNS proxy is running on a broadband gateway with NAT that is
-   compliant with [RFC4787], then it SHOULD also follow the
-   recommendations in Section 10 of [RFC5452] concerning how long DNS
-   state is kept.
-
-
-
-Bellis                   Best Current Practice                  [Page 9]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-6.2.  Interface Binding
-
-   Some gateways have been observed to have their DNS proxy listening on
-   both internal (LAN) and external (WAN) interfaces.  In this
-   configuration, it is possible for the proxy to be used to mount
-   reflector attacks as described in [RFC5358].
-
-   The DNS proxy in a gateway SHOULD NOT, by default, be accessible from
-   the WAN interfaces of the device.
-
-6.3.  Packet Filtering
-
-   The Transparency and Robustness Principles are not entirely
-   compatible with the deep packet-inspection features of security
-   appliances such as firewalls, which are intended to protect systems
-   on the inside of a network from rogue traffic.
-
-   However, a clear distinction may be made between traffic that is
-   intrinsically malformed and that which merely contains unexpected
-   data.
-
-   Examples of malformed packets that MAY be dropped include:
-
-   o  invalid compression pointers (i.e., those that point outside of
-      the current packet or that might cause a parsing loop)
-
-   o  incorrect counts for the Question, Answer, Authority, and
-      Additional Sections (although care should be taken where
-      truncation is a possibility)
-
-   Dropped packets will cause the client to repeatedly retransmit the
-   original request, with the client only detecting the error after
-   several retransmit intervals.
-
-   In these circumstances, proxies SHOULD synthesise a suitable DNS
-   error response to the client (i.e., SERVFAIL) instead of dropping the
-   packet completely.  This will allow the client to detect the error
-   immediately.
-
-7.  Acknowledgements
-
-   The author would particularly like to acknowledge the assistance of
-   Lisa Phifer of Core Competence.  In addition, the author is grateful
-   for the feedback from the members of the DNSEXT Working Group.
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                 [Page 10]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
-              RFC 793, September 1981.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
-              and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
-              RFC 2131, March 1997.
-
-   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-              Extensions", RFC 2132, March 1997.
-
-   [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.
-
-   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
-              (RR) Types", RFC 3597, September 2003.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
-              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
-              RFC 4787, January 2007.
-
-   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
-              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
-              October 2008.
-
-
-
-
-
-Bellis                   Best Current Practice                 [Page 11]
-
-RFC 5625          DNS Proxy Implementation Guidelines        August 2009
-
-
-   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
-              Resilient against Forged Answers", RFC 5452, January 2009.
-
-8.2.  Informative References
-
-   [DOTSE]    Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
-              Routers", February 2008,
-              <http://www.iis.se/docs/Routertester_en.pdf>.
-
-   [SAC035]   Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
-              Broadband Routers and Firewalls", September 2008,
-              <http://www.icann.org/committees/security/sac035.pdf>.
-
-Author's Address
-
-   Ray Bellis
-   Nominet UK
-   Edmund Halley Road
-   Oxford  OX4 4DQ
-   United Kingdom
-
-   Phone: +44 1865 332211
-   EMail: ray.bellis@nominet.org.uk
-   URI:   http://www.nominet.org.uk/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis                   Best Current Practice                 [Page 12]
-

doc/rfc/rfc5702.txt

@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          J. Jansen
-Request for Comments: 5702                                    NLnet Labs
-Category: Standards Track                                   October 2009
-
-
-                  Use of SHA-2 Algorithms with RSA in
-              DNSKEY and RRSIG Resource Records for DNSSEC
-
-Abstract
-
-   This document describes how to produce RSA/SHA-256 and RSA/SHA-512
-   DNSKEY and RRSIG resource records for use in the Domain Name System
-   Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 1]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. DNSKEY Resource Records .........................................3
-      2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
-      2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
-   3. RRSIG Resource Records ..........................................3
-      3.1. RSA/SHA-256 RRSIG Resource Records .........................4
-      3.2. RSA/SHA-512 RRSIG Resource Records .........................4
-   4. Deployment Considerations .......................................5
-      4.1. Key Sizes ..................................................5
-      4.2. Signature Sizes ............................................5
-   5. Implementation Considerations ...................................5
-      5.1. Support for SHA-2 Signatures ...............................5
-      5.2. Support for NSEC3 Denial of Existence ......................5
-   6. Examples ........................................................6
-      6.1. RSA/SHA-256 Key and Signature ..............................6
-      6.2. RSA/SHA-512 Key and Signature ..............................7
-   7. IANA Considerations .............................................8
-   8. Security Considerations .........................................8
-      8.1. SHA-1 versus SHA-2 Considerations for RRSIG
-           Resource Records ...........................................8
-      8.2. Signature Type Downgrade Attacks ...........................8
-   9. Acknowledgments .................................................9
-   10. References .....................................................9
-      10.1. Normative References ......................................9
-      10.2. Informative References ....................................9
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global, hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  [RFC4033], [RFC4034], and
-   [RFC4035] describe these DNS Security Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the algorithms RSA/SHA-256 and RSA/
-   SHA-512, and specifies how to store DNSKEY data and how to produce
-   RRSIG resource records with these hash algorithms.
-
-   Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family
-   of algorithms is assumed in this document.
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 2]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-   To refer to both SHA-256 and SHA-512, this document will use the name
-   SHA-2.  This is done to improve readability.  When a part of text is
-   specific for either SHA-256 or SHA-512, their specific names are
-   used.  The same goes for RSA/SHA-256 and RSA/SHA-512, which will be
-   grouped using the name RSA/SHA-2.
-
-   The term "SHA-2" is not officially defined but is usually used to
-   refer to the collection of the algorithms SHA-224, SHA-256, SHA-384,
-   and SHA-512.  Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2
-   will only refer to SHA-256 and SHA-512 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 [RFC2119].
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in [RFC4034].  [RFC3110]
-   describes the use of RSA/SHA-1 for DNSSEC signatures.
-
-2.1.  RSA/SHA-256 DNSKEY Resource Records
-
-   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
-   resource records (RRs) with the algorithm number 8.
-
-   For interoperability, as in [RFC3110], the key size of RSA/SHA-256
-   keys MUST NOT be less than 512 bits and MUST NOT be more than 4096
-   bits.
-
-2.2.  RSA/SHA-512 DNSKEY Resource Records
-
-   RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
-   resource records (RRs) with the algorithm number 10.
-
-   The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and
-   MUST NOT be more than 4096 bits.
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows the RSASSA-
-   PKCS1-v1_5 signature scheme and is calculated as follows.  The values
-   for the RDATA fields that precede the signature data are specified in
-   [RFC4034].
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 3]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-   hash = SHA-XXX(data)
-
-   Here XXX is either 256 or 512, depending on the algorithm used, as
-   specified in FIPS PUB 180-3; "data" is the wire format data of the
-   resource record set that is signed, as specified in [RFC4034].
-
-   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-   Here "|" is concatenation; "00", "01", "FF", and "00" are fixed
-   octets of corresponding hexadecimal value; "e" is the private
-   exponent of the signing RSA key; and "n" is the public modulus of the
-   signing key.  The FF octet MUST be repeated the exact number of times
-   so that the total length of the concatenated term in parentheses
-   equals the length of the modulus of the signer's public key ("n").
-
-   The "prefix" is intended to make the use of standard cryptographic
-   libraries easier.  These specifications are taken directly from the
-   specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of
-   [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2
-   of [RFC3447]).  The prefixes for the different algorithms are
-   specified below.
-
-3.1.  RSA/SHA-256 RRSIG Resource Records
-
-   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
-   records (RRs) with algorithm number 8.
-
-   The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as
-   specified in PKCS #1 v2.1 [RFC3447]:
-
-   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
-3.2.  RSA/SHA-512 RRSIG Resource Records
-
-   RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
-   records (RRs) with algorithm number 10.
-
-   The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as
-   specified in PKCS #1 v2.1 [RFC3447]:
-
-   hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 4]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-4.  Deployment Considerations
-
-4.1.  Key Sizes
-
-   Apart from the restrictions in Section 2, this document will not
-   specify what size of keys to use.  That is an operational issue and
-   depends largely on the environment and intended use.  A good starting
-   point for more information would be NIST SP 800-57 [NIST800-57].
-
-4.2.  Signature Sizes
-
-   In this family of signing algorithms, the size of signatures is
-   related to the size of the key and not to the hashing algorithm used
-   in the signing process.  Therefore, RRSIG resource records produced
-   with RSA/SHA-256 or RSA/SHA-512 will have the same size as those
-   produced with RSA/SHA-1, if the keys have the same length.
-
-5.  Implementation Considerations
-
-5.1.  Support for SHA-2 Signatures
-
-   DNSSEC-aware implementations SHOULD be able to support RRSIG and
-   DNSKEY resource records created with the RSA/SHA-2 algorithms as
-   defined in this document.
-
-5.2.  Support for NSEC3 Denial of Existence
-
-   [RFC5155] defines new algorithm identifiers for existing signing
-   algorithms, to indicate that zones signed with these algorithm
-   identifiers can use NSEC3 as well as NSEC records to provide denial
-   of existence.  That mechanism was chosen to protect implementations
-   predating RFC 5155 from encountering resource records about which
-   they could not know.  This document does not define such algorithm
-   aliases.
-
-   A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate
-   negative answers in the form of both NSEC and NSEC3 with hash
-   algorithm 1, as defined in [RFC5155].  An authoritative server that
-   does not implement NSEC3 MAY still serve zones that use RSA/SHA-2
-   with NSEC denial of existence.
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 5]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-6.  Examples
-
-6.1.  RSA/SHA-256 Key and Signature
-
-   Given a private key with the following values (in Base64):
-
-   Private-key-format: v1.2
-   Algorithm:       8 (RSASHA256)
-   Modulus:         wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
-                    idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
-   PublicExponent:  AQAB
-   PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
-                    HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
-   Prime1:          4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
-   Prime2:          2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
-   Exponent1:       G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
-   Exponent2:       GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
-   Coefficient:     icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
-
-   The DNSKEY record for this key would be:
-
-   example.net.     3600  IN  DNSKEY  (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
-                    my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
-                    kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
-
-   With this key, sign the following RRSet, consisting of 1 A record:
-
-   www.example.net. 3600  IN  A  192.0.2.91
-
-   If the inception date is set at 00:00 hours on January 1st, 2000, and
-   the expiration date at 00:00 hours on January 1st, 2030, the
-   following signature should be created:
-
- www.example.net. 3600  IN  RRSIG  (A 8 3 3600 20300101000000
-                     20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
-                     l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
-                     cFYK/lPtPiVYP4bwg==);{id = 9033}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 6]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-6.2.  RSA/SHA-512 Key and Signature
-
-   Given a private key with the following values (in Base64):
-
-   Private-key-format: v1.2
-   Algorithm:       10 (RSASHA512)
-   Modulus:         0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
-                    Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
-                    8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
-                    jXZlNKdyit99waaE4s=
-   PublicExponent:  AQAB
-   PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
-                    AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
-                    yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
-                    SEIAsrB043XzGrKIVE=
-   Prime1:          8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
-                    nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
-   Prime2:          3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
-                    Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
-   Exponent1:       v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
-                    MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
-   Exponent2:       m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
-                    PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
-   Coefficient:     Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
-                    /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
-
-   The DNSKEY record for this key would be:
-
-   example.net.    3600  IN  DNSKEY  (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
-                   p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
-                   xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
-                   pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
-                   );{id = 3740 (zsk), size = 1024b}
-
-   With this key, sign the following RRSet, consisting of 1 A record:
-
-   www.example.net. 3600  IN  A  192.0.2.91
-
-   If the inception date is set at 00:00 hours on January 1st, 2000, and
-   the expiration date at 00:00 hours on January 1st, 2030, the
-   following signature should be created:
-
-   www.example.net. 3600  IN  RRSIG  (A 10 3 3600 20300101000000
-                    20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
-                    6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
-                    eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
-                    DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
-                    =);{id = 3740}
-
-
-
-Jansen                      Standards Track                     [Page 7]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-7.  IANA Considerations
-
-   This document updates the IANA registry "DNS SECURITY ALGORITHM
-   NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols).  The
-   following entries are added to the registry:
-
-                                             Zone  Trans.
-   Value   Description       Mnemonic    Signing    Sec.   References
-     8     RSA/SHA-256      RSASHA256          Y      *    RFC 5702
-    10     RSA/SHA-512      RSASHA512          Y      *    RFC 5702
-
-   * There has been no determination of standardization of the use of
-     this algorithm with Transaction Security.
-
-8.  Security Considerations
-
-8.1.  SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
-
-   Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
-   implementations allow for it.  SHA-2 is widely believed to be more
-   resilient to attack than SHA-1, and confidence in SHA-1's strength is
-   being eroded by recently announced attacks.  Regardless of whether or
-   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
-   time of this writing) that SHA-2 is the better choice for use in
-   DNSSEC records.
-
-   SHA-2 is considered sufficiently strong for the immediate future, but
-   predictions about future development in cryptography and
-   cryptanalysis are beyond the scope of this document.
-
-   The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one
-   used for RSA/SHA-1 signatures.  This should ease implementation of
-   the new hashing algorithms in DNSSEC software.
-
-8.2.  Signature Type Downgrade Attacks
-
-   Since each RRSet MUST be signed with each algorithm present in the
-   DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a
-   malicious party cannot filter out the RSA/SHA-2 RRSIG and force the
-   validator to use the RSA/SHA-1 signature if both are present in the
-   zone.  This should provide resilience against algorithm downgrade
-   attacks, if the validator supports RSA/SHA-2.
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                     [Page 8]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-9.  Acknowledgments
-
-   This document is a minor extension to [RFC4034].  Also, we try to
-   follow the documents [RFC3110] and [RFC4509] 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, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
-   Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose,
-   Michael St. Johns, and Wouter Wijngaards.
-
-10.  References
-
-10.1.  Normative References
-
-   [FIPS.180-3.2008]
-              National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS PUB 180-3, October 2008.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-              Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.2.  Informative References
-
-   [NIST800-57]
-              Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
-              "Recommendations for Key Management", NIST SP 800-57,
-              March 2007.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-
-
-Jansen                      Standards Track                     [Page 9]
-
-RFC 5702                    DNSSEC RSA/SHA-2                October 2009
-
-
-   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-              (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-              Security (DNSSEC) Hashed Authenticated Denial of
-              Existence", RFC 5155, March 2008.
-
-Author's Address
-
-   Jelte Jansen
-   NLnet Labs
-   Science Park 140
-   1098 XG Amsterdam
-   NL
-
-   EMail: jelte@NLnetLabs.nl
-   URI:   http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                      Standards Track                    [Page 10]
-

doc/rfc/rfc5933.txt

@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Internet Engineering Task Force (IETF)                  V. Dolmatov, Ed.
-Request for Comments: 5933                                   A. Chuprina
-Category: Standards Track                                     I. Ustinov
-ISSN: 2070-1721                                           Cryptocom Ltd.
-                                                               July 2010
-
-
-               Use of GOST Signature Algorithms in DNSKEY
-                 and RRSIG Resource Records for DNSSEC
-
-Abstract
-
-   This document describes how to produce digital signatures and hash
-   functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms
-   for DNSKEY, RRSIG, and DS resource records, for use in the Domain
-   Name System Security Extensions (DNSSEC).
-
-Status of This Memo
-
-   This is an Internet Standards Track document.
-
-   This document is a product of the Internet Engineering Task Force
-   (IETF).  It represents the consensus of the IETF community.  It has
-   received public review and has been approved for publication by the
-   Internet Engineering Steering Group (IESG).  Further information on
-   Internet Standards is available in Section 2 of RFC 5741.
-
-   Information about the current status of this document, any errata,
-   and how to provide feedback on it may be obtained at
-   http://www.rfc-editor.org/info/rfc5933.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 1]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  Using a Public Key with Existing Cryptographic
-           Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 4
-   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
-     3.1.  RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . 5
-   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
-     4.1.  DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
-     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 6
-     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 6
-   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 6
-     6.1.  Support for GOST Signatures . . . . . . . . . . . . . . . . 6
-     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 6
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
-   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
-     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Naming.  The DNS has been extended to use
-   cryptographic keys and digital signatures for the verification of the
-   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
-   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
-   Extensions, called DNSSEC.
-
-   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
-   and specifies a list of cryptographic algorithms to use.  This
-   document extends that list with the signature and hash algorithms
-   GOST R 34.10-2001 ([GOST3410], [RFC5832]) and GOST R 34.11-94
-   ([GOST3411], [RFC5831]), and specifies how to store DNSKEY data and
-   how to produce RRSIG resource records with these algorithms.
-
-   Familiarity with DNSSEC and with GOST signature and hash algorithms
-   is assumed in this document.
-
-   The term "GOST" is not officially defined, but is usually used to
-   refer to the collection of the Russian cryptographic algorithms
-   GOST R 34.10-2001 [RFC5832], GOST R 34.11-94 [RFC5831], and
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 2]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-   GOST 28147-89 [RFC5830].  Since GOST 28147-89 is not used in DNSSEC,
-   "GOST" will only refer to GOST R 34.10-2001 and GOST R 34.11-94 in
-   this document.
-
-1.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 [RFC2119].
-
-2.  DNSKEY Resource Records
-
-   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
-   GOST R 34.10-2001 public keys are stored with the algorithm
-   number 12.
-
-   The wire format of the public key is compatible with RFC 4491
-   [RFC4491]:
-
-   According to [GOST3410] and [RFC5832], a public key is a point on the
-   elliptic curve Q = (x,y).
-
-   The wire representation of a public key MUST contain 64 octets, where
-   the first 32 octets contain the little-endian representation of x and
-   the second 32 octets contain the little-endian representation of y.
-
-   Corresponding public key parameters are those identified by
-   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
-   and the digest parameters are those identified by
-   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1.  Using a Public Key with Existing Cryptographic Libraries
-
-   At the time of this writing, existing GOST-aware cryptographic
-   libraries are capable of reading GOST public keys via a generic X509
-   API if the key is encoded according to RFC 4491 [RFC4491],
-   Section 2.3.2.
-
-   To make this encoding from the wire format of a GOST public key with
-   the parameters used in this document, prepend the 64 octets of key
-   data with the following 37-byte sequence:
-
-      0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
-      0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
-      0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 3]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-2.2.  GOST DNSKEY RR Example
-
-   Given a private key with the following value (the value of the
-   GostAsn1 field is split here into two lines to simplify reading; in
-   the private key file, it must be in one line):
-
-      Private-key-format: v1.2
-      Algorithm: 12 (ECC-GOST)
-      GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M
-                iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=
-
-   The following DNSKEY RR stores a DNS zone key for example.net:
-
-      example.net. 86400 IN DNSKEY 256 3 12 (
-                                   aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
-                                   MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
-                                   w4X1gpNrZiC01g==
-                                   ) ; key id = 59732
-
-3.  RRSIG Resource Records
-
-   The value of the signature field in the RRSIG RR follows RFC 4490
-   [RFC4490] and is calculated as follows.  The values for the RDATA
-   fields that precede the signature data are specified in RFC 4034
-   [RFC4034].
-
-   hash = GOSTR3411(data)
-
-   where "data" is the wire format data of the resource record set that
-   is signed, as specified in RFC 4034 [RFC4034].
-
-   The hash MUST be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-   The signature is calculated from the hash according to the
-   GOST R 34.10-2001 standard, and its wire format is compatible with
-   RFC 4490 [RFC4490].
-
-   Quoting RFC 4490:
-
-   "The signature algorithm GOST R 34.10-2001 generates a digital
-   signature in the form of two 256-bit numbers, r and s.  Its octet
-   string representation consists of 64 octets, where the first
-   32 octets contain the big-endian representation of s and the second
-   32 octets contain the big-endian representation of r".
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 4]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-3.1.  RRSIG RR Example
-
-   With the private key from Section 2.2, sign the following RRSet,
-   consisting of one A record:
-
-      www.example.net. 3600 IN A 192.0.2.1
-
-   Setting the inception date to 2000-01-01 00:00:00 UTC and the
-   expiration date to 2030-01-01 00:00:00 UTC, the following signature
-   RR will be valid:
-
-     www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
-                                    20000101000000 59732 example.net.
-                                    7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
-                                    kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
-                                    zi67+wBbbW/jrA== )
-
-   Note: The ECC-GOST signature algorithm uses random data, so the
-   actual computed signature value will differ between signature
-   calculations.
-
-4.  DS Resource Records
-
-   The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the
-   digest type 3.  The wire format of a digest value is compatible with
-   RFC 4490 [RFC4490], that is, the digest is in little-endian
-   representation.
-
-   The digest MUST always be calculated with GOST R 34.11-94 parameters
-   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1.  DS RR Example
-
-   For Key Signing Key (KSK):
-
-      example.net. 86400   DNSKEY  257 3 12 (
-                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
-                                   gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
-                                   SRGR7ZYcx+YIQw==
-                                   ) ; key id = 40692
-
-   The DS RR will be
-
-      example.net. 3600 IN DS 40692 12 3 (
-                22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
-                2071398F )
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 5]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-5.  Deployment Considerations
-
-5.1.  Key Sizes
-
-   According to RFC 4357 [RFC4357], the key size of GOST public keys
-   MUST be 512 bits.
-
-5.2.  Signature Sizes
-
-   According to the GOST R 34.10-2001 digital signature algorithm
-   specification ([GOST3410], [RFC5832]), the size of a GOST signature
-   is 512 bits.
-
-5.3.  Digest Sizes
-
-   According to GOST R 34.11-94 ([GOST3411], [RFC5831]), the size of a
-   GOST digest is 256 bits.
-
-6.  Implementation Considerations
-
-6.1.  Support for GOST Signatures
-
-   DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY
-   resource records created with the GOST algorithms as defined in this
-   document.
-
-6.2.  Support for NSEC3 Denial of Existence
-
-   Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and
-   NSEC3 [RFC5155].
-
-7.  Security Considerations
-
-   Currently, the cryptographic resistance of the GOST R 34.10-2001
-   digital signature algorithm is estimated as 2**128 operations of
-   multiple elliptic curve point computations on prime modulus of order
-   2**256.
-
-   Currently, the cryptographic resistance of the GOST R 34.11-94 hash
-   algorithm is estimated as 2**128 operations of computations of a step
-   hash function.  (There is a known method to reduce this estimate to
-   2**105 operations, but it demands padding the colliding message with
-   1024 random bit blocks each of 256-bit length; thus, it cannot be
-   used in any practical implementation).
-
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 6]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-8.  IANA Considerations
-
-   This document updates the IANA registry "DNS Security Algorithm
-   Numbers" [RFC4034].  The following entries have been added to the
-   registry:
-
-                                      Zone    Trans.
-    Value  Algorithm         Mnemonic Signing Sec.  References   Status
-     12    GOST R 34.10-2001 ECC-GOST     Y   *     RFC 5933    OPTIONAL
-
-   This document updates the RFC 4034 Digest Types assignment
-   ([RFC4034], Section A.2) by adding the value and status for the
-   GOST R 34.11-94 algorithm:
-
-      Value   Algorithm        Status
-        3    GOST R 34.11-94  OPTIONAL
-
-9.  Acknowledgments
-
-   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
-   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
-   and RFC 4357 [RFC4357] for consistency.  The authors of and
-   contributors to these documents are gratefully acknowledged for their
-   hard work.
-
-   The following people provided additional feedback, text, and valuable
-   assistance: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson,
-   Jelte Jansen, and Wouter Wijngaards.
-
-10.  References
-
-10.1.  Normative References
-
-   [GOST3410]  "Information technology.  Cryptographic data security.
-               Signature and verification processes of [electronic]
-               digital signature.", GOST R 34.10-2001, Gosudarstvennyi
-               Standard of Russian Federation, Government Committee of
-               Russia for Standards, 2001. (In Russian).
-
-   [GOST3411]  "Information technology.  Cryptographic data security.
-               Hashing function.", GOST R 34.11-94, Gosudarstvennyi
-               Standard of Russian Federation, Government Committee of
-               Russia for Standards, 1994. (In Russian).
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 7]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-   [RFC3110]   Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-               Domain Name System (DNS)", RFC 3110, May 2001.
-
-   [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
-               Rose, "DNS Security Introduction and Requirements",
-               RFC 4033, March 2005.
-
-   [RFC4034]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
-               Rose, "Resource Records for the DNS Security Extensions",
-               RFC 4034, March 2005.
-
-   [RFC4035]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
-               Rose, "Protocol Modifications for the DNS Security
-               Extensions", RFC 4035, March 2005.
-
-   [RFC4357]   Popov, V., Kurepkin, I., and S. Leontiev, "Additional
-               Cryptographic Algorithms for Use with GOST 28147-89,
-               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-               Algorithms", RFC 4357, January 2006.
-
-   [RFC4490]   Leontiev, S., Ed. and G. Chudov, Ed., "Using the
-               GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and
-               GOST R 34.10-2001 Algorithms with Cryptographic Message
-               Syntax (CMS)", RFC 4490, May 2006.
-
-   [RFC4491]   Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the
-               GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
-               Algorithms with the Internet X.509 Public Key
-               Infrastructure Certificate and CRL Profile", RFC 4491,
-               May 2006.
-
-   [RFC5155]   Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
-               Security (DNSSEC) Hashed Authenticated Denial of
-               Existence", RFC 5155, March 2008.
-
-10.2.  Informative References
-
-   [RFC4509]   Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
-               (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
-   [RFC5830]   Dolmatov, V., Ed., "GOST 28147-89: Encryption,
-               Decryption, and Message Authentication Code (MAC)
-               Algorithms", RFC 5830, March 2010.
-
-   [RFC5831]   Dolmatov, V., Ed., "GOST R 34.11-94: Hash Function
-               Algorithm", RFC 5831, March 2010.
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 8]
-
-RFC 5933            Use of GOST Signatures in DNSSEC           July 2010
-
-
-   [RFC5832]   Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature
-               Algorithm", RFC 5832, March 2010.
-
-Authors' Addresses
-
-   Vasily Dolmatov (editor)
-   Cryptocom Ltd.
-   14/2, Kedrova St.
-   Moscow,   117218
-   Russian Federation
-
-   Phone: +7 499 124 6226
-   EMail: dol@cryptocom.ru
-
-
-   Artem Chuprina
-   Cryptocom Ltd.
-   14/2, Kedrova St.
-   Moscow,   117218
-   Russian Federation
-
-   Phone: +7 499 124 6226
-   EMail: ran@cryptocom.ru
-
-
-   Igor Ustinov
-   Cryptocom Ltd.
-   14/2, Kedrova St.
-   Moscow,   117218
-   Russian Federation
-
-   Phone: +7 499 124 6226
-   EMail: igus@cryptocom.ru
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dolmatov, et al.             Standards Track                    [Page 9]
-

lib/dns/openssldsa_link.c

@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2004, 2006-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2002  Internet Software Consortium.
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
@@ -16,7 +16,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: openssldsa_link.c,v 1.1.4.9 2008/12/24 23:45:32 tbox Exp $ */
+/* $Id: openssldsa_link.c,v 1.1.4.8 2008/12/24 00:21:45 marka Exp $ */
 
 #ifdef OPENSSL
 
@@ -172,7 +172,7 @@ openssldsa_compare(const dst_key_t *key1, const dst_key_t *key2) {
 static isc_result_t
 openssldsa_generate(dst_key_t *key, int unused) {
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
-	BN_GENCB cb;
+        BN_GENCB cb;
 #endif
 	DSA *dsa;
 	unsigned char rand_array[ISC_SHA1_DIGESTLENGTH];
@@ -186,12 +186,12 @@ openssldsa_generate(dst_key_t *key, int unused) {
 		return (result);
 
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
-	dsa = DSA_new();
+        dsa = DSA_new();
 	if (dsa == NULL)
 		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
 
 	BN_GENCB_set_old(&cb, NULL, NULL);
-
+  
 	if (!DSA_generate_parameters_ex(dsa, key->key_size, rand_array,
 					ISC_SHA1_DIGESTLENGTH,  NULL, NULL,
 					&cb))

lib/dns/opensslrsa_link.c

@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and/or distribute this software for any
+ * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
@@ -17,7 +17,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: opensslrsa_link.c,v 1.1.4.11 2008/12/24 23:45:32 tbox Exp $
+ * $Id: opensslrsa_link.c,v 1.1.4.10 2008/12/24 00:21:45 marka Exp $
  */
 #ifdef OPENSSL
 
@@ -50,7 +50,7 @@
 #ifdef WIN32
 #if !((OPENSSL_VERSION_NUMBER >= 0x009070cfL && \
        OPENSSL_VERSION_NUMBER < 0x00908000L) || \
-      OPENSSL_VERSION_NUMBER >= 0x0090804fL)
+      OPENSSL_VERSION_NUMBER >= 0x0090804fL) 
 #error Please upgrade OpenSSL to 0.9.8d/0.9.7l or greater.
 #endif
 #endif

lib/dns/validator.c

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.c,v 1.91.2.5.8.43 2009/03/17 23:45:33 tbox Exp $ */
+/* $Id: validator.c,v 1.91.2.5.8.41 2008/08/21 04:59:16 marka Exp $ */
 
 #include <config.h>
 
@@ -244,36 +244,6 @@ auth_nonpending(dns_message_t *message) {
 	}
 }
 
-/*
- * Check that we have atleast one supported algorithm in the DLV RRset.
- */
-static inline isc_boolean_t
-dlv_algorithm_supported(dns_validator_t *val) {
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	dns_rdata_dlv_t dlv;
-	isc_result_t result;
-
-	for (result = dns_rdataset_first(&val->dlv);
-	     result == ISC_R_SUCCESS;
-	     result = dns_rdataset_next(&val->dlv)) {
-		dns_rdata_reset(&rdata);
-		dns_rdataset_current(&val->dlv, &rdata);
-		result = dns_rdata_tostruct(&rdata, &dlv, NULL);
-		RUNTIME_CHECK(result == ISC_R_SUCCESS);
-
-		if (!dns_resolver_algorithm_supported(val->view->resolver,
-						      val->event->name,
-						      dlv.algorithm))
-			continue;
-
-		if (dlv.digest_type != DNS_DSDIGEST_SHA1)
-			continue;
-
-		return (ISC_TRUE);
-	}
-	return (ISC_FALSE);
-}
-
 /*%
  * Look in the NSEC record returned from a DS query to see if there is
  * a NS RRset at this name.  If it is found we are at a delegation point.
@@ -2283,36 +2253,19 @@ dlvfetched(isc_task_t *task, isc_event_t *event) {
 				sizeof(namebuf));
 		dns_rdataset_clone(&val->frdataset, &val->dlv);
 		val->havedlvsep = ISC_TRUE;
-		if (dlv_algorithm_supported(val)) {
-			validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found",
-				      namebuf);
-			dlv_validator_start(val);
-		} else {
-			validator_log(val, ISC_LOG_DEBUG(3),
-				      "DLV %s found with no supported algorithms",
-				      namebuf);
-			markanswer(val);
-			validator_done(val, ISC_R_SUCCESS);
-		}
+		validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf);
+		dlv_validator_start(val);
 	} else if (eresult == DNS_R_NXRRSET ||
 		   eresult == DNS_R_NXDOMAIN ||
 		   eresult == DNS_R_NCACHENXRRSET ||
 		   eresult == DNS_R_NCACHENXDOMAIN) {
-		result = finddlvsep(val, ISC_TRUE);
+		   result = finddlvsep(val, ISC_TRUE);
 		if (result == ISC_R_SUCCESS) {
-			if (dlv_algorithm_supported(val)) {
-				dns_name_format(dns_fixedname_name(&val->dlvsep),
-						namebuf, sizeof(namebuf));
-				validator_log(val, ISC_LOG_DEBUG(3),
-					      "DLV %s found", namebuf);
-				dlv_validator_start(val);
-			} else {
-				validator_log(val, ISC_LOG_DEBUG(3),
-					      "DLV %s found with no supported "
-					      "algorithms", namebuf);
-				markanswer(val);
-				validator_done(val, ISC_R_SUCCESS);
-			}
+			dns_name_format(dns_fixedname_name(&val->dlvsep),
+					namebuf, sizeof(namebuf));
+			validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found",
+				      namebuf);
+			dlv_validator_start(val);
 		} else if (result == ISC_R_NOTFOUND) {
 			validator_log(val, ISC_LOG_DEBUG(3), "DLV not found");
 			markanswer(val);
@@ -2375,16 +2328,9 @@ startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure) {
 	}
 	dns_name_format(dns_fixedname_name(&val->dlvsep), namebuf,
 			sizeof(namebuf));
-	if (dlv_algorithm_supported(val)) {
-		validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf);
-		dlv_validator_start(val);
-		return (DNS_R_WAIT);
-	} 
-	validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found with no supported "
-		      "algorithms", namebuf);
-	markanswer(val);
-	validator_done(val, ISC_R_SUCCESS);
-	return (ISC_R_SUCCESS);
+	validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf);
+	dlv_validator_start(val);
+	return (DNS_R_WAIT);
 }
 
 /*%

util/copyrights

@@ -1,9 +1,9 @@
 ./.cvsignore					X	1998,1999,2000,2001,2004
-./CHANGES					X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
-./COPYRIGHT					TXT	1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./CHANGES					X	2000,2001,2002,2003,2004,2005,2006,2007,2008
+./COPYRIGHT					TXT	1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
 ./EXCLUDED					X	2001,2002,2003
-./FAQ						X	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
-./FAQ.xml					SGML	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./FAQ						X	2000,2001,2002,2003,2004,2005,2006,2007,2008
+./FAQ.xml					SGML	2000,2001,2002,2003,2004,2005,2006,2007,2008
 ./Makefile.in					MAKE	1998,1999,2000,2001,2002,2003,2004,2006,2007
 ./README					X	1999,2000,2001,2002,2003,2004,2005,2006,2008
 ./acconfig.h					C	1999,2000,2001,2002,2003,2004
@@ -1179,7 +1179,6 @@
 ./doc/misc/sdb					TXT.BRIEF	2000,2001,2004
 ./doc/misc/sort-options.pl			PERL	2007
 ./doc/private/CHANGES				X	2000,2001
-./doc/private/SRCID				X	2009,2010
 ./doc/private/bugfix-by-assertion		X	2001,2003
 ./doc/private/options				TXT.BRIEF	2000,2001,2004
 ./doc/todo/brister/todo				X	2000,2001
@@ -1771,8 +1770,8 @@
 ./lib/dns/nsec.c				C	1999,2000,2001,2003,2004
 ./lib/dns/openssl_link.c			C.NAI	1999,2000,2001,2002,2003,2004,2006,2007
 ./lib/dns/openssldh_link.c			C.NAI	1999,2000,2001,2002,2004,2006,2007
-./lib/dns/openssldsa_link.c			C.NAI	1999,2000,2001,2002,2004,2006,2007,2008
-./lib/dns/opensslrsa_link.c			C	2000,2001,2002,2003,2004,2006,2008
+./lib/dns/openssldsa_link.c			C.NAI	1999,2000,2001,2002,2004,2006,2007
+./lib/dns/opensslrsa_link.c			C	2000,2001,2002,2003,2004,2006
 ./lib/dns/order.c				C	2002,2003,2004,2007
 ./lib/dns/peer.c				C	2000,2001,2003,2004,2006
 ./lib/dns/portlist.c				C	2003,2004,2006
@@ -1902,7 +1901,7 @@
 ./lib/dns/tkey.c				C	1999,2000,2001,2003,2004,2005,2006,2008
 ./lib/dns/tsig.c				C	1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
 ./lib/dns/ttl.c					C	1999,2000,2001,2003,2004,2007
-./lib/dns/validator.c				C	2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./lib/dns/validator.c				C	2000,2001,2002,2003,2004,2005,2006,2007,2008
 ./lib/dns/version.c				C	1998,1999,2000,2001,2003,2004,2007
 ./lib/dns/view.c				C	1999,2000,2001,2002,2003,2004,2007,2008
 ./lib/dns/win32/DLLMain.c			C	2001,2004,2007
@@ -2384,7 +2383,7 @@
 ./util/check-instincludes.sh			SH	2000,2001,2003,2004,2007
 ./util/check-pullups.pl				PERL	2001,2002,2003,2004
 ./util/check-sources.pl				PERL	2000,2001,2004
-./util/copyrights				X	1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010
+./util/copyrights				X	1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
 ./util/kit.sh					SH	2000,2001,2002,2003,2004,2008
 ./util/mandoc2docbook.pl			PERL	2001,2004
 ./util/mdnbuildtest.sh				SH	2000,2001,2004
@@ -2396,7 +2395,7 @@
 ./util/spacewhack.pl				PERL	2000,2001,2004
 ./util/update-drafts.pl				PERL	2000,2001,2004
 ./util/update_copyrights			PERL	1998,1999,2000,2001,2004,2005,2006,2007,2008
-./version					X	1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009
+./version					X	1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
 ./win32utils/BINDBuild.dsw			X	2001,2003,2004,2005,2006
 ./win32utils/BuildAll.bat			BAT	2001,2002,2003,2004,2006,2007
 ./win32utils/BuildOpenSSL.bat			BAT	2007

version

@@ -1,4 +1,4 @@
-# $Id: version,v 1.26.2.17.2.36 2009/03/17 02:39:23 marka Exp $
+# $Id: version,v 1.26.2.17.2.35 2008/12/24 00:21:45 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=3
 PATCHVER=6
 RELEASETYPE=-P
-RELEASEVER=2
+RELEASEVER=1