9.2.8

bug -> security
2007-01-12 03:33:19 +00:00 · 2007-01-12 03:32:51 +00:00 · 2007-01-12 03:31:03 +00:00 · 2007-01-12 02:28:15 +00:00 · 2007-01-11 05:09:15 +00:00 · 2007-01-11 04:59:36 +00:00
19 changed files with 204 additions and 15278 deletions
--- a/4
+++ b/4
@@ -1,4 +1,8 @@
 	--- 9.2.8 released ---
 2126.	[securityt]	Serialise validation of type ANY responses. [RT #16555]
 	--- 9.2.7 released ---
 2107.	[bug]		dighost.c: more cleanup of buffers. [RT #16499]
--- a/43
+++ b/43
@@ -1,5 +1,9 @@
 Frequently Asked Questions about BIND 9
 Copyright © 2004-2007 Internet Systems Consortium, Inc. ("ISC")
 Copyright © 2000-2003 Internet Software Consortium.
 -------------------------------------------------------------------------------
 Q: Why doesn't -u work on Linux 2.2.x when I build with --enable-threads?
@@ -630,3 +634,42 @@ 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 want to forward all DNS queries from my caching nameserver to another server.
   But there are some domains which have to be served locally, via rbldnsd.
   How do I achieve this ?
 A: options {
           forward only;
           forwarders { <ip.of.primary.nameserver>; };
   };
   zone "sbl-xbl.spamhaus.org" {
           type forward; forward only;
           forwarders { <ip.of.rbldns.server> port 530; };
   };
   zone "list.dsbl.org" {
           type forward; forward only;
           forwarders { <ip.of.rbldns.server> port 530; };
   };
 Q: Will named be affected by the 2007 changes to daylight savings rules in the US.
 A: No, so long as the machines internal clock (as reported by "date -u") remains
   at UTC. The only visible change if you fail to upgrade your OS, if you are in a
   affected area, will be that log messages will be a hour out during the period
   where the old rules do not match the new rules.
   For most OS's this change just means that you need to update the conversion
   rules from UTC to local time. Normally this involves updating a file in /etc
   (which sets the default timezone for the machine) and possibly a directory
   which has all the conversion rules for the world (e.g. /usr/share/zoneinfo).
   When updating the OS do not forget to update any chroot areas as well. See your
   OS's documetation for more details.
   The local timezone conversion rules can also be done on a individual basis by
   setting the TZ envirionment variable appropriately. See your OS's documentation
   for more details.
--- a/FAQ.xml
+++ b/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-2006  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
 - Copyright (C) 2000-2003  Internet Software Consortium.
 -
 - Permission to use, copy, modify, and distribute this software for any
@@ -17,10 +17,26 @@
 - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: FAQ.xml,v 1.4.8.5 2006/02/27 21:11:57 marka Exp $ -->
+<!-- $Id: FAQ.xml,v 1.4.8.5.6.1 2007/01/12 02:28:15 marka Exp $ -->
 <article class="faq">
  <title>Frequently Asked Questions about BIND 9</title>
  <articleinfo>
    <copyright>
      <year>2004</year>
      <year>2005</year>
      <year>2006</year>
      <year>2007</year>
      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
    </copyright>
    <copyright>
      <year>2000</year>
      <year>2001</year>
      <year>2002</year>
      <year>2003</year>
      <holder>Internet Software Consortium.</holder>
    </copyright>
  </articleinfo>
  <qandaset defaultlabel='qanda'>
    <qandaentry>
      <question>
@@ -1193,5 +1209,68 @@ named_cache_t: for files modifiable by named - $ROOTDIR/var/{tmp,named/{slaves,d
 	</para>
      </answer>
    </qandaentry>
    <qandaentry>
      <question>
 	<para>
 	  I want to forward all DNS queries from my caching nameserver to
 	  another server. But there are some domains which have to be
 	  served locally, via rbldnsd.
 	</para>
 	<para>
 	  How do I achieve this ?
 	</para>
      </question>
      <answer>
        <programlisting>
 options {
 	forward only;
 	forwarders { &lt;ip.of.primary.nameserver&gt;; };
 };
 zone "sbl-xbl.spamhaus.org" {
 	type forward; forward only;
 	forwarders { &lt;ip.of.rbldns.server&gt; port 530; };
 };
 zone "list.dsbl.org" {
 	type forward; forward only;
 	forwarders { &lt;ip.of.rbldns.server&gt; port 530; };
 };
        </programlisting>
      </answer>
    </qandaentry>
    <qandaentry>
      <question>
 	<para>
 	  Will named be affected by the 2007 changes to daylight savings
 	  rules in the US.
 	</para>
      </question>
      <answer>
 	<para>
 	  No, so long as the machines internal clock (as reported
 	  by "date -u") remains at UTC.  The only visible change
 	  if you fail to upgrade your OS, if you are in a affected
 	  area, will be that log messages will be a hour out during
 	  the period where the old rules do not match the new rules.
 	</para>
 	<para>
 	  For most OS's this change just means that you need to
 	  update the conversion rules from UTC to local time.
 	  Normally this involves updating a file in /etc (which
 	  sets the default timezone for the machine) and possibly
 	  a directory which has all the conversion rules for the
 	  world (e.g. /usr/share/zoneinfo).  When updating the OS
 	  do not forget to update any chroot areas as well.
 	  See your OS's documetation for more details.
 	</para>
 	<para>
 	  The local timezone conversion rules can also be done on
 	  a individual basis by setting the TZ envirionment variable
 	  appropriately.  See your OS's documentation for more
 	  details.
 	</para>
      </answer>
    </qandaentry>
  </qandaset>
 </article>
--- a/7
+++ b/7
@@ -43,6 +43,13 @@ BIND 9
 		Nominum, Inc.
 BIND 9.2.8
 	BIND 9.2.8 is a security release.
 BIND 9.2.7
 	BIND 9.2.7 is a maintenance release, containing fixes for
 	a number of bugs in 9.2.6.
 BIND 9.2.6
 	BIND 9.2.6 is a maintenance release, containing fixes for
--- a/doc/rfc/rfc4193.txt
+++ b/doc/rfc/rfc4193.txt
@@ -1,899 +0,0 @@
 Network Working Group                                          R. Hinden
 Request for Comments: 4193                                         Nokia
 Category: Standards Track                                    B. Haberman
                                                                 JHU-APL
                                                            October 2005
                  Unique Local IPv6 Unicast Addresses
 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 (2005).
 Abstract
   This document defines an IPv6 unicast address format that is globally
   unique and is intended for local communications, usually inside of a
   site.  These addresses are not expected to be routable on the global
   Internet.
 Table of Contents
   1. Introduction ....................................................2
   2. Acknowledgements ................................................3
   3. Local IPv6 Unicast Addresses ....................................3
      3.1. Format .....................................................3
           3.1.1. Background ..........................................4
      3.2. Global ID ..................................................4
           3.2.1. Locally Assigned Global IDs .........................5
           3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
           3.2.3. Analysis of the Uniqueness of Global IDs ............6
      3.3. Scope Definition ...........................................6
   4. Operational Guidelines ..........................................7
      4.1. Routing ....................................................7
      4.2. Renumbering and Site Merging ...............................7
      4.3. Site Border Router and Firewall Packet Filtering ...........8
      4.4. DNS Issues .................................................8
      4.5. Application and Higher Level Protocol Issues ...............9
      4.6. Use of Local IPv6 Addresses for Local Communication ........9
      4.7. Use of Local IPv6 Addresses with VPNs .....................10
 Hinden & Haberman           Standards Track                     [Page 1]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
   5. Global Routing Considerations ..................................11
      5.1. From the Standpoint of the Internet .......................11
      5.2. From the Standpoint of a Site .............................11
   6. Advantages and Disadvantages ...................................12
      6.1. Advantages ................................................12
      6.2. Disadvantages .............................................13
   7. Security Considerations ........................................13
   8. IANA Considerations ............................................13
   9. References .....................................................13
      9.1. Normative References ......................................13
      9.2. Informative References ....................................14
 1.  Introduction
   This document defines an IPv6 unicast address format that is globally
   unique and is intended for local communications [IPV6].  These
   addresses are called Unique Local IPv6 Unicast Addresses and are
   abbreviated in this document as Local IPv6 addresses.  They are not
   expected to be routable on the global Internet.  They are routable
   inside of a more limited area such as a site.  They may also be
   routed between a limited set of sites.
   Local IPv6 unicast addresses have the following characteristics:
      - Globally unique prefix (with high probability of uniqueness).
      - Well-known prefix to allow for easy filtering at site
        boundaries.
      - Allow sites to be combined or privately interconnected without
        creating any address conflicts or requiring renumbering of
        interfaces that use these prefixes.
      - Internet Service Provider independent and can be used for
        communications inside of a site without having any permanent or
        intermittent Internet connectivity.
      - If accidentally leaked outside of a site via routing or DNS,
        there is no conflict with any other addresses.
      - In practice, applications may treat these addresses like global
        scoped addresses.
   This document defines the format of Local IPv6 addresses, how to
   allocate them, and usage considerations including routing, site
   border routers, DNS, application support, VPN usage, and guidelines
   for how to use for local communication inside a site.
 Hinden & Haberman           Standards Track                     [Page 2]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 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 [RFC2119].
 2.  Acknowledgements
   The underlying idea of creating Local IPv6 addresses described in
   this document has been proposed a number of times by a variety of
   people.  The authors of this document do not claim exclusive credit.
   Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
   Andrew White, Charlie Perkins, and many others.  The authors would
   also like to thank Brian Carpenter, Charlie Perkins, Harald
   Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
   Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
   Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
   Hartman, and Elwyn Davies for their comments and suggestions on this
   document.
 3.  Local IPv6 Unicast Addresses
 3.1.  Format
   The Local IPv6 addresses are created using a pseudo-randomly
   allocated global ID.  They have the following format:
      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+
   Where:
      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
                        addresses.
      L                 Set to 1 if the prefix is locally assigned.
                        Set to 0 may be defined in the future.  See
                        Section 3.2 for additional information.
      Global ID         40-bit global identifier used to create a
                        globally unique prefix.  See Section 3.2 for
                        additional information.
      Subnet ID         16-bit Subnet ID is an identifier of a subnet
                        within the site.
      Interface ID      64-bit Interface ID as defined in [ADDARCH].
 Hinden & Haberman           Standards Track                     [Page 3]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 3.1.1.  Background
   There were a range of choices available when choosing the size of the
   prefix and Global ID field length.  There is a direct tradeoff
   between having a Global ID field large enough to support foreseeable
   future growth and not using too much of the IPv6 address space
   needlessly.  A reasonable way of evaluating a specific field length
   is to compare it to a projected 2050 world population of 9.3 billion
   [POPUL] and the number of resulting /48 prefixes per person.  A range
   of prefix choices is shown in the following table:
    Prefix  Global ID     Number of          Prefixes    % of IPv6
            Length        /48 Prefixes       per Person  Address Space
    /11       37           137,438,953,472     15         0.049%
    /10       38           274,877,906,944     30         0.098%
    /9        39           549,755,813,888     59         0.195%
    /8        40         1,099,511,627,776    118         0.391%
    /7        41         2,199,023,255,552    236         0.781%
    /6        42         4,398,046,511,104    473         1.563%
   A very high utilization ratio of these allocations can be assumed
   because the Global ID field does not require internal structure, and
   there is no reason to be able to aggregate the prefixes.
   The authors believe that a /7 prefix resulting in a 41-bit Global ID
   space (including the L bit) is a good choice.  It provides for a
   large number of assignments (i.e., 2.2 trillion) and at the same time
   uses less than .8% of the total IPv6 address space.  It is unlikely
   that this space will be exhausted.  If more than this were to be
   needed, then additional IPv6 address space could be allocated for
   this purpose.
 3.2.  Global ID
   The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
   NOT be assigned sequentially or with well-known numbers.  This is to
   ensure that there is not any relationship between allocations and to
   help clarify that these prefixes are not intended to be routed
   globally.  Specifically, these prefixes are not designed to
   aggregate.
   This document defines a specific local method to allocate Global IDs,
   indicated by setting the L bit to 1.  Another method, indicated by
   clearing the L bit, may be defined later.  Apart from the allocation
   method, all Local IPv6 addresses behave and are treated identically.
 Hinden & Haberman           Standards Track                     [Page 4]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
   The local assignments are self-generated and do not need any central
   coordination or assignment, but have an extremely high probability of
   being unique.
 3.2.1.  Locally Assigned Global IDs
   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM].  Section 3.2.2 describes a
   suggested algorithm.  It is important that all sites generating
   Global IDs use a functionally similar algorithm to ensure there is a
   high probability of uniqueness.
   The use of a pseudo-random algorithm to generate Global IDs in the
   locally assigned prefix gives an assurance that any network numbered
   using such a prefix is highly unlikely to have that address space
   clash with any other network that has another locally assigned prefix
   allocated to it.  This is a particularly useful property when
   considering a number of scenarios including networks that merge,
   overlapping VPN address space, or hosts mobile between such networks.
 3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm
   The algorithm described below is intended to be used for locally
   assigned Global IDs.  In each case the resulting global ID will be
   used in the appropriate prefix as defined in Section 3.2.
     1) Obtain the current time of day in 64-bit NTP format [NTP].
     2) Obtain an EUI-64 identifier from the system running this
        algorithm.  If an EUI-64 does not exist, one can be created from
        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
        cannot be obtained or created, a suitably unique identifier,
        local to the node, should be used (e.g., system serial number).
     3) Concatenate the time of day with the system-specific identifier
        in order to create a key.
     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
        the resulting value is 160 bits.
     5) Use the least significant 40 bits as the Global ID.
     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
        ID to create a Local IPv6 address prefix.
   This algorithm will result in a Global ID that is reasonably unique
   and can be used to create a locally assigned Local IPv6 address
   prefix.
 Hinden & Haberman           Standards Track                     [Page 5]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 3.2.3.  Analysis of the Uniqueness of Global IDs
   The selection of a pseudo random Global ID is similar to the
   selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
   [RTP].  This analysis is adapted from that document.
   Since Global IDs are chosen randomly (and independently), it is
   possible that separate networks have chosen the same Global ID.  For
   any given network, with one or more random Global IDs, that has
   inter-connections to other such networks, having a total of N such
   IDs, the probability that two or more of these IDs will collide can
   be approximated using the formula:
      P = 1 - exp(-N**2 / 2**(L+1))
   where P is the probability of collision, N is the number of
   interconnected Global IDs, and L is the length of the Global ID.
   The following table shows the probability of a collision for a range
   of connections using a 40-bit Global ID field.
      Connections      Probability of Collision
          2                1.81*10^-12
         10                4.54*10^-11
        100                4.54*10^-09
       1000                4.54*10^-07
      10000                4.54*10^-05
   Based on this analysis, the uniqueness of locally generated Global
   IDs is adequate for sites planning a small to moderate amount of
   inter-site communication using locally generated Global IDs.
 3.3.  Scope Definition
   By default, the scope of these addresses is global.  That is, they
   are not limited by ambiguity like the site-local addresses defined in
   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
   their applicability is greater than site-local addresses.  Their
   limitation is in the routability of the prefixes, which is limited to
   a site and any explicit routing agreements with other sites to
   propagate them (also see Section 4.1).  Also, unlike site-locals, a
   site may have more than one of these prefixes and use them at the
   same time.
 Hinden & Haberman           Standards Track                     [Page 6]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 4.  Operational Guidelines
   The guidelines in this section do not require any change to the
   normal routing and forwarding functionality in an IPv6 host or
   router.  These are configuration and operational usage guidelines.
 4.1.  Routing
   Local IPv6 addresses are designed to be routed inside of a site in
   the same manner as other types of unicast addresses.  They can be
   carried in any IPv6 routing protocol without any change.
   It is expected that they would share the same Subnet IDs with
   provider-based global unicast addresses, if they were being used
   concurrently [GLOBAL].
   The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the FC00::/7 block.  A network operator may
   specifically configure prefixes longer than FC00::/7 for inter-site
   communication.
   If BGP is being used at the site border with an ISP, the default BGP
   configuration must filter out any Local IPv6 address prefixes, both
   incoming and outgoing.  It must be set both to keep any Local IPv6
   address prefixes from being advertised outside of the site as well as
   to keep these prefixes from being learned from another site.  The
   exception to this is if there are specific /48 or longer routes
   created for one or more Local IPv6 prefixes.
   For link-state IGPs, it is suggested that a site utilizing IPv6 local
   address prefixes be contained within one IGP domain or area.  By
   containing an IPv6 local address prefix to a single link-state area
   or domain, the distribution of prefixes can be controlled.
 4.2.  Renumbering and Site Merging
   The use of Local IPv6 addresses in a site results in making
   communication that uses these addresses independent of renumbering a
   site's provider-based global addresses.
   When merging multiple sites, the addresses created with these
   prefixes are unlikely to need to be renumbered because all of the
   addresses have a high probability of being unique.  Routes for each
   specific prefix would have to be configured to allow routing to work
   correctly between the formerly separate sites.
 Hinden & Haberman           Standards Track                     [Page 7]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 4.3.  Site Border Router and Firewall Packet Filtering
   While no serious harm will be done if packets with these addresses
   are sent outside of a site via a default route, it is recommended
   that routers be configured by default to keep any packets with Local
   IPv6 addresses from leaking outside of the site and to keep any site
   prefixes from being advertised outside of their site.
   Site border routers and firewalls should be configured to not forward
   any packets with Local IPv6 source or destination addresses outside
   of the site, unless they have been explicitly configured with routing
   information about specific /48 or longer Local IPv6 prefixes.  This
   will ensure that packets with Local IPv6 destination addresses will
   not be forwarded outside of the site via a default route.  The
   default behavior of these devices should be to install a "reject"
   route for these prefixes.  Site border routers should respond with
   the appropriate ICMPv6 Destination Unreachable message to inform the
   source that the packet was not forwarded. [ICMPV6].  This feedback is
   important to avoid transport protocol timeouts.
   Routers that maintain peering arrangements between Autonomous Systems
   throughout the Internet should obey the recommendations for site
   border routers, unless configured otherwise.
 4.4.  DNS Issues
   At the present time, AAAA and PTR records for locally assigned local
   IPv6 addresses are not recommended to be installed in the global DNS.
   For background on this recommendation, one of the concerns about
   adding AAAA and PTR records to the global DNS for locally assigned
   Local IPv6 addresses stems from the lack of complete assurance that
   the prefixes are unique.  There is a small possibility that the same
   locally assigned IPv6 Local addresses will be used by two different
   organizations both claiming to be authoritative with different
   contents.  In this scenario, it is likely there will be a connection
   attempt to the closest host with the corresponding locally assigned
   IPv6 Local address.  This may result in connection timeouts,
   connection failures indicated by ICMP Destination Unreachable
   messages, or successful connections to the wrong host.  Due to this
   concern, adding AAAA records for these addresses to the global DNS is
   thought to be unwise.
   Reverse (address-to-name) queries for locally assigned IPv6 Local
   addresses MUST NOT be sent to name servers for the global DNS, due to
   the load that such queries would create for the authoritative name
   servers for the ip6.arpa zone.  This form of query load is not
   specific to locally assigned Local IPv6 addresses; any current form
 Hinden & Haberman           Standards Track                     [Page 8]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
   of local addressing creates additional load of this kind, due to
   reverse queries leaking out of the site.  However, since allowing
   such queries to escape from the site serves no useful purpose, there
   is no good reason to make the existing load problems worse.
   The recommended way to avoid sending such queries to nameservers for
   the global DNS is for recursive name server implementations to act as
   if they were authoritative for an empty d.f.ip6.arpa zone and return
   RCODE 3 for any such query.  Implementations that choose this
   strategy should allow it to be overridden, but returning an RCODE 3
   response for such queries should be the default, both because this
   will reduce the query load problem and also because, if the site
   administrator has not set up the reverse tree corresponding to the
   locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
   fact the correct answer.
 4.5.  Application and Higher Level Protocol Issues
   Application and other higher level protocols can treat Local IPv6
   addresses in the same manner as other types of global unicast
   addresses.  No special handling is required.  This type of address
   may not be reachable, but that is no different from other types of
   IPv6 global unicast address.  Applications need to be able to handle
   multiple addresses that may or may not be reachable at any point in
   time.  In most cases, this complexity should be hidden in APIs.
   From a host's perspective, the difference between Local IPv6 and
   other types of global unicast addresses shows up as different
   reachability and could be handled by default in that way.  In some
   cases, it is better for nodes and applications to treat them
   differently from global unicast addresses.  A starting point might be
   to give them preference over global unicast, but fall back to global
   unicast if a particular destination is found to be unreachable.  Much
   of this behavior can be controlled by how they are allocated to nodes
   and put into the DNS.  However, it is useful if a host can have both
   types of addresses and use them appropriately.
   Note that the address selection mechanisms of [ADDSEL], and in
   particular the policy override mechanism replacing default address
   selection, are expected to be used on a site where Local IPv6
   addresses are configured.
 4.6.  Use of Local IPv6 Addresses for Local Communication
   Local IPv6 addresses, like global scope unicast addresses, are only
   assigned to nodes if their use has been enabled (via IPv6 address
   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
 Hinden & Haberman           Standards Track                     [Page 9]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
   not created automatically in the way that IPv6 link-local addresses
   are and will not appear or be used unless they are purposely
   configured.
   In order for hosts to autoconfigure Local IPv6 addresses, routers
   have to be configured to advertise Local IPv6 /64 prefixes in router
   advertisements, or a DHCPv6 server must have been configured to
   assign them.  In order for a node to learn the Local IPv6 address of
   another node, the Local IPv6 address must have been installed in a
   naming system (e.g., DNS, proprietary naming system, etc.)  For these
   reasons, controlling their usage in a site is straightforward.
   To limit the use of Local IPv6 addresses the following guidelines
   apply:
      - Nodes that are to only be reachable inside of a site:  The local
        DNS should be configured to only include the Local IPv6
        addresses of these nodes.  Nodes with only Local IPv6 addresses
        must not be installed in the global DNS.
      - Nodes that are to be limited to only communicate with other
        nodes in the site:  These nodes should be set to only
        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
        receive Local IPv6 addresses via [DHCP6].  Note: For the case
        where both global and Local IPv6 prefixes are being advertised
        on a subnet, this will require a switch in the devices to only
        autoconfigure Local IPv6 addresses.
      - Nodes that are to be reachable from inside of the site and from
        outside of the site:  The DNS should be configured to include
        the global addresses of these nodes.  The local DNS may be
        configured to also include the Local IPv6 addresses of these
        nodes.
      - Nodes that can communicate with other nodes inside of the site
        and outside of the site: These nodes should autoconfigure global
        addresses via [ADDAUTO] or receive global address via [DHCP6].
        They may also obtain Local IPv6 addresses via the same
        mechanisms.
 4.7.  Use of Local IPv6 Addresses with VPNs
   Local IPv6 addresses can be used for inter-site Virtual Private
   Networks (VPN) if appropriate routes are set up.  Because the
   addresses are unique, these VPNs will work reliably and without the
   need for translation.  They have the additional property that they
   will continue to work if the individual sites are renumbered or
   merged.
 Hinden & Haberman           Standards Track                    [Page 10]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 5.  Global Routing Considerations
   Section 4.1 provides operational guidelines that forbid default
   routing of local addresses between sites.  Concerns were raised to
   the IPv6 working group and to the IETF as a whole that sites may
   attempt to use local addresses as globally routed provider-
   independent addresses.  This section describes why using local
   addresses as globally-routed provider-independent addresses is
   unadvisable.
 5.1.  From the Standpoint of the Internet
   There is a mismatch between the structure of IPv6 local addresses and
   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
   addresses.  Normal IPv6 unicast addresses can be routed
   hierarchically down to physical subnet (link) level and only have to
   be flat-routed on the physical subnet.  IPv6 local addresses would
   have to be flat-routed even over the wide area Internet.
   Thus, packets whose destination address is an IPv6 local address
   could be routed over the wide area only if the corresponding /48
   prefix were carried by the wide area routing protocol in use, such as
   BGP.  This contravenes the operational assumption that long prefixes
   will be aggregated into many fewer short prefixes, to limit the table
   size and convergence time of the routing protocol.  If a network uses
   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
   types of addresses will certainly not aggregate with each other,
   since they differ from the most significant bit onwards.  Neither
   will IPv6 local addresses aggregate with each other, due to their
   random bit patterns.  This means that there would be a very
   significant operational penalty for attempting to use IPv6 local
   address prefixes generically with currently known wide area routing
   technology.
 5.2.  From the Standpoint of a Site
   There are a number of design factors in IPv6 local addresses that
   reduce the likelihood that IPv6 local addresses will be used as
   arbitrary global unicast addresses.  These include:
      - The default rules to filter packets and routes make it very
        difficult to use IPv6 local addresses for arbitrary use across
        the Internet.  For a site to use them as general purpose unicast
        addresses, it would have to make sure that the default rules
        were not being used by all other sites and intermediate ISPs
        used for their current and future communication.
 Hinden & Haberman           Standards Track                    [Page 11]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
      - They are not mathematically guaranteed to be unique and are not
        registered in public databases.  Collisions, while highly
        unlikely, are possible and a collision can compromise the
        integrity of the communications.  The lack of public
        registration creates operational problems.
      - The addresses are allocated randomly.  If a site had multiple
        prefixes that it wanted to be used globally, the cost of
        advertising them would be very high because they could not be
        aggregated.
      - They have a long prefix (i.e., /48) so a single local address
        prefix doesn't provide enough address space to be used
        exclusively by the largest organizations.
 6.  Advantages and Disadvantages
 6.1.  Advantages
   This approach has the following advantages:
      - Provides Local IPv6 prefixes that can be used independently of
        any provider-based IPv6 unicast address allocations.  This is
        useful for sites not always connected to the Internet or sites
        that wish to have a distinct prefix that can be used to localize
        traffic inside of the site.
      - Applications can treat these addresses in an identical manner as
        any other type of global IPv6 unicast addresses.
      - Sites can be merged without any renumbering of the Local IPv6
        addresses.
      - Sites can change their provider-based IPv6 unicast address
        without disrupting any communication that uses Local IPv6
        addresses.
      - Well-known prefix that allows for easy filtering at site
        boundary.
      - Can be used for inter-site VPNs.
      - If accidently leaked outside of a site via routing or DNS, there
        is no conflict with any other addresses.
 Hinden & Haberman           Standards Track                    [Page 12]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 6.2.  Disadvantages
   This approach has the following disadvantages:
      - Not possible to route Local IPv6 prefixes on the global Internet
        with current routing technology.  Consequentially, it is
        necessary to have the default behavior of site border routers to
        filter these addresses.
      - There is a very low probability of non-unique locally assigned
        Global IDs being generated by the algorithm in Section 3.2.3.
        This risk can be ignored for all practical purposes, but it
        leads to a theoretical risk of clashing address prefixes.
 7.  Security Considerations
   Local IPv6 addresses do not provide any inherent security to the
   nodes that use them.  They may be used with filters at site
   boundaries to keep Local IPv6 traffic inside of the site, but this is
   no more or less secure than filtering any other type of global IPv6
   unicast addresses.
   Local IPv6 addresses do allow for address-based security mechanisms,
   including IPsec, across end to end VPN connections.
 8.  IANA Considerations
   The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
 9.  References
 9.1.  Normative References
   [ADDARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
             (IPv6) Addressing Architecture", RFC 3513, April 2003.
   [FIPS]    "Federal Information Processing Standards Publication",
             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
             Unicast Address Format", RFC 3587, August 2003.
   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
             Protocol (ICMPv6) for the Internet Protocol Version 6
             (IPv6) Specification", RFC 2463, December 1998.
 Hinden & Haberman           Standards Track                    [Page 13]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.
   [NTP]     Mills, D., "Network Time Protocol (Version 3)
             Specification, Implementation and Analysis", RFC 1305,
             March 1992.
   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
             "Randomness Requirements for Security", BCP 106, RFC 4086,
             June 2005.
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
   [SHA1]    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
             (SHA1)", RFC 3174, September 2001.
 9.2.  Informative References
   [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC 2462, December 1998.
   [ADDSEL]  Draves, R., "Default Address Selection for Internet
             Protocol version 6 (IPv6)", RFC 3484, February 2003.
   [DHCP6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
             M. Carney, "Dynamic Host Configuration Protocol for IPv6
             (DHCPv6)", RFC 3315, July 2003.
   [POPUL]   Population Reference Bureau, "World Population Data Sheet
             of the Population Reference Bureau 2002",  August 2002.
   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.
 Hinden & Haberman           Standards Track                    [Page 14]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 Authors' Addresses
   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   USA
   Phone: +1 650 625-2004
   EMail: bob.hinden@nokia.com
   Brian Haberman
   Johns Hopkins University
   Applied Physics Lab
   11100 Johns Hopkins Road
   Laurel, MD 20723
   USA
   Phone: +1 443 778 1319
   EMail: brian@innovationslab.net
 Hinden & Haberman           Standards Track                    [Page 15]
 RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
 Full Copyright Statement
   Copyright (C) The Internet Society (2005).
   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 Intellectual Property
   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
   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.
 Hinden & Haberman           Standards Track                    [Page 16]
--- a/doc/rfc/rfc4255.txt
+++ b/doc/rfc/rfc4255.txt
@@ -1,507 +0,0 @@
 Network Working Group                                        J. Schlyter
 Request for Comments: 4255                                       OpenSSH
 Category: Standards Track                                     W. Griffin
                                                                  SPARTA
                                                            January 2006
   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
 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 describes a method of verifying Secure Shell (SSH) host
   keys using Domain Name System Security (DNSSEC).  The document
   defines a new DNS resource record that contains a standard SSH key
   fingerprint.
 Table of Contents
   1. Introduction ....................................................2
   2. SSH Host Key Verification .......................................2
      2.1. Method .....................................................2
      2.2. Implementation Notes .......................................2
      2.3. Fingerprint Matching .......................................3
      2.4. Authentication .............................................3
   3. The SSHFP Resource Record .......................................3
      3.1. The SSHFP RDATA Format .....................................4
           3.1.1. Algorithm Number Specification ......................4
           3.1.2. Fingerprint Type Specification ......................4
           3.1.3. Fingerprint .........................................5
      3.2. Presentation Format of the SSHFP RR ........................5
   4. Security Considerations .........................................5
   5. IANA Considerations .............................................6
   6. Normative References ............................................7
   7. Informational References ........................................7
   8. Acknowledgements ................................................8
 Schlyter & Griffin          Standards Track                     [Page 1]
 RFC 4255                DNS and SSH Fingerprints            January 2006
 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 an 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          Standards Track                     [Page 2]
 RFC 4255                DNS and SSH Fingerprints            January 2006
   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 an
   SSH public host key that is associated with a Domain Name System
   (DNS) name.
   The RR type code for the SSHFP RR is 44.
 Schlyter & Griffin          Standards Track                     [Page 3]
 RFC 4255                DNS and SSH Fingerprints            January 2006
 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.
 Schlyter & Griffin          Standards Track                     [Page 4]
 RFC 4255                DNS and SSH Fingerprints            January 2006
 3.1.3.  Fingerprint
   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.
 Schlyter & Griffin          Standards Track                     [Page 5]
 RFC 4255                DNS and SSH Fingerprints            January 2006
   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 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 has allocated the RR type code 44 for SSHFP from the standard RR
   type space.
   IANA has opened a new registry for the SSHFP RR type for public key
   algorithms.  The defined types are:
      0 is reserved
      1 is RSA
      2 is DSA
   Adding new reservations requires IETF consensus [4].
 Schlyter & Griffin          Standards Track                     [Page 6]
 RFC 4255                DNS and SSH Fingerprints            January 2006
   IANA has opened a new registry for the SSHFP RR type for fingerprint
   types.  The defined types are:
      0 is reserved
      1 is SHA-1
   Adding new reservations requires IETF consensus [4].
 6.  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]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033, March
         2005.
         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Resource Records for the DNS Security Extensions", RFC 4034,
         March 2005.
         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Protocol Modifications for the DNS Security Extensions", RFC
         4035, March 2005.
   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
         Protocol Architecture", RFC 4251, January 2006.
   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
         Transport Layer Protocol", RFC 4253, January 2006.
 7.  Informational References
   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
         Roadmap", RFC 2411, November 1998.
 Schlyter & Griffin          Standards Track                     [Page 7]
 RFC 4255                DNS and SSH Fingerprints            January 2006
   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
         Wellington, "Secret Key Transaction Authentication for DNS
         (TSIG)", RFC 2845, May 2000.
   [10]  Eastlake 3rd, 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.
 8.  Acknowledgements
   The authors gratefully acknowledge, in no particular order, the
   contributions of the following persons:
      Martin Fredriksson
      Olafur Gudmundsson
      Edward Lewis
      Bill Sommerfeld
 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/
 Schlyter & Griffin          Standards Track                     [Page 8]
 RFC 4255                DNS and SSH Fingerprints            January 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).
 Schlyter & Griffin          Standards Track                     [Page 9]
--- a/doc/rfc/rfc4343.txt
+++ b/doc/rfc/rfc4343.txt
@@ -1,563 +0,0 @@
 Network Working Group                                    D. Eastlake 3rd
 Request for Comments: 4343                         Motorola Laboratories
 Updates: 1034, 1035, 2181                                   January 2006
 Category: Standards Track
       Domain Name System (DNS) Case Insensitivity Clarification
 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
   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, 1035, and 2181.
 Table of Contents
   1. Introduction ....................................................2
   2. Case Insensitivity of DNS Labels ................................2
      2.1. Escaping Unusual DNS Label Octets ..........................2
      2.2. Example Labels with Escapes ................................3
   3. Name Lookup, Label Types, and CLASS .............................3
      3.1. Original DNS Label Types ...................................4
      3.2. Extended Label Type Case Insensitivity Considerations ......4
      3.3. CLASS Case Insensitivity Considerations ....................4
   4. Case on Input and Output ........................................5
      4.1. DNS Output Case Preservation ...............................5
      4.2. DNS Input Case Preservation ................................5
   5. Internationalized Domain Names ..................................6
   6. Security Considerations .........................................6
   7. Acknowledgements ................................................7
   Normative References................................................7
   Informative References..............................................8
 Eastlake 3rd                Standards Track                     [Page 1]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 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 [STD13, RFC1591, RFC2606] that are treated in
   a case insensitive fashion.  This document clarifies the meaning of
   "case insensitive" for the DNS.  This clarification updates RFCs
   1034, 1035 [STD13], and [RFC2181].
   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.  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 to 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 [RFC3092] 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 [STD13] 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 from 0x21
   ("!") to 0x7E ("~").  That is to say, 0x2E and all octet values in
   the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
 Eastlake 3rd                Standards Track                     [Page 2]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
   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 \.  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 shows 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
   According to the original DNS design decision, comparisons on name
   lookup for DNS queries should be case insensitive [STD13].  That is
   to say, a lookup string octet with a value in the inclusive range
   from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
   identical value and also match the corresponding value in the
   inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
   lookup string octet with a lowercase ASCII letter value MUST
   similarly match the identical value and also match the corresponding
   value in the uppercase ASCII letter range.
   (Historical note: The terms "uppercase" and "lowercase" were invented
   after movable type.  The terms originally referred to the two font
   trays for storing, in partitioned areas, the different physical type
   elements.  Before movable type, the nearest equivalent terms were
   "majuscule" and "minuscule".)
 Eastlake 3rd                Standards Track                     [Page 3]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
   One way to implement this rule would be to subtract 0x20 from all
   octets in the inclusive range from 0x61 to 0x7A before comparing
   octets.  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 [STD13] had only two types: ASCII labels,
   with a length 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 [RFC2671] so that additional label type numbers
   would be available.  (The only such type defined so far is the BINARY
   type [RFC2673], which is now Experimental [RFC3363].)
   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 [STD13] and [RFC2929], DNS has an additional axis for
   data location called CLASS.  The only CLASS in global use at this
   time is the "IN" (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
   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 desirable, for example, to allocate
   a CLASS with "case sensitive ASCII labels", it would be necessary to
   allocate a new label type for these labels.
 Eastlake 3rd                Standards Track                     [Page 4]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 4.  Case on Input and Output
   While ASCII label comparisons are case insensitive, [STD13] 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
   [STD13] views the DNS namespace as a node tree.  ASCII output is as
   if a name were 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 are 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
   [STD13] or a zone transfer.  DNS Dynamic update and incremental zone
   transfers [RFC1995] have been added as a source of DNS data [RFC2136,
   RFC3007].  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 exists in DNS data being
   held, the situation is more complex.  Implementations are free to
   retain the case first loaded for such a label, to allow new input to
   override the old case, or even to maintain separate copies preserving
   the input case.
   For example, if data with owner name "foo.bar.example" [RFC3092] 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.  Thus,
   later retrieval of data stored under "xyz.bar.example" in this case
   can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
   in all returned data, or even, when more than one RR is being
   returned, use a mixture of these two capitalizations.  This last case
 Eastlake 3rd                Standards Track                     [Page 5]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
   is unlikely, as optimization of answer length through indirect labels
   tends to cause only one 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 or 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 resource 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, the second MAY override the first so that
   only an uppercase 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 [RFC3490, RFC3454,
   RFC3491, and RFC3492].  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 [RFC3454] and [RFC3491], which should be seen for
   further details.  This is not a part of the DNS as standardized in
   STD 13.
 6.  Security Considerations
   The equivalence of certain DNS label types with case differences, as
   clarified in this document, can lead to security problems.  For
   example, a user could be confused by believing that 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 database
   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
 Eastlake 3rd                Standards Track                     [Page 6]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
   ASCII type labels; that is, always mapping the ASCII letter value
   octets in ASCII labels to some specific pre-chosen case, either
   uppercase or lower case.  An example of a canonical form for domain
   names (and also a canonical ordering for them) appears in Section 6
   of [RFC4034].  See also [RFC3597].
   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 Responsible Person
   (RP) [RFC1183] 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.
 7.  Acknowledgements
   The contributions to this document by Rob Austein, Olafur
   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
   are gratefully acknowledged.
 Normative References
   [ASCII]      ANSI, "USA Standard Code for Information Interchange",
                X3.4, American National Standards Institute: New York,
                1968.
   [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.
   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
                Specification", RFC 2181, July 1997.
   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
                Update", RFC 3007, November 2000.
 Eastlake 3rd                Standards Track                     [Page 7]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
   [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.
   [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.
 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.
   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
                Mockapetris, "New DNS RR Definitions", RFC 1183, October
                1990.
   [RFC1591]    Postel, J., "Domain Name System Structure and
                Delegation", RFC 1591, March 1994.
   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
                Names", BCP 32, RFC 2606, June 1999.
   [RFC2929]    Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
                "Domain Name System (DNS) IANA Considerations", BCP 42,
                RFC 2929, September 2000.
   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
                2671, August 1999.
   [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
                RFC 2673, August 1999.
   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
                of "Foo"", RFC 3092, 1 April 2001.
   [RFC3363]    Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
                Hain, "Representing Internet Protocol version 6 (IPv6)
                Addresses in the Domain Name System (DNS)", RFC 3363,
                August 2002.
 Eastlake 3rd                Standards Track                     [Page 8]
 RFC 4343          DNS Case Insensitivity Clarification      January 2006
   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.
   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
                "Internationalizing Domain Names in Applications
                (IDNA)", RFC 3490, March 2003.
   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
                Profile for Internationalized Domain Names (IDN)", RFC
                3491, March 2003.
   [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
                Unicode for Internationalized Domain Names in
                Applications (IDNA)", RFC 3492, March 2003.
   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
                <http://www.unicode.org/unicode/standard/standard.html>.
 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 9]
 RFC 4343          DNS Case Insensitivity Clarification      January 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 10]
--- a/doc/rfc/rfc4367.txt
+++ b/doc/rfc/rfc4367.txt
@@ -1,955 +0,0 @@
 Network Working Group                                  J. Rosenberg, Ed.
 Request for Comments: 4367                                           IAB
 Category: Informational                                    February 2006
          What's in a Name: False Assumptions about DNS Names
 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 Internet Society (2006).
 Abstract
   The Domain Name System (DNS) provides an essential service on the
   Internet, mapping structured names to a variety of data, usually IP
   addresses.  These names appear in email addresses, Uniform Resource
   Identifiers (URIs), and other application-layer identifiers that are
   often rendered to human users.  Because of this, there has been a
   strong demand to acquire names that have significance to people,
   through equivalence to registered trademarks, company names, types of
   services, and so on.  There is a danger in this trend; the humans and
   automata that consume and use such names will associate specific
   semantics with some names and thereby make assumptions about the
   services that are, or should be, provided by the hosts associated
   with the names.  Those assumptions can often be false, resulting in a
   variety of failure conditions.  This document discusses this problem
   in more detail and makes recommendations on how it can be avoided.
 Rosenberg                    Informational                      [Page 1]
 RFC 4367                    Name Assumptions               February 2006
 Table of Contents
   1. Introduction ....................................................2
   2. Target Audience .................................................4
   3. Modeling Usage of the DNS .......................................4
   4. Possible Assumptions ............................................5
      4.1. By the User ................................................5
      4.2. By the Client ..............................................6
      4.3. By the Server ..............................................7
   5. Consequences of False Assumptions ...............................8
   6. Reasons Why the Assumptions Can Be False ........................9
      6.1. Evolution ..................................................9
      6.2. Leakage ...................................................10
      6.3. Sub-Delegation ............................................10
      6.4. Mobility ..................................................12
      6.5. Human Error ...............................................12
   7. Recommendations ................................................12
   8. A Note on RFC 2219 and RFC 2782 ................................13
   9. Security Considerations ........................................14
   10. Acknowledgements ..............................................14
   11. IAB Members ...................................................14
   12. Informative References ........................................15
 1.  Introduction
   The Domain Name System (DNS) [1] provides an essential service on the
   Internet, mapping structured names to a variety of different types of
   data.  Most often it is used to obtain the IP address of a host
   associated with that name [2] [1] [3].  However, it can be used to
   obtain other information, and proposals have been made for nearly
   everything, including geographic information [4].
   Domain names are most often used in identifiers used by application
   protocols.  The most well known include email addresses and URIs,
   such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
   [6], and SIP URI [7].  These identifiers are ubiquitous, appearing on
   business cards, web pages, street signs, and so on.  Because of this,
   there has been a strong demand to acquire domain names that have
   significance to people through equivalence to registered trademarks,
   company names, types of services, and so on.  Such identifiers serve
   many business purposes, including extension of brand, advertising,
   and so on.
   People often make assumptions about the type of service that is or
   should be provided by a host associated with that name, based on
   their expectations and understanding of what the name implies.  This,
   in turn, triggers attempts by organizations to register domain names
   based on that presumed user expectation.  Examples of this are the
 Rosenberg                    Informational                      [Page 2]
 RFC 4367                    Name Assumptions               February 2006
   various proposals for a Top-Level Domain (TLD) that could be
   associated with adult content [8], the requests for creation of TLDs
   associated with mobile devices and services, and even phishing
   attacks.
   When these assumptions are codified into the behavior of an
   automaton, such as an application client or server, as a result of
   implementor choice, management directive, or domain owner policy, the
   overall system can fail in various ways.  This document describes a
   number of typical ways in which these assumptions can be codified,
   how they can be wrong, the consequences of those mistakes, and the
   recommended ways in which they can be avoided.
   Section 4 describes some of the possible assumptions that clients,
   servers, and people can make about a domain name.  In this context,
   an "assumption" is defined as any behavior that is expected when
   accessing a service at a domain name, even though the behavior is not
   explicitly codified in protocol specifications.  Frequently, these
   assumptions involve ignoring parts of a specification based on an
   assumption that the client or server is deployed in an environment
   that is more rigid than the specification allows.  Section 5
   overviews some of the consequences of these false assumptions.
   Generally speaking, these consequences can include a variety of
   different interoperability failures, user experience failures, and
   system failures.  Section 6 discusses why these assumptions can be
   false from the very beginning or become false at some point in the
   future.  Most commonly, they become false because the environment
   changes in unexpected ways over time, and what was a valid assumption
   before, no longer is.  Other times, the assumptions prove wrong
   because they were based on the belief that a specific community of
   clients and servers was participating, and an element outside of that
   community began participating.
   Section 7 then provides some recommendations.  These recommendations
   encapsulate some of the engineering mantras that have been at the
   root of Internet protocol design for decades.  These include:
      Follow the specifications.
      Use the capability negotiation techniques provided in the
      protocols.
      Be liberal in what you accept, and conservative in what you send.
      [18]
   Overall, automata should not change their behavior within a protocol
   based on the domain name, or some component of the domain name, of
   the host they are communicating with.
 Rosenberg                    Informational                      [Page 3]
 RFC 4367                    Name Assumptions               February 2006
 2.  Target Audience
   This document has several audiences.  Firstly, it is aimed at
   implementors who ultimately develop the software that make the false
   assumptions that are the subject of this document.  The
   recommendations described here are meant to reinforce the engineering
   guidelines that are often understood by implementors, but frequently
   forgotten as deadlines near and pressures mount.
   The document is also aimed at technology managers, who often develop
   the requirements that lead to these false assumptions.  For them,
   this document serves as a vehicle for emphasizing the importance of
   not taking shortcuts in the scope of applicability of a project.
   Finally, this document is aimed at domain name policy makers and
   administrators.  For them, it points out the perils in establishing
   domain policies that get codified into the operation of applications
   running within that domain.
 3.  Modeling Usage of the DNS
                       +--------+
                       |        |
                       |        |
                       |  DNS   |
                       |Service |
                       |        |
                       +--------+
                         ^   |
                         |   |
                         |   |
                         |   |
          /--\           |   |
         |    |          |   V
         |    |        +--------+                     +--------+
          \--/         |        |                     |        |
            |          |        |                     |        |
         ---+---       | Client |-------------------->| Server |
            |          |        |                     |        |
            |          |        |                     |        |
           /\          +--------+                     +--------+
          /  \
         /    \
         User
                                 Figure 1
 Rosenberg                    Informational                      [Page 4]
 RFC 4367                    Name Assumptions               February 2006
   Figure 1 shows a simple conceptual model of how the DNS is used by
   applications.  A user of the application obtains an identifier for
   particular content or service it wishes to obtain.  This identifier
   is often a URL or URI that contains a domain name.  The user enters
   this identifier into its client application (for example, by typing
   in the URL in a web browser window).  The client is the automaton (a
   software and/or hardware system) that contacts a server for that
   application in order to provide service to the user.  To do that, it
   contacts a DNS server to resolve the domain name in the identifier to
   an IP address.  It then contacts the server at that IP address.  This
   simple model applies to application protocols such as HTTP [5], SIP
   [7], RTSP [6], and SMTP [9].
   >From this model, it is clear that three entities in the system can
   potentially make false assumptions about the service provided by the
   server.  The human user may form expectations relating to the content
   of the service based on a parsing of the host name from which the
   content originated.  The server might assume that the client
   connecting to it supports protocols that it does not, can process
   content that it cannot, or has capabilities that it does not.
   Similarly, the client might assume that the server supports
   protocols, content, or capabilities that it does not.  Furthermore,
   applications can potentially contain a multiplicity of humans,
   clients, and servers, all of which can independently make these false
   assumptions.
 4.  Possible Assumptions
   For each of the three elements, there are many types of false
   assumptions that can be made.
 4.1.  By the User
   The set of possible assumptions here is nearly boundless.  Users
   might assume that an HTTP URL that looks like a company name maps to
   a server run by that company.  They might assume that an email from a
   email address in the .gov TLD is actually from a government employee.
   They might assume that the content obtained from a web server within
   a TLD labeled as containing adult materials (for example, .sex)
   actually contains adult content [8].  These assumptions are
   unavoidable, may all be false, and are not the focus of this
   document.
 Rosenberg                    Informational                      [Page 5]
 RFC 4367                    Name Assumptions               February 2006
 4.2.  By the Client
   Even though the client is an automaton, it can make some of the same
   assumptions that a human user might make.  For example, many clients
   assume that any host with a hostname that begins with "www" is a web
   server, even though this assumption may be false.
   In addition, the client concerns itself with the protocols needed to
   communicate with the server.  As a result, it might make assumptions
   about the operation of the protocols for communicating with the
   server.  These assumptions manifest themselves in an implementation
   when a standardized protocol negotiation technique defined by the
   protocol is ignored, and instead, some kind of rule is coded into the
   software that comes to its own conclusion about what the negotiation
   would have determined.  The result is often a loss of
   interoperability, degradation in reliability, and worsening of user
   experience.
   Authentication Algorithm: Though a protocol might support a
      multiplicity of authentication techniques, a client might assume
      that a server always supports one that is only optional according
      to the protocol.  For example, a SIP client contacting a SIP
      server in a domain that is apparently used to identify mobile
      devices (for example, www.example.cellular) might assume that the
      server supports the optional Authentication and Key Agreement
      (AKA) digest technique [10], just because of the domain name that
      was used to access the server.  As another example, a web client
      might assume that a server with the name https.example.com
      supports HTTP over Transport Layer Security (TLS) [16].
   Data Formats: Though a protocol might allow a multiplicity of data
      formats to be sent from the server to the client, the client might
      assume a specific one, rather than using the content labeling and
      negotiation capabilities of the underlying protocol.  For example,
      an RTSP client might assume that all audio content delivered to it
      from media.example.cellular uses a low-bandwidth codec.  As
      another example, a mail client might assume that the contents of
      messages it retrieves from a mail server at mail.example.cellular
      are always text, instead of checking the MIME headers [11] in the
      message in order to determine the actual content type.
   Protocol Extensions: A client may attempt an operation on the server
      that requires the server to support an optional protocol
      extension.  However, rather than implementing the necessary
      fallback logic, the client may falsely assume that the extension
      is supported.  As an example, a SIP client that requires reliable
      provisional responses to its request (RFC 3262 [17]) might assume
      that this extension is supported on servers in the domain
 Rosenberg                    Informational                      [Page 6]
 RFC 4367                    Name Assumptions               February 2006
      sip.example.telecom.  Furthermore, the client would not implement
      the fallback behavior defined in RFC 3262, since it would assume
      that all servers it will communicate with are in this domain and
      that all therefore support this extension.  However, if the
      assumptions prove wrong, the client is unable to make any phone
      calls.
   Languages: A client may support facilities for processing text
      content differently depending on the language of the text.  Rather
      than determining the language from markers in the message from the
      server, the client might assume a language based on the domain
      name.  This assumption can easily be wrong.  For example, a client
      might assume that any text in a web page retrieved from a server
      within the .de country code TLD (ccTLD) is in German, and attempt
      a translation to Finnish.  This would fail dramatically if the
      text was actually in French.  Unfortunately, this client behavior
      is sometimes exhibited because the server has not properly labeled
      the language of the content in the first place, often because the
      server assumed such a labeling was not needed.  This is an example
      of how these false assumptions can create vicious cycles.
 4.3.  By the Server
   The server, like the client, is an automaton.  Let us consider one
   servicing a particular domain -- www.company.cellular, for example.
   It might assume that all clients connecting to this domain support
   particular capabilities, rather than using the underlying protocol to
   make this determination.  Some examples include:
   Authentication Algorithm: The server can assume that a client
      supports a particular, optional, authentication technique, and it
      therefore does not support the mandatory one.
   Language: The server can serve content in a particular language,
      based on an assumption that clients accessing the domain speak a
      particular language, or based on an assumption that clients coming
      from a particular IP address speak a certain language.
   Data Formats: The server can assume that the client supports a
      particular set of MIME types and is only capable of sending ones
      within that set.  When it generates content in a protocol
      response, it ignores any content negotiation headers that were
      present in the request.  For example, a web server might ignore
      the Accept HTTP header field and send a specific image format.
 Rosenberg                    Informational                      [Page 7]
 RFC 4367                    Name Assumptions               February 2006
   Protocol Extensions: The server might assume that the client supports
      a particular optional protocol extension, and so it does not
      support the fallback behavior necessary in the case where the
      client does not.
   Client Characteristics: The server might assume certain things about
      the physical characteristics of its clients, such as memory
      footprint, processing power, screen sizes, screen colors, pointing
      devices, and so on.  Based on these assumptions, it might choose
      specific behaviors when processing a request.  For example, a web
      server might always assume that clients connect through cell
      phones, and therefore return content that lacks images and is
      tuned for such devices.
 5.  Consequences of False Assumptions
   There are numerous negative outcomes that can arise from the various
   false assumptions that users, servers, and clients can make.  These
   include:
   Interoperability Failure: In these cases, the client or server
      assumed some kind of protocol operation, and this assumption was
      wrong.  The result is that the two are unable to communicate, and
      the user receives some kind of an error.  This represents a total
      interoperability failure, manifesting itself as a lack of service
      to users of the system.  Unfortunately, this kind of failure
      persists.  Repeated attempts over time by the client to access the
      service will fail.  Only a change in the server or client software
      can fix this problem.
   System Failure: In these cases, the client or server misinterpreted a
      protocol operation, and this misinterpretation was serious enough
      to uncover a bug in the implementation.  The bug causes a system
      crash or some kind of outage, either transient or permanent (until
      user reset).  If this failure occurs in a server, not only will
      the connecting client lose service, but other clients attempting
      to connect will not get service.  As an example, if a web server
      assumes that content passed to it from a client (created, for
      example, by a digital camera) is of a particular content type, and
      it always passes image content to a codec for decompression prior
      to storage, the codec might crash when it unexpectedly receives an
      image compressed in a different format.  Of course, it might crash
      even if the Content-Type was correct, but the compressed bitstream
      was invalid.  False assumptions merely introduce additional
      failure cases.
 Rosenberg                    Informational                      [Page 8]
 RFC 4367                    Name Assumptions               February 2006
   Poor User Experience: In these cases, the client and server
      communicate, but the user receives a diminished user experience.
      For example, if a client on a PC connects to a web site that
      provides content for mobile devices, the content may be
      underwhelming when viewed on the PC.  Or, a client accessing a
      streaming media service may receive content of very low bitrate,
      even though the client supported better codecs.  Indeed, if a user
      wishes to access content from both a cellular device and a PC
      using a shared address book (that is, an address book shared
      across multiple devices), the user would need two entries in that
      address book, and would need to use the right one from the right
      device.  This is a poor user experience.
   Degraded Security: In these cases, a weaker security mechanism is
      used than the one that ought to have been used.  As an example, a
      server in a domain might assume that it is only contacted by
      clients with a limited set of authentication algorithms, even
      though the clients have been recently upgraded to support a
      stronger set.
 6.  Reasons Why the Assumptions Can Be False
   Assumptions made by clients and servers about the operation of
   protocols when contacting a particular domain are brittle, and can be
   wrong for many reasons.  On the server side, many of the assumptions
   are based on the notion that a domain name will only be given to, or
   used by, a restricted set of clients.  If the holder of the domain
   name assumes something about those clients, and can assume that only
   those clients use the domain name, then it can configure or program
   the server to operate specifically for those clients.  Both parts of
   this assumption can be wrong, as discussed in more detail below.
   On the client side, the notion is similar, being based on the
   assumption that a server within a particular domain will provide a
   specific type of service.  Sub-delegation and evolution, both
   discussed below, can make these assumptions wrong.
 6.1.  Evolution
   The Internet and the devices that access it are constantly evolving,
   often at a rapid pace.  Unfortunately, there is a tendency to build
   for the here and now, and then worry about the future at a later
   time.  Many of the assumptions above are predicated on
   characteristics of today's clients and servers.  Support for specific
   protocols, authentication techniques, or content are based on today's
   standards and today's devices.  Even though they may, for the most
   part, be true, they won't always be.  An excellent example is mobile
   devices.  A server servicing a domain accessed by mobile devices
 Rosenberg                    Informational                      [Page 9]
 RFC 4367                    Name Assumptions               February 2006
   might try to make assumptions about the protocols, protocol
   extensions, security mechanisms, screen sizes, or processor power of
   such devices.  However, all of these characteristics can and will
   change over time.
   When they do change, the change is usually evolutionary.  The result
   is that the assumptions remain valid in some cases, but not in
   others.  It is difficult to fix such systems, since it requires the
   server to detect what type of client is connecting, and what its
   capabilities are.  Unless the system is built and deployed with these
   capability negotiation techniques built in to begin with, such
   detection can be extremely difficult.  In fact, fixing it will often
   require the addition of such capability negotiation features that, if
   they had been in place and used to begin with, would have avoided the
   problem altogether.
 6.2.  Leakage
   Servers also make assumptions because of the belief that they will
   only be accessed by specific clients, and in particular, those that
   are configured or provisioned to use the domain name.  In essence,
   there is an assumption of community -- that a specific community
   knows and uses the domain name, while others outside of the community
   do not.
   The problem is that this notion of community is a false one.  The
   Internet is global.  The DNS is global.  There is no technical
   barrier that separates those inside of the community from those
   outside.  The ease with which information propagates across the
   Internet makes it extremely likely that such domain names will
   eventually find their way into clients outside of the presumed
   community.  The ubiquitous presence of domain names in various URI
   formats, coupled with the ease of conveyance of URIs, makes such
   leakage merely a matter of time.  Furthermore, since the DNS is
   global, and since it can only have one root [12], it becomes possible
   for clients outside of the community to search and find and use such
   "special" domain names.
   Indeed, this leakage is a strength of the Internet architecture, not
   a weakness.  It enables global access to services from any client
   with a connection to the Internet.  That, in turn, allows for rapid
   growth in the number of customers for any particular service.
 6.3.  Sub-Delegation
   Clients and users make assumptions about domains because of the
   notion that there is some kind of centralized control that can
   enforce those assumptions.  However, the DNS is not centralized; it
 Rosenberg                    Informational                     [Page 10]
 RFC 4367                    Name Assumptions               February 2006
   is distributed.  If a domain doesn't delegate its sub-domains and has
   its records within a single zone, it is possible to maintain a
   centralized policy about operation of its domain.  However, once a
   domain gets sufficiently large that the domain administrators begin
   to delegate sub-domains to other authorities, it becomes increasingly
   difficult to maintain any kind of central control on the nature of
   the service provided in each sub-domain.
   Similarly, the usage of domain names with human semantic connotation
   tends to lead to a registration of multiple domains in which a
   particular service is to run.  As an example, a service provider with
   the name "example" might register and set up its services in
   "example.com", "example.net", and generally example.foo for each foo
   that is a valid TLD.  This, like sub-delegation, results in a growth
   in the number of domains over which it is difficult to maintain
   centralized control.
   Not that it is not possible, since there are many examples of
   successful administration of policies across sub-domains many levels
   deep.  However, it takes an increasing amount of effort to ensure
   this result, as it requires human intervention and the creation of
   process and procedure.  Automated validation of adherence to policies
   is very difficult to do, as there is no way to automatically verify
   many policies that might be put into place.
   A less costly process for providing centralized management of
   policies is to just hope that any centralized policies are being
   followed, and then wait for complaints or perform random audits.
   Those approaches have many problems.
   The invalidation of assumptions due to sub-delegation is discussed in
   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
   As a result of the fragility of policy continuity across sub-
   delegations, if a client or user assumes some kind of property
   associated with a TLD (such as ".wifi"), it becomes increasingly more
   likely with the number of sub-domains that this property will not
   exist in a server identified by a particular name.  For example, in
   "store.chain.company.provider.wifi", there may be four levels of
   delegation from ".wifi", making it quite likely that, unless the
   holder of ".wifi" is working diligently, the properties that the
   holder of ".wifi" wishes to enforce are not present.  These
   properties may not be present due to human error or due to a willful
   decision not to adhere to them.
 Rosenberg                    Informational                     [Page 11]
 RFC 4367                    Name Assumptions               February 2006
 6.4.  Mobility
   One of the primary value propositions of a hostname as an identifier
   is its persistence.  A client can change IP addresses, yet still
   retain a persistent identifier used by other hosts to reach it.
   Because their value derives from their persistence, hostnames tend to
   move with a host not just as it changes IP addresses, but as it
   changes access network providers and technologies.  For this reason,
   assumptions made about a host based on the presumed access network
   corresponding to that hostname tend to be wrong over time.  As an
   example, a PC might normally be connected to its broadband provider,
   and through dynamic DNS have a hostname within the domain of that
   provider.  However, one cannot assume that any host within that
   network has access over a broadband link; the user could connect
   their PC over a low-bandwidth wireless access network and still
   retain its domain name.
 6.5.  Human Error
   Of course, human error can be the source of errors in any system, and
   the same is true here.  There are many examples relevant to the
   problem under discussion.
   A client implementation may make the assumption that, just because a
   DNS SRV record exists for a particular protocol in a particular
   domain, indicating that the service is available on some port, that
   the service is, in fact, running there.  This assumption could be
   wrong because the SRV records haven't been updated by the system
   administrators to reflect the services currently running.  As another
   example, a client might assume that a particular domain policy
   applies to all sub-domains.  However, a system administrator might
   have omitted to apply the policy to servers running in one of those
   sub-domains.
 7.  Recommendations
   Based on these problems, the clear conclusion is that clients,
   servers, and users should not make assumptions on the nature of the
   service provided to, or by, a domain.  More specifically, however,
   the following can be said:
   Follow the specifications: When specifications define mandatory
      baseline procedures and formats, those should be implemented and
      supported, even if the expectation is that optional procedures
      will most often be used.  For example, if a specification mandates
      a particular baseline authentication technique, but allows others
      to be negotiated and used, implementations need to implement the
      baseline authentication algorithm even if the other ones are used
 Rosenberg                    Informational                     [Page 12]
 RFC 4367                    Name Assumptions               February 2006
      most of the time.  Put more simply, the behavior of the protocol
      machinery should never change based on the domain name of the
      host.
   Use capability negotiation: Many protocols are engineered with
      capability negotiation mechanisms.  For example, a content
      negotiation framework has been defined for protocols using MIME
      content [13] [14] [15].  SIP allows for clients to negotiate the
      media types used in the multimedia session, as well as protocol
      parameters.  HTTP allows for clients to negotiate the media types
      returned in requests for content.  When such features are
      available in a protocol, client and servers should make use of
      them rather than making assumptions about supported capabilities.
      A corollary is that protocol designers should include such
      mechanisms when evolution is expected in the usage of the
      protocol.
   "Be liberal in what you accept, and conservative in what you send"
      [18]:  This axiom of Internet protocol design is applicable here
      as well.  Implementations should be prepared for the full breadth
      of what a protocol allows another entity to send, rather than be
      limiting in what it is willing to receive.
   To summarize -- there is never a need to make assumptions.  Rather
   than doing so, utilize the specifications and the negotiation
   capabilities they provide, and the overall system will be robust and
   interoperable.
 8.  A Note on RFC 2219 and RFC 2782
   Based on the definition of an assumption given here, the behavior
   hinted at by records in the DNS also represents an assumption.  RFC
   2219 [19] defines well-known aliases that can be used to construct
   domain names for reaching various well-known services in a domain.
   This approach was later followed by the definition of a new resource
   record, the SRV record [2], which specifies that a particular service
   is running on a server in a domain.  Although both of these
   mechanisms are useful as a hint that a particular service is running
   in a domain, both of them represent assumptions that may be false.
   However, they differ in the set of reasons why those assumptions
   might be false.
   A client that assumes that "ftp.example.com" is an FTP server may be
   wrong because the presumed naming convention in RFC 2219 was not
   known by, or not followed by, the owner of domain.com.  With RFC
   2782, an SRV record for a particular service would be present only by
   explicit choice of the domain administrator, and thus a client that
 Rosenberg                    Informational                     [Page 13]
 RFC 4367                    Name Assumptions               February 2006
   assumes that the corresponding host provides this service would be
   wrong only because of human error in configuration.  In this case,
   the assumption is less likely to be wrong, but it certainly can be.
   The only way to determine with certainty that a service is running on
   a host is to initiate a connection to the port for that service, and
   check.  Implementations need to be careful not to codify any
   behaviors that cause failures should the information provided in the
   record actually be false.  This borders on common sense for robust
   implementations, but it is valuable to raise this point explicitly.
 9.  Security Considerations
   One of the assumptions that can be made by clients or servers is the
   availability and usage (or lack thereof) of certain security
   protocols and algorithms.  For example, a client accessing a service
   in a particular domain might assume a specific authentication
   algorithm or hash function in the application protocol.  It is
   possible that, over time, weaknesses are found in such a technique,
   requiring usage of a different mechanism.  Similarly, a system might
   start with an insecure mechanism, and then decide later on to use a
   secure one.  In either case, assumptions made on security properties
   can result in interoperability failures, or worse yet, providing
   service in an insecure way, even though the client asked for, and
   thought it would get, secure service.  These kinds of assumptions are
   fundamentally unsound even if the records themselves are secured with
   DNSSEC.
 10.  Acknowledgements
   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
   for their comments.
 11.  IAB Members
   Internet Architecture Board members at the time of writing of this
   document are:
      Bernard Aboba
      Loa Andersson
      Brian Carpenter
      Leslie Daigle
      Patrik Faltstrom
 Rosenberg                    Informational                     [Page 14]
 RFC 4367                    Name Assumptions               February 2006
      Bob Hinden
      Kurtis Lindqvist
      David Meyer
      Pekka Nikander
      Eric Rescorla
      Pete Resnick
      Jonathan Rosenberg
 12.  Informative References
   [1]   Mockapetris, P., "Domain names - concepts and facilities",
         STD 13, RFC 1034, November 1987.
   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.
   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The Domain Name System (DNS) Database", RFC 3403,
         October 2002.
   [4]   Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
         for Expressing Location Information in the Domain Name System",
         RFC 1876, January 1996.
   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.
   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.
   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.
   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
         February 2004.
   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.
 Rosenberg                    Informational                     [Page 15]
 RFC 4367                    Name Assumptions               February 2006
   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
         Protocol (HTTP) Digest Authentication Using Authentication and
         Key Agreement (AKA)", RFC 3310, September 2002.
   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.
   [12]  Internet Architecture Board, "IAB Technical Comment on the
         Unique DNS Root", RFC 2826, May 2000.
   [13]  Klyne, G., "Indicating Media Features for MIME Content",
         RFC 2912, September 2000.
   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
         RFC 2533, March 1999.
   [15]  Klyne, G., "Protocol-independent Content Negotiation
         Framework", RFC 2703, September 1999.
   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.
   [18]  Braden, R., "Requirements for Internet Hosts - Communication
         Layers", STD 3, RFC 1122, October 1989.
   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
         Services", BCP 17, RFC 2219, October 1997.
   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
         Progress, June 2005.
 Author's Address
   Jonathan Rosenberg, Editor
   IAB
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US
   Phone: +1 973 952-5000
   EMail: jdrosen@cisco.com
   URI:   http://www.jdrosen.net
 Rosenberg                    Informational                     [Page 16]
 RFC 4367                    Name Assumptions               February 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).
 Rosenberg                    Informational                     [Page 17]
--- a/doc/rfc/rfc4398.txt
+++ b/doc/rfc/rfc4398.txt
@@ -1,955 +0,0 @@
 Network Working Group                                       S. Josefsson
 Request for Comments: 4398                                    March 2006
 Obsoletes: 2538
 Category: Standards Track
          Storing Certificates in the Domain Name System (DNS)
 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
   Cryptographic public keys are frequently published, and their
   authenticity is 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                   Standards Track                     [Page 1]
 RFC 4398            Storing Certificates in the DNS        February 2006
 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 ............................6
      2.3. X.509 OIDs .................................................6
   3. Appropriate Owner Names for CERT RRs ............................7
      3.1. Content-Based X.509 CERT RR Names ..........................8
      3.2. Purpose-Based X.509 CERT RR Names ..........................9
      3.3. Content-Based OpenPGP CERT RR Names ........................9
      3.4. Purpose-Based OpenPGP CERT RR Names .......................10
      3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
   4. Performance Considerations .....................................11
   5. Contributors ...................................................11
   6. Acknowledgements ...............................................11
   7. Security Considerations ........................................12
   8. IANA Considerations ............................................12
   9. Changes since RFC 2538 .........................................13
   10. References ....................................................14
      10.1. Normative References .....................................14
      10.2. Informative References ...................................15
   Appendix A.  Copying Conditions ...................................16
 Josefsson                   Standards Track                     [Page 2]
 RFC 4398            Storing Certificates in the DNS        February 2006
 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 of 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 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, 7, and 8 cover performance, security, and IANA
   considerations, respectively.
   Section 9 explains the changes in this document compared to RFC 2538.
   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 [12].  This field is used as an efficiency measure to
 Josefsson                   Standards Track                     [Page 3]
 RFC 4398            Storing Certificates in the DNS        February 2006
   pick which CERT RRs may be applicable to a particular key.  The key
   tag can be calculated for the key in question, and then only CERT RRs
   with the same key tag need to be examined.  Note that two different
   keys can have the same key tag.  However, the key MUST 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 complies to limits (such as key size)
   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 [12], except that a zero algorithm field
   indicates that the algorithm is unknown to a secure DNS, which may
   simply be the result of the algorithm not having been standardized
   for DNSSEC [11].
 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 fingerprint and URL of an OpenPGP packet
             7  ACPKIX    Attribute Certificate
             8  IACPKIX   The URL of an Attribute Certificate
         9-252            Available for IANA assignment
           253  URI       URI private
           254  OID       OID private
           255            Reserved
     256-65279            Available for IANA assignment
   65280-65534            Experimental
         65535            Reserved
   These values represent the initial content of the IANA registry; see
   Section 8.
   The PKIX type is reserved to indicate an X.509 certificate conforming
   to the profile defined by the IETF PKIX working group [8].  The
   certificate section will start with a one-octet unsigned OID length
   and then an X.500 OID indicating the nature of the remainder of the
 Josefsson                   Standards Track                     [Page 4]
 RFC 4398            Storing Certificates in the DNS        February 2006
   certificate section (see Section 2.3, below).  (NOTE: X.509
   certificates do not include their X.500 directory-type-designating
   OID as a prefix.)
   The SPKI and ISPKI types are reserved to indicate the SPKI
   certificate format [15], for use when the SPKI documents are moved
   from experimental status.  The format for these two CERT RR types
   will need to be specified later.
   The PGP type indicates an OpenPGP packet as described in [5] and its
   extensions and successors.  This is used 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
   transferable public keys as described in Section 10.1 of [5], but it
   MAY handle additional OpenPGP packets.
   The ACPKIX type indicates an Attribute Certificate format [9].
   The IPKIX and IACPKIX types indicate a URL that will serve the
   content that would have been in the "certificate, CRL, or URL" field
   of the corresponding type (PKIX or ACPKIX, respectively).
   The IPGP type contains both an OpenPGP fingerprint for the key in
   question, as well as a URL.  The certificate portion of the IPGP CERT
   RR is defined as a one-octet fingerprint length, followed by the
   OpenPGP fingerprint, followed by the URL.  The OpenPGP fingerprint is
   calculated as defined in RFC 2440 [5].  A zero-length fingerprint or
   a zero-length URL are legal, and indicate URL-only IPGP data or
   fingerprint-only IPGP data, respectively.  A zero-length fingerprint
   and a zero-length URL are meaningless and invalid.
   The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
   These 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 DNS message is 512 octets or smaller and could
   thus be expected to fit a UDP packet.
   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 [10], 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.
 Josefsson                   Standards Track                     [Page 5]
 RFC 4398            Storing Certificates in the DNS        February 2006
   The OID private type indicates a private format certificate specified
   by an ISO OID prefix.  The certificate section will start with a
   one-octet 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 [12].
   The certificate/CRL portion is represented in base 64 [16] and may be
   divided 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.
   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.  However, 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:
 Josefsson                   Standards Track                     [Page 6]
 RFC 4398            Storing Certificates in the DNS        February 2006
       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 DNS names with
   characters that require DNS quoting as per Section 5.1 of RFC 1035
   [2].
   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 email 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.
   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 ought to know already; 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 email.
   Implementations SHOULD use the purpose-based owner name guidelines
   described in this document and MAY use CNAME RRs at content-based
   owner names (or other names), pointing to the purpose-based owner
   name.
 Josefsson                   Standards Track                     [Page 7]
 RFC 4398            Storing Certificates in the DNS        February 2006
   Note that this section describes an application-based mapping from
   the name space used in a certificate to the name space used by DNS.
   The DNS does not infer any relationship amongst CERT resource records
   based on similarities or differences of the DNS owner name(s) of CERT
   resource records.  For example, if multiple labels are used when
   mapping from a CERT identifier to a domain name, then care must be
   taken in understanding wildcard record synthesis.
 3.1.  Content-Based X.509 CERT RR Names
   Some X.509 versions, such as the PKIX profile of X.509 [8], permit
   multiple names to be associated with subjects and issuers under
   "Subject Alternative Name" and "Issuer Alternative Name".  For
   example, the PKIX profile has such Alternate Names with an ASN.1
   specification as follows:
      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     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 ought to 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 ought to be used.
   3.  If neither of the above is used, but a URI containing a domain
       name is present, that domain name ought to be used.
   4.  If none of the above is included but a character string name is
       included, then it ought to be treated as described below for
       OpenPGP names.
   5.  If none of the above apply, then the distinguished name (DN)
       ought to 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
 Josefsson                   Standards Track                     [Page 8]
 RFC 4398            Storing Certificates in the DNS        February 2006
   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 [17], SSL/TLS [13], and IPsec [14]:
    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 [18].
 3.3.  Content-Based OpenPGP CERT RR Names
   OpenPGP signed keys (certificates) use a general character string
   User ID [5].  However, it is recommended by OpenPGP that such names
   include the RFC 2822 [7] email address of the party, as in "Leslie
   Example <Leslie@host.example>".  If such a format is used, the CERT
   ought to be under the standard translation of the email address into
 Josefsson                   Standards Track                     [Page 9]
 RFC 4398            Storing Certificates in the DNS        February 2006
   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.  For 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
   auxiliary 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 [16] is recommended.  For 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 help 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, IPGP, and IACPKIX
   These types are stored under the same owner names, both purpose- and
   content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
 Josefsson                   Standards Track                    [Page 10]
 RFC 4398            Storing Certificates in the DNS        February 2006
 4.  Performance Considerations
   The Domain Name System (DNS) protocol was designed for small
   transfers, typically below 512 octets.  While larger transfers will
   perform correctly and work is underway to make larger transfers more
   efficient, it is still advisable at this time that every reasonable
   effort be made 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.
   Deploying CERT RRs to support digitally signed email changes the
   access patterns of DNS lookups from per-domain to per-user.  If
   digitally signed email and a key/certificate lookup based on CERT RRs
   are deployed on a wide scale, this may lead to an increased DNS load,
   with potential performance and cache effectiveness consequences.
   Whether or not this load increase will be noticeable is not known.
 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, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
   Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
   Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
   Weiler, and Florian Weimer.  No doubt the list is incomplete.  We
   apologize to anyone we left out.
 Josefsson                   Standards Track                    [Page 11]
 RFC 4398            Storing Certificates in the DNS        February 2006
 7.  Security Considerations
   By definition, certificates contain their own authenticating
   signatures.  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,
   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 its employees,
   placing CERT RRs 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 that enterprise phone listings are not often publicly
   published and are even marked confidential.
   Using the URI type introduces another level of indirection that may
   open a new vulnerability.  One method of securing that indirection is
   to include a hash of the certificate in the URI 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
   The IANA has created a new registry for CERT RR: certificate types.
   The initial contents of this registry is:
       Decimal   Type     Meaning                           Reference
       -------   ----     -------                           ---------
             0            Reserved                          RFC 4398
             1   PKIX     X.509 as per PKIX                 RFC 4398
             2   SPKI     SPKI certificate                  RFC 4398
             3   PGP      OpenPGP packet                    RFC 4398
             4   IPKIX    The URL of an X.509 data object   RFC 4398
             5   ISPKI    The URL of an SPKI certificate    RFC 4398
             6   IPGP     The fingerprint and URL           RFC 4398
                          of an OpenPGP packet
             7   ACPKIX   Attribute Certificate             RFC 4398
             8   IACPKIX  The URL of an Attribute           RFC 4398
                             Certificate
 Josefsson                   Standards Track                    [Page 12]
 RFC 4398            Storing Certificates in the DNS        February 2006
         9-252            Available for IANA assignment
                             by IETF Standards action
           253   URI      URI private                       RFC 4398
           254   OID      OID private                       RFC 4398
           255            Reserved                          RFC 4398
     256-65279            Available for IANA assignment
                          by IETF Consensus
   65280-65534            Experimental                      RFC 4398
         65535            Reserved                          RFC 4398
   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
   only be assigned by an IETF standards action [6].  This document
   assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE.  Certificate
   types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
   based on RFC documentation of the certificate type.  The availability
   of private types under 0x00FD and 0x00FE ought to 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 will 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.
   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, IPGP, and IACPKIX.
 Josefsson                   Standards Track                    [Page 13]
 RFC 4398            Storing Certificates in the DNS        February 2006
   11.  An IANA registry of CERT type values was created.
 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,
         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
         January 1998.
   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
         "OpenPGP Message Format", RFC 2440, November 1998.
   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.
   [7]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
   [8]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.
   [9]   Farrell, S. and R. Housley, "An Internet Attribute Certificate
         Profile for Authorization", RFC 3281, April 2002.
   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.
   [11]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033,
         March 2005.
   [12]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Resource Records for the DNS Security Extensions", RFC 4034,
         March 2005.
 Josefsson                   Standards Track                    [Page 14]
 RFC 4398            Storing Certificates in the DNS        February 2006
 10.2.  Informative References
   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.
   [14]  Kent, S. and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.
   [15]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
         September 1999.
   [16]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
         RFC 3548, July 2003.
   [17]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851,
         July 2004.
   [18]  Richardson, M., "A Method for Storing IPsec Keying Material in
         DNS", RFC 4025, March 2005.
 Josefsson                   Standards Track                    [Page 15]
 RFC 4398            Storing Certificates in the DNS        February 2006
 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.
 Author's Address
   Simon Josefsson
   EMail: simon@josefsson.org
 Josefsson                   Standards Track                    [Page 16]
 RFC 4398            Storing Certificates in the DNS        February 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).
 Josefsson                   Standards Track                    [Page 17]
--- a/doc/rfc/rfc4408.txt
+++ b/doc/rfc/rfc4408.txt
--- a/doc/rfc/rfc4431.txt
+++ b/doc/rfc/rfc4431.txt
@@ -1,227 +0,0 @@
 Network Working Group                                         M. Andrews
 Request for Comments: 4431                   Internet Systems Consortium
 Category: Informational                                        S. Weiler
                                                            SPARTA, Inc.
                                                           February 2006
       The DNSSEC Lookaside Validation (DLV) DNS Resource Record
 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 Internet Society (2006).
 Abstract
   This document defines a new DNS resource record, called the DNSSEC
   Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
   outside of the DNS delegation chain.
 1.  Introduction
   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
   signature chains along the DNS delegation chain from a trust anchor,
   ideally a trust anchor for the DNS root.
   This document defines a new resource record for publishing such trust
   anchors outside of the DNS's normal delegation chain.  Use of these
   records by DNSSEC validators is outside the scope of this document,
   but it is expected that these records will help resolvers validate
   DNSSEC-signed data from zones whose ancestors either aren't signed or
   refuse to publish delegation signer (DS) records for their children.
 2.  DLV Resource Record
   The DLV resource record has exactly the same wire and presentation
   formats as the DS resource record, defined in RFC 4034, Section 5.
   It uses the same IANA-assigned values in the algorithm and digest
   type fields as the DS record.  (Those IANA registries are known as
   the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
   Numbers" registries.)
 Andrews & Weiler             Informational                      [Page 1]
 RFC 4431                  DLV Resource Record              February 2006
   The DLV record is a normal DNS record type without any special
   processing requirements.  In particular, the DLV record does not
   inherit any of the special processing or handling requirements of the
   DS record type (described in Section 3.1.4.1 of RFC 4035).  Unlike
   the DS record, the DLV record may not appear on the parent's side of
   a zone cut.  A DLV record may, however, appear at the apex of a zone.
 3.  Security Considerations
   For authoritative servers and resolvers that do not attempt to use
   DLV RRs as part of DNSSEC validation, there are no particular
   security concerns -- DLV RRs are just like any other DNS data.
   Software using DLV RRs as part of DNSSEC validation will almost
   certainly want to impose constraints on their use, but those
   constraints are best left to be described by the documents that more
   fully describe the particulars of how the records are used.  At a
   minimum, it would be unwise to use the records without some sort of
   cryptographic authentication.  More likely than not, DNSSEC itself
   will be used to authenticate the DLV RRs.  Depending on how a DLV RR
   is used, failure to properly authenticate it could lead to
   significant additional security problems including failure to detect
   spoofed DNS data.
   RFC 4034, Section 8, describes security considerations specific to
   the DS RR.  Those considerations are equally applicable to DLV RRs.
   Of particular note, the key tag field is used to help select DNSKEY
   RRs efficiently, but it does not uniquely identify a single DNSKEY
   RR.  It is possible for two distinct DNSKEY RRs to have the same
   owner name, the same algorithm type, and the same key tag.  An
   implementation that uses only the key tag to select a DNSKEY RR might
   select the wrong public key in some circumstances.
   For further discussion of the security implications of DNSSEC, see
   RFC 4033, RFC 4034, and RFC 4035.
 4.  IANA Considerations
   IANA has assigned DNS type code 32769 to the DLV resource record from
   the Specification Required portion of the DNS Resource Record Type
   registry, as defined in [4].
   The DLV resource record reuses the same algorithm and digest type
   registries already used for the DS resource record, currently known
   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
   Numbers" registries.
 Andrews & Weiler             Informational                      [Page 2]
 RFC 4431                  DLV Resource Record              February 2006
 5.  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]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
        System (DNS) IANA Considerations", BCP 42, RFC 2929,
        September 2000.
 Authors' Addresses
   Mark Andrews
   Internet Systems Consortium
   950 Charter St.
   Redwood City, CA  94063
   US
   EMail: Mark_Andrews@isc.org
   Samuel Weiler
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, Maryland  21046
   US
   EMail: weiler@tislabs.com
 Andrews & Weiler             Informational                      [Page 3]
 RFC 4431                  DLV Resource Record              February 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).
 Andrews & Weiler             Informational                      [Page 4]
--- a/doc/rfc/rfc4470.txt
+++ b/doc/rfc/rfc4470.txt
@@ -1,451 +0,0 @@
 Network Working Group                                          S. Weiler
 Request for Comments: 4470                                  SPARTA, Inc.
 Updates: 4035, 4034                                             J. Ihren
 Category: Standards Track                                  Autonomica AB
                                                              April 2006
       Minimally Covering NSEC Records and DNSSEC On-line Signing
 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 describes how to construct DNSSEC NSEC resource records
   that cover a smaller range of names than called for by RFC 4034.  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.
 Table of Contents
   1. Introduction ....................................................1
   2. Applicability of This Technique .................................2
   3. Minimally Covering NSEC Records .................................2
   4. Better Epsilon Functions ........................................4
   5. Security Considerations .........................................5
   6. Acknowledgements ................................................6
   7. Normative References ............................................6
 1.  Introduction
   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.
 Weiler & Ihren              Standards Track                     [Page 1]
 RFC 4470                      NSEC Epsilon                    April 2006
   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.
 1.2.  Keywords
   The 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 [4].
 2.  Applicability of This Technique
   The technique presented here may be useful to a zone owner that wants
   to use DNSSEC, is concerned about exposure of its zone contents via
   zone walking, and is willing to bear the costs of on-line signing.
   As discussed in Section 5, on-line signing has several security
   risks, including an increased likelihood of private keys being
   disclosed and an increased risk of denial of service attack.  Anyone
   contemplating use of this technique is strongly encouraged to review
   the discussion of the risks of on-line signing in Section 5.
   Furthermore, at the time this document was published, the DNSEXT
   working group was actively working on a mechanism to prevent zone
   walking that does not require on-line signing (tentatively called
   NSEC3).  The new mechanism is likely to expose slightly more
   information about the zone than this technique (e.g., the number of
   instantiated names), but it may be preferable to this technique.
 3.  Minimally Covering NSEC Records
   This mechanism involves changes to NSEC records for instantiated
   names, which can still be generated and signed in advance, as well as
   the on-demand generation and signing of new NSEC records whenever a
   name must be proven not to exist.
 Weiler & Ihren              Standards Track                     [Page 2]
 RFC 4470                      NSEC Epsilon                    April 2006
   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
   RFC 4034 [2] Section 6.1.  This relaxes the requirement in Section
   4.1.1 of RFC 4034 that the "next name" field contains the next owner
   name in the zone.  This change is expected to be fully compatible
   with all existing DNSSEC validators.  These NSEC records are returned
   whenever proving something specifically about the owner name (e.g.,
   that no resource records of a given type appear at that name).
   Whenever an NSEC record is needed to prove the non-existence of a
   name, a new NSEC record is dynamically produced and signed.  The new
   NSEC record has an owner name lexically before the QNAME but
   lexically following any existing name and a "next name" lexically
   following the QNAME but before any existing name.
   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
   bits set and SHOULD NOT have any other bits set.  This relaxes the
   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
   names that did not exist before the zone was signed.
   The functions to generate the lexically following and proceeding
   names need not be perfect or consistent, but the generated NSEC
   records must not cover any existing names.  Furthermore, this
   technique works best when the generated NSEC records cover as few
   names as possible.  In this document, the functions that generate the
   nearby names are called "epsilon" functions, a reference to the
   mathematical convention of using the greek letter epsilon to
   represent small deviations.
   An NSEC record denying the existence of a wildcard may be generated
   in the same way.  Since the NSEC record covering a non-existent
   wildcard is likely to be used in response to many queries,
   authoritative name servers using the techniques described here may
   want to pregenerate or cache that record and its corresponding RRSIG.
   For example, a query for an A record at the non-instantiated name
   example.com might produce the following two NSEC records, the first
   denying the existence of the name example.com and the second denying
   the existence of a wildcard:
          exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
          \).com 3600 IN NSEC +.com ( RRSIG NSEC )
 Weiler & Ihren              Standards Track                     [Page 3]
 RFC 4470                      NSEC Epsilon                    April 2006
   Before answering a query with these records, an authoritative server
   must test for the existence of names between these endpoints.  If the
   generated NSEC would cover existing names (e.g., exampldd.com or
   *bizarre.example.com), a better epsilon function may be used or the
   covered name closest to the QNAME could be used as the NSEC owner
   name or next name, as appropriate.  If an existing name is used as
   the NSEC owner name, that name's real NSEC record MUST be returned.
   Using the same example, assuming an exampldd.com delegation exists,
   this record might be returned from the parent:
          exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
   Like every authoritative record in the zone, each generated NSEC
   record MUST have corresponding RRSIGs generated using each algorithm
   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
   described in RFC 4035 [3] Section 2.2.  To minimize the number of
   signatures that must be generated, a zone may wish to limit the
   number of algorithms in its DNSKEY RRset.
 4.  Better Epsilon Functions
   Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
   Working backward from that definition, it should be possible to
   define epsilon functions that generate the immediately following and
   preceding names, respectively.  This document does not define such
   functions.  Instead, this section presents functions that come
   reasonably close to the perfect ones.  As described above, an
   authoritative server should still ensure than no generated NSEC
   covers any existing name.
   To increment a name, add a leading label with a single null (zero-
   value) octet.
   To decrement a name, decrement the last character of the leftmost
   label, then fill that label to a length of 63 octets with octets of
   value 255.  To decrement a null (zero-value) octet, remove the octet
   -- if an empty label is left, remove the label.  Defining this
   function numerically: fill the leftmost 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 the following:
 Weiler & Ihren              Standards Track                     [Page 4]
 RFC 4470                      NSEC Epsilon                    April 2006
     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
   The first of these NSEC RRs proves that no exact match for
   foo.example.com exists, and the second proves that there is no
   wildcard in example.com.
   Both of these functions are imperfect: they do not take into account
   constraints on number of labels in a name nor total length of a name.
   As noted in the previous section, though, this technique does not
   depend on the use of perfect epsilon functions: it is sufficient to
   test whether any instantiated names fall into the span covered by the
   generated NSEC and, if so, substitute those instantiated owner names
   for the NSEC owner name or next name, as appropriate.
 5.  Security Considerations
   This approach requires on-demand generation of RRSIG records.  This
   creates several new vulnerabilities.
   First, on-demand signing requires that a zone's authoritative servers
   have access to its private keys.  Storing private keys on well-known
   Internet-accessible servers may make them more vulnerable to
   unintended disclosure.
   Second, since generation of digital signatures tends to be
   computationally demanding, the requirement for on-demand signing
   makes authoritative servers vulnerable to a denial of service attack.
   Last, if the epsilon functions are predictable, on-demand signing may
   enable a chosen-plaintext attack on a zone's private keys.  Zones
   using this approach should attempt to use cryptographic algorithms
   that are resistant to chosen-plaintext attacks.  It is worth noting
   that although 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 records to prevent zone
   walking depends greatly on the quality of the epsilon functions
 Weiler & Ihren              Standards Track                     [Page 5]
 RFC 4470                      NSEC Epsilon                    April 2006
   chosen.  An increment function that chooses a name obviously derived
   from the next instantiated name may be easily reverse engineered,
   destroying the value of this technique.  An increment function that
   always returns a name close to the next instantiated name is likewise
   a poor choice.  Good choices of epsilon functions are the ones that
   produce the immediately following and preceding names, respectively,
   though zone administrators may wish to use less perfect functions
   that return more human-friendly names than the functions described in
   Section 4 above.
   Another obvious but misguided concern is the danger from synthesized
   NSEC records being replayed.  It is possible for an attacker to
   replay an old but still validly signed NSEC record after a new name
   has been added in the span covered by that NSEC, incorrectly proving
   that there is no record at that name.  This danger exists with DNSSEC
   as defined in [3].  The techniques described here actually decrease
   the danger, since the span covered by any NSEC record is smaller than
   before.  Choosing better epsilon functions will further reduce this
   danger.
 6.  Acknowledgements
   Many individuals contributed to this design.  They include, in
   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
   Jakob Schlyter, Bill Manning, and Joao Damas.
   In addition, the editors would like to thank Ed Lewis, Scott Rose,
   and David Blacka for their careful review of the document.
 7.  Normative References
   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "DNS Security Introduction and Requirements", RFC 4033, March
        2005.
   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Resource Records for the DNS Security Extensions", RFC 4034,
        March 2005.
   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Protocol Modifications for the DNS Security Extensions", RFC
        4035, March 2005.
   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.
 Weiler & Ihren              Standards Track                     [Page 6]
 RFC 4470                      NSEC Epsilon                    April 2006
 Authors' Addresses
   Samuel Weiler
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, Maryland  21046
   US
   EMail: weiler@tislabs.com
   Johan Ihren
   Autonomica AB
   Bellmansgatan 30
   Stockholm  SE-118 47
   Sweden
   EMail: johani@autonomica.se
 Weiler & Ihren              Standards Track                     [Page 7]
 RFC 4470                      NSEC Epsilon                    April 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).
 Weiler & Ihren              Standards Track                     [Page 8]
--- a/doc/rfc/rfc4634.txt
+++ b/doc/rfc/rfc4634.txt
--- a/doc/rfc/rfc4641.txt
+++ b/doc/rfc/rfc4641.txt
--- a/lib/dns/api
+++ b/lib/dns/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 18
+LIBINTERFACE = 19
-LIBREVISION = 3
+LIBREVISION = 0
-LIBAGE = 2
+LIBAGE = 3
--- a/lib/dns/include/dns/validator.h
+++ b/lib/dns/include/dns/validator.h
@@ -15,7 +15,7 @@
 * PERFORMANCE OF THIS SOFTWARE.
 */
-/* $Id: validator.h,v 1.18.2.1 2004/03/09 06:11:24 marka Exp $ */
+/* $Id: validator.h,v 1.18.2.1.24.1 2007/01/11 04:58:37 marka Exp $ */
 #ifndef DNS_VALIDATOR_H
 #define DNS_VALIDATOR_H 1
@@ -111,6 +111,11 @@ struct dns_validator {
 	ISC_LINK(dns_validator_t)	link;
 };
 /*%
 * dns_validator_create() options.
 */
 #define DNS_VALIDATOR_DEFER 2U
 ISC_LANG_BEGINDECLS
 isc_result_t
@@ -153,6 +158,15 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 * part of a known insecure domain.
 */
 void
 dns_validator_send(dns_validator_t *validator);
 /*%<
 * Send a deferred validation request
 *
 * Requires:
 *	'validator' to points to a valid DNSSEC validator.
 */
 void
 dns_validator_cancel(dns_validator_t *validator);
 /*
--- a/lib/dns/resolver.c
+++ b/lib/dns/resolver.c
@@ -15,7 +15,7 @@
 * PERFORMANCE OF THIS SOFTWARE.
 */
-/* $Id: resolver.c,v 1.218.2.46 2006/07/28 04:51:18 marka Exp $ */
+/* $Id: resolver.c,v 1.218.2.46.6.1 2007/01/11 04:58:37 marka Exp $ */
 #include <config.h>
@@ -837,6 +837,8 @@ fctx_query(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	INSIST(ISC_LIST_EMPTY(fctx->validators));
 	dns_message_reset(fctx->rmessage, DNS_MESSAGE_INTENTPARSE);
 	query = isc_mem_get(res->mctx, sizeof *query);
@@ -2622,12 +2624,21 @@ maybe_destroy(fetchctx_t *fctx) {
 	unsigned int bucketnum;
 	isc_boolean_t bucket_empty = ISC_FALSE;
 	dns_resolver_t *res = fctx->res;
 	dns_validator_t *validator;
 	REQUIRE(SHUTTINGDOWN(fctx));
-	if (fctx->pending != 0 || !ISC_LIST_EMPTY(fctx->validators))
+	if (fctx->pending != 0)
 		return;
 	for (validator = ISC_LIST_HEAD(fctx->validators);
 	     validator != NULL;
 	     validator = ISC_LIST_HEAD(fctx->validators)) {
 		ISC_LIST_UNLINK(fctx->validators, validator, link);
 		dns_validator_cancel(validator);
 		dns_validator_destroy(&validator);
 	}
 	bucketnum = fctx->bucketnum;
 	LOCK(&res->buckets[bucketnum].lock);
 	if (fctx->references == 0)
@@ -2810,7 +2821,9 @@ validated(isc_task_t *task, isc_event_t *event) {
 			goto noanswer_response;
 	}
-	if (sentresponse) {
+	if (!ISC_LIST_EMPTY(fctx->validators))
 		dns_validator_send(ISC_LIST_HEAD(fctx->validators));
 	else if (sentresponse) {
 		/*
 		 * If we only deferred the destroy because we wanted to cache
 		 * the data, destroy now.
@@ -2830,6 +2843,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 		 * more rdatasets that still need to
 		 * be validated.
 		 */
 		dns_validator_send(ISC_LIST_HEAD(fctx->validators));
 		goto cleanup_event;
 	}
@@ -2878,6 +2892,7 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 	unsigned int options;
 	isc_task_t *task;
 	dns_validator_t *validator;
 	unsigned int valoptions = 0;
 	/*
 	 * The appropriate bucket lock must be held.
@@ -3065,15 +3080,18 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 						rdataset,
 						sigrdataset,
 						fctx->rmessage,
-						0,
+						valoptions,
 						task,
 						validated,
 						fctx,
 						&validator);
-					if (result == ISC_R_SUCCESS)
+					if (result == ISC_R_SUCCESS) {
 						ISC_LIST_APPEND(
 							fctx->validators,
 							validator, link);
 						valoptions |=
 							 DNS_VALIDATOR_DEFER;
 					}
 				}
 			}
 		} else if (!EXTERNAL(rdataset)) {
@@ -3148,7 +3166,7 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, isc_stdtime_t now) {
 					      valrdataset,
 					      valsigrdataset,
 					      fctx->rmessage,
-					      0,
+					      valoptions,
 					      task,
 					      validated,
 					      fctx,
--- a/lib/dns/validator.c
+++ b/lib/dns/validator.c
@@ -15,7 +15,7 @@
 * PERFORMANCE OF THIS SOFTWARE.
 */
-/* $Id: validator.c,v 1.91.2.12 2006/01/06 02:55:16 marka Exp $ */
+/* $Id: validator.c,v 1.91.2.12.6.1 2007/01/11 04:58:37 marka Exp $ */
 #include <config.h>
@@ -1546,7 +1546,8 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	ISC_LINK_INIT(val, link);
 	val->magic = VALIDATOR_MAGIC;
-	isc_task_send(task, ISC_EVENT_PTR(&event));
+	if ((options & DNS_VALIDATOR_DEFER) == 0)
 		isc_task_send(task, ISC_EVENT_PTR(&event));
 	*validatorp = val;
@@ -1563,6 +1564,21 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	return (result);
 }
 void
 dns_validator_send(dns_validator_t *validator) {
 	isc_event_t *event;
 	REQUIRE(VALID_VALIDATOR(validator));
 	LOCK(&validator->lock);
 	INSIST((validator->options & DNS_VALIDATOR_DEFER) != 0);
 	event = (isc_event_t *)validator->event;
 	validator->options &= ~DNS_VALIDATOR_DEFER;
 	UNLOCK(&validator->lock);
 	isc_task_send(validator->task, ISC_EVENT_PTR(&event));
 }
 void
 dns_validator_cancel(dns_validator_t *validator) {
 	REQUIRE(VALID_VALIDATOR(validator));
@@ -1582,6 +1598,13 @@ dns_validator_cancel(dns_validator_t *validator) {
 		if (validator->authvalidator != NULL)
 			dns_validator_cancel(validator->authvalidator);
 		if ((validator->options & DNS_VALIDATOR_DEFER) != 0) {
 			isc_task_t *task = validator->event->ev_sender;
 			validator->options &= ~DNS_VALIDATOR_DEFER;
 			isc_event_free((isc_event_t **)&validator->event);
 			isc_task_detach(&task);
 		}
 	}
 	UNLOCK(&validator->lock);
 }
--- a/4
+++ b/4
@@ -1,10 +1,10 @@
-# $Id: version,v 1.26.2.47 2006/11/28 01:57:58 marka Exp $
+# $Id: version,v 1.26.2.47.4.1 2007/01/11 04:59:36 marka Exp $
 #
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
 #
 MAJORVER=9
 MINORVER=2
-PATCHVER=7
+PATCHVER=8
 RELEASETYPE=
 RELEASEVER=
Author	SHA1	Message	Date
Mark Andrews	a8b6b203c4	9.2.8	2007-01-12 03:33:19 +00:00
Mark Andrews	b000aa3a43	9.2.8	2007-01-12 03:32:51 +00:00
Mark Andrews	a5531ea804	bug -> security	2007-01-12 03:31:03 +00:00
Mark Andrews	9a6a58a66e	update	2007-01-12 02:28:15 +00:00
Mark Andrews	41c9e33e46	9.2.8	2007-01-11 05:09:15 +00:00
Mark Andrews	c83b10e993	9.2.8	2007-01-11 04:59:36 +00:00
Mark Andrews	4e596c759e	2126. [bug] Serialise validation of type ANY responses. [RT #16555 ]	2007-01-11 04:58:37 +00:00
cvs2git	ec42406459	This commit was manufactured by cvs2git to create branch 'v9_2_8_patch'.	2006-12-07 01:36:53 +00:00