diff options
Diffstat (limited to 'contrib/bind9/doc/rfc')
| -rw-r--r-- | contrib/bind9/doc/rfc/index | 5 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4193.txt | 899 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4255.txt | 507 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4343.txt | 563 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4367.txt | 955 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4431.txt | 227 |
6 files changed, 3156 insertions, 0 deletions
diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index index 5c588db..947827e 100644 --- a/contrib/bind9/doc/rfc/index +++ b/contrib/bind9/doc/rfc/index @@ -101,3 +101,8 @@ 4035: Protocol Modifications for the DNS Security Extensions 4074: Common Misbehavior Against DNS Queries for IPv6 Addresses 4159: Deprecation of "ip6.int" +4193: Unique Local IPv6 Unicast Addresses +4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints +4343: Domain Name System (DNS) Case Insensitivity Clarification +4367: What's in a Name: False Assumptions about DNS Names +4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record diff --git a/contrib/bind9/doc/rfc/rfc4193.txt b/contrib/bind9/doc/rfc/rfc4193.txt new file mode 100644 index 0000000..17e2c0b --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4193.txt @@ -0,0 +1,899 @@ + + + + + + +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] + diff --git a/contrib/bind9/doc/rfc/rfc4255.txt b/contrib/bind9/doc/rfc/rfc4255.txt new file mode 100644 index 0000000..f350b7a --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4255.txt @@ -0,0 +1,507 @@ + + + + + + +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] + diff --git a/contrib/bind9/doc/rfc/rfc4343.txt b/contrib/bind9/doc/rfc/rfc4343.txt new file mode 100644 index 0000000..621420a --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4343.txt @@ -0,0 +1,563 @@ + + + + + + +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] + diff --git a/contrib/bind9/doc/rfc/rfc4367.txt b/contrib/bind9/doc/rfc/rfc4367.txt new file mode 100644 index 0000000..f066b64 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4367.txt @@ -0,0 +1,955 @@ + + + + + + +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] + diff --git a/contrib/bind9/doc/rfc/rfc4431.txt b/contrib/bind9/doc/rfc/rfc4431.txt new file mode 100644 index 0000000..8b38872 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4431.txt @@ -0,0 +1,227 @@ + + + + + + +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] + |
