idnits 2.17.1 draft-ietf-dnssd-mdns-dns-interop-00.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 (March 4, 2015) is 3341 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 March 4, 2015 5 Expires: September 5, 2015 7 On Interoperation of Labels Between mDNS and DNS 8 draft-ietf-dnssd-mdns-dns-interop-00 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 Different name systems use different conventions for the characters 15 allowed in any name. In order for DNS-SD to be used effectively in 16 environments where multiple different name systems are in use, it is 17 important to attend to differences in the underlying technology. 18 This memo presents an outline of the requirements for selection of 19 labels for mDNS and DNS when they are expected to interoperate in 20 this manner. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 5, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions and terms used in this document . . . . . . . 3 58 2. Requirements for a profile for label interoperation . . . . . 3 59 3. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. The Portion of the Service Instance Name . 4 61 3.2. The Portion of the Service Instance Name . 5 62 3.3. The Portion of the Service Instance Name . . 5 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. Informative References . . . . . . . . . . . . . . . . . . . 7 67 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 8 68 A.1. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 8 69 A.2. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 8 70 A.3. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism 76 for discovering services using queries both to the Domain Name System 77 (DNS, [RFC1034], [RFC1035]) and to Multicast DNS (mDNS, [RFC6762]). 78 Conventional use of the DNS generally follows the host name rules 79 [RFC0952] for labels -- the so-called LDH rule. That convention is 80 the reason behind the development of Internationalized Domain Names 81 for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892], 82 [RFC5893], [RFC5894], [RFC5895]). It is worth noting that the LDH 83 rule is a convention, and not a strict rule of the DNS. It is 84 assumed to be true widely enough, however, that in many circumstances 85 names cannot be used unless they cleave to the LDH rule. 87 At the same time, mDNS requires that labels be encoded in UTF-8, and 88 permits a range of characters in labels that are not permitted by 89 IDNA2008 or the LDH rule. For example, mDNS encourages the use of 90 spaces and punctuation in mDNS names (see [RFC6763], section 4.1.3). 91 It does not restrict which Unicode code points may be used in those 92 labels, so long as the code points are UTF-8 in Net-Unicode [RFC5198] 93 format. 95 Users of applications are, of course, frequently unconcerned with 96 (not to say oblivious to) the name-resolution system(s) in service at 97 any given moment, and are inclined simply to use the same names in 98 different contexts. As a result, the same string might be tried as a 99 name using different name resolution technologies. If DNS-SD is to 100 be used in an environment where both mDNS and DNS are to be queried 101 for services, then some parts of the names to be queried will need to 102 be compatible with the rules and conventions for both DNS and mDNS. 104 One approach to interoperability under these circumstances is to use 105 a single operational convention for names under the different naming 106 systems. This memo assumes such a use profile, and outlines what is 107 necessary to make it work. 109 It is worth noting that users of DNS-SD do not use the service 110 discovery names in the same way that users of other domain names 111 might. Most domain names might as easily be typed in as direct user 112 input as any other method. But the service discovery context 113 generally assumes users are picking a service from a list. As a 114 result, the sorts of application considerations that are appropriate 115 to the general-purpose DNS name, and that resulted in the A-label/ 116 U-label (see below) in IDNA2008, are not the right approach for DNS- 117 SD. 119 1.1. Conventions and terms used in this document 121 Wherever appropriate, this memo uses the terminology defined in 122 Section 2 of [RFC5890]. In particular, the reader is assumed to be 123 familiar with the terms "U-label", "LDH label", and "A-label" from 124 that document. Similarly, the reader is assumed to be familiar with 125 the U+NNNN notation for Unicode code points used in [RFC5890] and 126 other documents dealing with Unicode code points. In the interests 127 of brevity and consistency, the definitions are not repeated here. 129 This memo refers to names in the DNS as though the LDH rule and 130 IDNA2008 are strict requirements. They are not. DNS labels are, in 131 principle, just collections of octets, and therefore in principle the 132 LDH rule is not a constraint. In practice, applications often 133 intercept labels that do not conform to the LDH rule and apply IDNA 134 and other transformations. 136 The term "owner name" (common to the DNS vernacular) is used here to 137 apply not just to the names to be looked up in the DNS, but to any 138 name that might be looked up either in the DNS or using mDNS. 140 2. Requirements for a profile for label interoperation 142 Any interoperability between mDNS and DNS will require 143 interoperability across some of the portions of a DNS-SD Service 144 Instance Name (see Section 3) that are implicated in regular mDNS and 145 DNS lookups. Only some portions are implicated. In any case, if a 146 given portion is implicated, the profile will need to apply to all 147 labels in that portion. 149 In addition, because DNS-SD Service Instance Names can be used in a 150 domain name slot, care must be taken by DNS-SD resolvers to undertake 151 the special processing outlined here, so that DNS-SD portions that do 152 not use IDNA2008 will not be treated as U-labels and will not undergo 153 IDNA processing. 155 Because the profile will need to apply to names that might need to 156 interoperate with names in the DNS, and because mDNS permits labels 157 that IDNA does not, the profile might reduce the labels that could be 158 used with mDNS. Consequently, some recommendations from [RFC6763] 159 will not really be possible to implement using names subject to the 160 profile. In particular, [RFC6763], section 4.1.3 recommends that 161 labels always be stored and communicated as UTF-8, even in the DNS. 162 Because IDNA2008 libraries will treat any Unicode-encoded labels as 163 candidate U-labels and attempt to perform resolution in A-label form, 164 the advice to store and transmit labels as UTF-8 in the DNS is likely 165 to encounter problems. In particular, the part of a Service 166 Instance Name is unlikely to be found in its UTF-8 form in the public 167 DNS tree for zones that are using IDNA2008. By contrast, mDNS 168 normally uses UTF-8. 170 U-labels cannot contain upper case letters. That restriction extends 171 to ASCII-range upper case letters that work fine in LDH-labels. It 172 may be confusing that the character "A" works in the DNS when none of 173 the characters in the label has a diacritic, but does not work when 174 there is such a diacritic in the label. Labels in mDNS names may 175 contain upper case characters, so the profile will need either to 176 restrict the use of upper case or come up with a reliable and 177 predictable (to users) convention for case folding even in the 178 presence of diacritics. 180 3. DNS-SD portions 182 DNS-SD specifies three portions of the owner name for a DNS-SD 183 resource record. These are the portion, the 184 portion, and the . The owner name made of these three parts 185 is called the Service Instance Name. It is worth observing that a 186 portion may be more than one label long. See [RFC6763], section 4.1. 188 3.1. The Portion of the Service Instance Name 190 [RFC6763] is clear that the portion of the Service 191 Instance Name is intended for presentation to users, and therefore 192 virtually any character is permitted in it. There are two ways that 193 a profile might address this portion. 195 The first way would be to treat this portion as likely to be 196 intercepted by system-wide IDNA-aware resolvers. In this case, the 197 portion needs to be made subject to the profile, thereby curtailing 198 what characters may appear in this portion. This approach permits 199 DNS-SD to use any standard system resolver but presents 200 inconsistencies with the DNS-SD specification and with DNS-SD that is 201 exclusively mDNS-based. Therefore, this strategy is rejected. 203 Instead, DNS-SD implementations can intercept the portion 204 of a Service Instance Name and ensure that those labels are never 205 handed to IDNA-aware resolvers that might attempt to convert these 206 labels into A-labels. Under this approach, the DNS-SD 207 portion works as it always does, but at the cost of using special 208 resolution code built into the DNS-SD system. 210 3.2. The Portion of the Service Instance Name 212 DNS-SD includes a component in the Service Instance Name. 213 This component is not really user-facing data, but is instead control 214 data embedded in the Service Instance Name. This component includes 215 so-called "underscore labels", which are labels prepended with U+005F 216 (_). The underscore label convention was established by DNS SRV 217 ([RFC2782]) for identifying metadata inside DNS names. A system-wide 218 resolver (or DNS middlebox) that cannot handle underscore labels will 219 not work with DNS-SD at all, so it is safe to suppose that such 220 resolvers will not attempt to do special processing on these labels. 221 Therefore, the portion of the Service Instance Name will 222 not be subject to the profile. 224 3.3. The Portion of the Service Instance Name 226 The portion of the Service Instance Name forms an integral 227 part of the QNAME submitted for DNS resolution, and a system-wide 228 resolver that is IDNA2008-aware is likely to interpret labels with 229 UTF-8 in the QNAME as candidates for IDNA2008 processing. Operators 230 of Internationalized Domain Names will frequently publish them in the 231 DNS as A-labels. Therefore, these labels will need to be subject to 232 the profile. DNS-SD implementations ought to identify the 233 portion of the Service Instance Name and treat it subject to IDNA2008 234 in case the domain is to be queried from the global DNS. In the 235 event that the portion of the Service Instance Name fails to 236 resolve, it is acceptable to substitute labels with plain UTF-8, 237 starting at the lowest label in the DNS tree and working toward the 238 root. This approach different to the rule for resolution published 239 in [RFC6763], because it privileges IDNA2008-compatible labels over 240 UTF-8 labels. 242 One might argue against this restriction on either of two grounds: 244 1. It is possible the names may be in the DNS in UTF-8, and RFC 6763 245 already specifies a fallback strategy of progressively attempting 246 first the U-label lookup and then the A-label lookup. 248 2. Zone administrators that wish to support DNS-SD can publish a 249 UTF-8 version of the zone along side the A-label version of the 250 zone. 252 The first of these is rejected because it represents a potentially 253 significant increase in DNS lookup traffic for no value. It is 254 possible for a DNS-SD application to identify the portion of 255 the Service Instance Name. The standard way to publish IDNs on the 256 Internet uses IDNA. Therefore, additional lookups should not be 257 encouraged. When [RFC6763] was published, the bulk of IDNs were 258 lower in the tree, but now that there are internationalized labels in 259 the root zone, it seems reasonable to use only the single lookup 260 strategy. 262 The second reason depends on the idea that it is possible to maintain 263 two names in sync with one another. This is not strictly speaking 264 true, although in this case the domain operator could simply create a 265 DNAME record [RFC6672] from the UTF-8 name to the IDNA2008 zone. 266 This still, however, relies on being able to reach the (UTF-8) name 267 in question, and it is unlikely that the UTF-8 version of the zone 268 will be delegated from anywhere. Moreover, in many organizations the 269 support for DNS-SD and the support for domain name delegations are 270 not performed by the same department, and depending on a co- 271 ordination between the two will make the system more fragile or 272 slower or both. 274 4. Acknowledgements 276 The author gratefully acknowledges the insights of Stuart Cheshire, 277 Kerry Lynn, and Dave Thaler. 279 5. IANA Considerations 281 This memo makes no requests of IANA. 283 6. Security Considerations 285 This memo presents some requirements for future development, but does 286 not specify anything. Therefore, it has no implications for 287 security. 289 7. Informative References 291 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 292 host table specification", RFC 952, October 1985. 294 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 295 STD 13, RFC 1034, November 1987. 297 [RFC1035] Mockapetris, P., "Domain names - implementation and 298 specification", STD 13, RFC 1035, November 1987. 300 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 301 specifying the location of services (DNS SRV)", RFC 2782, 302 February 2000. 304 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 305 Interchange", RFC 5198, March 2008. 307 [RFC5890] Klensin, J., "Internationalized Domain Names for 308 Applications (IDNA): Definitions and Document Framework", 309 RFC 5890, August 2010. 311 [RFC5891] Klensin, J., "Internationalized Domain Names in 312 Applications (IDNA): Protocol", RFC 5891, August 2010. 314 [RFC5892] Faltstrom, P., "The Unicode Code Points and 315 Internationalized Domain Names for Applications (IDNA)", 316 RFC 5892, August 2010. 318 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 319 Internationalized Domain Names for Applications (IDNA)", 320 RFC 5893, August 2010. 322 [RFC5894] Klensin, J., "Internationalized Domain Names for 323 Applications (IDNA): Background, Explanation, and 324 Rationale", RFC 5894, August 2010. 326 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 327 Internationalized Domain Names in Applications (IDNA) 328 2008", RFC 5895, September 2010. 330 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 331 DNS", RFC 6672, June 2012. 333 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 334 February 2013. 336 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 337 Discovery", RFC 6763, February 2013. 339 Appendix A. Change History 341 A.1. draft-ietf-dnssd-mdns-dns-interop-00 343 1st WG version 345 Add text to make clear that fallback from A-label lookup to UTF-8 346 label lookup ok, per WG comments at IETF 91 348 A.2. draft-sullivan-dnssd-mdns-dns-interop-01 350 o Decided which portions would be affected 352 o Explained the difference in user interfaces between DNS-SD and 353 usual DNS operation 355 o Provided background on why the Domain portion should be treated 356 differently 358 A.3. draft-sullivan-dnssd-mdns-dns-interop-00 360 Initial version. 362 Author's Address 364 Andrew Sullivan 365 Dyn 366 150 Dow St. 367 Manchester, NH 03101 368 U.S.A. 370 Email: asullivan@dyn.com