On Interoperation of Labels Between mDNS and DNS
Dyn
150 Dow St.
Manchester
NH
03101
U.S.A.
asullivan@dyn.com
DNSSD
Despite its name, DNS-Based Service Discovery can use naming
systems other than the Domain Name System when looking for
services. Different name systems use different conventions for
the characters allowed in any name. In order for DNS-SD to be
used effectively in environments where multiple different name
systems are in use, it is important to attend to differences in
the underlying technology. This memo presents an outline of the
requirements for selection of labels for mDNS and DNS when they
are expected to interoperate in this manner.
DNS-Based Service Discovery (DNS-SD, )
specifies a mechanism for discovering services using queries both to
the Domain Name System (DNS, , ) and to Multicast DNS (mDNS, ). Conventional use of the DNS generally follows
the host name rules for labels -- the
so-called LDH rule. That convention is the reason behind the
development of Internationalized Domain Names for Applications
(IDNA2008, , , , , , ). It is worth noting
that the LDH rule is a convention, and not a strict rule of the
DNS. It is assumed to be true widely enough, however, that in many
circumstances names cannot be used unless they cleave to the LDH rule.
At the same time, mDNS requires that labels be encoded in UTF-8,
and permits a range of characters in labels that are not permitted
by IDNA2008 or the LDH rule. For example, mDNS encourages the use of
spaces and punctuation in mDNS names (see ,
section 4.1.3). 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 format.
Users of applications are, of course, frequently unconcerned
with (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 different contexts. As a result, the same string
might be tried as a name using different name resolution
technologies. If DNS-SD is to be used in an environment where
both mDNS and DNS are to be queried for services, then some parts
of the names to be queried will need to be compatible with the
rules and conventions for both DNS and mDNS.
One approach to interoperability under these circumstances is
to use a single operational convention for names under the
different naming systems. This memo assumes such a use profile,
and outlines what is necessary to make it work.
It is worth noting that users of DNS-SD do not use the service
discovery names in the same way that users of other domain names
might. Most domain names might as easily be typed in as direct
user input as any other method. But the service discovery context
generally assumes users are picking a service from a list. As a
result, the sorts of application considerations that are
appropriate to the general-purpose DNS name, and that resulted in
the A-label/U-label (see below) in IDNA2008, are not the right
approach for DNS-SD.
Wherever appropriate, this memo uses the terminology defined
in Section 2 of . In particular, the
reader is assumed to be familiar with the terms "U-label", "LDH
label", and "A-label" from that document. Similarly, the reader
is assumed to be familiar with the U+NNNN notation for Unicode
code points used in and other documents
dealing with Unicode code points. In the interests of brevity
and consistency, the definitions are not repeated here.
This memo refers to names in the DNS as though the LDH rule
and IDNA2008 are strict requirements. They are not. DNS labels
are, in principle, just collections of octets, and therefore in
principle the LDH rule is not a constraint. In practice,
applications often intercept labels that do not conform to the
LDH rule and apply IDNA and other transformations.
The term "owner name" (common to the DNS vernacular) is used
here to apply not just to the names to be looked up in the DNS,
but to any name that might be looked up either in the DNS or
using mDNS.
Any interoperability between mDNS and DNS will require
interoperability across some of the portions of a DNS-SD Service
Instance Name (see ) that are
implicated in regular mDNS and DNS lookups. Only some portions are
implicated. In any case, if a given portion is implicated, the
profile will need to apply to all labels in that portion.
In addition, because DNS-SD Service Instance Names can be used in
a domain name slot, care must be taken by DNS-SD resolvers to
undertake the special processing outlined here, so that DNS-SD
portions that do not use IDNA2008 will not be treated as U-labels
and will not undergo IDNA processing.
Because the profile will need to apply to names that might need
to interoperate with names in the DNS, and because mDNS permits
labels that IDNA does not, the profile might reduce the labels that
could be used with mDNS. Consequently, some recommendations from
will not really be possible to implement
using names subject to the profile. In particular, , section 4.1.3 recommends that labels always be
stored and communicated as UTF-8, even in the DNS. Because IDNA2008
libraries will treat any Unicode-encoded labels as candidate
U-labels and attempt to perform resolution in A-label form, the
advice to store and transmit labels as UTF-8 in the DNS is likely to
encounter problems. 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,
mDNS normally uses UTF-8.
U-labels cannot contain upper case letters. That restriction
extends 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 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 contain upper case characters, so the profile will
need either to restrict the use of upper case or come up with a
reliable and predictable (to users) convention for case folding even
in the presence of diacritics.
DNS-SD specifies three portions of the owner name for a DNS-SD
resource record. These are the <Instance> portion, the
<Service> portion, and the <Domain>. The owner name
made of these three parts is called the Service Instance Name. It
is worth observing that a portion may be more than one label
long. See , section 4.1.
is clear that the <Instance>
portion of the Service Instance Name is intended for
presentation to users, and therefore virtually any character is
permitted in it. There are two ways that a profile might address
this portion.
The first way would be to treat this portion as likely to be
intercepted by system-wide IDNA-aware resolvers. In this case,
the portion needs to be made subject to the profile, thereby
curtailing what characters may appear in this portion. This
approach permits DNS-SD to use any standard system resolver but
presents inconsistencies with the DNS-SD specification and with
DNS-SD that is exclusively mDNS-based. Therefore, this strategy
is rejected.
Instead, DNS-SD implementations can intercept the
<Instance> portion of a Service Instance Name and ensure
that those labels are never handed to IDNA-aware resolvers that
might attempt to convert these labels into A-labels. Under this
approach, the DNS-SD <Instance> portion works as it always
does, but at the cost of using special resolution code built into
the DNS-SD system.
DNS-SD includes a <Service> component in the Service
Instance Name. This component is not really user-facing data, but
is instead control data embedded in the Service Instance Name.
This component includes so-called "underscore labels", which are
labels prepended with U+005F (_). The underscore label convention
was established by DNS SRV () for
identifying metadata inside DNS names. A system-wide resolver (or
DNS middlebox) that cannot handle underscore labels will not work
with DNS-SD at all, so it is safe to suppose that such resolvers
will not attempt to do special processing on these
labels. Therefore, the <Service> portion of the Service
Instance Name will not be subject to the profile.
The <Domain> portion of the Service Instance Name forms
an integral part of the QNAME submitted for DNS resolution, and a
system-wide resolver that is IDNA2008-aware is likely to interpret
labels with UTF-8 in the QNAME as candidates for IDNA2008
processing. Operators of Internationalized Domain Names will
frequently publish them in the DNS as A-labels. Therefore, these
labels will need to be subject to the profile. DNS-SD
implementations ought to identify the <Domain> portion of
the Service Instance Name and treat it subject to IDNA2008 in case
the domain is to be queried from the global DNS. In the event
that the <Domain> portion of the Service Instance Name fails
to resolve, it is acceptable to substitute labels with plain
UTF-8, starting at the lowest label in the DNS tree and working
toward the root. This approach different to the rule for resolution
published in , because it privileges
IDNA2008-compatible labels over UTF-8 labels.
One might argue against this restriction on either of two
grounds:
It is possible the names may be in the DNS in UTF-8, and RFC
6763 already specifies a fallback strategy of progressively
attempting first the U-label lookup and then the A-label
lookup.
Zone administrators that wish to support DNS-SD can publish a
UTF-8 version of the zone along side the A-label version of the
zone.
The first of these is rejected because it represents a potentially
significant increase in DNS lookup traffic for no value. It is
possible for a DNS-SD application to identify the <Domain>
portion of the Service Instance Name. The standard way to publish
IDNs on the Internet uses IDNA. Therefore, additional lookups
should not be encouraged. When was
published, the bulk of IDNs were lower in the tree, but now that
there are internationalized labels in the root zone, it seems
reasonable to use only the single lookup strategy.
The second reason depends on the idea that it is possible to
maintain two names in sync with one another. This is not strictly
speaking true, although in this case the domain operator could
simply create a DNAME record from the
UTF-8 name to the IDNA2008 zone. This still, however, relies on
being able to reach the (UTF-8) name in question, and it is
unlikely that the UTF-8 version of the zone will be delegated from
anywhere. Moreover, in many organizations the support for DNS-SD
and the support for domain name delegations are not performed by
the same department, and depending on a co-ordination between the
two will make the system more fragile or slower or both.
The author gratefully acknowledges the insights of Stuart
Cheshire, Kerry Lynn, and Dave Thaler.
This memo makes no requests of IANA.
This memo presents some requirements for future development, but
does not specify anything. Therefore, it has no implications for security.
DoD Internet host table specification
SRI International
SRI International
SRI International
Domain names - concepts and facilities
Information Sciences Institute (ISI)
Domain names - implementation and specification
USC/ISI
4676 Admiralty Way
Marina del Rey
CA
90291
US
+1 213 822 1511
A DNS RR for specifying the location of services (DNS SRV)
Troll Tech
Waldemar Thranes gate 98B
Oslo
N-0175
NO
+47 22 806390
+47 22 806380
arnt@troll.no
Internet Software Consortium
950 Charter Street
Redwood City
CA
94063
US
+1 650 779 7001
Microsoft Corporation
One Microsoft Way
Redmond
WA
98052
US
levone@microsoft.com
This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.
Unicode Format for Network Interchange
The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]
Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]
Internationalized Domain Names in Applications (IDNA): Protocol
This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]
The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).</t><t> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]
Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]
Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale
Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.
Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.
DNAME Redirection in the DNS
The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]
Multicast DNS
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t><t> Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t><t> The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.
DNS-Based Service Discovery
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.
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
Decided which portions would be affected
Explained the difference in user interfaces between DNS-SD
and usual DNS operation
Provided background on why the Domain portion should be
treated differently