idnits 2.17.00 (12 Aug 2021) /tmp/idnits14536/draft-austein-dnsext-nsid-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 18, 2005) is 6150 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 125, but not defined == Unused Reference: 'I-D.ietf-dnsop-serverid' is defined on line 304, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) == Outdated reference: draft-ietf-dnsop-serverid has been published as RFC 4892 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 Internet-Draft ISC 4 Expires: January 19, 2006 July 18, 2005 6 EDNS NSID Extension 7 draft-austein-dnsext-nsid-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 With the increased use of DNS anycast, load balancing, and other 41 mechanisms allowing more than one DNS name server to share a single 42 IP address, it is sometimes difficult to tell which of a pool of name 43 servers has answered a particular query. While existing ad-hoc 44 mechanism allow an operator to send follow-up queries when it is 45 necessary to debug such a configuration, the only completely reliable 46 way to obtain the identity of the name server which actually 47 responded is to have the name server include this information in the 48 response itself. This note proposes a protocol extension to support 49 this functionality. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Proposed Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 The SI Flag . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2 The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 57 3. What Should the NSID Payload Be? . . . . . . . . . . . . . . . 5 58 4. Should Recursive Name Servers Respond to SI? . . . . . . . . . 8 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 64 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . 13 68 1. Introduction 70 With the increased use of DNS anycast, load balancing, and other 71 mechanisms allowing more than one DNS name server to share a single 72 IP address, it is sometimes difficult to tell which of a pool of name 73 servers has answered a particular query. 75 Existing ad-hoc mechanisms such as those described in [I-D.ietf- 76 dnsop-serverid] allow an operator to send follow-up queries when it 77 is necessary to debug such a configuration, but there are situations 78 in which this is not a totally satisfactory solution, since anycast 79 routing may have changed, or the server pool in question may be 80 behind some kind of extremely dynamic load balancing hardware. Thus, 81 while these ad-hoc mechanisms are certainly better than nothing (and 82 have the advantage of already being deployed), a better solution 83 seems desirable. 85 Given that a DNS query is an idempotent operation with no retained 86 state, it would appear that the only completely reliable way to 87 obtain the identity of the name server which actually responded to a 88 particular query is to have that name server include identifying 89 information in the response itself. This note proposes a protocol 90 enhancement to achieve this. 92 2. Proposed Mechanism 94 This note proposes using an EDNS [RFC2671] flag bit to signal the 95 resolver's desire for information identifying the name server, and an 96 EDNS option to hold the name server's response (should it choose to 97 honor the resolver's request). 99 2.1 The SI Flag 101 A resolver signals its desire for information identifying the server 102 by setting the SI (Send Identification) flag in the extended flags 103 field of the OPT pseudo-RR. 105 The value of the SI flag is [TBD]. 107 The semantics of the SI flag are not transitive. That is: the SI 108 flag is a request that the name server which receives the query 109 identify itself; in a so-called forwarding setup, the first hop name 110 server is the one that should identify itself. If the resolver side 111 of a forwarding name server wishes to receive identifying 112 information, it is free to set the SI flag in its own queries, but 113 that is a separate matter. 115 A name server which understands the SI flag should echo its value 116 back in the response message, regardless of whether the name server 117 chose to honor the request. 119 2.2 The NSID Option 121 A name server which understands the SI flag and chooses to honor it 122 responds by including identifying information in a NSID option in an 123 EDNS OPT pseudo-RR in the response message. 125 The OPTION-CODE for the NSID option is [TBD]. 127 The OPTION-DATA for the NSID option is an opaque byte string the 128 semantics of which are deliberately left outside the protocol. See 129 Section 3 for discussion. 131 The NSID option is not transitive. A name server must not send an 132 NSID option back to a resolver which did not request it. In 133 particular, while a forwarder may choose to set the SI bit when 134 forwarding a query, this has no effect on the setting of the SI bit 135 or the presence or absence of the NSID option in the forwarder's 136 response to the original client. 138 3. What Should the NSID Payload Be? 140 The syntax and semantics of the content of the NSID option is 141 deliberately left outside the scope of this specification. This 142 describe some of the kinds of data that server administrators might 143 choose to provide as the content of the NSID option, and explains the 144 reasoning (such as it is) behind choosing a simple opaque byte 145 string. 147 There are several possibilities for the payload of the NSID option. 149 o It could be the "real" name of the specific name server within the 150 name server pool. 152 o It could be the "real" IP address (IPv4 or IPv6) of the name 153 server within the name server pool. 155 o It could be some sort of pseudo-random number generated in a 156 predictable fashion somehow using the server's IP address or name 157 as a seed value. 159 o It could be some sort of probabilisticly unique identifier 160 initially derived from some sort of random number generator then 161 preserved across reboots of the name server. 163 o It could be some sort of dynamicly generated identifier so that 164 only the name server operator could even tell whether or not any 165 two queries had been answered by the same server. 167 o It could be a blob of signed data, with a corresponding key which 168 might (or might not) be available via DNS lookups. 170 o It could be a blob of encrypted data, the key for which presumably 171 would be restricted to parties with a need to know (in the opinion 172 of the server operator). 174 o It could be an arbitrary string of octets chosen at the discretion 175 of the name server operator. 177 Each of these options has advantages and disadvantages. 179 o Using the "real" name is simple, but assumes that the name server 180 has a "real" name, which it may not. 182 o Using the "real" address is also simple, and the name server 183 almost certainly does have at least one non-anycast IP address for 184 maintenance operations, but assumes that the operator of the name 185 server is willing to divulge its non-anycast address, which might 186 not be the case. 188 o Given that one common reason for using anycast DNS techniques is 189 an attempt to harden a critical name server against denial of 190 service attacks, some name server operators are likely to want an 191 identifier other than the "real" name or "real" address of the 192 name server instance. 194 o Using a hash or pseudo-random number can provide a fixed length 195 value that the resolver can use to tell two name servers apart 196 without necessarily being able to tell where either one of them 197 "really" is, but makes debugging more difficult if one happens to 198 be in a friendly open environment. Furthermore, a nonce may not 199 add much value, since a hash based on an IPv4 address still only 200 involves a 32-bit search space, and DNS names used for servers 201 that operators might have to debug at 4am tend not to be very 202 random at all. 204 o Probabilisticly unique identifiers have similar properties to 205 hashed identifiers, but (given a sufficiently good random number 206 generator) are immune to the search space issues. However, the 207 strength of this approach is also its weakness: there is no 208 algorithmic transformation by which even the server operator can 209 associate name server instances with identifiers while debugging, 210 which might be annoying. This approach also requires the name 211 server instance to preserve the probabilisticly unique identifier 212 across reboots, but this does not appear to be a serious 213 restriction, since authoritative nameservers almost always have 214 nonvolatile storage (such as a disk drive) in any case, and in 215 rare cases where a name server does not have any way to store such 216 an identifier, nothing terrible will happen if the name server 217 just generates a new identifier every time it reboots. 219 o Using an arbitrary octet string gives name server operators yet 220 another thing to configure, or mis-configure, or forget to 221 configure. Having all the nodes in an anycast name server 222 constellation identify themselves as "My Name Server" would not be 223 particularly useful. 225 Given all of the issues listed above, the best approach might be: 227 o Define the NSID payload to be an opaque byte string, as specified 228 in Section 2.2. 230 o Operators for whom divulging the unicast address is an issue could 231 use the raw binary representation of a probabilisticly unique 232 random number. This should probably be the default implementation 233 behavior. 235 o Operators for whom divulging the unicast address is not an issue 236 could just use the raw binary representation of a unicast address 237 for simplicity. This would only be done via an explicit 238 configuration choice by the operator. 240 o Operators who really need or want the ability to set the NSID 241 payload to an arbitrary value could do so, but this would only be 242 done via an explicit configuration choice by the operator. 244 This approach appears to provide enough information for useful 245 debugging without unintentionally leaking the maintenance addresses 246 of anycast name servers to nogoodniks, while also allowing name 247 server operators who do not find such leakage threatening to provide 248 more information at their own discretion. 250 4. Should Recursive Name Servers Respond to SI? 252 Most of the discussion of name server identification to date has 253 focused on identifying authoritative name servers, since the best 254 known cases of anycast name servers are a subset of the name servers 255 for the root zone. However, given that anycast DNS techniques are 256 equally applicable to recursive name servers as well as authoritative 257 name servers, it may be useful for the name server side of a 258 recursive name server to support this mechanism as well. The 259 semantics proposed for the SI bit in Section 2.1 are intended to 260 support this model. 262 5. IANA Considerations 264 This mechanism requires allocation of one EDNS flag bit for the SI 265 flag (Section 2.1). 267 This mechanism requires allocation of one ENDS option code for the 268 NSID option (Section 2.2). 270 6. Security Considerations 272 This document describes a channel signaling mechanism, intended 273 primarily for debugging. Channel signaling mechanisms are outside 274 the scope of DNSSEC per se. Thus, applications that require 275 integrity protection for the data being signaled will need to use a 276 channel security mechanism such as TSIG [RFC2845]. 278 Section 3 discusses a number of different kinds of information that a 279 name server operator might choose to provide as the value of the NSID 280 option. Some of these kinds of information are security sensitive in 281 some environments. This specification deliberately leaves the syntax 282 and semantics of the NSID option content up to the implementation and 283 the name server operator. 285 7. Acknowledgements 287 Joe Abley, Harald Alvestrand, Roy Arends, Steve Bellovin, Randy Bush, 288 David Conrad, Johan Ihren, Mike Patton, Paul Vixie, Sam Weiler, 289 Suzanne Woolf, and the law firm of Dewey, Chetham, and Howe. 291 8. References 293 8.1 Normative References 295 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 296 RFC 2671, August 1999. 298 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 299 Wellington, "Secret Key Transaction Authentication for DNS 300 (TSIG)", RFC 2845, May 2000. 302 8.2 Informative References 304 [I-D.ietf-dnsop-serverid] 305 Conrad, D., "Identifying an Authoritative Name Server", 306 draft-ietf-dnsop-serverid-04 (work in progress), 307 March 2005. 309 Author's Address 311 Rob Austein 312 ISC 313 950 Charter Street 314 Redwood City, CA 94063 315 USA 317 Email: sra@isc.org 319 Intellectual Property Statement 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Disclaimer of Validity 345 This document and the information contained herein are provided on an 346 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 347 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 348 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 349 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 350 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 Copyright Statement 355 Copyright (C) The Internet Society (2005). This document is subject 356 to the rights, licenses and restrictions contained in BCP 78, and 357 except as set forth therein, the authors retain all their rights. 359 Acknowledgment 361 Funding for the RFC Editor function is currently provided by the 362 Internet Society.