IETF A. Sullivan
Internet-Draft Dyn
Intended status: Informational January 22, 2014
Expires: July 26, 2014
Requirements for Labels to Interoperate Between mDNS and DNS
draft-sullivan-dnssd-mdns-dns-interop-00
Abstract
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 follow a common set of conventions for naming. This
memo presents an outline of the reqiurements for selection of labels
for mDNS and DNS when they are expected to interoperate in this
manner.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Sullivan Expires July 26, 2014 [Page 1]
Internet-Draft mDNS and DNS Interop January 2014
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and terms used in this document . . . . . . . 3
2. Requirements for a profile for label interoperation . . . . . 3
3. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. The <Instance> Portion of the Service Instance Name . 4
3.2. The <Service> Portion of the Service Instance Name . 5
3.3. The <Domain> Portion of the Service Instance Name . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Informative References . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism
for discovering services using queries both to the Domain Name System
(DNS, [RFC1034], [RFC1035]) and to Multicast DNS (mDNS, [RFC6762]).
Conventional use of the DNS generally follows the host name rules
[RFC0952] for labels -- the so-called LDH rule. That convention is
the reason behind the development of Internationalized Domain Names
for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892],
[RFC5893], [RFC5894], [RFC5895]). 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 [RFC6763], 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 [RFC5198]
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
Sullivan Expires July 26, 2014 [Page 2]
Internet-Draft mDNS and DNS Interop January 2014
for services, then 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 posits such a use profile, and outlines what is
necessary to make it work.
1.1. Conventions and terms used in this document
Wherever appropriate, this memo uses the terminology defined in
Section 2 of [RFC5890]. In particular, the reader is assumed to be
familiar with the terms "U-label", "LDH label", and "A-label" from
that document. Similarly, the reader is assumed to be familiar with
the U+NNNN notation for Unicode code points used in [RFC5890] and
other documents dealing with Unicode code points. In the interests
of brevity and consistency, the definitions are not repeated here.
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.
2. Requirements for a profile for label interoperation
Any interoperability between mDNS and DNS will require
interoperability across some of the portions of a DNS-SD Service
Instance Name (see Section 3) that are implicated in regular mDNS and
DNS lookups. The open question is which of the portions are
implicated. In any case, if a given portion is implicated, the
profile will need to apply to all labels in that portion.
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 will reduce the labels that may be
used with mDNS. Consequently, some recommendations from [RFC6763]
will not really be possible to implement using names subject to the
profile. In particular, [RFC6763], section 4.1.3 recommends that
rich text, human-readable labels be used, and includes punctuation
and space characters in the examples. It is not clear whether such
uses will be possible, because spaces and most punctuation are
permitted neither in U-labels nor in LDH labels. In addition, the
Sullivan Expires July 26, 2014 [Page 3]
Internet-Draft mDNS and DNS Interop January 2014
same section 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. 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 convention for case folding.
3. DNS-SD portions
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 [RFC6763], section 4.1.
3.1. The <Instance> Portion of the Service Instance Name
[RFC6763] is clear that the <Instance> portion of the Service
Instance Name is intended for presentation to users, and therefore
virtually any character is permitted in it. There are two ways that
a profile might address this portion; a specification of the profile
will need to select one of these strategies.
The first option is 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.
The second option is to specify that the portion never be handled by
"normal" DNS resolution, and that it instead be handled by a special
DNS-SD resolution path. In this case, DNS-SD works as it always
does, but at the cost of a possibly more complicated system-wide
resolver or special resolution code built into the DNS-SD system.
Sullivan Expires July 26, 2014 [Page 4]
Internet-Draft mDNS and DNS Interop January 2014
3.2. The <Service> Portion of the Service Instance Name
DNS-SD includes a <Service> component in the Service Instance Name.
This component is not really user-facing data, 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
([RFC2782]) for identifying metadata inside DNS names. A system-wide
resolver (or DNS middlebox) that cannot handle underscore labels will
not work with DNS-SD at all, so it is safe to suppose that such
resolvers will not attempt to do special processing on these labels.
Therefore, the <Service> portion of the Service Instance Name will
not be subject to the profile.
3.3. The <Domain> Portion of the Service Instance Name
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. Therefore,
these labels will need to be subject to the profile.
4. Acknowledgements
The author gratefully acknowledges the insights of Kerry Lynn.
5. IANA Considerations
This memo makes no requests of IANA.
6. Security Considerations
This memo presents some requirements for future development, but does
not specify anything. Therefore, it has no imlpications for
security.
7. Informative References
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Sullivan Expires July 26, 2014 [Page 5]
Internet-Draft mDNS and DNS Interop January 2014
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5892] Faltstrom, P., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)",
RFC 5892, August 2010.
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
Internationalized Domain Names for Applications (IDNA)",
RFC 5893, August 2010.
[RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, August 2010.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, September 2010.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
Author's Address
Andrew Sullivan
Dyn
150 Dow St.
Manchester, NH 03101
U.S.A.
Email: asullivan@dyn.com
Sullivan Expires July 26, 2014 [Page 6]