INTERNET-DRAFT DavidNetwork Working Group S. Woolf Internet-Draft Internet Systems Consortium, Inc. Expires: January 16, 2005 D. Conrad draft-ietf-dnsop-serverid-01.txtNominum, Inc. November, 2002July 18, 2004 Identifying an Authoritative Name Server`Server draft-ietf-dnsop-serverid-02 Status of this Memo This document is an Internet-Draft and is in full conformance withsubject to all provisions of Section 10section 3 of RFC 3667. 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 RFC2026.which he or she become aware will be disclosed, in accordance with RFC 3668. 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. 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.txthttp:// 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 January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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. Existing ad hoc mechanisms for addressing this concern are not adequate. This document describes an identification convention used in one widely deployed implementation ofattempts to describe the DNS protocolcommon ad hoc solution to this problem, including its advantages and disadvantasges, and proposes a slight modificationto that convention aimed at addressing some implementation concerns.characterize an improved mechanism. 1. Introduction DeterminingWith the identityincreased use of theDNS anycast, load balancing, and other mechanisms allowing more than one DNS name server respondingto share a querysingle IP address, it is sometimes difficult to tell which of a pool of name servers has become more complex due primarilyanswered a particular query. A standardized mechanism to determine the proliferationidentity of various load balancing techniques. This document describesa convention used by one particular DNSname server implementationresponding to provide identifying information and proposesa slight modification to that convention to address concerns regarding implementation neutrality. Note that this document makes no value judgementsparticular query would be useful, particularly as to whether ora diagnostic aid. Unfortunately, existing ad-hoc mechanisms for providing such identification have some shortcomings, not the convention in current useleast of which is good or bad; it merely documentsthe covention's existence and proposes a slight redefinitionlack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention to address non-technicalused in one widely deployed implementation concerns.of the DNS protocol and discusses requirements for an improved solution to the problem. 2. Rationale Identifying which name server is responding to queries is often useful, particularly in attempting to diagnose name server difficulties. However, relying on the IP address of the name server has become more problematic due the deployment of various load balancing solutions, including the use of shared unicast addresses as documented in [RFC3258]. An unfortunate side effect of these load balancing solutions is that traditional methods of determining which server is responding can be unreliable. Specifically, non-DNS methods such as ICMP ping, TCP connections, or non-DNS UDP packets (e.g., as generated by tools such as "traceroute"), etc., can end up going to a different server than that which receives the DNS queries. This proposal makesThe widespread use of the existing convention suggests a need for a documented, interoperable means of querying the assumptionidentity of a nameserver that may be part of an identification mechanism that relies on the DNS protocol is more likely to be successful (although not guaranteed) in going toanycast or load-balancing cluster. At the same machinetime, however, it also has some drawbacks that argue against standardizing it as a "normal" DNS query.it's been practiced so far. 3. HistoricalExisting Conventions Recent versions of the commonly deployed Berkeley Internet Name Domain implementation of the DNS protocol suite from the Internet Software Consortium [BIND] support a way of identifying a particular server via the use of a standard, if somewhat unusual, DNS query. Specifically, a query to a late model 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 (defaulting to the value 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. 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 TXT RR for this name will return an administratively re- definable string which defaults to the version of the server responding. 4.3.1 Advantages There are several valuable attributes to this mechanism, which account for its usefulness. 1. This mechanism is within the DNS protocol itself. An Implementation Neutral Convention The previously described use ofidentification mechanism that relies on the CHAOS class "BIND." domain has (rightly) been viewed by many implementors asDNS protocol is more likely to be successful (although not being standardized nor being implementation neutral. As such, a standard mechanismguaranteed) in going to identify a particular machine among a shared unicast set of machines servingthe same DNS data does not currently exist. Sincemachine as a name server conforming"normal" DNS query. 2. It is simple to [RFC1034] and [RFC1035] should support the CHAOS classconfigure. An administrator can easily turn on this feature and control the useresults of TXT resource record queries in the CHAOS class to derive information about a name server has been used in several independent name server implementations,the quickest way of supportingrelevant query. 3. It allows the identificationadministrator complete control of a particular name serverwhat information is given out in the response, minimizing passive leakage of a set of name servers all sharingimplementation or configuration details. Such details are often considered sensitive by infrastructure operators. 3.2 Disadvantages At the same unicast prefix would likely betime, there are some forbidding drawbacks to standardize onthe BIND convention, albeit with a slight modificationVERSION.BIND mechanism that argue against standardizing it as it currently operates. 1. It requires an additional query to address implementation neutrality concerns. The convention proposed here simply redefinescorrelate between the top level CHAOS domainanswer to be "SERVER." insteada DNS query under normal conditions and the supposed identity of "BIND.". Since usingthe actual hostname may be consideredserver receiving the query. There are a number of situations in which this simply isn't reliable. 2. It reserves an information leakage security risk,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 actual hostnamenamespace or of the serverimplementation effort. 3. It is discouraged and instead a unique per-server identifier should be used. As theimplementation specific. BIND convention of "HOSTNAME" impliesis one DNS implementation. At the usetime of this writing, it is probably the most prevalent, for authoritative servers anyway. This does not justify standardizing on its ad hoc solution to a hostname,problem shared across many operators and implementors. The first of the domain name "ID.SERVER"listed disadvantages is proposed. That is, a TXT RR query for "ID.SERVER." intechnically the CHAOS class will returnmost serious. It argues for an administratively defined string that can be usedattempt to differentiate among multiple servers. To make this convention useful, DNS operators wishing to identify their servers uniquely MUST, for EACH server, putdesign a unique string forgood answer to the RDATAproblem that "I need to know what nameserver is answering my queries", not simply a convenient one. 4. Characteristics of the TXT record associated with the "ID.SERVER." domain in class CHAOS. For example, given two machines "a.example.com"an Implementation Neutral Convention The discussion above of advantages and "b.example.com" that receive DNS queries atdisadvantages to the same IP address,HOSTNAME.BIND mechanism suggest some requirements for a better solution to the nameserver administrator could include $ORIGIN SERVER. ID CH TXT "a" in the appropriate zone file on machine "a.example.com" and $ORIGIN SERVER. ID CH TXT "b" in the appropriate zone file on machine "b.example.com". Queriesidentification problem. These are summarized here as guidelines for TXT RRs of "id.server" in class CHAOSany effort to provide appropriate protocol extensions: 1. The mechanism adopted MUST be in-band for the IP address serving both "a.example.com" and "b.example.com" should return "a" or "b" depending on which machineDNS protocol. That is, it needs to allow the query was routed. Implementors MUST provide a way to disable returning thisfor the server's identifying information. Implementorsinformation to be part of a normal, operational query. It SHOULD providealso permit a way to limit who canseparate, dedicated query for the server's identifying information. 2. The use ofnew mechanism should not require dedicated namespaces or other names inreserved values outside of the CHAOS class "SERVER." domain are beyondexisting protocol mechanisms for these, i.e. the scope of this document. IANA Considerations The "SERVER." domain inOPT pseudo-RR. 3. Support for the CHAOS class shouldidentification functionality SHOULD be reserved by IANAeasy to implement and a registryeasy 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 created that reserves the "ID" name. Inpossible to return a unique identifier for a server without requiring the future, requestsexposure of information that may be submittednon-public and considered sensitive by the operator, such as a hostname or unicast IP address maintained for other sub-domainsadministrative purposes. 5. The identification mechanism SHOULD NOT be implementation-specific. 5. IANA Considerations This document proposes no specific IANA action. Protocol extensions, if any, to meet the requirements described are out of "SERVER.", e.g., "VERSION.SERVER."scope for this document. Should such extensions be specified and adopted by normal IETF process, the IANA should takespecification will include appropriate action.guidance to IANA. 6. Security Considerations Providing identifying information as to which server is responding can be seen as information leakage and thus a security risk. It may be appropriateThis motivates the suggestion above that a new mechanism for server identification allow the administrator to disable the functionality altogether or partially restrict who can query foravailability of the "ID.SERVER." domain. Filtering on sourcedata. It also suggests that the serverid data should not be readily correlated with a hostname or unicast IP address wouldthat may be one way in which restrictionsconsidered private to the nameserver operator's management infrastructure. Propagation of protocol or service meta-data can be applied. The identifer returned via an "ID.SERVER." query SHOULD NOT containsometimes expose the hostnameapplication to denial of service or other information that couldattack. As DNS is a critically important infrastructure service for the production Internet, extra care needs to be considered sensitive.taken against this risk for designers, implementors, and operators of a new mechanism for server identification. 7. Acknowledgements The technique for host identification documented here derive from practiceswas initially implemented by Paul Vixie of the Internet Software Consortium in the Berkeley Internet Name DomainDaemon package. Useful commentsComments 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 Council. Additional explanatory information provided due to questions receivedCommittee. The newest draft takes a significantly different direction from Randy Bush. References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCsprevious versions, owing to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April, 2002. Author's Address David Conrad Nominum, Inc. 2385 Bay Road Redwood City, CA 94063 USA Phone: +1 650 381 6003 Fax: +1 650 381 6055 Email: firstname.lastname@example.org Full Copyrightdiscussion among contributors to the DNSOP working group and others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler, and Rob Austein. Intellectual Property Statement Copyright (C)The Internet Society (2000). All Rights Reserved. This document and translationsIETF takes no position regarding the validity or scope of it mayany Intellectual Property Rights or other rights that might be copied and furnishedclaimed to others, and derivative works that comment on or otherwise explain it or assist in itspertain to the implementation may be prepared, copied, published and distributed, in wholeor in part, without restrictionuse of any kind, provided thatthe above copyright notice and this paragraph are included on all such copies and derivative works. However,technology described in this document itself mayor the extent to which any license under such rights might or might not be modified inavailable; nor does it represent that it has made any independent effort to identify any way,such as by removingrights. Information on the copyright notice or referencesprocedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the Internet SocietyIETF Secretariat and any assurances of licenses to be made available, or other Internet organizations, except as needed forthe purposeresult of developing Internet standards in which case the proceduresan attempt made to obtain a general license or permission for copyrights defined inthe Internet Standards process must be followed,use of such proprietary rights by implementers or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will notusers of this specification can be revoked byobtained from the Internet Society orIETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its successorsattention any copyrights, patents or patent applications, or assigns.other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Disclaimer of Validity This document and the information contained herein isare 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 DISCLAIMSDISCLAIM 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."PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). 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.