RFC 8222

Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery

📅 published September 2017, from ietf

RFC 8222: Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery 🎀

Okay bestie, let's start with the basics 🧚 This is an Informational RFC from September 2017, so it's published for information and isn't a Standards Track spec 💅 It was written by A. Sullivan at Oracle, it's an IETF document, and its ISSN is 2070-1721. The title block has no Obsoletes or Updates line, so this RFC doesn't list anything it replaces or changes ✨

Abstract 💖

Okay so, DNS-Based Service Discovery (DNS-SD) can look for services in naming systems that aren't DNS at all 👀 And when it does use DNS, it goes full main character and uses the whole DNS capability, not just a subset of the octets 💅 This gets extra spicy where some environments use labels that follow IDNA, while others use labels with raw Unicode characters (like characters encoded as UTF-8 octets) 🌈 So if DNS-SD is going to work well where lots of different name systems and their own rules are running together, you have to pay attention to the differences in the underlying tech and the environment it runs in 🫶 This memo lays out the requirements for picking labels when conventional DNS and other resolution systems are expected to interoperate like this 🦋

Status of This Memo 📋

This document isn't an Internet Standards Track specification, it's just published for informational purposes 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it has had public review and been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🧐

Info about this document's current status, any errata, and how to give feedback on it lives at https://www.rfc-editor.org/info/rfc8222 🔗

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), as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're 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]) is a mechanism for finding services by querying DNS ([RFC1034] and [RFC1035]) and any other system that uses domain names, like Multicast DNS (mDNS, [RFC6762]) 🔍 Lots of apps that use DNS follow the "Internet hostname" syntax from [RFC952] for labels, which is the so-called LDH (letters, digits, and hyphen) rule 🔤 That convention is the reason IDNA2008 exists ([RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894], and [RFC5895]) 🌍 Here's the tea: the LDH rule is a convention, not a rule of the DNS. Section 11 of [RFC2181] makes that totally clear, and Section 3 of [RFC6055] goes into it more 🫖 Even so, a lot of people believe that in many situations, domain names can't be used in the DNS unless they follow the LDH rule 🙃

Meanwhile, mDNS requires labels to be encoded in UTF-8, and it allows a bunch of characters in labels that IDNA2008 and the LDH rule don't allow 🎨 For example, mDNS encourages spaces and punctuation in mDNS names (see Section 4.2.3 of [RFC6763]) ✨ It doesn't restrict which Unicode code points can be used in those labels, as long as the code points are UTF-8 in Net-Unicode [RFC5198] format 💅

App users and developers are usually not thinking about (or are totally oblivious to) which name-resolution system is running at any given moment 🙈 They just want to use the same domain names everywhere. So a name typed into the same domain name slot might get resolved by different name resolution technologies 😬 If a given name won't work across all those environments, users are most likely to be happy when at least some parts of the domain names being queried follow the rules and conventions for all the relevant technologies 🫶 Given how DNS-SD gets used, the choice to make that happen probably belongs to the application designer or the service operator 🧑‍💻

One way to get interoperability here is to use a single operational convention (a "profile") for domain names across the different naming systems 🎀 This memo assumes that kind of use profile, and tries to outline what's needed to make it work without naming any specific technology 🧚 It does assume that the global DNS is likely to be involved, though. Since resolution almost always eventually falls through to the DNS, that assumption doesn't seem controversial 🌈

Also worth knowing: DNS-SD users don't use service discovery names the same way users of other domain names do 👀 Domain names can often be typed in directly as user input, but service discovery usually assumes users are picking a service from a list 📋 So the application considerations that fit a general-purpose DNS name (and that led to the A-label/U-label split in IDNA2008, see below) aren't entirely the right approach for DNS-SD 💖

1.1. Conventions and Terms Used in This Document 📚

Wherever it makes sense, this memo uses the terminology defined in Section 2 of [RFC5890] 🤓 In particular, the reader is assumed to know the terms "U-label", "LDH label", and "A-label" from that document. The reader is also assumed to know the U+NNNN notation for Unicode code points, which [RFC5890] and other documents about Unicode code points use. For the sake of brevity and consistency, the definitions aren't repeated here 🫶

This memo sometimes talks about names in the DNS as if the LDH rule and IDNA2008 were strict requirements. They aren't! DNS labels are, in principle, just collections of octets, so in principle the LDH rule isn't a constraint at all 🙌 In practice, though, applications sometimes catch labels that don't follow the LDH rule and apply IDNA and other transformations to them 🔁

DNS, perhaps unfortunately, has built up its own jargon 😭 If you run into unfamiliar DNS-related terms in this memo, look them up in [RFC7719] 📖

The term "owner name" (common DNS vernacular, see above) is used here not just for domain names looked up in the DNS, but for any name that might be looked up either in the DNS or with another technology 🧩 So it includes names that might not actually exist anywhere. The rest of this memo also depends on the idea that not every domain name will be looked up in the DNS 🌸 For instance, names ending in "local." (in presentation format) usually aren't looked up with DNS. They're looked up with mDNS instead 🧚

DNS-SD specifies three portions of the owner name for a DNS-SD resource record: the <Instance> portion, the <Service> portion, and the <Domain> portion 🎀 The owner name made of these three parts is called the "Service Instance Name". Also, a portion can be more than one label long, so see Section 4.1 of [RFC6763] 🧩 More discussion of these parts is in Section 4.

Throughout this memo, mDNS is used a lot as the alternative resolution mechanism to DNS 💅 That's for convenience, not rigor. Any alternative name resolution to DNS could cause the same friction with the common operational conventions of the global DNS 🌍 It just so happens that mDNS is the overwhelmingly successful alternative as of this writing, so it's used to make the issues clearer for the reader 🦋 Wherever mDNS shows up in the text, other alternative resolution mechanisms can be read in its place, except where details of the mDNS specification are being described ✨

2. Why There Could Be a Problem at All 🤔

One might reasonably wonder why there's a problem to solve at all 🧐 After all, DNS labels allow any octet whatsoever, and anything useful with DNS-SD can't use names outside the protocol strictures of the DNS 🙃

The trouble comes from two things 🫖 The first, and least troublesome, is the possibility of resolvers trying to offer IDNA service system-wide. Given how IDNA2008 is designed, it's reasonable to suppose that on some systems, high-level name resolution libraries will do the U-label/A-label transformation automatically, so applications don't have to deal with the details 💖 But system-level services don't always have the resolution context available, so they might apply the transformation in a way that foils the application instead of helping it 😬 If this were the main problem, it would presumably fix itself, because the right answer would be "Don't use those libraries for DNS-SD," and DNS-SD just wouldn't work reliably wherever those libraries were in use 🙈 That would be unfortunate, but since DNS-SD in Internet contexts is (as of this writing) not in ubiquitous use, it shouldn't be a fatal issue 🌸

The bigger 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 in their zones 🚫 As of this writing, there's (perhaps unfortunately) no reliable way to discover where these DNS services end 😭 Still, some client programs (notably web browsers) have adopted a number of different policies about how domain names get looked up and presented to users, based on the policies of the relevant DNS zone operators 🌐 None of these policies permit raw UTF-8 💀 Since DNS-SD used with the DNS is expected to sit inside domain names beneath those kinds of "infrastructure" domains, the implications of IDNA2008 have to be considered 👑

For more on encoding domain names in general, check out [RFC6055] 📚

3. Requirements for a Profile for Label Interoperation ✨

okay so any time DNS (including the operational habits people already have) needs to play nicely with other resolution technologies 🫶, the two have to be interoperable across whichever parts of a DNS-SD Service Instance Name actually get used in regular DNS lookups. not every part gets pulled in, though 💅. and if a given part does get pulled in, the profile has to apply to all the labels in that part, no exceptions bestie.

also, Service Instance Names can show up in a domain name slot, so DNS-SD-aware resolvers need to be careful and handle each portion the way this doc lays out 🎀. that way, DNS-SD portions that don't use IDNA2008 never get treated as U-labels and never get accidentally run through IDNA processing. the horror 💀.

because the profile will apply to names that might show up in the public DNS, and because other resolution mechanisms (like mDNS) can allow labels that IDNA doesn't, the profile might shrink the set of labels you can use with those other mechanisms 🦋.

one result of all this is that some recommendations from [RFC6763] just aren't really doable with names under the profile 😭. specifically, Section 4.2.3 of [RFC6763] recommends that labels always be stored and communicated as UTF-8, even in the DNS. but the public DNS is run the way it is right now (see Section 2), so telling people to store and send labels as UTF-8 in the DNS is either going to run into problems, cause unnecessary traffic to the public DNS, or do both 🙈. honestly, lots of labels in the <Domain> part of a Service Instance Name probably won't be found in UTF-8 form in the public DNS tree for zones using IDNA2008. meanwhile mDNS uses UTF-8 exclusively, so it's a whole different vibe 🌈.

here's another wild one: U-labels cannot contain uppercase letters (see Sections 3.1.3 and 4.2 of [RFC5894]) 😤. that restriction also covers ASCII-range uppercase letters, which work totally fine in LDH labels. it's so confusing that "A" works in the DNS when none of the characters in the label has a diacritic, but stops working once there's a diacritic in the label 🥴. labels in mDNS names (or other resolution technologies) can contain uppercase characters, so the profile will need to either restrict uppercase use or come up with a case folding convention (even with diacritics) that's reliable and predictable for 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 super clear that the <Instance> portion is meant to be shown to users, so basically any character is allowed in it 💖. there are two ways a profile could handle this portion.

the first way is to treat this portion as likely to get intercepted by system-wide IDNA-aware (but otherwise context-unaware) resolvers, or as likely to be subject to strict IDNA-conformance requirements for publication in the relevant zone. in that case, the portion would have to be made subject to the profile, which would cut down on what characters can show up in it. this approach lets DNS-SD use any standard system resolver, but it creates inconsistencies with the DNS-SD specification and with DNS-SD use that's exclusively mDNS-based. so yeah, this strategy gets rejected 🚫.

so instead, DNS-SD implementations can intercept the <Instance> portion of a Service Instance Name and make sure those labels never get handed to IDNA-aware resolvers that might try to turn them into A-labels 🎀. under this approach the <Instance> portion works exactly like it always does, but the cost is special resolution code built into the DNS-SD system. a practical consequence is that zone operators need to be ready to not apply the LDH rule to all labels, and they may need to make special concessions so the <Instance> portion can contain spaces, uppercase and lowercase, and any UTF-8 code point ✨. otherwise, they'll need a user interface to handle the exceptions that get generated. automatic conversion to A-labels is not acceptable, full stop 🙅‍♀️.

it's worth noting that this advice is not actually compatible with the advice in Section 4 of [RFC6055] 👀. that section seems to assume names aren't really made up 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. realistically, that 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 one isn't really user-facing data 🙅‍♀️. instead it's control data embedded in the name. it 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 can't handle underscore labels won't work with DNS-SD at all, so it's safe to assume those resolvers won't try to do special processing on these labels 🤝. which means the <Service> portion of the Service Instance Name will not be subject to the profile. same vibe here: underscore labels are never subject to IDNA processing (they're formally incompatible), so concerns about IDNA are irrelevant for these labels 💅.

4.3. The <Domain> Portion of the Service Instance Name 🌍

the <Domain> portion is an integral part of the owner name submitted for DNS resolution, and this is where things get spicy 🌶️. a system-wide resolver that's IDNA2008-aware is likely to treat labels with UTF-8 in the owner name as candidates for IDNA2008 processing. even more important, operators of internationalized domain names will frequently publish those names in the public DNS as A-labels, and the topmost labels will always be A-labels 💜. so 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 as subject to IDNA2008, in case the domain is going to be queried from the global DNS. (this document doesn't specify how to do that and doesn't change the specification in [RFC6763] 📝.)

if the <Domain> portion of the Service Instance Name fails to resolve, it's acceptable to swap in labels with plain UTF-8, starting at the lowest label in the DNS tree and working toward the root 🔄. this differs from the resolution rule published in [RFC6763], because this approach favors IDNA2008-compatible labels over UTF-8 labels. there's more than one way to get that result, but for predictability, it's probably best if the lowest-level resolution component can learn the correct resolution context, so it can do the right transformations on the various domain portions 🧠.

someone could argue against the restriction above on either of two grounds 🤔:

  1. it's possible the names are in the DNS as UTF-8, and RFC 6763 already specifies a fallback strategy of progressively trying the UTF-8 label lookup first (it might not be a U-label) and then, if possible, the A-label lookup.
  2. zone administrators who want to support DNS-SD can publish a UTF-8 version of the zone alongside the A-label version of the zone.

the first one gets rejected because it could mean a significant jump in DNS lookup traffic 📈. it's possible for a DNS-SD application to identify the <Domain> portion of the Service Instance Name, and the standard way to publish IDNs on the Internet uses IDNA. so extra lookups shouldn't be encouraged 🙅‍♀️. when [RFC6763] was published, most IDNs sat lower in the tree. now that there are internationalized labels in the root zone, it's desirable to minimize queries to the Internet infrastructure when they're sure to get a negative answer 🫠.

the second reason depends on the idea that you can keep two names in sync with each other. that's not strictly true 😬, although in this case the domain operator could just create a DNAME record [RFC6672] from the UTF-8 name to the IDNA2008 zone. this still relies on being able to reach the (UTF-8) name in question, though, and the UTF-8 version of the zone is unlikely to be delegated from anywhere. plus, in many organizations, support for DNS-SD and support for domain name delegations aren't handled by the same department. depending on coordination between the two will make the system more fragile, slower, or both 🥲.

some resolvers (especially ones used in mixed DNS and non-DNS environments) may be aware of different operational conventions in different parts of the DNS tree 🗺️. for example, implementations might be able to use hints about the boundary of an organization's domain name infrastructure to tell that example.com. is part of the Example Organization, while com. is a large delegation-centric zone on the public Internet. in those cases, the resolution system might flip its preferences and 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 uses 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 only try other strategies in case of negative answers 🔁. the mechanism for learning 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 from the 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 ✨

Okay, bestie, here's the reading list 📚 Each of these is a source the spec leans on:

Acknowledgments 🫶

Huge thank-you to Joe Abley, Stuart Cheshire, Paul Hoffman, Warren Kumari, Eliot Lear, Kerry Lynn, Juergen Schoenwaelder, and Dave Thaler for sharing their insights, the author is so grateful 💜 Kerry Lynn gets extra-special gratitude for his energy and persistence in pushing on the unanswered questions 🔥 And Doug Otis sent a ton of 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
📦 where this page comes from