diff options
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.txt | 618 |
1 files changed, 0 insertions, 618 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 deleted file mode 100644 index c6ec7e4..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - -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] - - |
