draft-ietf-dnssd-mdns-dns-interop-00.txt | draft-ietf-dnssd-mdns-dns-interop-01.txt | |||
---|---|---|---|---|
DNSSD A. Sullivan | DNSSD A. Sullivan | |||
Internet-Draft Dyn | Internet-Draft Dyn | |||
Intended status: Informational March 4, 2015 | Intended status: Informational July 4, 2015 | |||
Expires: September 5, 2015 | Expires: January 5, 2016 | |||
On Interoperation of Labels Between mDNS and DNS | On Interoperation of Labels Between mDNS and DNS | |||
draft-ietf-dnssd-mdns-dns-interop-00 | draft-ietf-dnssd-mdns-dns-interop-01 | |||
Abstract | Abstract | |||
Despite its name, DNS-Based Service Discovery can use naming systems | Despite its name, DNS-Based Service Discovery can use naming systems | |||
other than the Domain Name System when looking for services. | other than the Domain Name System when looking for services. | |||
Different name systems use different conventions for the characters | Moreover, when it uses the DNS, DNS-Based Service Discovery uses the | |||
allowed in any name. In order for DNS-SD to be used effectively in | full capability of DNS, rather than using a subset of available | |||
environments where multiple different name systems are in use, it is | octets. In order for DNS-SD to be used effectively in environments | |||
important to attend to differences in the underlying technology. | where multiple different name systems and conventions for their | |||
This memo presents an outline of the requirements for selection of | operation are in use, it is important to attend to differences in the | |||
labels for mDNS and DNS when they are expected to interoperate in | underlying technology and operational environment. This memo | |||
this manner. | presents an outline of the requirements for 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 Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 5, 2015. | This Internet-Draft will expire on January 5, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | (http://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. Requirements for a profile for label interoperation . . . . . 3 | 2. Why there could be a problem at all . . . . . . . . . . . . . 4 | |||
3. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Requirements for a profile for label interoperation . . . . . 5 | |||
3.1. The <Instance> Portion of the Service Instance Name . 4 | 4. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. The <Service> Portion of the Service Instance Name . 5 | 4.1. The <Instance> Portion of the Service | |||
3.3. The <Domain> Portion of the Service Instance Name . . 5 | Instance Name . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | 4.2. The <Service> Portion of the Service | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | Instance Name . . . . . . . . . . . . . . . . . . . . . . 7 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 4.3. The <Domain> Portion of the Service Instance | |||
7. Informative References . . . . . . . . . . . . . . . . . . . 7 | Name . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 8 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
A.1. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 8 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
A.2. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 8 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
A.3. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 8 | 8. Informative References . . . . . . . . . . . . . . . . . . . 8 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 | Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 | |||
A.1. draft-ietf-dnssd-mdns-dns-interop-01 . . . . . . . . . . 10 | ||||
A.2. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 10 | ||||
A.3. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 10 | ||||
A.4. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 10 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
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 both to the Domain Name System | for discovering services using queries to the Domain Name System | |||
(DNS, [RFC1034], [RFC1035]) and to Multicast DNS (mDNS, [RFC6762]). | (DNS, [RFC1034], [RFC1035]); and to any other system that uses domain | |||
Conventional use of the DNS generally follows the host name rules | names, such as Multicast DNS (mDNS, [RFC6762]). Conventional use of | |||
[RFC0952] for labels -- the so-called LDH rule. That convention is | the DNS generally follows the host name rules [RFC0952] for labels -- | |||
the reason behind the development of Internationalized Domain Names | the so-called LDH rule. That convention is the reason behind the | |||
for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892], | development of Internationalized Domain Names for Applications | |||
[RFC5893], [RFC5894], [RFC5895]). It is worth noting that the LDH | (IDNA2008, [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894], | |||
rule is a convention, and not a strict rule of the DNS. It is | [RFC5895]). It is worth noting that the LDH rule is a convention, | |||
assumed to be true widely enough, however, that in many circumstances | and not a rule of the DNS; this is made entirely plain by [RFC2181], | |||
names cannot be used unless they cleave to the LDH rule. | section 11. Nevertheless, there is a widespread belief that in many | |||
circumstances domain names cannot be used in the DNS unless they | ||||
cleave to the LDH 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 [RFC6763], section 4.1.3). | |||
It does not restrict which Unicode code points may be used in those | 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] | labels, so long as the code points are UTF-8 in Net-Unicode [RFC5198] | |||
format. | format. | |||
Users of applications are, of course, frequently unconcerned with | Users of applications are, of course, frequently unconcerned with | |||
(not to say oblivious to) the name-resolution system(s) in service at | (not to say oblivious to) the name-resolution system(s) in service at | |||
any given moment, and are inclined simply to use the same names in | any given moment, and are inclined simply to use the same domain | |||
different contexts. As a result, the same string might be tried as a | names in different contexts. As a result, the same domain name might | |||
name using different name resolution technologies. If DNS-SD is to | be tried using different name resolution technologies. If DNS-SD is | |||
be used in an environment where both mDNS and DNS are to be queried | to be used in an environment where multiple resolution systems (such | |||
for services, then some parts of the names to be queried will need to | as mDNS and DNS) are to be queried for services, then some parts of | |||
be compatible with the rules and conventions for both DNS and mDNS. | the domain names to be queried will need to be compatible with the | |||
rules and conventions for all the relevant technologies. | ||||
One approach to interoperability under these circumstances is to use | One approach to interoperability under these circumstances is to use | |||
a single operational convention for names under the different naming | a single operational convention (a "profile") for domain names under | |||
systems. This memo assumes such a use profile, and outlines what is | the different naming systems. This memo assumes such a use profile, | |||
necessary to make it work. | 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 eventually 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 | 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. Most domain names might as easily be typed in as direct user | might. Domain names often might as easily be entered as direct user | |||
input as any other method. But the service discovery context | input as by any other method. But the service discovery context | |||
generally assumes users are picking a service from a list. As a | generally assumes users are picking a service from a list. As a | |||
result, the sorts of application considerations that are appropriate | result, the sorts of application considerations that are appropriate | |||
to the general-purpose DNS name, and that resulted in the A-label/ | to the general-purpose DNS name, and that resulted in the A-label/ | |||
U-label (see below) in IDNA2008, are not the right approach for DNS- | U-label split (see below) in IDNA2008, are not entirely the right | |||
SD. | 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. | |||
This memo refers to names in the DNS as though the LDH rule and | Sometimes this memo refers to names in the DNS as though the LDH rule | |||
IDNA2008 are strict requirements. They are not. DNS labels are, in | and IDNA2008 are strict requirements. They are not. DNS labels are, | |||
principle, just collections of octets, and therefore in principle the | in principle, just collections of octets, and therefore in principle | |||
LDH rule is not a constraint. In practice, applications often | the LDH rule is not a constraint. In practice, applications | |||
intercept labels that do not conform to the LDH rule and apply IDNA | sometimes intercept labels that do not conform to the LDH rule and | |||
and other transformations. | apply IDNA and other transformations. | |||
The term "owner name" (common to the DNS vernacular) is used here to | The DNS, perhaps unfortunately, has produced its own jargon. | |||
apply not just to the names to be looked up in the DNS, but to any | Unfamiliar DNS-related terms in this memo should be found in | |||
name that might be looked up either in the DNS or using mDNS. | [I-D.ietf-dnsop-dns-terminology]. | |||
2. Requirements for a profile for label interoperation | 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 other technologies. It therefore includes names that might not | ||||
actually exist anywhere. In addition, what follows depends on the | ||||
idea that not every domain name may be looked up in the DNS. For | ||||
instance, names ending in "local." (in the presentation format) are | ||||
not ordinarily looked up in the DNS, but instead by querying mDNS. | ||||
Any interoperability between mDNS and DNS will require | DNS-SD specifies three portions of the owner name for a DNS-SD | |||
interoperability across some of the portions of a DNS-SD Service | resource record. These are the <Instance> portion, the <Service> | |||
Instance Name (see Section 3) that are implicated in regular mDNS and | portion, and the <Domain>. The owner name made of these three parts | |||
DNS lookups. Only some portions are implicated. In any case, if a | is called the Service Instance Name. It is worth observing that a | |||
given portion is implicated, the profile will need to apply to all | portion may be more than one label long. See [RFC6763], section 4.1. | |||
labels in that portion. | 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 | ||||
rigour: 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 in general 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 | ||||
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. If this were the main problem, | ||||
however, it would presumably be self-correcting; for 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 | In addition, because DNS-SD Service Instance Names can be used in a | |||
domain name slot, care must be taken by DNS-SD resolvers to undertake | domain name slot, care must be taken by DNS-SD-aware resolvers to | |||
the special processing outlined here, so that DNS-SD portions that do | handle the different portions as outlined here, so that DNS-SD | |||
not use IDNA2008 will not be treated as U-labels and will not undergo | portions that do not use IDNA2008 will not be treated as U-labels and | |||
IDNA processing. | will not accidentally undergo IDNA processing. | |||
Because the profile will need to apply to names that might need to | Because the profile will need to apply to names that might need to | |||
interoperate with names in the DNS, and because mDNS permits labels | interoperate with names in the public DNS, and because other | |||
that IDNA does not, the profile might reduce the labels that could be | resolution mechanisms (such as mDNS) could permit labels that IDNA | |||
used with mDNS. Consequently, some recommendations from [RFC6763] | does not, the profile might reduce the labels that could be used with | |||
will not really be possible to implement using names subject to the | those other resolution mechanisms. One consequence of this is that | |||
profile. In particular, [RFC6763], section 4.1.3 recommends that | some recommendations from [RFC6763] will not really be possible to | |||
labels always be stored and communicated as UTF-8, even in the DNS. | implement using names subject to the profile. In particular, | |||
Because IDNA2008 libraries will treat any Unicode-encoded labels as | [RFC6763], section 4.1.3 recommends that labels always be stored and | |||
candidate U-labels and attempt to perform resolution in A-label form, | communicated as UTF-8, even in the DNS. Because of the way the | |||
the advice to store and transmit labels as UTF-8 in the DNS is likely | public DNS is currently operated (see Section 2), the advice to store | |||
to encounter problems. In particular, the <Domain> part of a Service | and transmit labels as UTF-8 in the DNS is likely either to encounter | |||
Instance Name is unlikely to be found in its UTF-8 form in the public | problems or result in unnecessary traffic to the public DNS (or | |||
DNS tree for zones that are using IDNA2008. By contrast, mDNS | both). In particular, the <Domain> part of a Service Instance Name | |||
is unlikely to be found in its UTF-8 form in the public DNS tree for | ||||
zones that are using IDNA2008. By contrast, for example, mDNS | ||||
normally uses UTF-8. | normally uses UTF-8. | |||
U-labels cannot contain upper case letters. That restriction extends | U-labels cannot contain upper case letters. That restriction extends | |||
to ASCII-range upper case letters that work fine in LDH-labels. It | to ASCII-range upper case letters that work fine in LDH-labels. It | |||
may be confusing that the character "A" works in the DNS when none of | may be confusing that the character "A" works in the DNS when none of | |||
the characters in the label has a diacritic, but does not work when | the characters in the label has a diacritic, but does not work when | |||
there is such a diacritic in the label. Labels in mDNS names may | there is such a diacritic in the label. Labels in mDNS names (or | |||
contain upper case characters, so the profile will need either to | other resolution technologies) may contain upper case characters, so | |||
restrict the use of upper case or come up with a reliable and | the profile will need either to restrict the use of upper case or | |||
predictable (to users) convention for case folding even in the | come up with a reliable and predictable (to users) convention for | |||
presence of diacritics. | case folding even in the presence of diacritics. | |||
3. DNS-SD portions | 4. DNS-SD portions | |||
DNS-SD specifies three portions of the owner name for a DNS-SD | Service Instance Names are made up of three portions. | |||
resource record. These are the <Instance> portion, the <Service> | ||||
portion, and the <Domain>. 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 [RFC6763], section 4.1. | ||||
3.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, and 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 resolvers. In this case, the | intercepted by system-wide IDNA-aware resolvers, or likely subject to | |||
portion needs to be made subject to the profile, thereby curtailing | strict IDNA conformance requirements for publication in the relevant | |||
what characters may appear in this portion. This approach permits | zone. In this case, the portion would need to be made subject to the | |||
DNS-SD to use any standard system resolver but presents | profile, thereby curtailing what characters may appear in this | |||
inconsistencies with the DNS-SD specification and with DNS-SD that is | portion. This approach permits DNS-SD to use any standard system | |||
exclusively mDNS-based. Therefore, this strategy is rejected. | resolver but presents inconsistencies with the DNS-SD specification | |||
and with DNS-SD that is exclusively 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. | 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 may need to make special | ||||
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 | ||||
user interface to handle the exceptions that would otherwise be | ||||
generated. Automatic conversion to A-labels is not acceptable. | ||||
3.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, but is instead 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. | not be subject to the profile. By the same token, it should be noted | |||
that underscore labels are never subject to IDNA processing (they're | ||||
formally incompatible), and therefore concerns about IDNA are | ||||
irrelevant for these labels. | ||||
3.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 QNAME submitted for DNS resolution, and 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 QNAME as candidates for IDNA2008 processing. Operators | UTF-8 in the owner name as candidates for IDNA2008 processing. More | |||
of Internationalized Domain Names will frequently publish them in the | important, operators of internationalized domain names will | |||
DNS as A-labels. Therefore, these labels will need to be subject to | frequently publish such names in the DNS as A-labels; certainly, the | |||
the profile. DNS-SD implementations ought to identify the <Domain> | top-most labels will always be A-labels. Therefore, these labels | |||
portion of the Service Instance Name and treat it subject to IDNA2008 | will need to be subject to the profile. DNS-SD implementations ought | |||
in case the domain is to be queried from the global DNS. In the | to identify the <Domain> portion of the Service Instance Name and | |||
event that the <Domain> portion of the Service Instance Name fails to | treat it subject to IDNA2008 in case the domain is to be queried from | |||
resolve, it is acceptable to substitute labels with plain UTF-8, | the global DNS. In the event that the <Domain> portion of the | |||
starting at the lowest label in the DNS tree and working toward the | Service Instance Name fails to resolve, it is acceptable to | |||
root. This approach different to the rule for resolution published | substitute labels with plain UTF-8, starting at the lowest label in | |||
in [RFC6763], because it privileges IDNA2008-compatible labels over | the DNS tree and working toward the root. This approach differs from | |||
UTF-8 labels. | the rule for resolution published in [RFC6763], because it privileges | |||
IDNA2008-compatible labels over UTF-8 labels. | ||||
One might argue against this restriction on either of two grounds: | One might argue against this restriction on either of two grounds: | |||
1. It is possible the names may be in the DNS in UTF-8, and RFC 6763 | 1. It is possible the names may be in the DNS in UTF-8, and RFC 6763 | |||
already specifies a fallback strategy of progressively attempting | already specifies a fallback strategy of progressively attempting | |||
first the U-label lookup and then the A-label lookup. | 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 | 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 for no value. It is | |||
possible for a DNS-SD application to identify the <Domain> portion of | possible for a DNS-SD application to identify the <Domain> portion of | |||
the Service Instance Name. The standard way to publish IDNs on the | the Service Instance Name. The standard way to publish IDNs on the | |||
Internet uses IDNA. Therefore, additional lookups should not be | Internet uses IDNA. Therefore, additional lookups should not be | |||
encouraged. When [RFC6763] was published, the bulk of IDNs were | encouraged. When [RFC6763] was published, the bulk of IDNs were | |||
lower in the tree, but now that there are internationalized labels in | lower in the tree. Now that there are internationalized labels in | |||
the root zone, it seems reasonable to use only the single lookup | the root zone, it is desirable to minimize queries to the Internet | |||
strategy. | infrastructure if they 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 the | |||
support for DNS-SD and the support for domain name delegations are | support for DNS-SD and the support for domain name delegations are | |||
not performed by the same department, and depending on a co- | not performed by the same department, and depending on a co- | |||
ordination between the two will make the system more fragile or | ordination between the two will make the system more fragile, or | |||
slower or both. | slower, or both. | |||
4. Acknowledgements | 5. Acknowledgements | |||
The author gratefully acknowledges the insights of Stuart Cheshire, | The author gratefully acknowledges the insights of Stuart Cheshire, | |||
Kerry Lynn, and Dave Thaler. | Kerry Lynn, and Dave Thaler. Kerry Lynn deserves special gratitude | |||
for his energy and persistence in pressing unanswered questions. | ||||
5. IANA Considerations | 6. IANA Considerations | |||
This memo makes no requests of IANA. | This memo makes no requests of IANA. | |||
6. Security Considerations | 7. 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. Therefore, it has no implications for | not specify anything. Therefore, it has no implications for | |||
security. | security. | |||
7. Informative References | 8. Informative References | |||
[I-D.ietf-dnsop-dns-terminology] | ||||
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS | ||||
Terminology", draft-ietf-dnsop-dns-terminology-03 (work in | ||||
progress), June 2015. | ||||
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet | [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet | |||
host table specification", RFC 952, October 1985. | host table specification", RFC 952, October 1985. | |||
[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, November 1987. | |||
[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, November 1987. | |||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS | ||||
Specification", RFC 2181, July 1997. | ||||
[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. | February 2000. | |||
[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, March 2008. | |||
[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, August 2010. | |||
skipping to change at page 8, line 5 | skipping to change at page 9, line 47 | |||
RFC 5893, August 2010. | RFC 5893, August 2010. | |||
[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, August 2010. | |||
[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, September 2010. | |||
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on | ||||
Encodings for Internationalized Domain Names", RFC 6055, | ||||
February 2011. | ||||
[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, June 2012. | |||
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, | [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, | |||
February 2013. | February 2013. | |||
[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, February 2013. | |||
Appendix A. Change History | Appendix A. Change History | |||
A.1. draft-ietf-dnssd-mdns-dns-interop-00 | A.1. 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.2. draft-ietf-dnssd-mdns-dns-interop-00 | ||||
1st WG version | 1st WG version | |||
Add text to make clear that fallback from A-label lookup to UTF-8 | Add text to make clear that fallback from A-label lookup to UTF-8 | |||
label lookup ok, per WG comments at IETF 91 | label lookup ok, per WG comments at IETF 91 | |||
A.2. draft-sullivan-dnssd-mdns-dns-interop-01 | A.3. draft-sullivan-dnssd-mdns-dns-interop-01 | |||
o Decided which portions would be affected | o Decided which portions would be affected | |||
o Explained the difference in user interfaces between DNS-SD and | o Explained the difference in user interfaces between DNS-SD and | |||
usual DNS operation | usual DNS operation | |||
o Provided background on why the Domain portion should be treated | o Provided background on why the Domain portion should be treated | |||
differently | differently | |||
A.3. draft-sullivan-dnssd-mdns-dns-interop-00 | A.4. draft-sullivan-dnssd-mdns-dns-interop-00 | |||
Initial version. | Initial version. | |||
Author's Address | Author's Address | |||
Andrew Sullivan | Andrew Sullivan | |||
Dyn | Dyn | |||
150 Dow St. | 150 Dow St. | |||
Manchester, NH 03101 | Manchester, NH 03101 | |||
U.S.A. | U.S.A. | |||
End of changes. 40 change blocks. | ||||
129 lines changed or deleted | 237 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |