idnits 2.17.1 draft-stw-whatsinaname-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC2870' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC7719' is defined on line 543, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2870 (Obsoleted by RFC 7720) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Woolf 3 Internet-Draft October 31, 2016 4 Intended status: Informational 5 Expires: May 4, 2017 7 Some Considerations for the Use of Domain Names in non-DNS Protocols 8 draft-stw-whatsinaname-01 10 Abstract 12 From time to time, networking protocols need to be able to name 13 things used within the protocol, and resolve the names created or 14 referenced. It's common for protocol designers in this predicament 15 to attempt to use domain names as the starting point for their 16 systems of names, and the DNS as the starting point for name 17 resolution. 19 There is existing guidance on how to think about application-specific 20 extensions to DNS if the protocol or software designer is re-using 21 both domain name abstractions and DNS protocol assumptions (see RFC 22 6950). However, recently there's also a tendency to re-use a domain- 23 name-based namespace without necessarily re-using DNS protocol for 24 name resolution. This document acknowledges that class of extensions 25 to the shared domain namespace and considers a framework for the 26 properties a naming and resolution convention should have in the 27 internet protocol environment, including the avoidance of collision 28 with other uses of the namespace. Depending to the answers to the 29 suggested questions, the answer may be that domain names will not 30 meet the constraints at hand. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 4, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. How We Got Here . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Some Questions . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Framework: what are the necessary pieces? . . . . . . . . . . 7 71 6. Some Guidelines . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Policy: The IETF and the Public DNS . . . . . . . . . . . 8 73 6.2. Operations: the Resolution Environment . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 10. Informative References . . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 From time to time, networking protocols need to be able to name 83 things used within the protocol, and resolve the names created or 84 referenced. Necessary operations tend to include creating, 85 modifying, and deleting names and accessing values and relationships 86 that correspond to them. 88 It's common for protocol designers in this predicament to attempt to 89 use domain names as the starting point for their systems of names, 90 and the DNS as the starting point for name resolution. This is 91 completely understandable-- domain names, and DNS resolution, are 92 well-established in both the expectations of network users and 93 developers, and well-supported by fielded software. 95 However, there are some risks when the protocol designer attempts to 96 re-use domain names and DNS, even (or especially) with modifications, 97 to support a specific use case or protocol design or deployment 98 constraint. These have been touched upon in several RFCs, and in the 99 long history of struggles to keep evolving DNS itself and the use of 100 domain names as new needs and constraints appear. See in particular 101 RFC 6055 ("IAB Thoughts on Encodings for Internationalized Domain 102 Names"), RFC 6950 ("Architectural Considerations on Application 103 Features in the DNS"), and RFC 6943 ("Issues in Identifier Comparison 104 for Security Purposes"). 106 This document deals principally with the questions a protocol 107 designer or software developer should ask themselves about what 108 behavior they want from the names they use in the context of a new 109 protocol or scope for names. It also provides a basic framework for 110 describing desired interactions for a naming and resolution context 111 as part of a protocol design. 113 This approach is admittedly somewhat "DNS-centric," in that it's 114 attempting to address the default assumption that domain names and 115 DNS-like semantics are desirable or even necessarily acceptable for 116 new naming needs. Depending to the answers to these questions, the 117 designer may find that domain names will not meet the constraints at 118 hand. Future versions of this draft will provide some comments on 119 alternatives. 121 This discussion also owes a great deal to the RFCs already mentioned, 122 especially RFC 6950, which "provides guidance to application 123 designers and application protocol designers looking to use the DNS 124 to support features in their applications." The consideration there 125 of how to structure domain names and associated data is invaluable. 126 This document takes a step in a different direction, however, in 127 attempting to separate domain names from DNS protocol in the analysis 128 of new protocol needs. RFC 6950 primarily assumes that the 129 namespace, the database of instantiated names, and the protocol for 130 lookup and retrieval are all of a piece, while it's become the case 131 recently that people are attempting to separate the namespace from 132 the protocol, with varying degrees of drama and varying degrees of 133 success. 135 Required reading includes draft-lewis-domain-names.txt, [RFC1034], 136 [RFC2826], [RFC2860], [RFC6950], [RFC6055], [RFC6943], [RFC6761] 138 2. How We Got Here 140 The Domain Name System is a critical part of the global internet 141 infrastructure. From the protocol standards perspective, it's 142 comprised of a number of standards-track documents and BCPs, but 143 roughly speaking, it includes a description of naming syntax and 144 semantics, some operational rules for constructing a globally shared 145 database of such names, and a specification of a wire protocol for 146 maintaining, querying, and generating responses from that database. 147 It has always been the case that all three need to be maintained in a 148 coordinated fashion for the DNS to function properly and the DNS 149 database to remain useful. 151 In an even larger sense, however, domain names and the DNS protocol 152 provide one answer to some fundamental questions for any computer 153 system: naming and the manipulation of names are fundamental topics 154 in computer science. Thus, DNS names and the DNS protocol exist as a 155 common and highly useful solution to the basic need for naming 156 "stuff" in certain applications and activities on the internet. We 157 do occasionally have to notice, however, that they're not the final 158 and complete solutions-- they have weaknesses-- even as they've 159 proven so useful they tend to be re-used where possible. 161 Domain names considerably predate the Domain Name System. The set of 162 domain names is, however, a superset of the DNS namespace, and the 163 characteristics of the DNS namespace are inherited from it. In 164 particular, part of the abstraction that describes domain names is a 165 tree with an identified root and identified semantics for labeling 166 nodes. 168 The basic structure of the domain namespace is a tree, with a domain 169 name as a list of nodes in the tree. Such a tree must have a single 170 root in order to maintain the uniqueness of each node. In 2002, the 171 IAB wrote [RFC2826] to clarify that the existence of this root is 172 inherent in the design of the DNS and requires coordination of 173 changes to the root of the global namespace. This remains true-- the 174 mathematics in particular have not changed!-- but is not as simple as 175 it sounds. This root domain isn't limited to names instantiated in 176 the DNS namespace, but of both mathematical and operational 177 necessity, includes them. 179 For application and protocol designers, then, domain names come with 180 desirable properties such as relatively straightforward structure and 181 widespread conventions for interpretation (such as IDNA to 182 internationalize a name in cases where human-friendliness is 183 important). 185 This apparent ease of use has been increased in recent years by the 186 publication of RFC 6761, which specifies a registry of domain names 187 for special uses. In a case where a protocol uses domain names and a 188 DNS-like protocol such as mDNS (see [RFC6762]), the registry marks a 189 portion of the abstract domain name space as associated with that 190 use. This allows a protocol- or application-specific node or subtree 191 to be associated with a location in the global domain namespace, 192 offering a degee of assurance that such names are globally unique-- 193 also often a valuable property. 195 However, there are also risks in this approach. For all the useful 196 properties that come with domain names, they can be tricky to use, 197 and interoperation can be subtle. There's no historically accepted 198 definition of "domain name," and in some cases people use more 199 restricted subsets of domain names such as host names with 200 idiosyncratic limitations of their own. There are security and 201 interoperability risks in comparison of such identifiers (see RFC 202 6943). They allow people to think of domain name labels as "words" 203 and other natural language analogs, but don't behave as people expect 204 in such contexts. 206 The situation is complicated by the fact that many applications have 207 their own resolution engines, and parse any input that looks like a 208 sequence of ASCII-string labels separated by dots as a "domain name," 209 with esolution to be requested of DNS by default. 211 Thus any choice to re-use DNS namespace, even without the DNS 212 protocol for resolving names, requires some decisions to be made 213 about namespace management and potential collisions or overlaps 214 between DNS namespace and others. 216 3. Terminology 218 (Note: very much under construction; should be consistent with the 219 cited RFCs to the degree possible.) 221 The primary references for this section will be RFC 7719, draft- 222 lewis-domain-names, and RFC 1034; the primary elements probably 223 include: 225 domain name (and domain namespace) 227 DNS name (and DNS namespace) 229 DNS global, distributed database as instantiation of DNS namespace 231 root zone 233 probably others.... 235 4. Some Questions 237 This section will offer some questions that should be considered in 238 analysis of a candidate naming scheme for a new or revised protocol. 240 For the protocol designer who thinks they want to use domain names, 241 RFC 6761 lists a set of questions to be answered for a special use 242 name, discussing how users, DNS name registries, and DNS operators 243 should treat such a namein order to maintain compatibility with the 244 public DNS. However, those questions largely leave undefined how to 245 tell if a special use domain name is really what's required, or how 246 to choose an appropriate string if it is, and don't touch at all on 247 the underlying fundamentals of choosing a naming scheme in the first 248 place. 250 In general, it's important to discuss separately: 252 * What behavior the protocol designer wants to occur around use of 253 the name 255 * What name format and composition rules the designer wants to use 257 Some questions follow, not yet in any particular order, about how the 258 protocol will use names; they start with the assumption that domain 259 names may be suitable, but may lead to the conclusion that domain 260 names won't solve the problem at hand: 262 1. Do you expect to use a non-DNS resolution protocol? What is it? 264 2. Are all domain names legal for the protocol? If not, how are 265 they limited? 267 3. Do you expect to have a limited or qualified (non-global) scope? 268 How are you specifying? 270 4. Do your names need to resolvable in the global public DNS? Do 271 they need to *not* be resolvable in the global public DNS? Do 272 you care about collisions with the global public DNS? (It's 273 quite generally the case that domain names that aren't intended 274 to be resolved in the global public DNS nonetheless result in DNS 275 queries, since the default context for a domain name in many, 276 many applications and generic resolution engines is in fact the 277 global DNS.) 279 5. What happens to your application/protocol if names are ambiguous 280 or resolvable with multiple protocols/scopes? Do you assume a 281 precedence or ordering of possible resolution methods? Do you 282 signal it explicitly? 284 6. How will names be created, allocated, de-allocated, and 285 destroyed? How long are they likely to persist? What 286 authorization are these activities likely to require? 288 7. Do names need to be authenticable? by what mechanism? 290 8. What are the security and privacy implications of name disclosure 291 to those on the intended resolution or routing paths, or leakage 292 to those outside? 294 There are also some questions that arise, once a protocol has taken 295 shape, in making a choice of what names are suitable. If the choice 296 is domain names, some analysis still needs to be done. Of the 297 extremely large set of possible domain names, the list of acceptable 298 ones may be quite long, or quite short, depending on the constraints 299 imposed by the protocol and the preferences of the protocol 300 designers. 302 Such questions include: 304 1. Will these names be human-visible? What humans will see them? 305 In normal operations, or only in geeky places like URLs or error 306 messages? 308 2. If human-visible, do they need to be mnemonic or otherwise 309 meaningful? 311 3. If names are to be human-visible, is internationalization a 312 concern? It's easy to pick a domain name string that seems to 313 represent a "word" in a particular language, or an acronym or 314 expression that's meaningful to the designers. However, 315 translation or otherwise extending the meaning of the string 316 beyond that initial human context is usually far more challenging 317 than it first appears. 319 4. Do you need (not just want) a single label? ("a TLD")? Why? 321 5. Framework: what are the necessary pieces? 323 Consideration of how to use names within a protocol leads quickly to 324 a set of interrelated structures that have to be defined 326 Again people tend to use DNS as a starting point, even though DNS as 327 a protocol has not always been rigorously specified. This has in 328 many ways been an advantage, as it's allowed for the DNS to be 329 extended in useful ways without being too restricted by structure. 330 However, this also causes confusion when considering naming in a new 331 protocol or environment: designers and developers who are used to 332 working with DNS as implemented in the Internet may think of the 333 system as a "blob," but it's probably useful to be able to separate: 335 name construction rules and structure of namespace; for DNS, this 336 includes character restrictions for a subset of domain names, 337 hierarchical traversal of a tree as the mechanics of resolution 339 server behavior, such as the different roles in name resolution of 340 resolvers and authoritative servers 342 wire protocol, including the specific interactions of query and 343 response, any confidentiality or validation requirements, and any 344 caching or required state maintenance; 346 name resolution context, which can be complex to manage because it 347 largely lives outside of the protocol; a DNS server doesn't know 348 whether its scope is global or local, because the effective scope 349 of a DNS name is basically "who can query for it" 351 Any or all of these attributes can be incompatible with the DNS 352 protocol, if the designer is attempting to modify it in part (mDNS 353 and .local names) or simply to re-use strings that look like domain 354 names in an entirely different way (Tor and .onion names). But doing 355 this carelessly can result in ambiguity of resolution, leakage of 356 names between resolution contexts, and other forms of pathlogical 357 behavior if it's not done carefully. 359 6. Some Guidelines 361 Decades of experience with naming in computer programming and network 362 protocols, and with the DNS and domain names in the internet, suggest 363 a few observations that may be relevant for those looking for a 364 suitable naming system and name resolution protocol for network 365 applications and protocols. 367 As a starting point, most of them pertain to the challenges of using 368 domain names and DNS conventions in internet protocols. Later 369 revisions of this document will add some observations on other ways 370 of approaching names. 372 6.1. Policy: The IETF and the Public DNS 374 It's increasingly common for protocol designers to denote a specific 375 name resolution context for a domain in the domain namespace by using 376 a special string, intended to be interpreted as a domain name and 377 then used as a switch into another name resolution context. This is 378 usually done by designating a string to be used as a "special use 379 name" in the rightmost label in a domain name (presentation format) 380 or the node closest to the root in a canonical FQDN. This solution 381 may or may not involve a delegation for the name in the global DNS, 382 or an expectation that the string will not be delegated. (See 383 questions above regarding the assumptions made in a new protocol 384 about potential collision between domain names in its context and 385 domain names in the public DNS or elsewhere.) 387 As described above, this practice has some benefits. It allows the 388 protocol to take advantage of a number of existing features of the 389 internet environment, including widespread availability of libraries 390 for parsing domain names and a reasonable degree of comfort that 391 names in a subtree of the domain namespace are globally unique. 393 It's commonly referred to as obtaining or reserving "a TLD". This 394 usage is deceptive, however, and this apparently simple solution 395 hides some risks. Problems with this approach include: 397 1. The IETF can't get you "a TLD"-- a single-label DNS name to be 398 added to the root zone of the global public DNS. That authority 399 was delegated to ICANN in RFC 2860. The IETF has no role in 400 ICANN's decisions about what to put into the global public DNS 401 root outside of the IETF's authority over the DNS protocol 402 standard. In recent years ICANN has dramatically expanded the 403 number of names actually delegated in the root zone of the DNS 404 namespace, and since the rules for doing so are determined in a 405 widely consultative public process, there are no guarantees about 406 how the root zone might change in the future. 408 2. If DNS resolution to a specific DNS name is required, this can be 409 accomplished at the direction of the IAB, which is the 410 administrator of record for the .arpa TLD and can get you a DNS 411 name under .arpa. (See RFC 3172 for more on this.) 413 3. The IAB can also commit that a domain name intended for 414 resolution outside of the DNS under .arpa will not collide with a 415 DNS name there. 417 4. It's also been proposed that a special use name be set aside 418 specifically as the root domain label for "domain names not to be 419 used in the DNS" so that protocol designers and implementers can 420 be reasonably sure that names used in that domain will not 421 collide with names in the global DNS namespace. (Reference alt- 422 tld draft.) 424 6.2. Operations: the Resolution Environment 426 An IETF standard cannot force a name to be resolved in a given 427 context, or not. That authority belongs to the operators of name 428 resolvers, for the DNS protocol and otherwise. In the case of DNS, 429 DNS operators determine what names can and can't be resolved with the 430 DNS protocol by users sending queries to their resolvers. In other 431 words, having the IETF document in an RFC that a particular name is 432 to be used for a particular purpose or protocol does not prevent 433 network operators from using the same string as a name for other 434 purposes or in other protocols. An RFC is accepted as guidance by 435 many DNS operators and implementers, however. 437 RFC 6761 establishes a registry of names that the IETF has designated 438 as "special use domain names." An entry in this registry does not 439 prevent local operators from configuring their environments as they 440 see fit, including allowing such names to leak into the global DNS 441 even if they're not supposed to (often considered a privacy risk). 442 An entry in this registry discourages others from attempting to re- 443 use the same domain names for other purposes or protocols, 444 particularly within the set of IETF protocols. 446 Concerns are frequently expressed that spurious queries into the DNS 447 are to be avoided in order to avoid leakage of potentially sensitive 448 information into the global internet, challenges in debugging 449 provided by giving up control of where such queries go, and extra 450 load on the DNS root name servers. The first two concerns are well 451 within the scope of operational concern. However, root name servers 452 are configured for abnormal environmental conditions, not normal 453 loads, and are probably not a big concern here. It's been the case 454 for decades that most of the load on the root name servers is already 455 spurious, in much the same way that load on email services is a 456 concern only after one has considered that the vast bulk of email is 457 spam. 459 Human-readable names may pose problems that random strings do not, 460 such as internationalization and intellectual property concerns. 461 "Human readable" is not a constraint to be added casually to the 462 choice of domain names for a protocol or application. 464 Global uniqueness is also a constraint that comes at a higher price 465 than may be obvious. The contents of the DNS root zone are evolving 466 on a relatively short time scale, and the number of protocols and 467 applications that assume their choices of strings will meet with 468 universal respect from potentially colliding other uses seemsto be 469 growing. 471 7. IANA Considerations 473 This document has no action for IANA. It might, in fact, help make 474 some possible future IANA actions unnecessary. 476 8. Security Considerations 478 This document poses no specific security considerations. However, a 479 poorly specified naming scheme at the base of a protocol poses 480 significant security risks and should be avoided. 482 9. Acknowledgements 484 This draft is the outcome of many conversations over many months, 485 including discussions in the DNSOP WG, the IAB, and the ICANN SSAC. 486 Particular thanks to Ed Lewis, Wendy Seltzer, Ralph Droms, Lyman 487 Chapin, Dave Thaler, Brian Trammell, David Conrad, Andrew Sullivan, 488 and everyone who's expressed exasperation to the author with respect 489 to the issues discussed here. 491 10. Informative References 493 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 494 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 495 . 497 [RFC1035] Mockapetris, P., "Domain names - implementation and 498 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 499 November 1987, . 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 507 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 508 2000, . 510 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 511 Understanding Concerning the Technical Work of the 512 Internet Assigned Numbers Authority", RFC 2860, 513 DOI 10.17487/RFC2860, June 2000, 514 . 516 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 517 Name Server Operational Requirements", RFC 2870, 518 DOI 10.17487/RFC2870, June 2000, 519 . 521 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 522 Encodings for Internationalized Domain Names", RFC 6055, 523 DOI 10.17487/RFC6055, February 2011, 524 . 526 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 527 RFC 6761, DOI 10.17487/RFC6761, February 2013, 528 . 530 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 531 DOI 10.17487/RFC6762, February 2013, 532 . 534 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 535 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 536 2013, . 538 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 539 "Architectural Considerations on Application Features in 540 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 541 . 543 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 544 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 545 2015, . 547 Author's Address 549 Suzanne Woolf 550 39 Dodge St. #317 551 Beverly, MA 01915 552 USA 554 Email: suzworldwide@gmail.com