summaryrefslogtreecommitdiffstats
path: root/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt')
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt618
1 files changed, 618 insertions, 0 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt
new file mode 100644
index 0000000..c6ec7e4
--- /dev/null
+++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt
@@ -0,0 +1,618 @@
+
+
+
+
+Network Working Group S. Woolf
+Internet-Draft Internet Systems Consortium, Inc.
+Expires: September 6, 2006 D. Conrad
+ Nominum, Inc.
+ March 5, 2006
+
+
+ Requirements for a Mechanism Identifying a Name Server Instance
+ draft-ietf-dnsop-serverid-06
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 6, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. A standardized mechanism to
+ determine the identity of a name server responding to a particular
+ query would be useful, particularly as a diagnostic aid for
+ administrators. Existing ad hoc mechanisms for addressing this need
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 1]
+
+Internet-Draft Serverid March 2006
+
+
+ have some shortcomings, not the least of which is the lack of prior
+ analysis of exactly how such a mechanism should be designed and
+ deployed. This document describes the existing convention used in
+ some widely deployed implementations of the DNS protocol, including
+ advantages and disadvantages, and discusses some attributes of an
+ improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 2]
+
+Internet-Draft Serverid March 2006
+
+
+1. Introduction and Rationale
+
+ Identifying which name server is responding to queries is often
+ useful, particularly in attempting to diagnose name server
+ difficulties. This is most obviously useful for authoritative
+ nameservers in the attempt to diagnose the source or prevalence of
+ inaccurate data, but can also conceivably be useful for caching
+ resolvers in similar and other situations. Furthermore, the ability
+ to identify which server is responding to a query has become more
+ useful as DNS has become more critical to more Internet users, and as
+ network and server deployment topologies have become more complex.
+
+ The traditional means for determining which of several possible
+ servers is answering a query has traditionally been based on the use
+ of the server's IP address as a unique identifier. However, the
+ modern Internet has seen the deployment of various load balancing,
+ fault-tolerance, or attack-resistance schemes such as shared use of
+ unicast IP addresses as documented in [RFC3258]. An unfortunate side
+ effect of these schemes has been to make the use of IP addresses as
+ identifiers somewhat problematic. Specifically, a dedicated DNS
+ query may not go to the same server as answered a previous query,
+ even though sent to the same IP address. Non-DNS methods such as
+ ICMP ping, TCP connections, or non-DNS UDP packets (such as those
+ generated by tools like "traceroute"), etc., may well be even less
+ certain to reach the same server as the one which receives the DNS
+ queries.
+
+ There is a well-known and frequently-used technique for determining
+ an identity for a nameserver more specific than the possibly-non-
+ unique "server that answered the query I sent to IP address XXX".
+ The widespread use of the existing convention suggests a need for a
+ documented, interoperable means of querying the identity of a
+ nameserver that may be part of an anycast or load-balancing cluster.
+ At the same time, however, it also has some drawbacks that argue
+ against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 3]
+
+Internet-Draft Serverid March 2006
+
+
+2. Existing Conventions
+
+ For some time, the commonly deployed Berkeley Internet Name Domain
+ implementation of the DNS protocol suite from the Internet Systems
+ Consortium [BIND] has supported a way of identifying a particular
+ server via the use of a standards-compliant, if somewhat unusual, DNS
+ query. Specifically, a query to a recent BIND server for a TXT
+ resource record in class 3 (CHAOS) for the domain name
+ "HOSTNAME.BIND." will return a string that can be configured by the
+ name server administrator to provide a unique identifier for the
+ responding server. (The value defaults to the result of a
+ gethostname() call). This mechanism, which is an extension of the
+ BIND convention of using CHAOS class TXT RR queries to sub-domains of
+ the "BIND." domain for version information, has been copied by
+ several name server vendors.
+
+ A refinement to the BIND-based mechanism, which dropped the
+ implementation-specific string, replaces ".BIND" with ".SERVER".
+ Thus the query string to learn the unique name of a server may be
+ queried as "ID.SERVER".
+
+ (For reference, the other well-known name used by recent versions of
+ BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
+ query for a CHAOS TXT RR for this name will return an
+ administratively defined string which defaults to the version of the
+ server responding. This is, however, not generally implemented by
+ other vendors.)
+
+2.1. Advantages
+
+ There are several valuable attributes to this mechanism, which
+ account for its usefulness.
+
+ 1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
+ within the DNS protocol itself. An identification mechanism that
+ relies on the DNS protocol is more likely to be successful
+ (although not guaranteed) in going to the same system as a
+ "normal" DNS query.
+
+ 2. Since the identity information is requested and returned within
+ the DNS protocol, it doesn't require allowing any other query
+ mechanism to the server, such as holes in firewalls for
+ otherwise-unallowed ICMP Echo requests. Thus it is likely to
+ reach the same server over a path subject to the same routing,
+ resource, and security policy as the query, without any special
+ exceptions to site security policy.
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 4]
+
+Internet-Draft Serverid March 2006
+
+
+ 3. It is simple to configure. An administrator can easily turn on
+ this feature and control the results of the relevant query.
+
+ 4. It allows the administrator complete control of what information
+ is given out in the response, minimizing passive leakage of
+ implementation or configuration details. Such details are often
+ considered sensitive by infrastructure operators.
+
+ 5. Hypothetically, since it's an ordinary DNS record and the
+ relevant DNSSEC RRs are class independent, the id.server response
+ RR could be signed, which has the advantages described in
+ [RFC4033].
+
+2.2. Disadvantages
+
+ At the same time, there are some serious drawbacks to the CHAOS/TXT
+ query mechanism that argue against standardizing it as it currently
+ operates.
+
+ 1. It requires an additional query to correlate between the answer
+ to a DNS query under normal conditions and the supposed identity
+ of the server receiving the query. There are a number of
+ situations in which this simply isn't reliable.
+
+ 2. It reserves an entire class in the DNS (CHAOS) for what amounts
+ to one zone. While CHAOS class is defined in [RFC1034] and
+ [RFC1035], it's not clear that supporting it solely for this
+ purpose is a good use of the namespace or of implementation
+ effort.
+
+ 3. The initial and still common form, using .BIND, is implementation
+ specific. BIND is one DNS implementation. At the time of this
+ writing, it is probably the most prevalent for authoritative
+ servers. This does not justify standardizing on its ad hoc
+ solution to a problem shared across many operators and
+ implementors. Meanwhile, the proposed refinement changes the
+ string but preserves the ad hoc CHAOS/TXT mechanism.
+
+ 4. There is no convention or shared understanding of what
+ information an answer to such a query for a server identity could
+ or should include, including a possible encoding or
+ authentication mechanism.
+
+ The first of the listed disadvantages may be technically the most
+ serious. It argues for an attempt to design a good answer to the
+ problem that "I need to know what nameserver is answering my
+ queries", not simply a convenient one.
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 5]
+
+Internet-Draft Serverid March 2006
+
+
+2.3. Characteristics of an Implementation Neutral Convention
+
+ The discussion above of advantages and disadvantages to the
+ HOSTNAME.BIND mechanism suggest some requirements for a better
+ solution to the server identification problem. These are summarized
+ here as guidelines for any effort to provide appropriate protocol
+ extensions:
+
+ 1. The mechanism adopted must be in-band for the DNS protocol. That
+ is, it needs to allow the query for the server's identifying
+ information to be part of a normal, operational query. It should
+ also permit a separate, dedicated query for the server's
+ identifying information. But it should preserve the ability of
+ the CHAOS/TXT query-based mechanism to work through firewalls and
+ in other situations where only DNS can be relied upon to reach
+ the server of interest.
+
+ 2. The new mechanism should not require dedicated namespaces or
+ other reserved values outside of the existing protocol mechanisms
+ for these, i.e. the OPT pseudo-RR. In particular, it should not
+ propagate the existing drawback of requiring support for a CLASS
+ and top level domain in the authoritative server (or the querying
+ tool) to be useful.
+
+ 3. Support for the identification functionality should be easy to
+ implement and easy to enable. It must be easy to disable and
+ should lend itself to access controls on who can query for it.
+
+ 4. It should be possible to return a unique identifier for a server
+ without requiring the exposure of information that may be non-
+ public and considered sensitive by the operator, such as a
+ hostname or unicast IP address maintained for administrative
+ purposes.
+
+ 5. It should be possible to authenticate the received data by some
+ mechanism analogous to those provided by DNSSEC. In this
+ context, the need could be met by including encryption options in
+ the specification of a new mechanism.
+
+ 6. The identification mechanism should not be implementation-
+ specific.
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 6]
+
+Internet-Draft Serverid March 2006
+
+
+3. IANA Considerations
+
+ This document proposes no specific IANA action. Protocol extensions,
+ if any, to meet the requirements described are out of scope for this
+ document. A proposed extension, specified and adopted by normal IETF
+ process, is described in [NSID], including relevant IANA action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 7]
+
+Internet-Draft Serverid March 2006
+
+
+4. Security Considerations
+
+ Providing identifying information as to which server is responding to
+ a particular query from a particular location in the Internet can be
+ seen as information leakage and thus a security risk. This motivates
+ the suggestion above that a new mechanism for server identification
+ allow the administrator to disable the functionality altogether or
+ partially restrict availability of the data. It also suggests that
+ the serverid data should not be readily correlated with a hostname or
+ unicast IP address that may be considered private to the nameserver
+ operator's management infrastructure.
+
+ Propagation of protocol or service meta-data can sometimes expose the
+ application to denial of service or other attack. As DNS is a
+ critically important infrastructure service for the production
+ Internet, extra care needs to be taken against this risk for
+ designers, implementors, and operators of a new mechanism for server
+ identification.
+
+ Both authentication and confidentiality of serverid data are
+ potentially of interest to administrators-- that is, operators may
+ wish to make serverid data available and reliable to themselves and
+ their chosen associates only. This would imply both an ability to
+ authenticate it to themselves and keep it private from arbitrary
+ other parties. This led to Characteristics 4 and 5 of an improved
+ solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 8]
+
+Internet-Draft Serverid March 2006
+
+
+5. Acknowledgements
+
+ The technique for host identification documented here was initially
+ implemented by Paul Vixie of the Internet Software Consortium in the
+ Berkeley Internet Name Daemon package. Comments and questions on
+ earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+ Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+ ICANN Root Server System Advisory Committee. The newest version
+ takes a significantly different direction from previous versions,
+ owing to discussion among contributors to the DNSOP working group and
+ others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
+ Weiler, and Rob Austein.
+
+6. References
+
+ [1] Mockapetris, P., "Domain Names - Concepts and Facilities",
+ RFC 1034, STD 0013, November 1987.
+
+ [2] Mockapetris, P., "Domain Names - Implementation and
+ Specification", RFC 1035, STD 0013, November 1987.
+
+ [3] Hardie, T., "Distributing Authoritative Name Servers via Shared
+ Unicast Addresses", RFC 3258, April 2002.
+
+ [4] ISC, "BIND 9 Configuration Reference".
+
+ [5] Austein, S., "DNS Name Server Identifier Option (NSID)",
+ Internet Drafts http://www.ietf.org/internet-drafts/
+ draft-ietf-dnsext-nsid-01.txt, January 2006.
+
+ [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 9]
+
+Internet-Draft Serverid March 2006
+
+
+Authors' Addresses
+
+ Suzanne Woolf
+ Internet Systems Consortium, Inc.
+ 950 Charter Street
+ Redwood City, CA 94063
+ US
+
+ Phone: +1 650 423-1333
+ Email: woolf@isc.org
+ URI: http://www.isc.org/
+
+
+ David Conrad
+ Nominum, Inc.
+ 2385 Bay Road
+ Redwood City, CA 94063
+ US
+
+ Phone: +1 1 650 381 6003
+ Email: david.conrad@nominum.com
+ URI: http://www.nominum.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 10]
+
+Internet-Draft Serverid March 2006
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2006). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 11]
+
+
OpenPOWER on IntegriCloud