+++ /dev/null
--
--
--
--Network Working Group S. Weiler
--Internet-Draft SPARTA, Inc
--Updates: 4034, 4035 (if approved) J. Ihren
--Expires: July 24, 2006 Autonomica AB
-- January 20, 2006
--
--
-- Minimally Covering NSEC Records and DNSSEC On-line Signing
-- draft-ietf-dnsext-dnssec-online-signing-02
--
--Status of this Memo
--
-- By submitting this Internet-Draft, each author represents that any
-- applicable patent or other IPR claims of which he or she is aware
-- have been or will be disclosed, and any of which he or she becomes
-- aware will be disclosed, in accordance with Section 6 of BCP 79.
--
-- Internet-Drafts are working documents of the Internet Engineering
-- Task Force (IETF), its areas, and its working groups. Note that
-- other groups may also distribute working documents as Internet-
-- Drafts.
--
-- Internet-Drafts are draft documents valid for a maximum of six months
-- and may be updated, replaced, or obsoleted by other documents at any
-- time. It is inappropriate to use Internet-Drafts as reference
-- material or to cite them other than as "work in progress."
--
-- The list of current Internet-Drafts can be accessed at
-- http://www.ietf.org/ietf/1id-abstracts.txt.
--
-- The list of Internet-Draft Shadow Directories can be accessed at
-- http://www.ietf.org/shadow.html.
--
-- This Internet-Draft will expire on July 24, 2006.
--
--Copyright Notice
--
-- Copyright (C) The Internet Society (2006).
--
--Abstract
--
-- This document describes how to construct DNSSEC NSEC resource records
-- that cover a smaller range of names than called for by RFC4034. By
-- generating and signing these records on demand, authoritative name
-- servers can effectively stop the disclosure of zone contents
-- otherwise made possible by walking the chain of NSEC records in a
-- signed zone.
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 1]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
--Changes from ietf-01 to ietf-02
--
-- Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
-- and NSEC bits set, to be consistent with DNSSECbis -- previous text
-- said SHOULD.
--
-- Made the applicability statement a little less oppressive.
--
--Changes from ietf-00 to ietf-01
--
-- Added an applicability statement, making reference to ongoing work on
-- NSEC3.
--
-- Added the phrase "epsilon functions", which has been commonly used to
-- describe the technique and already appeared in the header of each
-- page, in place of "increment and decrement functions". Also added an
-- explanatory sentence.
--
-- Corrected references from 4034 section 6.2 to section 6.1.
--
-- Fixed an out-of-date reference to [-bis] and other typos.
--
-- Replaced IANA Considerations text.
--
-- Escaped close parentheses in examples.
--
-- Added some more acknowledgements.
--
--Changes from weiler-01 to ietf-00
--
-- Inserted RFC numbers for 4033, 4034, and 4035.
--
-- Specified contents of bitmap field in synthesized NSEC RR's, pointing
-- out that this relaxes a constraint in 4035. Added 4035 to the
-- Updates header.
--
--Changes from weiler-00 to weiler-01
--
-- Clarified that this updates RFC4034 by relaxing requirements on the
-- next name field.
--
-- Added examples covering wildcard names.
--
-- In the 'better functions' section, reiterated that perfect functions
-- aren't needed.
--
-- Added a reference to RFC 2119.
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 2]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
--Table of Contents
--
-- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
-- 2. Applicability of This Technique . . . . . . . . . . . . . . . 4
-- 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5
-- 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6
-- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
-- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
-- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
-- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
-- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-- Intellectual Property and Copyright Statements . . . . . . . . . . 11
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 3]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
--1. Introduction and Terminology
--
-- With DNSSEC [1], an NSEC record lists the next instantiated name in
-- its zone, proving that no names exist in the "span" between the
-- NSEC's owner name and the name in the "next name" field. In this
-- document, an NSEC record is said to "cover" the names between its
-- owner name and next name.
--
-- Through repeated queries that return NSEC records, it is possible to
-- retrieve all of the names in the zone, a process commonly called
-- "walking" the zone. Some zone owners have policies forbidding zone
-- transfers by arbitrary clients; this side-effect of the NSEC
-- architecture subverts those policies.
--
-- This document presents a way to prevent zone walking by constructing
-- NSEC records that cover fewer names. These records can make zone
-- walking take approximately as many queries as simply asking for all
-- possible names in a zone, making zone walking impractical. Some of
-- these records must be created and signed on demand, which requires
-- on-line private keys. Anyone contemplating use of this technique is
-- strongly encouraged to review the discussion of the risks of on-line
-- signing in Section 6.
--
-- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-- document are to be interpreted as described in RFC 2119 [4].
--
--
--2. Applicability of This Technique
--
-- The technique presented here may be useful to a zone owner that wants
-- to use DNSSEC, is concerned about exposure of its zone contents via
-- zone walking, and is willing to bear the costs of on-line signing.
--
-- As discussed in Section 6, on-line signing has several security
-- risks, including an increased likelihood of private keys being
-- disclosed and an increased risk of denial of service attack. Anyone
-- contemplating use of this technique is strongly encouraged to review
-- the discussion of the risks of on-line signing in Section 6.
--
-- Furthermore, at the time this document was published, the DNSEXT
-- working group was actively working on a mechanism to prevent zone
-- walking that does not require on-line signing (tentatively called
-- NSEC3). The new mechanism is likely to expose slightly more
-- information about the zone than this technique (e.g. the number of
-- instantiated names), but it may be preferable to this technique.
--
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 4]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
--3. Minimally Covering NSEC Records
--
-- This mechanism involves changes to NSEC records for instantiated
-- names, which can still be generated and signed in advance, as well as
-- the on-demand generation and signing of new NSEC records whenever a
-- name must be proven not to exist.
--
-- In the 'next name' field of instantiated names' NSEC records, rather
-- than list the next instantiated name in the zone, list any name that
-- falls lexically after the NSEC's owner name and before the next
-- instantiated name in the zone, according to the ordering function in
-- RFC4034 [2] section 6.1. This relaxes the requirement in section
-- 4.1.1 of RFC4034 that the 'next name' field contains the next owner
-- name in the zone. This change is expected to be fully compatible
-- with all existing DNSSEC validators. These NSEC records are returned
-- whenever proving something specifically about the owner name (e.g.
-- that no resource records of a given type appear at that name).
--
-- Whenever an NSEC record is needed to prove the non-existence of a
-- name, a new NSEC record is dynamically produced and signed. The new
-- NSEC record has an owner name lexically before the QNAME but
-- lexically following any existing name and a 'next name' lexically
-- following the QNAME but before any existing name.
--
-- The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
-- bits set and SHOULD NOT have any other bits set. This relaxes the
-- requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
-- names that did not exist before the zone was signed.
--
-- The functions to generate the lexically following and proceeding
-- names need not be perfect nor consistent, but the generated NSEC
-- records must not cover any existing names. Furthermore, this
-- technique works best when the generated NSEC records cover as few
-- names as possible. In this document, the functions that generate the
-- nearby names are called 'epsilon' functions, a reference to the
-- mathematical convention of using the greek letter epsilon to
-- represent small deviations.
--
-- An NSEC record denying the existence of a wildcard may be generated
-- in the same way. Since the NSEC record covering a non-existent
-- wildcard is likely to be used in response to many queries,
-- authoritative name servers using the techniques described here may
-- want to pregenerate or cache that record and its corresponding RRSIG.
--
-- For example, a query for an A record at the non-instantiated name
-- example.com might produce the following two NSEC records, the first
-- denying the existence of the name example.com and the second denying
-- the existence of a wildcard:
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 5]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
-- exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
--
-- \).com 3600 IN NSEC +.com ( RRSIG NSEC )
--
-- Before answering a query with these records, an authoritative server
-- must test for the existence of names between these endpoints. If the
-- generated NSEC would cover existing names (e.g. exampldd.com or
-- *bizarre.example.com), a better epsilon function may be used or the
-- covered name closest to the QNAME could be used as the NSEC owner
-- name or next name, as appropriate. If an existing name is used as
-- the NSEC owner name, that name's real NSEC record MUST be returned.
-- Using the same example, assuming an exampldd.com delegation exists,
-- this record might be returned from the parent:
--
-- exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
--
-- Like every authoritative record in the zone, each generated NSEC
-- record MUST have corresponding RRSIGs generated using each algorithm
-- (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
-- described in RFC4035 [3] section 2.2. To minimize the number of
-- signatures that must be generated, a zone may wish to limit the
-- number of algorithms in its DNSKEY RRset.
--
--
--4. Better Epsilon Functions
--
-- Section 6.1 of RFC4034 defines a strict ordering of DNS names.
-- Working backwards from that definition, it should be possible to
-- define epsilon functions that generate the immediately following and
-- preceding names, respectively. This document does not define such
-- functions. Instead, this section presents functions that come
-- reasonably close to the perfect ones. As described above, an
-- authoritative server should still ensure than no generated NSEC
-- covers any existing name.
--
-- To increment a name, add a leading label with a single null (zero-
-- value) octet.
--
-- To decrement a name, decrement the last character of the leftmost
-- label, then fill that label to a length of 63 octets with octets of
-- value 255. To decrement a null (zero-value) octet, remove the octet
-- -- if an empty label is left, remove the label. Defining this
-- function numerically: fill the left-most label to its maximum length
-- with zeros (numeric, not ASCII zeros) and subtract one.
--
-- In response to a query for the non-existent name foo.example.com,
-- these functions produce NSEC records of:
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 6]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
-- fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
--
-- \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-- \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
--
-- The first of these NSEC RRs proves that no exact match for
-- foo.example.com exists, and the second proves that there is no
-- wildcard in example.com.
--
-- Both of these functions are imperfect: they don't take into account
-- constraints on number of labels in a name nor total length of a name.
-- As noted in the previous section, though, this technique does not
-- depend on the use of perfect epsilon functions: it is sufficient to
-- test whether any instantiated names fall into the span covered by the
-- generated NSEC and, if so, substitute those instantiated owner names
-- for the NSEC owner name or next name, as appropriate.
--
--
--5. IANA Considerations
--
-- This document specifies no IANA Actions.
--
--
--6. Security Considerations
--
-- This approach requires on-demand generation of RRSIG records. This
-- creates several new vulnerabilities.
--
-- First, on-demand signing requires that a zone's authoritative servers
-- have access to its private keys. Storing private keys on well-known
-- internet-accessible servers may make them more vulnerable to
-- unintended disclosure.
--
-- Second, since generation of digital signatures tends to be
-- computationally demanding, the requirement for on-demand signing
-- makes authoritative servers vulnerable to a denial of service attack.
--
-- Lastly, if the epsilon functions are predictable, on-demand signing
-- may enable a chosen-plaintext attack on a zone's private keys. Zones
-- using this approach should attempt to use cryptographic algorithms
-- that are resistant to chosen-plaintext attacks. It's worth noting
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 7]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
-- that while DNSSEC has a "mandatory to implement" algorithm, that is a
-- requirement on resolvers and validators -- there is no requirement
-- that a zone be signed with any given algorithm.
--
-- The success of using minimally covering NSEC record to prevent zone
-- walking depends greatly on the quality of the epsilon functions
-- chosen. An increment function that chooses a name obviously derived
-- from the next instantiated name may be easily reverse engineered,
-- destroying the value of this technique. An increment function that
-- always returns a name close to the next instantiated name is likewise
-- a poor choice. Good choices of epsilon functions are the ones that
-- produce the immediately following and preceding names, respectively,
-- though zone administrators may wish to use less perfect functions
-- that return more human-friendly names than the functions described in
-- Section 4 above.
--
-- Another obvious but misguided concern is the danger from synthesized
-- NSEC records being replayed. It's possible for an attacker to replay
-- an old but still validly signed NSEC record after a new name has been
-- added in the span covered by that NSEC, incorrectly proving that
-- there is no record at that name. This danger exists with DNSSEC as
-- defined in [3]. The techniques described here actually decrease the
-- danger, since the span covered by any NSEC record is smaller than
-- before. Choosing better epsilon functions will further reduce this
-- danger.
--
--7. Normative References
--
-- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-- "DNS Security Introduction and Requirements", RFC 4033,
-- March 2005.
--
-- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-- "Resource Records for the DNS Security Extensions", RFC 4034,
-- March 2005.
--
-- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-- "Protocol Modifications for the DNS Security Extensions",
-- RFC 4035, March 2005.
--
-- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-- Levels", BCP 14, RFC 2119, March 1997.
--
--
--Appendix A. Acknowledgments
--
-- Many individuals contributed to this design. They include, in
-- addition to the authors of this document, Olaf Kolkman, Ed Lewis,
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 8]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
-- Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
-- Jakob Schlyter, Bill Manning, and Joao Damas.
--
-- In addition, the editors would like to thank Ed Lewis, Scott Rose,
-- and David Blacka for their careful review of the document.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 9]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
--Authors' Addresses
--
-- Samuel Weiler
-- SPARTA, Inc
-- 7075 Samuel Morse Drive
-- Columbia, Maryland 21046
-- US
--
-- Email: weiler@tislabs.com
--
--
-- Johan Ihren
-- Autonomica AB
-- Bellmansgatan 30
-- Stockholm SE-118 47
-- Sweden
--
-- Email: johani@autonomica.se
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 10]
--\f
--Internet-Draft NSEC Epsilon January 2006
--
--
--Intellectual Property Statement
--
-- The IETF takes no position regarding the validity or scope of any
-- Intellectual Property Rights or other rights that might be claimed to
-- pertain to the implementation or use of the technology described in
-- this document or the extent to which any license under such rights
-- might or might not be available; nor does it represent that it has
-- made any independent effort to identify any such rights. Information
-- on the procedures with respect to rights in RFC documents can be
-- found in BCP 78 and BCP 79.
--
-- Copies of IPR disclosures made to the IETF Secretariat and any
-- assurances of licenses to be made available, or the result of an
-- attempt made to obtain a general license or permission for the use of
-- such proprietary rights by implementers or users of this
-- specification can be obtained from the IETF on-line IPR repository at
-- http://www.ietf.org/ipr.
--
-- The IETF invites any interested party to bring to its attention any
-- copyrights, patents or patent applications, or other proprietary
-- rights that may cover technology that may be required to implement
-- this standard. Please address the information to the IETF at
-- ietf-ipr@ietf.org.
--
--
--Disclaimer of Validity
--
-- This document and the information contained herein are provided on an
-- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--
--
--Copyright Statement
--
-- Copyright (C) The Internet Society (2006). This document is subject
-- to the rights, licenses and restrictions contained in BCP 78, and
-- except as set forth therein, the authors retain all their rights.
--
--
--Acknowledgment
--
-- Funding for the RFC Editor function is currently provided by the
-- Internet Society.
--
--
--
--
--Weiler & Ihren Expires July 24, 2006 [Page 11]
--\f
+++ /dev/null
--
--
--
--Network Working Group R. Austein
--Internet-Draft ISC
--Expires: July 15, 2006 January 11, 2006
--
--
-- DNS Name Server Identifier Option (NSID)
-- draft-ietf-dnsext-nsid-01
--
--Status of this Memo
--
-- By submitting this Internet-Draft, each author represents that any
-- applicable patent or other IPR claims of which he or she is aware
-- have been or will be disclosed, and any of which he or she becomes
-- aware will be disclosed, in accordance with Section 6 of BCP 79.
--
-- Internet-Drafts are working documents of the Internet Engineering
-- Task Force (IETF), its areas, and its working groups. Note that
-- other groups may also distribute working documents as Internet-
-- Drafts.
--
-- Internet-Drafts are draft documents valid for a maximum of six months
-- and may be updated, replaced, or obsoleted by other documents at any
-- time. It is inappropriate to use Internet-Drafts as reference
-- material or to cite them other than as "work in progress."
--
-- The list of current Internet-Drafts can be accessed at
-- http://www.ietf.org/ietf/1id-abstracts.txt.
--
-- The list of Internet-Draft Shadow Directories can be accessed at
-- http://www.ietf.org/shadow.html.
--
-- This Internet-Draft will expire on July 15, 2006.
--
--Copyright Notice
--
-- Copyright (C) The Internet Society (2006).
--
--Abstract
--
-- With the increased use of DNS anycast, load balancing, and other
-- mechanisms allowing more than one DNS name server to share a single
-- IP address, it is sometimes difficult to tell which of a pool of name
-- servers has answered a particular query. While existing ad-hoc
-- mechanism allow an operator to send follow-up queries when it is
-- necessary to debug such a configuration, the only completely reliable
-- way to obtain the identity of the name server which responded is to
-- have the name server include this information in the response itself.
-- This note defines a protocol extension to support this functionality.
--
--
--
--Austein Expires July 15, 2006 [Page 1]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--Table of Contents
--
-- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
-- 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
-- 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4
-- 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4
-- 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
-- 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5
-- 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-- 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6
-- 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8
-- 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8
-- 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9
-- 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
-- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
-- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-- 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
-- 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
-- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-- Intellectual Property and Copyright Statements . . . . . . . . . . 15
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 2]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--1. Introduction
--
-- With the increased use of DNS anycast, load balancing, and other
-- mechanisms allowing more than one DNS name server to share a single
-- IP address, it is sometimes difficult to tell which of a pool of name
-- servers has answered a particular query.
--
-- Existing ad-hoc mechanisms allow an operator to send follow-up
-- queries when it is necessary to debug such a configuration, but there
-- are situations in which this is not a totally satisfactory solution,
-- since anycast routing may have changed, or the server pool in
-- question may be behind some kind of extremely dynamic load balancing
-- hardware. Thus, while these ad-hoc mechanisms are certainly better
-- than nothing (and have the advantage of already being deployed), a
-- better solution seems desirable.
--
-- Given that a DNS query is an idempotent operation with no retained
-- state, it would appear that the only completely reliable way to
-- obtain the identity of the name server which responded to a
-- particular query is to have that name server include identifying
-- information in the response itself. This note defines a protocol
-- enhancement to achieve this.
--
--1.1. Reserved Words
--
-- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-- document are to be interpreted as described in [RFC2119].
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 3]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--2. Protocol
--
-- This note uses an EDNS [RFC2671] option to signal the resolver's
-- desire for information identifying the name server and to hold the
-- name server's response, if any.
--
--2.1. Resolver Behavior
--
-- A resolver signals its desire for information identifying a name
-- server by sending an empty NSID option (Section 2.3) in an EDNS OPT
-- pseudo-RR in the query message.
--
-- The resolver MUST NOT include any NSID payload data in the query
-- message.
--
-- The semantics of an NSID request are not transitive. That is: the
-- presence of an NSID option in a query is a request that the name
-- server which receives the query identify itself. If the name server
-- side of a recursive name server receives an NSID request, the client
-- is asking the recursive name server to identify itself; if the
-- resolver side of the recursive name server wishes to receive
-- identifying information, it is free to add NSID requests in its own
-- queries, but that is a separate matter.
--
--2.2. Name Server Behavior
--
-- A name server which understands the NSID option and chooses to honor
-- a particular NSID request responds by including identifying
-- information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
-- in the response message.
--
-- The name server MUST ignore any NSID payload data that might be
-- present in the query message.
--
-- The NSID option is not transitive. A name server MUST NOT send an
-- NSID option back to a resolver which did not request it. In
-- particular, while a recursive name server may choose to add an NSID
-- option when sending a query, this has no effect on the presence or
-- absence of the NSID option in the recursive name server's response to
-- the original client.
--
-- As stated in Section 2.1, this mechanism is not restricted to
-- authoritative name servers; the semantics are intended to be equally
-- applicable to recursive name servers.
--
--2.3. The NSID Option
--
-- The OPTION-CODE for the NSID option is [TBD].
--
--
--
--Austein Expires July 15, 2006 [Page 4]
--\f
--Internet-Draft DNS NSID January 2006
--
--
-- The OPTION-DATA for the NSID option is an opaque byte string the
-- semantics of which are deliberately left outside the protocol. See
-- Section 3.1 for discussion.
--
--2.4. Presentation Format
--
-- User interfaces MUST read and write the content of the NSID option as
-- a sequence of hexadecimal digits, two digits per payload octet.
--
-- The NSID payload is binary data. Any comparison between NSID
-- payloads MUST be a comparison of the raw binary data. Copy
-- operations MUST NOT assume that the raw NSID payload is null-
-- terminated. Any resemblance between raw NSID payload data and any
-- form of text is purely a convenience, and does not change the
-- underlying nature of the payload data.
--
-- See Section 3.3 for discussion.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 5]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--3. Discussion
--
-- This section discusses certain aspects of the protocol and explains
-- considerations that led to the chosen design.
--
--3.1. The NSID Payload
--
-- The syntax and semantics of the content of the NSID option is
-- deliberately left outside the scope of this specification. This
-- section describe some of the kinds of data that server administrators
-- might choose to provide as the content of the NSID option, and
-- explains the reasoning behind choosing a simple opaque byte string.
--
-- There are several possibilities for the payload of the NSID option:
--
-- o It could be the "real" name of the specific name server within the
-- name server pool.
--
-- o It could be the "real" IP address (IPv4 or IPv6) of the name
-- server within the name server pool.
--
-- o It could be some sort of pseudo-random number generated in a
-- predictable fashion somehow using the server's IP address or name
-- as a seed value.
--
-- o It could be some sort of probabilisticly unique identifier
-- initially derived from some sort of random number generator then
-- preserved across reboots of the name server.
--
-- o It could be some sort of dynamicly generated identifier so that
-- only the name server operator could tell whether or not any two
-- queries had been answered by the same server.
--
-- o It could be a blob of signed data, with a corresponding key which
-- might (or might not) be available via DNS lookups.
--
-- o It could be a blob of encrypted data, the key for which could be
-- restricted to parties with a need to know (in the opinion of the
-- server operator).
--
-- o It could be an arbitrary string of octets chosen at the discretion
-- of the name server operator.
--
-- Each of these options has advantages and disadvantages:
--
-- o Using the "real" name is simple, but the name server may not have
-- a "real" name.
--
--
--
--
--Austein Expires July 15, 2006 [Page 6]
--\f
--Internet-Draft DNS NSID January 2006
--
--
-- o Using the "real" address is also simple, and the name server
-- almost certainly does have at least one non-anycast IP address for
-- maintenance operations, but the operator of the name server may
-- not be willing to divulge its non-anycast address.
--
-- o Given that one common reason for using anycast DNS techniques is
-- an attempt to harden a critical name server against denial of
-- service attacks, some name server operators are likely to want an
-- identifier other than the "real" name or "real" address of the
-- name server instance.
--
-- o Using a hash or pseudo-random number can provide a fixed length
-- value that the resolver can use to tell two name servers apart
-- without necessarily being able to tell where either one of them
-- "really" is, but makes debugging more difficult if one happens to
-- be in a friendly open environment. Furthermore, hashing might not
-- add much value, since a hash based on an IPv4 address still only
-- involves a 32-bit search space, and DNS names used for servers
-- that operators might have to debug at 4am tend not to be very
-- random.
--
-- o Probabilisticly unique identifiers have similar properties to
-- hashed identifiers, but (given a sufficiently good random number
-- generator) are immune to the search space issues. However, the
-- strength of this approach is also its weakness: there is no
-- algorithmic transformation by which even the server operator can
-- associate name server instances with identifiers while debugging,
-- which might be annoying. This approach also requires the name
-- server instance to preserve the probabilisticly unique identifier
-- across reboots, but this does not appear to be a serious
-- restriction, since authoritative nameservers almost always have
-- some form of nonvolatile storage in any case, and in the rare case
-- of a name server that does not have any way to store such an
-- identifier, nothing terrible will happen if the name server just
-- generates a new identifier every time it reboots.
--
-- o Using an arbitrary octet string gives name server operators yet
-- another thing to configure, or mis-configure, or forget to
-- configure. Having all the nodes in an anycast name server
-- constellation identify themselves as "My Name Server" would not be
-- particularly useful.
--
-- Given all of the issues listed above, there does not appear to be a
-- single solution that will meet all needs. Section 2.3 therefore
-- defines the NSID payload to be an opaque byte string and leaves the
-- choice up to the implementor and name server operator. The following
-- guidelines may be useful to implementors and server operators:
--
--
--
--
--Austein Expires July 15, 2006 [Page 7]
--\f
--Internet-Draft DNS NSID January 2006
--
--
-- o Operators for whom divulging the unicast address is an issue could
-- use the raw binary representation of a probabilisticly unique
-- random number. This should probably be the default implementation
-- behavior.
--
-- o Operators for whom divulging the unicast address is not an issue
-- could just use the raw binary representation of a unicast address
-- for simplicity. This should only be done via an explicit
-- configuration choice by the operator.
--
-- o Operators who really need or want the ability to set the NSID
-- payload to an arbitrary value could do so, but this should only be
-- done via an explicit configuration choice by the operator.
--
-- This approach appears to provide enough information for useful
-- debugging without unintentionally leaking the maintenance addresses
-- of anycast name servers to nogoodniks, while also allowing name
-- server operators who do not find such leakage threatening to provide
-- more information at their own discretion.
--
--3.2. NSID Is Not Transitive
--
-- As specified in Section 2.1 and Section 2.2, the NSID option is not
-- transitive. This is strictly a hop-by-hop mechanism.
--
-- Most of the discussion of name server identification to date has
-- focused on identifying authoritative name servers, since the best
-- known cases of anycast name servers are a subset of the name servers
-- for the root zone. However, given that anycast DNS techniques are
-- also applicable to recursive name servers, the mechanism may also be
-- useful with recursive name servers. The hop-by-hop semantics support
-- this.
--
-- While there might be some utility in having a transitive variant of
-- this mechanism (so that, for example, a stub resolver could ask a
-- recursive server to tell it which authoritative name server provided
-- a particular answer to the recursive name server), the semantics of
-- such a variant would be more complicated, and are left for future
-- work.
--
--3.3. User Interface Issues
--
-- Given the range of possible payload contents described in
-- Section 3.1, it is not possible to define a single presentation
-- format for the NSID payload that is efficient, convenient,
-- unambiguous, and aesthetically pleasing. In particular, while it is
-- tempting to use a presentation format that uses some form of textual
-- strings, attempting to support this would significantly complicate
--
--
--
--Austein Expires July 15, 2006 [Page 8]
--\f
--Internet-Draft DNS NSID January 2006
--
--
-- what's intended to be a very simple debugging mechanism.
--
-- In some cases the content of the NSID payload may be binary data
-- meaningful only to the name server operator, and may not be
-- meaningful to the user or application, but the user or application
-- must be able to capture the entire content anyway in order for it to
-- be useful. Thus, the presentation format must support arbitrary
-- binary data.
--
-- In cases where the name server operator derives the NSID payload from
-- textual data, a textual form such as US-ASCII or UTF-8 strings might
-- at first glance seem easier for a user to deal with. There are,
-- however, a number of complex issues involving internationalized text
-- which, if fully addressed here, would require a set of rules
-- significantly longer than the rest of this specification. See
-- [RFC2277] for an overview of some of these issues.
--
-- It is much more important for the NSID payload data to be passed
-- unambiguously from server administrator to user and back again than
-- it is for the payload data data to be pretty while in transit. In
-- particular, it's critical that it be straightforward for a user to
-- cut and paste an exact copy of the NSID payload output by a debugging
-- tool into other formats such as email messages or web forms without
-- distortion. Hexadecimal strings, while ugly, are also robust.
--
--3.4. Truncation
--
-- In some cases, adding the NSID option to a response message may
-- trigger message truncation. This specification does not change the
-- rules for DNS message truncation in any way, but implementors will
-- need to pay attention to this issue.
--
-- Including the NSID option in a response is always optional, so this
-- specification never requires name servers to truncate response
-- messages.
--
-- By definition, a resolver that requests NSID responses also supports
-- EDNS, so a resolver that requests NSID responses can also use the
-- "sender's UDP payload size" field of the OPT pseudo-RR to signal a
-- receive buffer size large enough to make truncation unlikely.
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 9]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--4. IANA Considerations
--
-- This mechanism requires allocation of one ENDS option code for the
-- NSID option (Section 2.3).
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 10]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--5. Security Considerations
--
-- This document describes a channel signaling mechanism, intended
-- primarily for debugging. Channel signaling mechanisms are outside
-- the scope of DNSSEC per se. Applications that require integrity
-- protection for the data being signaled will need to use a channel
-- security mechanism such as TSIG [RFC2845].
--
-- Section 3.1 discusses a number of different kinds of information that
-- a name server operator might choose to provide as the value of the
-- NSID option. Some of these kinds of information are security
-- sensitive in some environments. This specification deliberately
-- leaves the syntax and semantics of the NSID option content up to the
-- implementation and the name server operator.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 11]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--6. Acknowledgements
--
-- Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
-- Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
-- Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
-- Suzanne Woolf. Apologies to anyone inadvertently omitted from the
-- above list.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 12]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--7. References
--
--7.1. Normative References
--
-- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-- Requirement Levels", RFC 2119, BCP 14, March 1997.
--
-- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-- RFC 2671, August 1999.
--
-- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-- Wellington, "Secret Key Transaction Authentication for DNS
-- (TSIG)", RFC 2845, May 2000.
--
--7.2. Informative References
--
-- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
-- Languages", RFC 2277, BCP 18, January 1998.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 13]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--Author's Address
--
-- Rob Austein
-- ISC
-- 950 Charter Street
-- Redwood City, CA 94063
-- USA
--
-- Email: sra@isc.org
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Austein Expires July 15, 2006 [Page 14]
--\f
--Internet-Draft DNS NSID January 2006
--
--
--Intellectual Property Statement
--
-- The IETF takes no position regarding the validity or scope of any
-- Intellectual Property Rights or other rights that might be claimed to
-- pertain to the implementation or use of the technology described in
-- this document or the extent to which any license under such rights
-- might or might not be available; nor does it represent that it has
-- made any independent effort to identify any such rights. Information
-- on the procedures with respect to rights in RFC documents can be
-- found in BCP 78 and BCP 79.
--
-- Copies of IPR disclosures made to the IETF Secretariat and any
-- assurances of licenses to be made available, or the result of an
-- attempt made to obtain a general license or permission for the use of
-- such proprietary rights by implementers or users of this
-- specification can be obtained from the IETF on-line IPR repository at
-- http://www.ietf.org/ipr.
--
-- The IETF invites any interested party to bring to its attention any
-- copyrights, patents or patent applications, or other proprietary
-- rights that may cover technology that may be required to implement
-- this standard. Please address the information to the IETF at
-- ietf-ipr@ietf.org.
--
--
--Disclaimer of Validity
--
-- This document and the information contained herein are provided on an
-- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--
--
--Copyright Statement
--
-- Copyright (C) The Internet Society (2006). This document is subject
-- to the rights, licenses and restrictions contained in BCP 78, and
-- except as set forth therein, the authors retain all their rights.
--
--
--Acknowledgment
--
-- Funding for the RFC Editor function is currently provided by the
-- Internet Society.
--
--
--
--
--Austein Expires July 15, 2006 [Page 15]
--\f
+++ /dev/null
--Internet-Draft dnsext-wcard January 9, 2006
--
--DNSEXT Working Group E. Lewis
--INTERNET DRAFT NeuStar
--Expiration Date: July 9, 2006 January 9, 2006
--Updates RFC 1034, RFC 2672
--
-- The Role of Wildcards
-- in the Domain Name System
-- draft-ietf-dnsext-wcard-clarify-10.txt
--
--Status of this Memo
--
-- By submitting this Internet-Draft, each author represents that
-- any applicable patent or other IPR claims of which he or she is
-- aware have been or will be disclosed, and any of which he or she
-- becomes aware will be disclosed, in accordance with Section 6 of
-- BCP 79.
--
-- Internet-Drafts are working documents of the Internet Engineering
-- Task Force (IETF), its areas, and its working groups. Note that
-- other groups may also distribute working documents as Internet-
-- Drafts.
--
-- Internet-Drafts are draft documents valid for a maximum of six
-- months and may be updated, replaced, or obsoleted by other
-- documents at any time. It is inappropriate to use Internet-Drafts
-- as reference material or to cite them other than as "work in
-- progress."
--
-- The list of current Internet-Drafts can be accessed at
-- http://www.ietf.org/ietf/1id-abstracts.txt
--
-- The list of Internet-Draft Shadow Directories can be accessed at
-- http://www.ietf.org/shadow.html
--
-- This Internet-Draft will expire on July 9, 2006.
--
--Copyright Notice
--
-- Copyright (C) The Internet Society (2006).
--
--Abstract
--
-- This is an update to the wildcard definition of RFC 1034. The
-- interaction with wildcards and CNAME is changed, an error
-- condition removed, and the words defining some concepts central
-- to wildcards are changed. The overall goal is not to change
-- wildcards, but to refine the definition of RFC 1034.
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 1]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--Table of Contents
--
--1. Introduction . . . . . . . . . . . . . . . . 3
--1 1 Motivation 3
--1 2 The Original Definition 3
--1 3 Roadmap to This Document 4
--1 3 1 New Terms 4
--1.3.2 Changed Text 5
--1.3.3 Considerations with Special Types 5
--1.4 Standards Terminology 5
--2. Wildcard Syntax . . . . . . . . . . . . . . . 6
--2.1 Identifying a Wildcard 6
--2.1.1 Wild Card Domain Name and Asterisk Label 6
--2.1.2 Asterisks and Other Characters 6
--2.1.3 Non-terminal Wild Card Domain Names 6
--2.2 Existence Rules 7
--2.2.1 An Example 7
--2.2.2 Empty Non-terminals 9
--2.2.3 Yet Another Definition of Existence 10
--2.3 When is a Wild Card Domain Name Not Special 10
--3. Impact of a Wild Card Domain Name On a Response . . . . . 10
--3.1 Step 2 10
--3.2 Step 3 11
--3.3 Part 'c' 11
--3.3.1 Closest Encloser and the Source of Synthesis 12
--3.3.2 Closest Encloser and Source of Synthesis Examples 12
--3.3.3 Type Matching 13
--4. Considerations with Special Types . . . . . . . . . 13
--4.1 SOA RRSet at a Wild Card Domain Name 13
--4.2 NS RRSet at a Wild Card Domain Name 14
--4.2.1 Discarded Notions 14
--4.3 CNAME RRSet at a Wild Card Domain Name 15
--4.4 DNAME RRSet at a Wild Card Domain Name 15
--4.5 SRV RRSet at a Wild Card Domain Name 16
--4.6 DS RRSet at a Wild Card Domain Name 16
--4.7 NSEC RRSet at a Wild Card Domain Name 17
--4.8 RRSIG at a Wild Card Domain Name 17
--4.9 Empty Non-terminal Wild Card Domain Name 17
--5. Security Considerations . . . . . . . . . . . . . 17
--6. IANA Considerations . . . . . . . . . . . . . 17
--7. References . . . . . . . . . . . . . 17
--8. Editor . . . . . . . . . . . . . 18
--9. Others Contributing to the Document . . . . . . . . 18
--10. Trailing Boilerplate . . . . . . . . . . . . . 19
--
--
--
--
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 2]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--1. Introduction
--
-- In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
-- synthesis of answers from special resource records called
-- wildcards. The definition in RFC 1034 is incomplete and has
-- proven to be confusing. This document describes the wildcard
-- synthesis by adding to the discussion and making limited
-- modifications. Modifications are made to close inconsistencies
-- that have led to interoperability issues. This description
-- does not expand the service intended by the original definition.
--
-- Staying within the spirit and style of the original documents,
-- this document avoids specifying rules for DNS implementations
-- regarding wildcards. The intention is to only describe what is
-- needed for interoperability, not restrict implementation choices.
-- In addition, consideration is given to minimize any backwards
-- compatibility issues with implementations that comply with RFC
-- 1034's definition.
--
-- This document is focused on the concept of wildcards as defined
-- in RFC 1034. Nothing is implied regarding alternative means of
-- synthesizing resource record sets, nor are alternatives discussed.
--
--1.1 Motivation
--
-- Many DNS implementations diverge, in different ways, from the
-- original definition of wildcards. Although there is clearly a
-- need to clarify the original documents in light of this alone,
-- the impetus for this document lay in the engineering of the DNS
-- security extensions [RFC4033]. With an unclear definition of
-- wildcards the design of authenticated denial became entangled.
--
-- This document is intended to limit its changes, documenting only
-- those based on implementation experience, and to remain as close
-- to the original document as possible. To reinforce that this
-- document is meant to clarify and adjust and not redefine wildcards,
-- relevant sections of RFC 1034 are repeated verbatim to facilitate
-- comparison of the old and new text.
--
--1.2 The Original Definition
--
-- The definition of the wildcard concept is comprised by the
-- documentation of the algorithm by which a name server prepares
-- a response (in RFC 1034's section 4.3.2) and the way in which
-- a resource record (set) is identified as being a source of
-- synthetic data (section 4.3.3).
--
-- This is the definition of the term "wildcard" as it appears in
-- RFC 1034, section 4.3.3.
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 3]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--# In the previous algorithm, special treatment was given to RRs with
--# owner names starting with the label "*". Such RRs are called
--# wildcards. Wildcard RRs can be thought of as instructions for
--# synthesizing RRs. When the appropriate conditions are met, the name
--# server creates RRs with an owner name equal to the query name and
--# contents taken from the wildcard RRs.
--
-- This passage follows the algorithm in which the term wildcard
-- is first used. In this definition, wildcard refers to resource
-- records. In other usage, wildcard has referred to domain names,
-- and it has been used to describe the operational practice of
-- relying on wildcards to generate answers. It is clear from this
-- that there is a need to define clear and unambiguous terminology
-- in the process of discussing wildcards.
--
-- The mention of the use of wildcards in the preparation of a
-- response is contained in step 3c of RFC 1034's section 4.3.2
-- entitled "Algorithm." Note that "wildcard" does not appear in
-- the algorithm, instead references are made to the "*" label.
-- The portion of the algorithm relating to wildcards is
-- deconstructed in detail in section 3 of this document, this is
-- the beginning of the relevant portion of the "Algorithm."
--
--# c. If at some label, a match is impossible (i.e., the
--# corresponding label does not exist), look to see if [...]
--# the "*" label exists.
--
-- The scope of this document is the RFC 1034 definition of
-- wildcards and the implications of updates to those documents,
-- such as DNSSEC. Alternate schemes for synthesizing answers are
-- not considered. (Note that there is no reference listed. No
-- document is known to describe any alternate schemes, although
-- there has been some mention of them in mailing lists.)
--
--1.3 Roadmap to This Document
--
-- This document accomplishes these three items.
-- o Defines new terms
-- o Makes minor changes to avoid conflicting concepts
-- o Describes the actions of certain resource records as wildcards
--
--1.3.1 New Terms
--
-- To help in discussing what resource records are wildcards, two
-- terms will be defined - "asterisk label" and "wild card domain
-- name". These are defined in section 2.1.1.
--
-- To assist in clarifying the role of wildcards in the name server
-- algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
-- encloser" are defined. These definitions are in section 3.3.2.
-- "Label match" is defined in section 3.2.
--
--DNSEXT Working Group Expires July 9, 2006 [Page 4]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- The new terms are used to make discussions of wildcards clearer.
-- Terminology doesn't directly have an impact on implementations.
--
--1.3.2 Changed Text
--
-- The definition of "existence" is changed superficially. This
-- change will not be apparent to implementations; it is needed to
-- make descriptions more precise. The change appears in section
-- 2.2.3.
--
-- RFC 1034, section 4.3.3., seems to prohibit having two asterisk
-- labels in a wildcard owner name. With this document the
-- restriction is removed entirely. This change and its implications
-- are in section 2.1.3.
--
-- The actions when a source of synthesis owns a CNAME RR are
-- changed to mirror the actions if an exact match name owns a
-- CNAME RR. This is an addition to the words in RFC 1034,
-- section 4.3.2, step 3, part c. The discussion of this is in
-- section 3.3.3.
--
-- Only the latter change represents an impact to implementations.
-- The definition of existence is not a protocol impact. The change
-- to the restriction on names is unlikely to have an impact, as
-- RFC 1034 contained no specification on when and how to enforce the
-- restriction.
--
--1.3.3 Considerations with Special Types
--
-- This document describes semantics of wildcard RRSets for
-- "interesting" types as well as empty non-terminal wildcards.
-- Understanding these situations in the context of wildcards has
-- been clouded because these types incur special processing if
-- they are the result of an exact match. This discussion is in
-- section 4.
--
-- These discussions do not have an implementation impact, they cover
-- existing knowledge of the types, but to a greater level of detail.
--
--1.4 Standards Terminology
--
-- This document does not use terms as defined in "Key words for use
-- in RFCs to Indicate Requirement Levels." [RFC2119]
--
-- Quotations of RFC 1034 are denoted by a '#' in the leftmost
-- column. References to section "4.3.2" are assumed to refer
-- to RFC 1034's section 4.3.2, simply titled "Algorithm."
--
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 5]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--2. Wildcard Syntax
--
-- The syntax of a wildcard is the same as any other DNS resource
-- record, across all classes and types. The only significant
-- feature is the owner name.
--
-- Because wildcards are encoded as resource records with special
-- names, they are included in zone transfers and incremental zone
-- transfers[RFC1995] just as non-wildcard resource records are.
-- This feature has been under appreciated until discussions on
-- alternative approaches to wildcards appeared on mailing lists.
--
--2.1 Identifying a Wildcard
--
-- To provide a more accurate description of wildcards, the
-- definition has to start with a discussion of the domain names
-- that appear as owners. Two new terms are needed, "Asterisk
-- Label" and "Wild Card Domain Name."
--
--2.1.1 Wild Card Domain Name and Asterisk Label
--
-- A "wild card domain name" is defined by having its initial
-- (i.e., left-most or least significant) label be, in binary format:
--
-- 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
--
-- The first octet is the normal label type and length for a 1 octet
-- long label, the second octet is the ASCII representation [RFC20]
-- for the '*' character.
--
-- A descriptive name of a label equaling that value is an "asterisk
-- label."
--
-- RFC 1034's definition of wildcard would be "a resource record
-- owned by a wild card domain name."
--
--2.1.2 Asterisks and Other Characters
--
-- No label values other than that in section 2.1.1 are asterisk
-- labels, hence names beginning with other labels are never wild
-- card domain names. Labels such as 'the*' and '**' are not
-- asterisk labels so these labels do not start wild card domain
-- names.
--
--2.1.3 Non-terminal Wild Card Domain Names
--
-- In section 4.3.3, the following is stated:
--
--# .......................... The owner name of the wildcard RRs is of
--# the form "*.<anydomain>", where <anydomain> is any domain name.
--# <anydomain> should not contain other * labels......................
--
--DNSEXT Working Group Expires July 9, 2006 [Page 6]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- The restriction is now removed. The original documentation of it
-- is incomplete and the restriction does not serve any purpose
-- given years of operational experience.
--
-- There are three possible reasons for putting the restriction in
-- place, but none of the three has held up over time. One is
-- that the restriction meant that there would never be subdomains
-- of wild card domain names, but the restriciton as stated still
-- permits "example.*.example." for instance. Another is that
-- wild card domain names are not intended to be empty non-terminals,
-- but this situation does not disrupt the algorithm in 4.3.2.
-- Finally, "nested" wild card domain names are not ambiguous once
-- the concept of the closest encloser had been documented.
--
-- A wild card domain name can have subdomains. There is no need
-- to inspect the subdomains to see if there is another asterisk
-- label in any subdomain.
--
-- A wild card domain name can be an empty non-terminal. (See the
-- upcoming sections on empty non-terminals.) In this case, any
-- lookup encountering it will terminate as would any empty
-- non-terminal match.
--
--2.2 Existence Rules
--
-- The notion that a domain name 'exists' is mentioned in the
-- definition of wildcards. In section 4.3.3 of RFC 1034:
--
--# Wildcard RRs do not apply:
--#
--...
--# - When the query name or a name between the wildcard domain and
--# the query name is know[n] to exist. For example, if a wildcard
--
-- "Existence" is therefore an important concept in the understanding
-- of wildcards. Unfortunately, the definition of what exists, in RFC
-- 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is
-- taken at the definition of existence.
--
--2.2.1 An Example
--
-- To illustrate what is meant by existence consider this complete
-- zone:
--
--
--
--
--
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 7]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- $ORIGIN example.
-- example. 3600 IN SOA <SOA RDATA>
-- example. 3600 NS ns.example.com.
-- example. 3600 NS ns.example.net.
-- *.example. 3600 TXT "this is a wild card"
-- *.example. 3600 MX 10 host1.example.
-- sub.*.example. 3600 TXT "this is not a wild card"
-- host1.example. 3600 A 192.0.4.1
-- _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
-- _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
-- subdel.example. 3600 NS ns.example.com.
-- subdel.example. 3600 NS ns.example.net.
--
-- A look at the domain names in a tree structure is helpful:
--
-- |
-- -------------example------------
-- / / \ \
-- / / \ \
-- / / \ \
-- * host1 host2 subdel
-- | | |
-- | | |
-- sub _tcp _tcp
-- | |
-- | |
-- _ssh _ssh
--
-- The following responses would be synthesized from one of the
-- wildcards in the zone:
--
-- QNAME=host3.example. QTYPE=MX, QCLASS=IN
-- the answer will be a "host3.example. IN MX ..."
--
-- QNAME=host3.example. QTYPE=A, QCLASS=IN
-- the answer will reflect "no error, but no data"
-- because there is no A RR set at '*.example.'
--
-- QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
-- the answer will be "foo.bar.example. IN TXT ..."
-- because bar.example. does not exist, but the wildcard
-- does.
--
-- The following responses would not be synthesized from any of the
-- wildcards in the zone:
--
-- QNAME=host1.example., QTYPE=MX, QCLASS=IN
-- because host1.example. exists
--
-- QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
-- because sub.*.example. exists
--
--DNSEXT Working Group Expires July 9, 2006 [Page 8]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
-- because _tcp.host1.example. exists (without data)
--
-- QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
-- because subdel.example. exists (and is a zone cut)
--
-- QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
-- because *.example. exists
--
-- The final example highlights one common misconception about
-- wildcards. A wildcard "blocks itself" in the sense that a
-- wildcard does not match its own subdomains. I.e. "*.example."
-- does not match all names in the "example." zone, it fails to
-- match the names below "*.example." To cover names under
-- "*.example.", another wild card domain name is needed -
-- "*.*.example." - which covers all but it's own subdomains.
--
--2.2.2 Empty Non-terminals
--
-- Empty non-terminals [RFC2136, Section 7.16] are domain names
-- that own no resource records but have subdomains that do. In
-- section 2.2.1, "_tcp.host1.example." is an example of a empty
-- non-terminal name. Empty non-terminals are introduced by this
-- text in section 3.1 of RFC 1034:
--
--# The domain name space is a tree structure. Each node and leaf on
--# the tree corresponds to a resource set (which may be empty). The
--# domain system makes no distinctions between the uses of the
--# interior nodes and leaves, and this memo uses the term "node" to
--# refer to both.
--
-- The parenthesized "which may be empty" specifies that empty non-
-- terminals are explicitly recognized, and that empty non-terminals
-- "exist."
--
-- Pedantically reading the above paragraph can lead to an
-- interpretation that all possible domains exist - up to the
-- suggested limit of 255 octets for a domain name [RFC1035].
-- For example, www.example. may have an A RR, and as far as is
-- practically concerned, is a leaf of the domain tree. But the
-- definition can be taken to mean that sub.www.example. also
-- exists, albeit with no data. By extension, all possible domains
-- exist, from the root on down.
--
-- As RFC 1034 also defines "an authoritative name error indicating
-- that the name does not exist" in section 4.3.1, so this apparently
-- is not the intent of the original definition, justifying the
-- need for an updated definition in the next section.
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 9]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--2.2.3 Yet Another Definition of Existence
--
-- RFC1034's wording is fixed by the following paragraph:
--
-- The domain name space is a tree structure. Nodes in the tree
-- either own at least one RRSet and/or have descendants that
-- collectively own at least one RRSet. A node may exist with no
-- RRSets only if it has descendents that do, this node is an empty
-- non-terminal.
--
-- A node with no descendants is a leaf node. Empty leaf nodes do
-- not exist.
--
-- Note that at a zone boundary, the domain name owns data,
-- including the NS RR set. In the delegating zone, the NS RR
-- set is not authoritative, but that is of no consequence here.
-- The domain name owns data, therefore, it exists.
--
--2.3 When is a Wild Card Domain Name Not Special
--
-- When a wild card domain name appears in a message's query section,
-- no special processing occurs. An asterisk label in a query name
-- only matches a single, corresponding asterisk label in the
-- existing zone tree when the 4.3.2 algorithm is being followed.
--
-- When a wild card domain name appears in the resource data of a
-- record, no special processing occurs. An asterisk label in that
-- context literally means just an asterisk.
--
--3. Impact of a Wild Card Domain Name On a Response
--
-- RFC 1034's description of how wildcards impact response
-- generation is in its section 4.3.2. That passage contains the
-- algorithm followed by a server in constructing a response.
-- Within that algorithm, step 3, part 'c' defines the behavior of
-- the wildcard.
--
-- The algorithm in section 4.3.2. is not intended to be pseudo-code,
-- i.e., its steps are not intended to be followed in strict order.
-- The "algorithm" is a suggested means of implementing the
-- requirements. As such, in step 3, parts a, b, and c, do not have
-- to be implemented in that order, provided that the result of the
-- implemented code is compliant with the protocol's specification.
--
--3.1 Step 2
--
-- Step 2 of section 4.3.2 reads:
--
--# 2. Search the available zones for the zone which is the nearest
--# ancestor to QNAME. If such a zone is found, go to step 3,
--# otherwise step 4.
--
--DNSEXT Working Group Expires July 9, 2006 [Page 10]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- In this step, the most appropriate zone for the response is
-- chosen. The significance of this step is that it means all of
-- step 3 is being performed within one zone. This has significance
-- when considering whether or not an SOA RR can be ever be used for
-- synthesis.
--
--3.2 Step 3
--
-- Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
-- But the beginning of the step is important and needs explanation.
--
--# 3. Start matching down, label by label, in the zone. The
--# matching process can terminate several ways:
--
-- The word 'matching' refers to label matching. The concept
-- is based in the view of the zone as the tree of existing names.
-- The query name is considered to be an ordered sequence of
-- labels - as if the name were a path from the root to the owner
-- of the desired data. (Which it is - 3rd paragraph of RFC 1034,
-- section 3.1.)
--
-- The process of label matching a query name ends in exactly one of
-- three choices, the parts 'a', 'b', and 'c'. Either the name is
-- found, the name is below a cut point, or the name is not found.
--
-- Once one of the parts is chosen, the other parts are not
-- considered. (E.g., do not execute part 'c' and then change
-- the execution path to finish in part 'b'.) The process of label
-- matching is also done independent of the query type (QTYPE).
--
-- Parts 'a' and 'b' are not an issue for this clarification as they
-- do not relate to record synthesis. Part 'a' is an exact match
-- that results in an answer, part 'b' is a referral.
--
--3.3 Part 'c'
--
-- The context of part 'c' is that the process of label matching the
-- labels of the query name has resulted in a situation in which
-- there is no corresponding label in the tree. It is as if the
-- lookup has "fallen off the tree."
--
--# c. If at some label, a match is impossible (i.e., the
--# corresponding label does not exist), look to see if [...]
--# the "*" label exists.
--
-- To help describe the process of looking 'to see if [...] the "*"
-- label exists' a term has been coined to describe the last domain
-- (node) matched. The term is "closest encloser."
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 11]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--3.3.1 Closest Encloser and the Source of Synthesis
--
-- The closest encloser is the node in the zone's tree of existing
-- domain names that has the most labels matching the query name
-- (consecutively, counting from the root label downward). Each match
-- is a "label match" and the order of the labels is the same.
--
-- The closest encloser is, by definition, an existing name in the
-- zone. The closest encloser might be an empty non-terminal or even
-- be a wild card domain name itself. In no circumstances is the
-- closest encloser to be used to synthesize records for the current
-- query.
--
-- The source of synthesis is defined in the context of a query
-- process as that wild card domain name immediately descending
-- from the closest encloser, provided that this wild card domain
-- name exists. "Immediately descending" means that the source
-- of synthesis has a name of the form:
-- <asterisk label>.<closest encloser>.
-- A source of synthesis does not guarantee having a RRSet to use
-- for synthesis. The source of synthesis could be an empty
-- non-terminal.
--
-- If the source of synthesis does not exist (not on the domain
-- tree), there will be no wildcard synthesis. There is no search
-- for an alternate.
--
-- The important concept is that for any given lookup process, there
-- is at most one place at which wildcard synthetic records can be
-- obtained. If the source of synthesis does not exist, the lookup
-- terminates, the lookup does not look for other wildcard records.
--
--3.3.2 Closest Encloser and Source of Synthesis Examples
--
-- To illustrate, using the example zone in section 2.2.1 of this
-- document, the following chart shows QNAMEs and the closest
-- enclosers.
--
-- QNAME Closest Encloser Source of Synthesis
-- host3.example. example. *.example.
-- _telnet._tcp.host1.example. _tcp.host1.example. no source
-- _telnet._tcp.host2.example. host2.example. no source
-- _telnet._tcp.host3.example. example. *.example.
-- _chat._udp.host3.example. example. *.example.
-- foobar.*.example. *.example. no source
--
--
--
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 12]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--3.3.3 Type Matching
--
-- RFC 1034 concludes part 'c' with this:
--
--# If the "*" label does not exist, check whether the name
--# we are looking for is the original QNAME in the query
--# or a name we have followed due to a CNAME. If the name
--# is original, set an authoritative name error in the
--# response and exit. Otherwise just exit.
--#
--# If the "*" label does exist, match RRs at that node
--# against QTYPE. If any match, copy them into the answer
--# section, but set the owner of the RR to be QNAME, and
--# not the node with the "*" label. Go to step 6.
--
-- The final paragraph covers the role of the QTYPE in the lookup
-- process.
--
-- Based on implementation feedback and similarities between step
-- 'a' and step 'c' a change to this passage has been made.
--
-- The change is to add the following text to step 'c' prior to the
-- instructions to "go to step 6":
--
-- If the data at the source of synthesis is a CNAME, and
-- QTYPE doesn't match CNAME, copy the CNAME RR into the
-- answer section of the response changing the owner name
-- to the QNAME, change QNAME to the canonical name in the
-- CNAME RR, and go back to step 1.
--
-- This is essentially the same text in step a covering the
-- processing of CNAME RRSets.
--
--4. Considerations with Special Types
--
-- Sections 2 and 3 of this document discuss wildcard synthesis
-- with respect to names in the domain tree and ignore the impact
-- of types. In this section, the implication of wildcards of
-- specific types are discussed. The types covered are those
-- that have proven to be the most difficult to understand. The
-- types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
-- "none," i.e., empty non-terminal wild card domain names.
--
--4.1 SOA RRSet at a Wild Card Domain Name
--
-- A wild card domain name owning an SOA RRSet means that the
-- domain is at the root of the zone (apex). The domain can not
-- be a source of synthesis because that is, by definition, a
-- descendent node (of the closest encloser) and a zone apex is
-- at the top of the zone.
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 13]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- Although a wild card domain name owning an SOA RRSet can never
-- be a source of synthesis, there is no reason to forbid the
-- ownership of an SOA RRSet.
--
-- E.g., given this zone:
-- $ORIGIN *.example.
-- @ 3600 IN SOA <SOA RDATA>
-- 3600 NS ns1.example.com.
-- 3600 NS ns1.example.net.
-- www 3600 TXT "the www txt record"
--
-- A query for www.*.example.'s TXT record would still find the
-- "the www txt record" answer. The asterisk label only becomes
-- significant when section 4.3.2, step 3 part 'c' is in effect.
--
-- Of course, there would need to be a delegation in the parent
-- zone, "example." for this to work too. This is covered in the
-- next section.
--
--4.2 NS RRSet at a Wild Card Domain Name
--
-- With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
-- in place, the semantics of a wild card domain name owning an
-- NS RRSet has come to be poorly defined. The dilemma relates to
-- a conflict between the rules for synthesis in part 'c' and the
-- fact that the resulting synthesis generates a record for which
-- the zone is not authoritative. In a DNSSEC signed zone, the
-- mechanics of signature management (generation and inclusion
-- in a message) have become unclear.
--
-- Salient points of the working group discussion on this topic is
-- summarized in section 4.2.1.
--
-- As a result of these discussion, there is no definition given for
-- wild card domain names owning an NS RRSet. The semantics are
-- left undefined until there is a clear need to have a set defined,
-- and until there is a clear direction to proceed. Operationally,
-- inclusion of wild card NS RRSets in a zone is discouraged, but
-- not barred.
--
--4.2.1 Discarded Notions
--
-- Prior to DNSSEC, a wild card domain name owning a NS RRSet
-- appeared to be workable, and there are some instances in which
-- it is found in deployments using implementations that support
-- this. Continuing to allow this in the specification is not
-- tenable with DNSSEC. The reason is that the synthesis of the
-- NS RRSet is being done in a zone that has delegated away the
-- responsibility for the name. This "unauthorized" synthesis is
-- not a problem for the base DNS protocol, but DNSSEC, in affirming
-- the authorization model for DNS exposes the problem.
--
--DNSEXT Working Group Expires July 9, 2006 [Page 14]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- Outright banning of wildcards of type NS is also untenable as
-- the DNS protocol does not define how to handle "illegal" data.
-- Implementations may choose not to load a zone, but there is no
-- protocol definition. The lack of the definition is complicated
-- by having to cover dynamic update [RFC 2136], zone transfers,
-- as well as loading at the master server. The case of a client
-- (resolver, caching server) getting a wildcard of type NS in
-- a reply would also have to be considered.
--
-- Given the daunting challenge of a complete definition of how to
-- ban such records, dealing with existing implementations that
-- permit the records today is a further complication. There are
-- uses of wild card domain name owning NS RRSets.
--
-- One compromise proposed would have redefined wildcards of type
-- NS to not be used in synthesis, this compromise fell apart
-- because it would have required significant edits to the DNSSEC
-- signing and validation work. (Again, DNSSEC catches
-- unauthorized data.)
--
-- With no clear consensus forming on the solution to this dilemma,
-- and the realization that wildcards of type NS are a rarity in
-- operations, the best course of action is to leave this open-ended
-- until "it matters."
--
--4.3 CNAME RRSet at a Wild Card Domain Name
--
-- The issue of a CNAME RRSet owned by a wild card domain name has
-- prompted a suggested change to the last paragraph of step 3c of
-- the algorithm in 4.3.2. The changed text appears in section
-- 3.3.3 of this document.
--
--4.4 DNAME RRSet at a Wild Card Domain Name
--
-- Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
-- represents a threat to the coherency of the DNS and is to be
-- avoided or outright rejected. Such a DNAME RRSet represents
-- non-deterministic synthesis of rules fed to different caches.
-- As caches are fed the different rules (in an unpredictable
-- manner) the caches will cease to be coherent. ("As caches
-- are fed" refers to the storage in a cache of records obtained
-- in responses by recursive or iterative servers.)
--
-- For example, assume one cache, responding to a recursive
-- request, obtains the record:
-- "a.b.example. DNAME foo.bar.example.net."
-- and another cache obtains:
-- "b.example. DNAME foo.bar.example.net."
-- both generated from the record:
-- "*.example. DNAME foo.bar.example.net."
-- by an authoritative server.
--
--DNSEXT Working Group Expires July 9, 2006 [Page 15]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- The DNAME specification is not clear on whether DNAME records
-- in a cache are used to rewrite queries. In some interpretations,
-- the rewrite occurs, in some, it is not. Allowing for the
-- occurrence of rewriting, queries for "sub.a.b.example. A" may
-- be rewritten as "sub.foo.bar.tld. A" by the former caching
-- server and may be rewritten as "sub.a.foo.bar.tld. A" by the
-- latter. Coherency is lost, an operational nightmare ensues.
--
-- Another justification for banning or avoiding wildcard DNAME
-- records is the observation that such a record could synthesize
-- a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
-- There is a restriction in the DNAME definition that no domain
-- exist below a DNAME-owning domain, hence, the wildcard DNAME
-- is not to be permitted.
--
--4.5 SRV RRSet at a Wild Card Domain Name
--
-- The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
-- definition of the record, there is some confusion over the term
-- "Name." The definition reads as follows:
--
--# The format of the SRV RR
--...
--# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
--...
--# Name
--# The domain this RR refers to. The SRV RR is unique in that the
--# name one searches for is not this name; the example near the end
--# shows this clearly.
--
-- Do not confuse the definition "Name" with the owner name. I.e.,
-- once removing the _Service and _Proto labels from the owner name
-- of the SRV RRSet, what remains could be a wild card domain name
-- but this is immaterial to the SRV RRSet.
--
-- E.g., If an SRV record is:
-- _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
--
-- *.example is a wild card domain name and although it is the Name
-- of the SRV RR, it is not the owner (domain name). The owner
-- domain name is "_foo._udp.*.example." which is not a wild card
-- domain name.
--
-- The confusion is likely based on the mixture of the specification
-- of the SRV RR and the description of a "use case."
--
--4.6 DS RRSet at a Wild Card Domain Name
--
-- A DS RRSet owned by a wild card domain name is meaningless and
-- harmless. This statement is made in the context that an NS RRSet
-- at a wild card domain name is undefined. At a non-delegation
--
--DNSEXT Working Group Expires July 9, 2006 [Page 16]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- point, a DS RRSet has no value (no corresponding DNSKEY RRSet
-- will be used in DNSSEC validation). If there is a synthesized
-- DS RRSet, it alone will not be very useful as it exists in the
-- context of a delegation point.
--
--4.7 NSEC RRSet at a Wild Card Domain Name
--
-- Wild card domain names in DNSSEC signed zones will have an NSEC
-- RRSet. Synthesis of these records will only occur when the
-- query exactly matches the record. Synthesized NSEC RR's will not
-- be harmful as they will never be used in negative caching or to
-- generate a negative response. [RFC2308]
--
--4.8 RRSIG at a Wild Card Domain Name
--
-- RRSIG records will be present at a wild card domain name in a
-- signed zone, and will be synthesized along with data sought in a
-- query. The fact that the owner name is synthesized is not a
-- problem as the label count in the RRSIG will instruct the
-- verifying code to ignore it.
--
--4.9 Empty Non-terminal Wild Card Domain Name
--
-- If a source of synthesis is an empty non-terminal, then the
-- response will be one of no error in the return code and no RRSet
-- in the answer section.
--
--5. Security Considerations
--
-- This document is refining the specifications to make it more
-- likely that security can be added to DNS. No functional
-- additions are being made, just refining what is considered
-- proper to allow the DNS, security of the DNS, and extending
-- the DNS to be more predictable.
--
--6. IANA Considerations
--
-- None.
--
--7. References
--
-- Normative References
--
-- [RFC20] ASCII Format for Network Interchange, V.G. Cerf,
-- Oct-16-1969
--
-- [RFC1034] Domain Names - Concepts and Facilities,
-- P.V. Mockapetris, Nov-01-1987
--
-- [RFC1035] Domain Names - Implementation and Specification, P.V
-- Mockapetris, Nov-01-1987
--
--DNSEXT Working Group Expires July 9, 2006 [Page 17]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
-- [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
--
-- [RFC2119] Key Words for Use in RFCs to Indicate Requirement
-- Levels, S Bradner, March 1997
--
-- [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
-- M. Andrews, March 1998
--
-- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
-- August 1999.
--
-- [RFC2782] A DNS RR for specifying the location of services (DNS
-- SRV), A. Gulbrandsen, et.al., February 2000
--
-- [RFC4033] DNS Security Introduction and Requirements, R. Arends,
-- et.al., March 2005
--
-- [RFC4034] Resource Records for the DNS Security Extensions,
-- R. Arends, et.al., March 2005
--
-- [RFC4035] Protocol Modifications for the DNS Security Extensions,
-- R. Arends, et.al., March 2005
--
-- Informative References
--
-- [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
-- P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
-- April 1997
--
--8. Editor
--
-- Name: Edward Lewis
-- Affiliation: NeuStar
-- Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
-- Phone: +1-571-434-5468
-- Email: ed.lewis@neustar.biz
--
-- Comments on this document can be sent to the editor or the mailing
-- list for the DNSEXT WG, namedroppers@ops.ietf.org.
--
--9. Others Contributing to the Document
--
-- This document represents the work of a large working group. The
-- editor merely recorded the collective wisdom of the working group.
--
--
--
--
--
--
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 17]
--\f
--Internet-Draft dnsext-wcard January 9, 2006
--
--10. Trailing Boilerplate
--
-- Copyright (C) The Internet Society (2006).
--
-- This document is subject to the rights, licenses and restrictions
-- contained in BCP 78, and except as set forth therein, the authors
-- retain all their rights.
--
-- This document and the information contained herein are provided
-- on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
-- HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
-- SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
-- WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
-- ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
-- INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--
--Intellectual Property
--
-- The IETF takes no position regarding the validity or scope of
-- any Intellectual Property Rights or other rights that might
-- be claimed to pertain to the implementation or use of the
-- technology described in this document or the extent to which
-- any license under such rights might or might not be available;
-- nor does it represent that it has made any independent effort
-- to identify any such rights. Information on the procedures
-- with respect to rights in RFC documents can be found in BCP 78
-- and BCP 79.
--
-- Copies of IPR disclosures made to the IETF Secretariat and any
-- assurances of licenses to be made available, or the result of an
-- attempt made to obtain a general license or permission for the
-- use of such proprietary rights by implementers or users of this
-- specification can be obtained from the IETF on-line IPR
-- repository at http://www.ietf.org/ipr. The IETF invites any
-- interested party to bring to its attention any copyrights,
-- patents or patent applications, or other proprietary rights
-- that may cover technology that may be required to implement
-- this standard. Please address the information to the IETF at
-- ietf-ipr@ietf.org.
--
--Acknowledgement
--
-- Funding for the RFC Editor function is currently provided by the
-- Internet Society.
--
--Expiration
--
-- This document expires on or about July 9, 2006.
--
--
--
--DNSEXT Working Group Expires July 9, 2006 [Page 19]
+++ /dev/null
--
--
--
--DNS Operations M. Larson
--Internet-Draft P. Barber
--Expires: August 14, 2006 VeriSign
-- February 10, 2006
--
--
-- Observed DNS Resolution Misbehavior
-- draft-ietf-dnsop-bad-dns-res-05
--
--Status of this Memo
--
-- By submitting this Internet-Draft, each author represents that any
-- applicable patent or other IPR claims of which he or she is aware
-- have been or will be disclosed, and any of which he or she becomes
-- aware will be disclosed, in accordance with Section 6 of BCP 79.
--
-- Internet-Drafts are working documents of the Internet Engineering
-- Task Force (IETF), its areas, and its working groups. Note that
-- other groups may also distribute working documents as Internet-
-- Drafts.
--
-- Internet-Drafts are draft documents valid for a maximum of six months
-- and may be updated, replaced, or obsoleted by other documents at any
-- time. It is inappropriate to use Internet-Drafts as reference
-- material or to cite them other than as "work in progress."
--
-- The list of current Internet-Drafts can be accessed at
-- http://www.ietf.org/ietf/1id-abstracts.txt.
--
-- The list of Internet-Draft Shadow Directories can be accessed at
-- http://www.ietf.org/shadow.html.
--
-- This Internet-Draft will expire on August 14, 2006.
--
--Copyright Notice
--
-- Copyright (C) The Internet Society (2006).
--
--Abstract
--
-- This memo describes DNS iterative resolver behavior that results in a
-- significant query volume sent to the root and top-level domain (TLD)
-- name servers. We offer implementation advice to iterative resolver
-- developers to alleviate these unnecessary queries. The
-- recommendations made in this document are a direct byproduct of
-- observation and analysis of abnormal query traffic patterns seen at
-- two of the thirteen root name servers and all thirteen com/net TLD
-- name servers.
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 1]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-- document are to be interpreted as described in RFC 2119 [1].
--
--
--Table of Contents
--
-- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-- 1.1. A note about terminology in this memo . . . . . . . . . . 3
-- 2. Observed iterative resolver misbehavior . . . . . . . . . . . 5
-- 2.1. Aggressive requerying for delegation information . . . . . 5
-- 2.1.1. Recommendation . . . . . . . . . . . . . . . . . . . . 6
-- 2.2. Repeated queries to lame servers . . . . . . . . . . . . . 7
-- 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7
-- 2.3. Inability to follow multiple levels of indirection . . . . 8
-- 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9
-- 2.4. Aggressive retransmission when fetching glue . . . . . . . 9
-- 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10
-- 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10
-- 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11
-- 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11
-- 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12
-- 2.7. Name server records with zero TTL . . . . . . . . . . . . 12
-- 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13
-- 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13
-- 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14
-- 2.9. Queries for domain names resembling IPv4 addresses . . . . 14
-- 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14
-- 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15
-- 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
-- 2.11. Suboptimal name server selection algorithm . . . . . . . . 15
-- 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
-- 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
-- 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
-- 5. Security considerations . . . . . . . . . . . . . . . . . . . 19
-- 6. Internationalization considerations . . . . . . . . . . . . . 20
-- 7. Informative References . . . . . . . . . . . . . . . . . . . . 20
-- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
-- Intellectual Property and Copyright Statements . . . . . . . . . . 22
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 2]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--1. Introduction
--
-- Observation of query traffic received by two root name servers and
-- the thirteen com/net TLD name servers has revealed that a large
-- proportion of the total traffic often consists of "requeries". A
-- requery is the same question (<QNAME, QTYPE, QCLASS>) asked
-- repeatedly at an unexpectedly high rate. We have observed requeries
-- from both a single IP address and multiple IP addresses (i.e., the
-- same query received simultaneously from multiple IP addresses).
--
-- By analyzing requery events we have found that the cause of the
-- duplicate traffic is almost always a deficient iterative resolver,
-- stub resolver or application implementation combined with an
-- operational anomaly. The implementation deficiencies we have
-- identified to date include well-intentioned recovery attempts gone
-- awry, insufficient caching of failures, early abort when multiple
-- levels of indirection must be followed, and aggressive retry by stub
-- resolvers or applications. Anomalies that we have seen trigger
-- requery events include lame delegations, unusual glue records, and
-- anything that makes all authoritative name servers for a zone
-- unreachable (DoS attacks, crashes, maintenance, routing failures,
-- congestion, etc.).
--
-- In the following sections, we provide a detailed explanation of the
-- observed behavior and recommend changes that will reduce the requery
-- rate. None of the changes recommended affects the core DNS protocol
-- specification; instead, this document consists of guidelines to
-- implementors of iterative resolvers.
--
--1.1. A note about terminology in this memo
--
-- To recast an old saying about standards, the nice thing about DNS
-- terms is that there are so many of them to choose from. Writing or
-- talking about DNS can be difficult and cause confusion resulting from
-- a lack of agreed-upon terms for its various components. Further
-- complicating matters are implementations that combine multiple roles
-- into one piece of software, which makes naming the result
-- problematic. An example is the entity that accepts recursive
-- queries, issues iterative queries as necessary to resolve the initial
-- recursive query, caches responses it receives, and which is also able
-- to answer questions about certain zones authoritatively. This entity
-- is an iterative resolver combined with an authoritative name server
-- and is often called a "recursive name server" or a "caching name
-- server".
--
-- This memo is concerned principally with the behavior of iterative
-- resolvers, which are typically found as part of a recursive name
-- server. This memo uses the more precise term "iterative resolver",
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 3]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- because the focus is usually on that component. In instances where
-- the name server role of this entity requires mentioning, this memo
-- uses the term "recursive name server". As an example of the
-- difference, the name server component of a recursive name server
-- receives DNS queries and the iterative resolver component sends
-- queries.
--
-- The advent of IPv6 requires mentioning AAAA records as well as A
-- records when discussing glue. To avoid continuous repetition and
-- qualification, this memo uses the general term "address record" to
-- encompass both A and AAAA records when a particular situation is
-- relevant to both types.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 4]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--2. Observed iterative resolver misbehavior
--
--2.1. Aggressive requerying for delegation information
--
-- There can be times when every name server in a zone's NS RRset is
-- unreachable (e.g., during a network outage), unavailable (e.g., the
-- name server process is not running on the server host) or
-- misconfigured (e.g., the name server is not authoritative for the
-- given zone, also known as "lame"). Consider an iterative resolver
-- that attempts to resolve a query for a domain name in such a zone and
-- discovers that none of the zone's name servers can provide an answer.
-- We have observed a recursive name server implementation whose
-- iterative resolver then verifies the zone's NS RRset in its cache by
-- querying for the zone's delegation information: it sends a query for
-- the zone's NS RRset to one of the parent zone's name servers. (Note
-- that queries with QTYPE=NS are not required by the standard
-- resolution algorithm described in section 4.3.2 of RFC 1034 [2].
-- These NS queries represent this implementation's addition to that
-- algorithm.)
--
-- For example, suppose that "example.com" has the following NS RRset:
--
-- example.com. IN NS ns1.example.com.
-- example.com. IN NS ns2.example.com.
--
-- Upon receipt of a query for "www.example.com" and assuming that
-- neither "ns1.example.com" nor "ns2.example.com" can provide an
-- answer, this iterative resolver implementation immediately queries a
-- "com" zone name server for the "example.com" NS RRset to verify it
-- has the proper delegation information. This implementation performs
-- this query to a zone's parent zone for each recursive query it
-- receives that fails because of a completely unresponsive set of name
-- servers for the target zone. Consider the effect when a popular zone
-- experiences a catastrophic failure of all its name servers: now every
-- recursive query for domain names in that zone sent to this recursive
-- name server implementation results in a query to the failed zone's
-- parent name servers. On one occasion when several dozen popular
-- zones became unreachable, the query load on the com/net name servers
-- increased by 50%.
--
-- We believe this verification query is not reasonable. Consider the
-- circumstances: When an iterative resolver is resolving a query for a
-- domain name in a zone it has not previously searched, it uses the
-- list of name servers in the referral from the target zone's parent.
-- If on its first attempt to search the target zone, none of the name
-- servers in the referral is reachable, a verification query to the
-- parent would be pointless: this query to the parent would come so
-- quickly on the heels of the referral that it would be almost certain
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 5]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- to contain the same list of name servers. The chance of discovering
-- any new information is slim.
--
-- The other possibility is that the iterative resolver successfully
-- contacts one of the target zone's name servers and then caches the NS
-- RRset from the authority section of a response, the proper behavior
-- according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
-- the target zone is more trustworthy than delegation information from
-- the parent zone. If, while processing a subsequent recursive query,
-- the iterative resolver discovers that none of the name servers
-- specified in the cached NS RRset is available or authoritative,
-- querying the parent would be wrong. An NS RRset from the parent zone
-- would now be less trustworthy than data already in the cache.
--
-- For this query of the parent zone to be useful, the target zone's
-- entire set of name servers would have to change AND the former set of
-- name servers would have to be deconfigured or decommissioned AND the
-- delegation information in the parent zone would have to be updated
-- with the new set of name servers, all within the TTL of the target
-- zone's NS RRset. We believe this scenario is uncommon:
-- administrative best practices dictate that changes to a zone's set of
-- name servers happen gradually when at all possible, with servers
-- removed from the NS RRset left authoritative for the zone as long as
-- possible. The scenarios that we can envision that would benefit from
-- the parent requery behavior do not outweigh its damaging effects.
--
-- This section should not be understood to claim that all queries to a
-- zone's parent are bad. In some cases, such queries are not only
-- reasonable but required. Consider the situation when required
-- information, such as the address of a name server (i.e., the address
-- record corresponding to the RDATA of an NS record), has timed out of
-- an iterative resolver's cache before the corresponding NS record. If
-- the name of the name server is below the apex of the zone, then the
-- name server's address record is only available as glue in the parent
-- zone. For example, consider this NS record:
--
-- example.com. IN NS ns.example.com.
--
-- If a cache has this NS record but not the address record for
-- "ns.example.com", it is unable to contact the "example.com" zone
-- directly and must query the "com" zone to obtain the address record.
-- Note, however, that such a query would not have QTYPE=NS according to
-- the standard resolution algorithm.
--
--2.1.1. Recommendation
--
-- An iterative resolver MUST NOT send a query for the NS RRset of a
-- non-responsive zone to any of the name servers for that zone's parent
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 6]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- zone. For the purposes of this injunction, a non-responsive zone is
-- defined as a zone for which every name server listed in the zone's NS
-- RRset:
--
-- 1. is not authoritative for the zone (i.e., lame), or,
--
-- 2. returns a server failure response (RCODE=2), or,
--
-- 3. is dead or unreachable according to section 7.2 of RFC 2308 [4].
--
--2.2. Repeated queries to lame servers
--
-- Section 2.1 describes a catastrophic failure: when every name server
-- for a zone is unable to provide an answer for one reason or another.
-- A more common occurrence is when a subset of a zone's name servers
-- are unavailable or misconfigured. Different failure modes have
-- different expected durations. Some symptoms indicate problems that
-- are potentially transient; for example, various types of ICMP
-- unreachable messages because a name server process is not running or
-- a host or network is unreachable, or a complete lack of a response to
-- a query. Such responses could be the result of a host rebooting or
-- temporary outages; these events don't necessarily require any human
-- intervention and can be reasonably expected to be temporary.
--
-- Other symptoms clearly indicate a condition requiring human
-- intervention, such as lame server: if a name server is misconfigured
-- and not authoritative for a zone delegated to it, it is reasonable to
-- assume that this condition has potential to last longer than
-- unreachability or unresponsiveness. Consequently, repeated queries
-- to known lame servers are not useful. In this case of a condition
-- with potential to persist for a long time, a better practice would be
-- to maintain a list of known lame servers and avoid querying them
-- repeatedly in a short interval.
--
-- It should also be noted, however, that some authoritative name server
-- implementations appear to be lame only for queries of certain types
-- as described in RFC 4074 [5]. In this case, it makes sense to retry
-- the "lame" servers for other types of queries, particularly when all
-- known authoritative name servers appear to be "lame".
--
--2.2.1. Recommendation
--
-- Iterative resolvers SHOULD cache name servers that they discover are
-- not authoritative for zones delegated to them (i.e. lame servers).
-- If this caching is performed, lame servers MUST be cached against the
-- specific query tuple <zone name, class, server IP address>. Zone
-- name can be derived from the owner name of the NS record that was
-- referenced to query the name server that was discovered to be lame.
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 7]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- Implementations that perform lame server caching MUST refrain from
-- sending queries to known lame servers based on a time interval from
-- when the server is discovered to be lame. A minimum interval of
-- thirty minutes is RECOMMENDED.
--
-- An exception to this recommendation occurs if all name servers for a
-- zone are marked lame. In that case, the iterative resolver SHOULD
-- temporarily ignore the servers' lameness status and query one or more
-- servers. This behavior is a workaround for the type-specific
-- lameness issue described in the previous section.
--
-- Implementors should take care not to make lame server avoidance logic
-- overly broad: note that a name server could be lame for a parent zone
-- but not a child zone, e.g., lame for "example.com" but properly
-- authoritative for "sub.example.com". Therefore a name server should
-- not be automatically considered lame for subzones. In the case
-- above, even if a name server is known to be lame for "example.com",
-- it should be queried for QNAMEs at or below "sub.example.com" if an
-- NS record indicates it should be authoritative for that zone.
--
--2.3. Inability to follow multiple levels of indirection
--
-- Some iterative resolver implementations are unable to follow
-- sufficient levels of indirection. For example, consider the
-- following delegations:
--
-- foo.example. IN NS ns1.example.com.
-- foo.example. IN NS ns2.example.com.
--
-- example.com. IN NS ns1.test.example.net.
-- example.com. IN NS ns2.test.example.net.
--
-- test.example.net. IN NS ns1.test.example.net.
-- test.example.net. IN NS ns2.test.example.net.
--
-- An iterative resolver resolving the name "www.foo.example" must
-- follow two levels of indirection, first obtaining address records for
-- "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
-- address records for "ns1.example.com" or "ns2.example.com" in order
-- to query those name servers for the address records of
-- "www.foo.example". While this situation may appear contrived, we
-- have seen multiple similar occurrences and expect more as new generic
-- top-level domains (gTLDs) become active. We anticipate many zones in
-- new gTLDs will use name servers in existing gTLDs, increasing the
-- number of delegations using out-of-zone name servers.
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 8]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--2.3.1. Recommendation
--
-- Clearly constructing a delegation that relies on multiple levels of
-- indirection is not a good administrative practice. However, the
-- practice is widespread enough to require that iterative resolvers be
-- able to cope with it. Iterative resolvers SHOULD be able to handle
-- arbitrary levels of indirection resulting from out-of-zone name
-- servers. Iterative resolvers SHOULD implement a level-of-effort
-- counter to avoid loops or otherwise performing too much work in
-- resolving pathological cases.
--
-- A best practice that avoids this entire issue of indirection is to
-- name one or more of a zone's name servers in the zone itself. For
-- example, if the zone is named "example.com", consider naming some of
-- the name servers "ns{1,2,...}.example.com" (or similar).
--
--2.4. Aggressive retransmission when fetching glue
--
-- When an authoritative name server responds with a referral, it
-- includes NS records in the authority section of the response.
-- According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
-- server should also "put whatever addresses are available into the
-- additional section, using glue RRs if the addresses are not available
-- from authoritative data or the cache." Some name server
-- implementations take this address inclusion a step further with a
-- feature called "glue fetching". A name server that implements glue
-- fetching attempts to include address records for every NS record in
-- the authority section. If necessary, the name server issues multiple
-- queries of its own to obtain any missing address records.
--
-- Problems with glue fetching can arise in the context of
-- "authoritative-only" name servers, which only serve authoritative
-- data and ignore requests for recursion. Such an entity will not
-- normally generate any queries of its own. Instead it answers non-
-- recursive queries from iterative resolvers looking for information in
-- zones it serves. With glue fetching enabled, however, an
-- authoritative server invokes an iterative resolver to look up an
-- unknown address record to complete the additional section of a
-- response.
--
-- We have observed situations where the iterative resolver of a glue-
-- fetching name server can send queries that reach other name servers,
-- but is apparently prevented from receiving the responses. For
-- example, perhaps the name server is authoritative-only and therefore
-- its administrators expect it to receive only queries and not
-- responses. Perhaps unaware of glue fetching and presuming that the
-- name server's iterative resolver will generate no queries, its
-- administrators place the name server behind a network device that
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 9]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- prevents it from receiving responses. If this is the case, all glue-
-- fetching queries will go answered.
--
-- We have observed name server implementations whose iterative
-- resolvers retry excessively when glue-fetching queries are
-- unanswered. A single com/net name server has received hundreds of
-- queries per second from a single such source. Judging from the
-- specific queries received and based on additional analysis, we
-- believe these queries result from overly aggressive glue fetching.
--
--2.4.1. Recommendation
--
-- Implementers whose name servers support glue fetching SHOULD take
-- care to avoid sending queries at excessive rates. Implementations
-- SHOULD support throttling logic to detect when queries are sent but
-- no responses are received.
--
--2.5. Aggressive retransmission behind firewalls
--
-- A common occurrence and one of the largest sources of repeated
-- queries at the com/net and root name servers appears to result from
-- resolvers behind misconfigured firewalls. In this situation, an
-- iterative resolver is apparently allowed to send queries through a
-- firewall to other name servers, but not receive the responses. The
-- result is more queries than necessary because of retransmission, all
-- of which are useless because the responses are never received. Just
-- as with the glue-fetching scenario described in Section 2.4, the
-- queries are sometimes sent at excessive rates. To make matters
-- worse, sometimes the responses, sent in reply to legitimate queries,
-- trigger an alarm on the originator's intrusion detection system. We
-- are frequently contacted by administrators responding to such alarms
-- who believe our name servers are attacking their systems.
--
-- Not only do some resolvers in this situation retransmit queries at an
-- excessive rate, but they continue to do so for days or even weeks.
-- This scenario could result from an organization with multiple
-- recursive name servers, only a subset of whose iterative resolvers'
-- traffic is improperly filtered in this manner. Stub resolvers in the
-- organization could be configured to query multiple recursive name
-- servers. Consider the case where a stub resolver queries a filtered
-- recursive name server first. The iterative resolver of this
-- recursive name server sends one or more queries whose replies are
-- filtered, so it can't respond to the stub resolver, which times out.
-- Then the stub resolver retransmits to a recursive name server that is
-- able to provide an answer. Since resolution ultimately succeeds the
-- underlying problem might not be recognized or corrected. A popular
-- stub resolver implementation has a very aggressive retransmission
-- schedule, including simultaneous queries to multiple recursive name
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 10]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- servers, which could explain how such a situation could persist
-- without being detected.
--
--2.5.1. Recommendation
--
-- The most obvious recommendation is that administrators SHOULD take
-- care not to place iterative resolvers behind a firewall that allows
-- queries to pass through but not the resulting replies.
--
-- Iterative resolvers SHOULD take care to avoid sending queries at
-- excessive rates. Implementations SHOULD support throttling logic to
-- detect when queries are sent but no responses are received.
--
--2.6. Misconfigured NS records
--
-- Sometimes a zone administrator forgets to add the trailing dot on the
-- domain names in the RDATA of a zone's NS records. Consider this
-- fragment of the zone file for "example.com":
--
-- $ORIGIN example.com.
-- example.com. 3600 IN NS ns1.example.com ; Note missing
-- example.com. 3600 IN NS ns2.example.com ; trailing dots
--
-- The zone's authoritative servers will parse the NS RDATA as
-- "ns1.example.com.example.com" and "ns2.example.com.example.com" and
-- return NS records with this incorrect RDATA in responses, including
-- typically the authority section of every response containing records
-- from the "example.com" zone.
--
-- Now consider a typical sequence of queries. An iterative resolver
-- attempting to resolve address records for "www.example.com" with no
-- cached information for this zone will query a "com" authoritative
-- server. The "com" server responds with a referral to the
-- "example.com" zone, consisting of NS records with valid RDATA and
-- associated glue records. (This example assumes that the
-- "example.com" zone delegation information is correct in the "com"
-- zone.) The iterative resolver caches the NS RRset from the "com"
-- server and follows the referral by querying one of the "example.com"
-- authoritative servers. This server responds with the
-- "www.example.com" address record in the answer section and,
-- typically, the "example.com" NS records in the authority section and,
-- if space in the message remains, glue address records in the
-- additional section. According to Section 5.4 of RFC 2181 [3], NS
-- records in the authority section of an authoritative answer are more
-- trustworthy than NS records from the authority section of a non-
-- authoritative answer. Thus the "example.com" NS RRset just received
-- from the "example.com" authoritative server overrides the
-- "example.com" NS RRset received moments ago from the "com"
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 11]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- authoritative server.
--
-- But the "example.com" zone contains the erroneous NS RRset as shown
-- in the example above. Subsequent queries for names in "example.com"
-- will cause the iterative resolver to attempt to use the incorrect NS
-- records and so it will try to resolve the nonexistent names
-- "ns1.example.com.example.com" and "ns2.example.com.example.com". In
-- this example, since all of the zone's name servers are named in the
-- zone itself (i.e., "ns1.example.com.example.com" and
-- "ns2.example.com.example.com" both end in "example.com") and all are
-- bogus, the iterative resolver cannot reach any "example.com" name
-- servers. Therefore attempts to resolve these names result in address
-- record queries to the "com" authoritative servers. Queries for such
-- obviously bogus glue address records occur frequently at the com/net
-- name servers.
--
--2.6.1. Recommendation
--
-- An authoritative server can detect this situation. A trailing dot
-- missing from an NS record's RDATA always results by definition in a
-- name server name that exists somewhere under the apex of the zone the
-- NS record appears in. Note that further levels of delegation are
-- possible, so a missing trailing dot could inadvertently create a name
-- server name that actually exists in a subzone.
--
-- An authoritative name server SHOULD issue a warning when one of a
-- zone's NS records references a name server below the zone's apex when
-- a corresponding address record does not exist in the zone AND there
-- are no delegated subzones where the address record could exist.
--
--2.7. Name server records with zero TTL
--
-- Sometimes a popular com/net subdomain's zone is configured with a TTL
-- of zero on the zone's NS records, which prohibits these records from
-- being cached and will result in a higher query volume to the zone's
-- authoritative servers. The zone's administrator should understand
-- the consequences of such a configuration and provision resources
-- accordingly. A zero TTL on the zone's NS RRset, however, carries
-- additional consequences beyond the zone itself: if an iterative
-- resolver cannot cache a zone's NS records because of a zero TTL, it
-- will be forced to query that zone's parent's name servers each time
-- it resolves a name in the zone. The com/net authoritative servers do
-- see an increased query load when a popular com/net subdomain's zone
-- is configured with a TTL of zero on the zone's NS records.
--
-- A zero TTL on an RRset expected to change frequently is extreme but
-- permissible. A zone's NS RRset is a special case, however, because
-- changes to it must be coordinated with the zone's parent. In most
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 12]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- zone parent/child relationships we are aware of, there is typically
-- some delay involved in effecting changes. Further, changes to the
-- set of a zone's authoritative name servers (and therefore to the
-- zone's NS RRset) are typically relatively rare: providing reliable
-- authoritative service requires a reasonably stable set of servers.
-- Therefore an extremely low or zero TTL on a zone's NS RRset rarely
-- makes sense, except in anticipation of an upcoming change. In this
-- case, when the zone's administrator has planned a change and does not
-- want iterative resolvers throughout the Internet to cache the NS
-- RRset for a long period of time, a low TTL is reasonable.
--
--2.7.1. Recommendation
--
-- Because of the additional load placed on a zone's parent's
-- authoritative servers resulting from a zero TTL on a zone's NS RRset,
-- under such circumstances authoritative name servers SHOULD issue a
-- warning when loading a zone.
--
--2.8. Unnecessary dynamic update messages
--
-- The UPDATE message specified in RFC 2136 [6] allows an authorized
-- agent to update a zone's data on an authoritative name server using a
-- DNS message sent over the network. Consider the case of an agent
-- desiring to add a particular resource record. Because of zone cuts,
-- the agent does not necessarily know the proper zone to which the
-- record should be added. The dynamic update process requires that the
-- agent determine the appropriate zone so the UPDATE message can be
-- sent to one of the zone's authoritative servers (typically the
-- primary master as specified in the zone's SOA MNAME field).
--
-- The appropriate zone to update is the closest enclosing zone, which
-- cannot be determined only by inspecting the domain name of the record
-- to be updated, since zone cuts can occur anywhere. One way to
-- determine the closest enclosing zone entails walking up the name
-- space tree by sending repeated UPDATE messages until success. For
-- example, consider an agent attempting to add an address record with
-- the name "foo.bar.example.com". The agent could first attempt to
-- update the "foo.bar.example.com" zone. If the attempt failed, the
-- update could be directed to the "bar.example.com" zone, then the
-- "example.com" zone, then the "com" zone, and finally the root zone.
--
-- A popular dynamic agent follows this algorithm. The result is many
-- UPDATE messages received by the root name servers, the com/net
-- authoritative servers, and presumably other TLD authoritative
-- servers. A valid question is why the algorithm proceeds to send
-- updates all the way to TLD and root name servers. This behavior is
-- not entirely unreasonable: in enterprise DNS architectures with an
-- "internal root" design, there could conceivably be private, non-
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 13]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- public TLD or root zones that would be the appropriate targets for a
-- dynamic update.
--
-- A significant deficiency with this algorithm is that knowledge of a
-- given UPDATE message's failure is not helpful in directing future
-- UPDATE messages to the appropriate servers. A better algorithm would
-- be to find the closest enclosing zone by walking up the name space
-- with queries for SOA or NS rather than "probing" with UPDATE
-- messages. Once the appropriate zone is found, an UPDATE message can
-- be sent. In addition, the results of these queries can be cached to
-- aid in determining closest enclosing zones for future updates. Once
-- the closest enclosing zone is determined with this method, the update
-- will either succeed or fail and there is no need to send further
-- updates to higher-level zones. The important point is that walking
-- up the tree with queries yields cacheable information, whereas
-- walking up the tree by sending UPDATE messages does not.
--
--2.8.1. Recommendation
--
-- Dynamic update agents SHOULD send SOA or NS queries to progressively
-- higher-level names to find the closest enclosing zone for a given
-- name to update. Only after the appropriate zone is found should the
-- client send an UPDATE message to one of the zone's authoritative
-- servers. Update clients SHOULD NOT "probe" using UPDATE messages by
-- walking up the tree to progressively higher-level zones.
--
--2.9. Queries for domain names resembling IPv4 addresses
--
-- The root name servers receive a significant number of A record
-- queries where the QNAME looks like an IPv4 address. The source of
-- these queries is unknown. It could be attributed to situations where
-- a user believes an application will accept either a domain name or an
-- IP address in a given configuration option. The user enters an IP
-- address, but the application assumes any input is a domain name and
-- attempts to resolve it, resulting in an A record lookup. There could
-- also be applications that produce such queries in a misguided attempt
-- to reverse map IP addresses.
--
-- These queries result in Name Error (RCODE=3) responses. An iterative
-- resolver can negatively cache such responses, but each response
-- requires a separate cache entry, i.e., a negative cache entry for the
-- domain name "192.0.2.1" does not prevent a subsequent query for the
-- domain name "192.0.2.2".
--
--2.9.1. Recommendation
--
-- It would be desirable for the root name servers not to have to answer
-- these queries: they unnecessarily consume CPU resources and network
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 14]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- bandwidth. A possible solution is to delegate these numeric TLDs
-- from the root zone to a separate set of servers to absorb the
-- traffic. The "black hole servers" used by the AS 112 Project [8],
-- which are currently delegated the in-addr.arpa zones corresponding to
-- RFC 1918 [7] private use address space, would be a possible choice to
-- receive these delegations. Of course, the proper and usual root zone
-- change procedures would have to be followed to make such a change to
-- the root zone.
--
--2.10. Misdirected recursive queries
--
-- The root name servers receive a significant number of recursive
-- queries (i.e., queries with the RD bit set in the header). Since
-- none of the root servers offers recursion, the servers' response in
-- such a situation ignores the request for recursion and the response
-- probably does not contain the data the querier anticipated. Some of
-- these queries result from users configuring stub resolvers to query a
-- root server. (This situation is not hypothetical: we have received
-- complaints from users when this configuration does not work as
-- hoped.) Of course, users should not direct stub resolvers to use
-- name servers that do not offer recursion, but we are not aware of any
-- stub resolver implementation that offers any feedback to the user
-- when so configured, aside from simply "not working".
--
--2.10.1. Recommendation
--
-- When the IP address of a name server that supposedly offers recursion
-- is configured in a stub resolver using an interactive user interface,
-- the resolver could send a test query to verify that the server indeed
-- supports recursion (i.e., verify that the response has the RA bit set
-- in the header). The user could be immediately notified if the server
-- is non-recursive.
--
-- The stub resolver could also report an error, either through a user
-- interface or in a log file, if the queried server does not support
-- recursion. Error reporting SHOULD be throttled to avoid a
-- notification or log message for every response from a non-recursive
-- server.
--
--2.11. Suboptimal name server selection algorithm
--
-- An entire document could be devoted to the topic of problems with
-- different implementations of the recursive resolution algorithm. The
-- entire process of recursion is woefully under specified, requiring
-- each implementor to design an algorithm. Sometimes implementors make
-- poor design choices that could be avoided if a suggested algorithm
-- and best practices were documented, but that is a topic for another
-- document.
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 15]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
-- Some deficiencies cause significant operational impact and are
-- therefore worth mentioning here. One of these is name server
-- selection by an iterative resolver. When an iterative resolver wants
-- to contact one of a zone's authoritative name servers, how does it
-- choose from the NS records listed in the zone's NS RRset? If the
-- selection mechanism is suboptimal, queries are not spread evenly
-- among a zone's authoritative servers. The details of the selection
-- mechanism are up to the implementor, but we offer some suggestions.
--
--2.11.1. Recommendation
--
-- This list is not conclusive, but reflects the changes that would
-- produce the most impact in terms of reducing disproportionate query
-- load among a zone's authoritative servers. I.e., these changes would
-- help spread the query load evenly.
--
-- o Do not make assumptions based on NS RRset order: all NS RRs SHOULD
-- be treated equally. (In the case of the "com" zone, for example,
-- most of the root servers return the NS record for "a.gtld-
-- servers.net" first in the authority section of referrals.
-- Apparently as a result, this server receives disproportionately
-- more traffic than the other 12 authoritative servers for "com".)
--
-- o Use all NS records in an RRset. (For example, we are aware of
-- implementations that hard-coded information for a subset of the
-- root servers.)
--
-- o Maintain state and favor the best-performing of a zone's
-- authoritative servers. A good definition of performance is
-- response time. Non-responsive servers can be penalized with an
-- extremely high response time.
--
-- o Do not lock onto the best-performing of a zone's name servers. An
-- iterative resolver SHOULD periodically check the performance of
-- all of a zone's name servers to adjust its determination of the
-- best-performing one.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 16]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--3. Acknowledgments
--
-- The authors would like to thank the following people for their
-- comments that improved this document: Andras Salamon, Dave Meyer,
-- Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
-- Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We
-- apologize if we have omitted anyone; any oversight was unintentional.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 17]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--4. IANA considerations
--
-- There are no new IANA considerations introduced by this memo.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 18]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--5. Security considerations
--
-- The iterative resolver misbehavior discussed in this document exposes
-- the root and TLD name servers to increased risk of both intentional
-- and unintentional denial of service attacks.
--
-- We believe that implementation of the recommendations offered in this
-- document will reduce the amount of unnecessary traffic seen at root
-- and TLD name servers, thus reducing the opportunity for an attacker
-- to use such queries to his or her advantage.
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 19]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--6. Internationalization considerations
--
-- There are no new internationalization considerations introduced by
-- this memo.
--
--7. Informative References
--
-- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-- Levels", BCP 14, RFC 2119, March 1997.
--
-- [2] Mockapetris, P., "Domain names - concepts and facilities",
-- STD 13, RFC 1034, November 1987.
--
-- [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-- RFC 2181, July 1997.
--
-- [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-- RFC 2308, March 1998.
--
-- [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
-- Queries for IPv6 Addresses", RFC 4074, May 2005.
--
-- [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-- April 1997.
--
-- [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
-- Lear, "Address Allocation for Private Internets", BCP 5,
-- RFC 1918, February 1996.
--
-- [8] <http://www.as112.net>
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 20]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--Authors' Addresses
--
-- Matt Larson
-- VeriSign, Inc.
-- 21345 Ridgetop Circle
-- Dulles, VA 20166-6503
-- USA
--
-- Email: mlarson@verisign.com
--
--
-- Piet Barber
-- VeriSign, Inc.
-- 21345 Ridgetop Circle
-- Dulles, VA 20166-6503
-- USA
--
-- Email: pbarber@verisign.com
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 21]
--\f
--Internet-Draft Observed DNS Resolution Misbehavior February 2006
--
--
--Intellectual Property Statement
--
-- The IETF takes no position regarding the validity or scope of any
-- Intellectual Property Rights or other rights that might be claimed to
-- pertain to the implementation or use of the technology described in
-- this document or the extent to which any license under such rights
-- might or might not be available; nor does it represent that it has
-- made any independent effort to identify any such rights. Information
-- on the procedures with respect to rights in RFC documents can be
-- found in BCP 78 and BCP 79.
--
-- Copies of IPR disclosures made to the IETF Secretariat and any
-- assurances of licenses to be made available, or the result of an
-- attempt made to obtain a general license or permission for the use of
-- such proprietary rights by implementers or users of this
-- specification can be obtained from the IETF on-line IPR repository at
-- http://www.ietf.org/ipr.
--
-- The IETF invites any interested party to bring to its attention any
-- copyrights, patents or patent applications, or other proprietary
-- rights that may cover technology that may be required to implement
-- this standard. Please address the information to the IETF at
-- ietf-ipr@ietf.org.
--
--
--Disclaimer of Validity
--
-- This document and the information contained herein are provided on an
-- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
--
--
--Copyright Statement
--
-- Copyright (C) The Internet Society (2006). This document is subject
-- to the rights, licenses and restrictions contained in BCP 78, and
-- except as set forth therein, the authors retain all their rights.
--
--
--Acknowledgment
--
-- Funding for the RFC Editor function is currently provided by the
-- Internet Society.
--
--
--
--
--Larson & Barber Expires August 14, 2006 [Page 22]
--\f
+++ /dev/null
--
--
--
--
--
--
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
+++ /dev/null
--
--
--
--
--
--
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
+++ /dev/null
--
--
--
--
--
--
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
--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]
--\f
projects / thirdparty / bind9.git / commitdiff
