diff options
Diffstat (limited to 'doc/rfc/rfc8222.txt')
| -rw-r--r-- | doc/rfc/rfc8222.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc8222.txt b/doc/rfc/rfc8222.txt new file mode 100644 index 0000000..2926baf --- /dev/null +++ b/doc/rfc/rfc8222.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Sullivan +Request for Comments: 8222 Oracle +Category: Informational September 2017 +ISSN: 2070-1721 + + + Selecting Labels for Use with Conventional DNS and + Other Resolution Systems in DNS-Based Service Discovery + +Abstract + + Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming + systems other than DNS when looking for services. Moreover, when it + uses DNS, DNS-SD uses the full capability of DNS, rather than using a + subset of available octets. This is of particular relevance where + some environments use DNS labels that conform to Internationalized + Domain Names for Applications (IDNA), and other environments use + labels containing Unicode characters (such as containing octets + corresponding to characters encoded as UTF-8). In order for DNS-SD + to be used effectively in environments where multiple different name + systems and conventions for their operation are in use, it is + important to attend to differences in the underlying technology and + operational environment. This memo presents an outline of the + requirements for the selection of labels for conventional DNS and + other resolution systems when they are expected to interoperate in + this manner. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8222. + + + + + + + + + +Sullivan Informational [Page 1] + +RFC 8222 DNS-SD Label Selection September 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Conventions and Terms Used in This Document . . . . . . . 3 + 2. Why There Could Be a Problem at All . . . . . . . . . . . . . 4 + 3. Requirements for a Profile for Label Interoperation . . . . . 5 + 4. DNS-SD Portions . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. The <Instance> Portion of the Service Instance Name . . . 6 + 4.2. The <Service> Portion of the Service + Instance Name . . . . . . . . . . . . . . . . . . . . . . 7 + 4.3. The <Domain> Portion of the Service Instance Name . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. Informative References . . . . . . . . . . . . . . . . . . . 9 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 + +1. Introduction + + DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism + for discovering services using queries to DNS ([RFC1034] and + [RFC1035]) and to any other system that uses domain names, such as + Multicast DNS (mDNS, [RFC6762]). Many applications that use DNS + follow "Internet hostname" syntax [RFC952] for labels -- the + so-called LDH (letters, digits, and hyphen) rule. That convention is + the reason behind the development of Internationalized Domain Names + for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892], + [RFC5893], [RFC5894], and [RFC5895]). It is worth noting that the + LDH rule is a convention, and not a rule of the DNS; this is made + entirely plain by Section 11 of [RFC2181], and discussed further in + Section 3 of [RFC6055]. Nevertheless, there is a widespread belief + that in many circumstances domain names cannot be used in the DNS + unless they follow the LDH rule. + + + +Sullivan Informational [Page 2] + +RFC 8222 DNS-SD Label Selection September 2017 + + + At the same time, mDNS requires that labels be encoded in UTF-8 and + permits a range of characters in labels that are not permitted by + IDNA2008 or the LDH rule. For example, mDNS encourages the use of + spaces and punctuation in mDNS names (see Section 4.2.3 of + [RFC6763]). It does not restrict which Unicode code points may be + used in those labels, so long as the code points are UTF-8 in + Net-Unicode [RFC5198] format. + + Users and developers of applications are, of course, frequently + unconcerned with (or oblivious to) the name-resolution system(s) in + service at any given moment; they are inclined simply to use the same + domain names in different contexts. As a result, names entered into + the same domain name slot might be resolved using different name + resolution technologies. If a given name will not work across the + various environments, then user expectations are likely to be best + satisfied when at least some parts of the domain names to be queried + are compatible with the rules and conventions for all the relevant + technologies. Given the uses of DNS-SD, a choice for such + compatibility likely lies with the application designer or service + operator. + + One approach to interoperability under these circumstances is to use + a single operational convention (a "profile") for domain names under + the different naming systems. This memo assumes such a use profile, + and attempts to outline what is necessary to make it work without + specifying any particular technology. It does assume, however, that + the global DNS is likely to be implicated. Given the general + tendency of all resolution eventually to fall through to the DNS, + that assumption does not seem controversial. + + It is worth noting that users of DNS-SD do not use the service + discovery names in the same way that users of other domain names + might. In many cases, domain names can be entered as direct user + input. But the service discovery context generally assumes that + users are picking a service from a list. As a result, the sorts of + application considerations that are appropriate to the general- + purpose DNS name, and that resulted in the A-label/U-label split (see + below) in IDNA2008, are not entirely the right approach for DNS-SD. + +1.1. Conventions and Terms Used in This Document + + Wherever appropriate, this memo uses the terminology defined in + Section 2 of [RFC5890]. In particular, the reader is assumed to be + familiar with the terms "U-label", "LDH label", and "A-label" from + that document. Similarly, the reader is assumed to be familiar with + the U+NNNN notation for Unicode code points used in [RFC5890] and + other documents dealing with Unicode code points. In the interests + of brevity and consistency, the definitions are not repeated here. + + + +Sullivan Informational [Page 3] + +RFC 8222 DNS-SD Label Selection September 2017 + + + Sometimes this memo refers to names in the DNS as though the LDH rule + and IDNA2008 are strict requirements. They are not. DNS labels are, + in principle, just collections of octets; therefore, in principle, + the LDH rule is not a constraint. In practice, applications + sometimes intercept labels that do not conform to the LDH rule and + apply IDNA and other transformations. + + DNS, perhaps unfortunately, has produced its own jargon. Unfamiliar + DNS-related terms in this memo should be found in [RFC7719]. + + The term "owner name" (common to the DNS vernacular; see above) is + used here to apply not just to the domain names to be looked up in + the DNS, but to any name that might be looked up either in the DNS or + using another technology. Therefore, it includes names that might + not actually exist anywhere. In addition, what follows depends on + the idea that not every domain name will be looked up in the DNS. + For instance, names ending in "local." (in the presentation format) + are not ordinarily looked up using DNS, but instead looked up using + mDNS. + + DNS-SD specifies three portions of the owner name for a DNS-SD + resource record. These are the <Instance> portion, the <Service> + portion, and the <Domain> portion. The owner name made of these + three parts is called the "Service Instance Name". It is worth + observing that a portion may be more than one label long. See + Section 4.1 of [RFC6763]. Further discussion of the parts is found + in Section 4. + + Throughout this memo, mDNS is used liberally as the alternative + resolution mechanism to DNS. This is for convenience rather than + rigor: any alternative name resolution to DNS could present the same + friction with the prevailing operational conventions of the global + DNS. It so happens that mDNS is the overwhelmingly successful + alternative as of this writing, so it is used in order to make the + issues plainer to the reader. Other alternative resolution + mechanisms may generally be read wherever mDNS appears in the text, + except where details of the mDNS specification appear. + +2. Why There Could Be a Problem at All + + One might reasonably wonder why there is a problem to be solved at + all. After all, DNS labels permit any octet whatsoever, and anything + that can be useful with DNS-SD cannot use any names that are outside + the protocol strictures of the DNS. + + The reason for the trouble is twofold. First, and least troublesome, + is the possibility of resolvers that are attempting to offer IDNA + service system-wide. Given the design of IDNA2008, it is reasonable + + + +Sullivan Informational [Page 4] + +RFC 8222 DNS-SD Label Selection September 2017 + + + to suppose that, on some systems, high-level name resolution + libraries will perform the U-label/A-label transformation + automatically, saving applications from these details. But system- + level services do not always have available to them the resolution + context, and they may apply the transformation in a way that foils + rather than helps the application. Of course, if this were the main + problem, it would presumably be self-correcting because the right + answer would be, "Don't use those libraries for DNS-SD", and DNS-SD + would not work reliably in cases where such libraries were in use. + This would be unfortunate, but given that DNS-SD in Internet contexts + is (as of this writing) not in ubiquitous use, it should not + represent a fatal issue. + + The greater problem is that the "infrastructure" types of DNS service + -- the root zone, the top-level domains, and so on -- have embraced + IDNA and refuse registration of raw UTF-8 into their zones. As of + this writing, there is (perhaps unfortunately) no reliable way to + discover where these sorts of DNS services end. Nevertheless, some + client programs (notably web browsers) have adopted a number of + different policies about how domain names will be looked up and + presented to users given the policies of the relevant DNS zone + operators. None of these policies permit raw UTF-8. Since it is + anticipated that DNS-SD when used with the DNS will be inside domain + names beneath those kinds of "infrastructure" domains, the + implications of IDNA2008 must be a consideration. + + For further exploration of issues relating to encoding of domain + names generally, the reader should consult [RFC6055]. + +3. Requirements for a Profile for Label Interoperation + + Any interoperability between DNS (including prevailing operational + conventions) and other resolution technologies will require + interoperability across the portions of a DNS-SD Service Instance + Name that are implicated in regular DNS lookups. Only some portions + are implicated. In any case, if a given portion is implicated, the + profile will need to apply to all labels in that portion. + + In addition, because DNS-SD Service Instance Names can be used in a + domain name slot, care must be taken by DNS-SD-aware resolvers to + handle the different portions as outlined here, so that DNS-SD + portions that do not use IDNA2008 will not be treated as U-labels and + will not accidentally undergo IDNA processing. + + Because the profile will apply to names that might appear in the + public DNS, and because other resolution mechanisms (such as mDNS) + could permit labels that IDNA does not, the profile might reduce the + labels that could be used with those other resolution mechanisms. + + + +Sullivan Informational [Page 5] + +RFC 8222 DNS-SD Label Selection September 2017 + + + One consequence of this is that some recommendations from [RFC6763] + will not really be possible to implement using names subject to the + profile. In particular, Section 4.2.3 of [RFC6763] recommends that + labels always be stored and communicated as UTF-8, even in the DNS. + Because of the way that the public DNS is currently operated (see + Section 2), the advice to store and transmit labels as UTF-8 in the + DNS is likely either to encounter problems, to result in unnecessary + traffic to the public DNS, or to do both. In particular, many labels + in the <Domain> part of a Service Instance Name are unlikely to be + found in the UTF-8 form in the public DNS tree for zones that are + using IDNA2008. By contrast, for example, mDNS exclusively uses + UTF-8. + + U-labels cannot contain uppercase letters (see Sections 3.1.3 and 4.2 + of [RFC5894]). That restriction extends to ASCII-range uppercase + letters that work fine in LDH labels. It may be confusing that the + character "A" works in the DNS when none of the characters in the + label has a diacritic, but it does not work when there is such a + diacritic in the label. Labels in mDNS names (or other resolution + technologies) may contain uppercase characters, so the profile will + need either to restrict the use of uppercase or to come up with a + convention for case folding (even in the presence of diacritics) that + is reliable and predictable to users. + +4. DNS-SD Portions + + Service Instance Names are made up of three portions. + +4.1. The <Instance> Portion of the Service Instance Name + + [RFC6763] is clear that the <Instance> portion of the Service + Instance Name is intended for presentation to users; therefore, + virtually any character is permitted in it. There are two ways that + a profile might address this portion. + + The first way would be to treat this portion as likely to be + intercepted by system-wide IDNA-aware (but otherwise context-unaware) + resolvers or likely subject to strict IDNA-conformance requirements + for publication in the relevant zone. In this case, the portion + would need to be made subject to the profile, thereby curtailing what + characters may appear in this portion. This approach permits DNS-SD + to use any standard system resolver but presents inconsistencies with + the DNS-SD specification and with DNS-SD use that is exclusively + mDNS-based. Therefore, this strategy is rejected. + + Instead, DNS-SD implementations can intercept the <Instance> portion + of a Service Instance Name and ensure that those labels are never + handed to IDNA-aware resolvers that might attempt to convert these + + + +Sullivan Informational [Page 6] + +RFC 8222 DNS-SD Label Selection September 2017 + + + labels into A-labels. Under this approach, the DNS-SD <Instance> + portion works as it always does, but at the cost of using special + resolution code built into the DNS-SD system. A practical + consequence of this is that zone operators need to be prepared not to + apply the LDH rule to all labels, and they may need to make special + concessions to ensure that the <Instance> portion can contain spaces, + uppercase and lowercase, and any UTF-8 code point. Otherwise, they + need to prepare a user interface to handle the exceptions that would + be generated. Automatic conversion to A-labels is not acceptable. + + It is worth noting that this advice is not actually compatible with + the advice in Section 4 of [RFC6055]. That section appears to assume + that names are not really composed of subsections, but because + [RFC6763] specifies portions of names, the advice in this memo is to + follow the advice of [RFC6055] according to the portion of the domain + name, rather than for the whole domain name. As a practical matter, + this means special-purpose name resolution software for DNS-SD. + +4.2. The <Service> Portion of the Service Instance Name + + DNS-SD includes a <Service> component in the Service Instance Name. + This component is not really user-facing data; instead it is control + data embedded in the Service Instance Name. This component includes + so-called "underscore labels", which are labels prepended with U+005F + (_). The underscore label convention was established by DNS SRV + ([RFC2782]) for identifying metadata inside DNS names. A system-wide + resolver (or DNS middlebox) that cannot handle underscore labels will + not work with DNS-SD at all, so it is safe to suppose that such + resolvers will not attempt to do special processing on these labels. + Therefore, the <Service> portion of the Service Instance Name will + not be subject to the profile. By the same token, underscore labels + are never subject to IDNA processing (they are formally + incompatible); therefore, concerns about IDNA are irrelevant for + these labels. + +4.3. The <Domain> Portion of the Service Instance Name + + The <Domain> portion of the Service Instance Name forms an integral + part of the owner name submitted for DNS resolution. A system-wide + resolver that is IDNA2008-aware is likely to interpret labels with + UTF-8 in the owner name as candidates for IDNA2008 processing. More + important, operators of internationalized domain names will + frequently publish such names in the public DNS as A-labels; + certainly, the topmost labels will always be A-labels. Therefore, + these labels will need to be subject to the profile. DNS-SD + implementations ought to identify the <Domain> portion of the Service + Instance Name and treat it subject to IDNA2008 in case the domain is + to be queried from the global DNS. (This document does not specify + + + +Sullivan Informational [Page 7] + +RFC 8222 DNS-SD Label Selection September 2017 + + + how to do that and does not alter the specification in [RFC6763].) + In the event that the <Domain> portion of the Service Instance Name + fails to resolve, it is acceptable to substitute labels with plain + UTF-8, starting at the lowest label in the DNS tree and working + toward the root. This approach would differ from the rule for + resolution published in [RFC6763], because this approach privileges + IDNA2008-compatible labels over UTF-8 labels. There is more than one + way to achieve such a result, but in terms of predictability, it is + probably best if the lowest-level resolution component is able to + learn the correct resolution context so that it can perform the + correct transformations on the various domain portions. + + One might argue against the above restriction on either of two + grounds: + + 1. It is possible that the names may be in the DNS in UTF-8, and RFC + 6763 already specifies a fallback strategy of progressively + attempting first the UTF-8 label lookup (it might not be a + U-label) and then, if possible, the A-label lookup. + + 2. Zone administrators that wish to support DNS-SD can publish a + UTF-8 version of the zone along side the A-label version of the + zone. + + The first of these is rejected because it represents a potentially + significant increase in DNS lookup traffic. It is possible for a + DNS-SD application to identify the <Domain> portion of the Service + Instance Name. The standard way to publish IDNs on the Internet uses + IDNA. Therefore, additional lookups should not be encouraged. When + [RFC6763] was published, the bulk of IDNs were lower in the tree. + Now that there are internationalized labels in the root zone, it is + desirable to minimize queries to the Internet infrastructure if they + are sure to be answered in the negative. + + The second reason depends on the idea that it is possible to maintain + two names in sync with one another. This is not strictly speaking + true, although in this case the domain operator could simply create a + DNAME record [RFC6672] from the UTF-8 name to the IDNA2008 zone. + This still, however, relies on being able to reach the (UTF-8) name + in question, and it is unlikely that the UTF-8 version of the zone + will be delegated from anywhere. Moreover, in many organizations, + the support for DNS-SD and the support for domain name delegations + are not performed by the same department; depending on a coordination + between the two will make the system more fragile, slower, or both. + + Some resolvers -- particularly those that are used in mixed DNS and + non-DNS environments -- may be aware of different operational + conventions in different parts of the DNS tree. For example, it may + + + +Sullivan Informational [Page 8] + +RFC 8222 DNS-SD Label Selection September 2017 + + + be possible for implementations to use hints about the boundary of an + organization's domain name infrastructure in order to tell, for + instance, that example.com. is part of the Example Organization, + while com. is a large delegation-centric zone on the public Internet. + In such cases, the resolution system might reverse its preferences to + prefer plain UTF-8 labels when resolving names below the boundary + point in the DNS tree. The result would be that any lookup past the + boundary point and closer to the root would use LDH labels first, + falling back to UTF-8 only after a failure; but a lookup below the + boundary point would use UTF-8 labels first, and try other strategies + only in case of negative answers. The mechanism to learn such a + boundary is beyond the scope of this document. + +5. IANA Considerations + + This document does not require any IANA actions. + +6. Security Considerations + + This memo presents some requirements for future development, but does + not specify anything. It makes no additional security-specific + requirements. Issues arising due to visual confusability of names + apply to this case as well as to any other case of internationalized + names, but interoperation between different resolution systems and + conventions does not alter the severity of those issues. + +7. Informative References + + [RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet + host table specification", RFC 952, DOI 10.17487/RFC0952, + October 1985, <https://www.rfc-editor.org/info/rfc952>. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + <https://www.rfc-editor.org/info/rfc1034>. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, + <https://www.rfc-editor.org/info/rfc2181>. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + DOI 10.17487/RFC2782, February 2000, + <https://www.rfc-editor.org/info/rfc2782>. + + + +Sullivan Informational [Page 9] + +RFC 8222 DNS-SD Label Selection September 2017 + + + [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network + Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, + <https://www.rfc-editor.org/info/rfc5198>. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + <https://www.rfc-editor.org/info/rfc5890>. + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + <https://www.rfc-editor.org/info/rfc5891>. + + [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and + Internationalized Domain Names for Applications (IDNA)", + RFC 5892, DOI 10.17487/RFC5892, August 2010, + <https://www.rfc-editor.org/info/rfc5892>. + + [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts + for Internationalized Domain Names for Applications + (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, + <https://www.rfc-editor.org/info/rfc5893>. + + [RFC5894] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Background, Explanation, and + Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, + <https://www.rfc-editor.org/info/rfc5894>. + + [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for + Internationalized Domain Names in Applications (IDNA) + 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, + <https://www.rfc-editor.org/info/rfc5895>. + + [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on + Encodings for Internationalized Domain Names", RFC 6055, + DOI 10.17487/RFC6055, February 2011, + <https://www.rfc-editor.org/info/rfc6055>. + + [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the + DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, + <https://www.rfc-editor.org/info/rfc6672>. + + [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + DOI 10.17487/RFC6762, February 2013, + <https://www.rfc-editor.org/info/rfc6762>. + + + + + +Sullivan Informational [Page 10] + +RFC 8222 DNS-SD Label Selection September 2017 + + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + <https://www.rfc-editor.org/info/rfc6763>. + + [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", RFC 7719, DOI 10.17487/RFC7719, December + 2015, <https://www.rfc-editor.org/info/rfc7719>. + +Acknowledgments + + The author gratefully acknowledges the insights of Joe Abley, Stuart + Cheshire, Paul Hoffman, Warren Kumari, Eliot Lear, Kerry Lynn, + Juergen Schoenwaelder, and Dave Thaler. Kerry Lynn deserves special + gratitude for his energy and persistence in pressing unanswered + questions. Doug Otis sent many comments about visual confusability. + +Author's Address + + Andrew Sullivan + Oracle Corporation + 100 Milverton Drive + Mississauga, ON L5R 4H1 + Canada + + Email: andrew.s.sullivan@oracle.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Sullivan Informational [Page 11] + |