idnits 2.17.1 draft-ietf-dnsop-serverid-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 364. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 22, 2007) is 6297 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Woolf 3 Internet-Draft Internet Systems Consortium, Inc. 4 Intended Status: Informational D. Conrad 5 Expires: July 26, 2007 ICANN 6 January 22, 2007 8 Requirements for a Mechanism Identifying a Name Server Instance 9 draft-ietf-dnsop-serverid-08 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 26, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 With the increased use of DNS anycast, load balancing, and other 43 mechanisms allowing more than one DNS name server to share a single 44 IP address, it is sometimes difficult to tell which of a pool of name 45 servers has answered a particular query. A standardized mechanism to 46 determine the identity of a name server responding to a particular 47 query would be useful, particularly as a diagnostic aid for 48 administrators. Existing ad hoc mechanisms for addressing this need 49 have some shortcomings, not the least of which is the lack of prior 50 analysis of exactly how such a mechanism should be designed and 51 deployed. This document describes the existing convention used in 52 some widely deployed implementations of the DNS protocol, including 53 advantages and disadvantages, and discusses some attributes of an 54 improved mechanism. 56 1. Introduction and Rationale 58 Identifying which name server is responding to queries is often 59 useful, particularly in attempting to diagnose name server 60 difficulties. This is most obviously useful for authoritative 61 nameservers in the attempt to diagnose the source or prevalence of 62 inaccurate data, but can also conceivably be useful for caching 63 resolvers in similar and other situations. Furthermore, the ability 64 to identify which server is responding to a query has become more 65 useful as DNS has become more critical to more Internet users, and as 66 network and server deployment topologies have become more complex. 68 The traditional means for determining which of several possible 69 servers is answering a query has traditionally been based on the use 70 of the server's IP address as a unique identifier. However, the 71 modern Internet has seen the deployment of various load balancing, 72 fault-tolerance, or attack-resistance schemes such as shared use of 73 unicast IP addresses as documented in [RFC3258]. An unfortunate side 74 effect of these schemes has been to make the use of IP addresses as 75 identifiers associated with DNS (or any other) service somewhat 76 problematic. Specifically, multiple dedicated DNS queries may not go 77 to the same server even though sent to the same IP address. Non-DNS 78 methods such as ICMP ping, TCP connections, or non-DNS UDP packets 79 (such as those generated by tools like "traceroute"), etc., may well 80 be even less certain to reach the same server as the one which 81 receives the DNS queries. 83 There is a well-known and frequently-used technique for determining 84 an identity for a nameserver more specific than the possibly-non- 85 unique "server that answered the query I sent to IP address A.B.C.D". 86 The widespread use of the existing convention suggests a need for a 87 documented, interoperable means of querying the identity of a 88 nameserver that may be part of an anycast or load-balancing cluster. 89 At the same time, however, it also has some drawbacks that argue 90 against standardizing it as it's been practiced so far. 92 2. Existing Conventions 94 For some time, the commonly deployed Berkeley Internet Name Domain 95 implementation of the DNS protocol suite from the Internet Systems 96 Consortium [BIND] has supported a way of identifying a particular 97 server via the use of a standards-compliant, if somewhat unusual, DNS 98 query. Specifically, a query to a recent BIND server for a TXT 99 resource record in class 3 (CHAOS) for the domain name 100 "HOSTNAME.BIND." will return a string that can be configured by the 101 name server administrator to provide a unique identifier for the 102 responding server. (The value defaults to the result of a 103 gethostname() call). This mechanism, which is an extension of the 104 BIND convention of using CHAOS class TXT RR queries to sub-domains of 105 the "BIND." domain for version information, has been copied by 106 several name server vendors. 108 A refinement to the BIND-based mechanism, which dropped the 109 implementation-specific label, replaces "BIND." with "SERVER.". Thus 110 the query label to learn the unique name of a server may appear as 111 "ID.SERVER.". 113 (For reference, the other well-known name used by recent versions of 114 BIND within the CHAOS class "BIND." domain is "VERSION.BIND.". A 115 query for a CHAOS TXT RR for this name will return an 116 administratively defined string which defaults to the software 117 version of the server responding. This is, however, not generally 118 implemented by other vendors.) 120 2.1. Advantages 122 There are several valuable attributes to this mechanism, which 123 account for its usefulness. 125 1. The "HOSTNAME.BIND." or "ID.SERVER." query response mechanism is 126 within the DNS protocol itself. An identification mechanism that 127 relies on the DNS protocol is more likely to be successful 128 (although not guaranteed) in going to the same system as a 129 "normal" DNS query. 131 2. Since the identity information is requested and returned within 132 the DNS protocol, it doesn't require allowing any other query 133 mechanism to the server, such as holes in firewalls for 134 otherwise-unallowed ICMP Echo requests. Thus it is likely to 135 reach the same server over a path subject to the same routing, 136 resource, and security policy as the query, without any special 137 exceptions to site security policy. 139 3. It is simple to configure. An administrator can easily turn on 140 this feature and control the results of the relevant query. 142 4. It allows the administrator complete control of what information 143 is given out in the response, minimizing passive leakage of 144 implementation or configuration details. Such details are often 145 considered sensitive by infrastructure operators. 147 2.2. Disadvantages 149 At the same time, there are some serious drawbacks to the CHAOS/TXT 150 query mechanism that argue against standardizing it as it currently 151 operates. 153 1. It requires an additional query to correlate between the answer 154 to a DNS query under normal conditions and the supposed identity 155 of the server receiving the query. There are a number of 156 situations in which this simply isn't reliable. 158 2. It reserves an entire class in the DNS (CHAOS) for what amounts 159 to one zone. While CHAOS class is defined in [RFC1034] and 160 [RFC1035], it's not clear that supporting it solely for this 161 purpose is a good use of the namespace or of implementation 162 effort. 164 3. The initial and still common form, using "BIND.", is 165 implementation specific. BIND is one DNS implementation. At the 166 time of this writing, it is probably the most prevalent for 167 authoritative servers. This does not justify standardizing on 168 its ad hoc solution to a problem shared across many operators and 169 implementors. Meanwhile, the aforementioned refinement changes 170 the query label but preserves the ad hoc CHAOS/TXT mechanism. 172 4. There is no convention or shared understanding of what 173 information an answer to such a query for a server identity could 174 or should contain, including a possible encoding or 175 authentication mechanism. 177 5. Hypothetically, since DNSSEC has been defined to cover all DNS 178 classes, the TXT RRs returned in response to the "ID.SERVER." 179 query could be signed, which has the advantages described in 180 [RFC4033]. However, since DNSSEC deployment for the CHAOS class 181 is neither existent nor foreseeable, and since the "ID.SERVER." 182 TXT RR is expected to be unique per server, this would be 183 impossible in practice. 185 The first of the listed disadvantages may be technically the most 186 serious. It argues for an attempt to design a good answer to the 187 problem that "I need to know what nameserver is answering my 188 queries", not simply a convenient one. 190 3. Characteristics of an Implementation Neutral Convention 192 The discussion above of advantages and disadvantages to the 193 "HOSTNAME.BIND." mechanism suggest some requirements for a better 194 solution to the server identification problem. These are summarized 195 here as guidelines for any effort to provide appropriate protocol 196 extensions: 198 1. The mechanism adopted must be in-band for the DNS protocol. That 199 is, it needs to allow the query for the server's identifying 200 information to be part of a normal, operational query. It should 201 also permit a separate, dedicated query for the server's 202 identifying information. But it should preserve the ability of 203 the CHAOS/TXT query-based mechanism to work through firewalls and 204 in other situations where only DNS can be relied upon to reach 205 the server of interest. 207 2. The new mechanism should not require dedicated namespaces or 208 other reserved values outside of the existing protocol mechanisms 209 for these, i.e. the OPT pseudo-RR. In particular, it should not 210 propagate the existing drawback of requiring support for a CLASS 211 and top level domain in the authoritative server (or the querying 212 tool) to be useful. 214 3. Support for the identification functionality should be easy to 215 implement and easy to enable. It must be easy to disable and 216 should lend itself to access controls on who can query for it. 218 4. It should be possible to return a unique identifier for a server 219 without requiring the exposure of information that may be non- 220 public and considered sensitive by the operator, such as a 221 hostname or unicast IP address maintained for administrative 222 purposes. 224 5. It should be possible to authenticate the received data by some 225 mechanism analogous to those provided by DNSSEC. In this 226 context, the need could be met by including encryption options in 227 the specification of a new mechanism. 229 6. The identification mechanism should not be implementation- 230 specific. 232 4. IANA Considerations 234 This document proposes no specific IANA action. Protocol extensions, 235 if any, to meet the requirements described are out of scope for this 236 document. A proposed extension, specified and adopted by normal IETF 237 process, is described in [NSID], including relevant IANA action. 239 5. Security Considerations 241 Providing identifying information as to which server is responding to 242 a particular query from a particular location in the Internet can be 243 seen as information leakage and thus a security risk. This motivates 244 the suggestion above that a new mechanism for server identification 245 allow the administrator to disable the functionality altogether or 246 partially restrict availability of the data. It also suggests that 247 the server identification data should not be readily correlated with 248 a hostname or unicast IP address that may be considered private to 249 the nameserver operator's management infrastructure. 251 Propagation of protocol or service meta-data can sometimes expose the 252 application to denial of service or other attack. As the DNS is a 253 critically important infrastructure service for the production 254 Internet, extra care needs to be taken against this risk for 255 designers, implementors, and operators of a new mechanism for server 256 identification. 258 Both authentication and confidentiality of server identification data 259 are potentially of interest to administrators-- that is, operators 260 may wish to make such data available and reliable to themselves and 261 their chosen associates only. This constraint would imply both an 262 ability to authenticate it to themselves and to keep it private from 263 arbitrary other parties, which leads to characteristics 4 and 5 of an 264 improved solution. 266 6. Acknowledgements 268 The technique for host identification documented here was initially 269 implemented by Paul Vixie of the Internet Software Consortium in the 270 Berkeley Internet Name Daemon package. Comments and questions on 271 earlier drafts were provided by Bob Halley, Brian Wellington, Andreas 272 Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the 273 ICANN Root Server System Advisory Committee. The newest version 274 takes a significantly different direction from previous versions, 275 owing to discussion among contributors to the DNSOP working group and 276 others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam 277 Weiler, and Rob Austein. 279 7. References 281 7.1. Normative References 283 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 284 RFC 1034, STD 0013, November 1987. 286 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 287 Specification", RFC 1035, STD 0013, November 1987. 289 [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via 290 Shared Unicast Addresses", RFC 3258, April 2002. 292 7.2. Informative References 294 [BIND] ISC, "BIND 9 Configuration Reference". 296 [NSID] Austein, S., "DNS Name Server Identifier Option (NSID)", 297 Internet Drafts http://www.ietf.org/internet-drafts/ 298 draft-ietf-dnsext-nsid-02.txt, June 2006. 300 [RFC4033] Arends, R., Austein, S., Larson, M., Massey, D., and S. 301 Rose, "DNS Security Introduction and Requirements", RFC 4033, 302 March 2005. 304 Authors' Addresses 306 Suzanne Woolf 307 Internet Systems Consortium, Inc. 308 950 Charter Street 309 Redwood City, CA 94063 310 US 312 Phone: +1 650 423-1333 313 Email: woolf@isc.org 314 URI: http://www.isc.org/ 316 David Conrad 317 ICANN 318 4676 Admiralty Way 319 Marina del Rey, CA 90292 320 US 322 Phone: +1 310 823 9358 323 Email: david.conrad@icann.org 324 URI: http://www.iana.org/ 326 Full Copyright Statement 328 Copyright (C) The IETF Trust (2007). 330 This document is subject to the rights, licenses and restrictions 331 contained in BCP 78, and except as set forth therein, the authors 332 retain all their rights. 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Intellectual Property 344 The IETF takes no position regarding the validity or scope of any 345 Intellectual Property Rights or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; nor does it represent that it has 349 made any independent effort to identify any such rights. Information 350 on the procedures with respect to rights in RFC documents can be 351 found in BCP 78 and BCP 79. 353 Copies of IPR disclosures made to the IETF Secretariat and any 354 assurances of licenses to be made available, or the result of an 355 attempt made to obtain a general license or permission for the use of 356 such proprietary rights by implementers or users of this 357 specification can be obtained from the IETF on-line IPR repository at 358 http://www.ietf.org/ipr. 360 The IETF invites any interested party to bring to its attention any 361 copyrights, patents or patent applications, or other proprietary 362 rights that may cover technology that may be required to implement 363 this standard. Please address the information to the IETF at 364 ietf-ipr@ietf.org. 366 Acknowledgment 368 Funding for the RFC Editor function is provided by the IETF 369 Administrative Support Activity (IASA).