idnits 2.17.1 draft-ietf-dnssd-mdns-dns-interop-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 (July 4, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-dnsop-dns-terminology-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSSD A. Sullivan 3 Internet-Draft Dyn 4 Intended status: Informational July 4, 2015 5 Expires: January 5, 2016 7 On Interoperation of Labels Between mDNS and DNS 8 draft-ietf-dnssd-mdns-dns-interop-01 10 Abstract 12 Despite its name, DNS-Based Service Discovery can use naming systems 13 other than the Domain Name System when looking for services. 14 Moreover, when it uses the DNS, DNS-Based Service Discovery uses the 15 full capability of DNS, rather than using a subset of available 16 octets. In order for DNS-SD to be used effectively in environments 17 where multiple different name systems and conventions for their 18 operation are in use, it is important to attend to differences in the 19 underlying technology and operational environment. This memo 20 presents an outline of the requirements for selection of labels for 21 conventional DNS and other resolution systems when they are expected 22 to interoperate in this manner. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 5, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions and terms used in this document . . . . . . . 3 60 2. Why there could be a problem at all . . . . . . . . . . . . . 4 61 3. Requirements for a profile for label interoperation . . . . . 5 62 4. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. The Portion of the Service 64 Instance Name . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. The Portion of the Service 66 Instance Name . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. The Portion of the Service Instance 68 Name . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. Informative References . . . . . . . . . . . . . . . . . . . 8 73 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 74 A.1. draft-ietf-dnssd-mdns-dns-interop-01 . . . . . . . . . . 10 75 A.2. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 10 76 A.3. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 10 77 A.4. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 10 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism 83 for discovering services using queries to the Domain Name System 84 (DNS, [RFC1034], [RFC1035]); and to any other system that uses domain 85 names, such as Multicast DNS (mDNS, [RFC6762]). Conventional use of 86 the DNS generally follows the host name rules [RFC0952] for labels -- 87 the so-called LDH rule. That convention is the reason behind the 88 development of Internationalized Domain Names for Applications 89 (IDNA2008, [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894], 90 [RFC5895]). It is worth noting that the LDH rule is a convention, 91 and not a rule of the DNS; this is made entirely plain by [RFC2181], 92 section 11. Nevertheless, there is a widespread belief that in many 93 circumstances domain names cannot be used in the DNS unless they 94 cleave to the LDH rule. 96 At the same time, mDNS requires that labels be encoded in UTF-8, and 97 permits a range of characters in labels that are not permitted by 98 IDNA2008 or the LDH rule. For example, mDNS encourages the use of 99 spaces and punctuation in mDNS names (see [RFC6763], section 4.1.3). 100 It does not restrict which Unicode code points may be used in those 101 labels, so long as the code points are UTF-8 in Net-Unicode [RFC5198] 102 format. 104 Users of applications are, of course, frequently unconcerned with 105 (not to say oblivious to) the name-resolution system(s) in service at 106 any given moment, and are inclined simply to use the same domain 107 names in different contexts. As a result, the same domain name might 108 be tried using different name resolution technologies. If DNS-SD is 109 to be used in an environment where multiple resolution systems (such 110 as mDNS and DNS) are to be queried for services, then some parts of 111 the domain names to be queried will need to be compatible with the 112 rules and conventions for all the relevant technologies. 114 One approach to interoperability under these circumstances is to use 115 a single operational convention (a "profile") for domain names under 116 the different naming systems. This memo assumes such a use profile, 117 and attempts to outline what is necessary to make it work without 118 specifying any particular technology. It does assume, however, that 119 the global DNS is eventually likely to be implicated. Given the 120 general tendency of all resolution eventually to fall through to the 121 DNS, that assumption does not seem controversial. 123 It is worth noting that users of DNS-SD do not use the service 124 discovery names in the same way that users of other domain names 125 might. Domain names often might as easily be entered as direct user 126 input as by any other method. But the service discovery context 127 generally assumes users are picking a service from a list. As a 128 result, the sorts of application considerations that are appropriate 129 to the general-purpose DNS name, and that resulted in the A-label/ 130 U-label split (see below) in IDNA2008, are not entirely the right 131 approach for DNS-SD. 133 1.1. Conventions and terms used in this document 135 Wherever appropriate, this memo uses the terminology defined in 136 Section 2 of [RFC5890]. In particular, the reader is assumed to be 137 familiar with the terms "U-label", "LDH label", and "A-label" from 138 that document. Similarly, the reader is assumed to be familiar with 139 the U+NNNN notation for Unicode code points used in [RFC5890] and 140 other documents dealing with Unicode code points. In the interests 141 of brevity and consistency, the definitions are not repeated here. 143 Sometimes this memo refers to names in the DNS as though the LDH rule 144 and IDNA2008 are strict requirements. They are not. DNS labels are, 145 in principle, just collections of octets, and therefore in principle 146 the LDH rule is not a constraint. In practice, applications 147 sometimes intercept labels that do not conform to the LDH rule and 148 apply IDNA and other transformations. 150 The DNS, perhaps unfortunately, has produced its own jargon. 151 Unfamiliar DNS-related terms in this memo should be found in 152 [I-D.ietf-dnsop-dns-terminology]. 154 The term "owner name" (common to the DNS vernacular; see above) is 155 used here to apply not just to the domain names to be looked up in 156 the DNS, but to any name that might be looked up either in the DNS or 157 using other technologies. It therefore includes names that might not 158 actually exist anywhere. In addition, what follows depends on the 159 idea that not every domain name may be looked up in the DNS. For 160 instance, names ending in "local." (in the presentation format) are 161 not ordinarily looked up in the DNS, but instead by querying mDNS. 163 DNS-SD specifies three portions of the owner name for a DNS-SD 164 resource record. These are the portion, the 165 portion, and the . The owner name made of these three parts 166 is called the Service Instance Name. It is worth observing that a 167 portion may be more than one label long. See [RFC6763], section 4.1. 168 Further discussion of the parts is found in Section 4. 170 Throughout this memo, mDNS is used liberally as the alternative 171 resolution mechanism to DNS. This is for convenience rather than 172 rigour: any alternative name resolution to DNS could present the same 173 friction with the prevailing operational conventions of the global 174 DNS. It so happens that mDNS is the overwhelmingly successful 175 alternative as of this writing, so it is used in order to make the 176 issues plainer to the reader. Other alternative resolution 177 mechanisms may in general be read wherever mDNS appears in the text, 178 except where details of the mDNS specification appear. 180 2. Why there could be a problem at all 182 One might reasonably wonder why there is a problem to be solved at 183 all. After all, DNS labels permit any octet whatsoever, and anything 184 that can be useful with DNS-SD cannot use any names that are outside 185 the protocol strictures of the DNS. 187 The reason for the trouble is twofold. First, and least troublesome, 188 is the possibility of resolvers that are attempting to offer IDNA 189 service system-wide. Given the design of IDNA2008, it is reasonable 190 to suppose that on some systems high-level name resolution libraries 191 will perform the U-label/A-label transformation automatically, saving 192 applications from these details. If this were the main problem, 193 however, it would presumably be self-correcting; for the right answer 194 would be, "Don't use those libraries for DNS-SD," and DNS-SD would 195 not work reliably in cases where such libraries were in use. This 196 would be unfortunate; but given that DNS-SD in Internet contexts is 197 as of this writing not in ubiquitous use, it should not represent a 198 fatal issue. 200 The greater problem is that the "infrastructure" types of DNS service 201 -- the root zone, the top-level domains, and so on -- have embraced 202 IDNA and refuse registration of raw UTF-8 into their zones. As of 203 this writing there is (perhaps unfortunately) no reliable way to 204 discover where these sorts of DNS services end. Nevertheless, some 205 client programs (notably web browsers) have adopted a number of 206 different policies about how domain names will be looked up and 207 presented to users given the policies of the relevant DNS zone 208 operators. None of these policies permit raw UTF-8. Since it is 209 anticipated that DNS-SD when used with the DNS will be inside domain 210 names beneath those kinds of "infrastructure" domains, the 211 implications of IDNA2008 must be a consideration. 213 For further exploration of issues relating to encoding of domain 214 names generally, the reader should consult [RFC6055]. 216 3. Requirements for a profile for label interoperation 218 Any interoperability between DNS (including prevailing operational 219 conventions and other resolution technologies will require 220 interoperability across the portions of a DNS-SD Service Instance 221 Name that are implicated in regular DNS lookups. Only some portions 222 are implicated. In any case, if a given portion is implicated, the 223 profile will need to apply to all labels in that portion. 225 In addition, because DNS-SD Service Instance Names can be used in a 226 domain name slot, care must be taken by DNS-SD-aware resolvers to 227 handle the different portions as outlined here, so that DNS-SD 228 portions that do not use IDNA2008 will not be treated as U-labels and 229 will not accidentally undergo IDNA processing. 231 Because the profile will need to apply to names that might need to 232 interoperate with names in the public DNS, and because other 233 resolution mechanisms (such as mDNS) could permit labels that IDNA 234 does not, the profile might reduce the labels that could be used with 235 those other resolution mechanisms. One consequence of this is that 236 some recommendations from [RFC6763] will not really be possible to 237 implement using names subject to the profile. In particular, 238 [RFC6763], section 4.1.3 recommends that labels always be stored and 239 communicated as UTF-8, even in the DNS. Because of the way the 240 public DNS is currently operated (see Section 2), the advice to store 241 and transmit labels as UTF-8 in the DNS is likely either to encounter 242 problems or result in unnecessary traffic to the public DNS (or 243 both). In particular, the part of a Service Instance Name 244 is unlikely to be found in its UTF-8 form in the public DNS tree for 245 zones that are using IDNA2008. By contrast, for example, mDNS 246 normally uses UTF-8. 248 U-labels cannot contain upper case letters. That restriction extends 249 to ASCII-range upper case letters that work fine in LDH-labels. It 250 may be confusing that the character "A" works in the DNS when none of 251 the characters in the label has a diacritic, but does not work when 252 there is such a diacritic in the label. Labels in mDNS names (or 253 other resolution technologies) may contain upper case characters, so 254 the profile will need either to restrict the use of upper case or 255 come up with a reliable and predictable (to users) convention for 256 case folding even in the presence of diacritics. 258 4. DNS-SD portions 260 Service Instance Names are made up of three portions. 262 4.1. The Portion of the Service Instance Name 264 [RFC6763] is clear that the portion of the Service 265 Instance Name is intended for presentation to users, and therefore 266 virtually any character is permitted in it. There are two ways that 267 a profile might address this portion. 269 The first way would be to treat this portion as likely to be 270 intercepted by system-wide IDNA-aware resolvers, or likely subject to 271 strict IDNA conformance requirements for publication in the relevant 272 zone. In this case, the portion would need to be made subject to the 273 profile, thereby curtailing what characters may appear in this 274 portion. This approach permits DNS-SD to use any standard system 275 resolver but presents inconsistencies with the DNS-SD specification 276 and with DNS-SD that is exclusively mDNS-based. Therefore, this 277 strategy is rejected. 279 Instead, DNS-SD implementations can intercept the portion 280 of a Service Instance Name and ensure that those labels are never 281 handed to IDNA-aware resolvers that might attempt to convert these 282 labels into A-labels. Under this approach, the DNS-SD 283 portion works as it always does, but at the cost of using special 284 resolution code built into the DNS-SD system. A practical 285 consequence of this is that zone operators need to be prepared not to 286 apply the LDH rule to all labels, and may need to make special 287 concessions to ensure that the portion can contain spaces, 288 upper and lower case, and any UTF-8 code point; or else to prepare a 289 user interface to handle the exceptions that would otherwise be 290 generated. Automatic conversion to A-labels is not acceptable. 292 4.2. The Portion of the Service Instance Name 294 DNS-SD includes a component in the Service Instance Name. 295 This component is not really user-facing data, but is instead control 296 data embedded in the Service Instance Name. This component includes 297 so-called "underscore labels", which are labels prepended with U+005F 298 (_). The underscore label convention was established by DNS SRV 299 ([RFC2782]) for identifying metadata inside DNS names. A system-wide 300 resolver (or DNS middlebox) that cannot handle underscore labels will 301 not work with DNS-SD at all, so it is safe to suppose that such 302 resolvers will not attempt to do special processing on these labels. 303 Therefore, the portion of the Service Instance Name will 304 not be subject to the profile. By the same token, it should be noted 305 that underscore labels are never subject to IDNA processing (they're 306 formally incompatible), and therefore concerns about IDNA are 307 irrelevant for these labels. 309 4.3. The Portion of the Service Instance Name 311 The portion of the Service Instance Name forms an integral 312 part of the owner name submitted for DNS resolution. A system-wide 313 resolver that is IDNA2008-aware is likely to interpret labels with 314 UTF-8 in the owner name as candidates for IDNA2008 processing. More 315 important, operators of internationalized domain names will 316 frequently publish such names in the DNS as A-labels; certainly, the 317 top-most labels will always be A-labels. Therefore, these labels 318 will need to be subject to the profile. DNS-SD implementations ought 319 to identify the portion of the Service Instance Name and 320 treat it subject to IDNA2008 in case the domain is to be queried from 321 the global DNS. In the event that the portion of the 322 Service Instance Name fails to resolve, it is acceptable to 323 substitute labels with plain UTF-8, starting at the lowest label in 324 the DNS tree and working toward the root. This approach differs from 325 the rule for resolution published in [RFC6763], because it privileges 326 IDNA2008-compatible labels over UTF-8 labels. 328 One might argue against this restriction on either of two grounds: 330 1. It is possible the names may be in the DNS in UTF-8, and RFC 6763 331 already specifies a fallback strategy of progressively attempting 332 first the UTF-8 label lookup (it might not be a U-label) and then 333 if possible the A-label lookup. 335 2. Zone administrators that wish to support DNS-SD can publish a 336 UTF-8 version of the zone along side the A-label version of the 337 zone. 339 The first of these is rejected because it represents a potentially 340 significant increase in DNS lookup traffic for no value. It is 341 possible for a DNS-SD application to identify the portion of 342 the Service Instance Name. The standard way to publish IDNs on the 343 Internet uses IDNA. Therefore, additional lookups should not be 344 encouraged. When [RFC6763] was published, the bulk of IDNs were 345 lower in the tree. Now that there are internationalized labels in 346 the root zone, it is desirable to minimize queries to the Internet 347 infrastructure if they are sure to be answered in the negative. 349 The second reason depends on the idea that it is possible to maintain 350 two names in sync with one another. This is not strictly speaking 351 true, although in this case the domain operator could simply create a 352 DNAME record [RFC6672] from the UTF-8 name to the IDNA2008 zone. 353 This still, however, relies on being able to reach the (UTF-8) name 354 in question, and it is unlikely that the UTF-8 version of the zone 355 will be delegated from anywhere. Moreover, in many organizations the 356 support for DNS-SD and the support for domain name delegations are 357 not performed by the same department, and depending on a co- 358 ordination between the two will make the system more fragile, or 359 slower, or both. 361 5. Acknowledgements 363 The author gratefully acknowledges the insights of Stuart Cheshire, 364 Kerry Lynn, and Dave Thaler. Kerry Lynn deserves special gratitude 365 for his energy and persistence in pressing unanswered questions. 367 6. IANA Considerations 369 This memo makes no requests of IANA. 371 7. Security Considerations 373 This memo presents some requirements for future development, but does 374 not specify anything. Therefore, it has no implications for 375 security. 377 8. Informative References 379 [I-D.ietf-dnsop-dns-terminology] 380 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 381 Terminology", draft-ietf-dnsop-dns-terminology-03 (work in 382 progress), June 2015. 384 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 385 host table specification", RFC 952, October 1985. 387 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 388 STD 13, RFC 1034, November 1987. 390 [RFC1035] Mockapetris, P., "Domain names - implementation and 391 specification", STD 13, RFC 1035, November 1987. 393 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 394 Specification", RFC 2181, July 1997. 396 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 397 specifying the location of services (DNS SRV)", RFC 2782, 398 February 2000. 400 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 401 Interchange", RFC 5198, March 2008. 403 [RFC5890] Klensin, J., "Internationalized Domain Names for 404 Applications (IDNA): Definitions and Document Framework", 405 RFC 5890, August 2010. 407 [RFC5891] Klensin, J., "Internationalized Domain Names in 408 Applications (IDNA): Protocol", RFC 5891, August 2010. 410 [RFC5892] Faltstrom, P., "The Unicode Code Points and 411 Internationalized Domain Names for Applications (IDNA)", 412 RFC 5892, August 2010. 414 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 415 Internationalized Domain Names for Applications (IDNA)", 416 RFC 5893, August 2010. 418 [RFC5894] Klensin, J., "Internationalized Domain Names for 419 Applications (IDNA): Background, Explanation, and 420 Rationale", RFC 5894, August 2010. 422 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 423 Internationalized Domain Names in Applications (IDNA) 424 2008", RFC 5895, September 2010. 426 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 427 Encodings for Internationalized Domain Names", RFC 6055, 428 February 2011. 430 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 431 DNS", RFC 6672, June 2012. 433 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 434 February 2013. 436 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 437 Discovery", RFC 6763, February 2013. 439 Appendix A. Change History 441 A.1. draft-ietf-dnssd-mdns-dns-interop-01 443 Alter text to make clear that the main issue is the way the public 444 DNS is currently administered, not system resolvers. I suppose this 445 should have been clear before, but I didn't do that. Many thanks to 446 Kerry Lynn for penetrating questions that illuminated what I'd left 447 out. 449 A.2. draft-ietf-dnssd-mdns-dns-interop-00 451 1st WG version 453 Add text to make clear that fallback from A-label lookup to UTF-8 454 label lookup ok, per WG comments at IETF 91 456 A.3. draft-sullivan-dnssd-mdns-dns-interop-01 458 o Decided which portions would be affected 460 o Explained the difference in user interfaces between DNS-SD and 461 usual DNS operation 463 o Provided background on why the Domain portion should be treated 464 differently 466 A.4. draft-sullivan-dnssd-mdns-dns-interop-00 468 Initial version. 470 Author's Address 472 Andrew Sullivan 473 Dyn 474 150 Dow St. 475 Manchester, NH 03101 476 U.S.A. 478 Email: asullivan@dyn.com