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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/