draft-ietf-dnssd-mdns-dns-interop-01.txt   draft-ietf-dnssd-mdns-dns-interop-02.txt 
DNSSD A. Sullivan DNSSD A. Sullivan
Internet-Draft Dyn Internet-Draft Dyn
Intended status: Informational July 4, 2015 Intended status: Informational October 31, 2015
Expires: January 5, 2016 Expires: May 3, 2016
On Interoperation of Labels Between mDNS and DNS On Interoperation of Labels Between DNS and Other Resolution Systems
draft-ietf-dnssd-mdns-dns-interop-01 draft-ietf-dnssd-mdns-dns-interop-02
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.
Moreover, when it uses the DNS, DNS-Based Service Discovery uses the Moreover, when it uses the DNS, DNS-Based Service Discovery uses the
full capability of DNS, rather than using a subset of available full capability of DNS, rather than using a subset of available
octets. In order for DNS-SD to be used effectively in environments octets. In order for DNS-SD to be used effectively in environments
where multiple different name systems and conventions for their where multiple different name systems and conventions for their
operation are in use, it is important to attend to differences in the operation are in use, it is important to attend to differences in the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 5, 2016. This Internet-Draft will expire on May 3, 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Informative References . . . . . . . . . . . . . . . . . . . 8 8. Informative References . . . . . . . . . . . . . . . . . . . 9
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10
A.1. draft-ietf-dnssd-mdns-dns-interop-01 . . . . . . . . . . 10 A.1. draft-ietf-dnssd-mdns-dns-interop-02 . . . . . . . . . . 10
A.2. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 10 A.2. draft-ietf-dnssd-mdns-dns-interop-01 . . . . . . . . . . 11
A.3. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 10 A.3. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 11
A.4. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 10 A.4. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 A.5. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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 the Domain Name System
(DNS, [RFC1034], [RFC1035]); and to any other system that uses domain (DNS, [RFC1034], [RFC1035]); and to any other system that uses domain
names, such as Multicast DNS (mDNS, [RFC6762]). Conventional use of names, such as Multicast DNS (mDNS, [RFC6762]). Conventional use of
the DNS generally follows the host name rules [RFC0952] for labels -- the DNS generally follows the host name rules [RFC0952] for labels --
the so-called LDH rule. That convention is the reason behind the the so-called LDH rule. That convention is the reason behind the
development of Internationalized Domain Names for Applications development of Internationalized Domain Names for Applications
skipping to change at page 5, line 32 skipping to change at page 5, line 32
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
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.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
resolution mechanisms (such as mDNS) could permit labels that IDNA resolution mechanisms (such as mDNS) could permit labels that IDNA
does not, the profile might reduce the labels that could be used with does not, the profile might reduce the labels that could be used with
those other resolution mechanisms. One consequence of this is that those other resolution mechanisms. One consequence of this is that
some recommendations from [RFC6763] will not really be possible to some recommendations from [RFC6763] will not really be possible to
implement using names subject to the profile. In particular, implement using names subject to the profile. In particular,
[RFC6763], section 4.1.3 recommends that labels always be stored and [RFC6763], section 4.1.3 recommends that labels always be stored and
communicated as UTF-8, even in the DNS. Because of the way the communicated as UTF-8, even in the DNS. Because of the way the
public DNS is currently operated (see Section 2), the advice to store public DNS is currently operated (see Section 2), the advice to store
and transmit labels as UTF-8 in the DNS is likely either to encounter and transmit labels as UTF-8 in the DNS is likely either to encounter
problems or result in unnecessary traffic to the public DNS (or problems or result in unnecessary traffic to the public DNS (or
both). In particular, the <Domain> part of a Service Instance Name both). In particular, many labels in the <Domain> part of a Service
is unlikely to be found in its UTF-8 form in the public DNS tree for Instance Name is unlikely to be found in its UTF-8 form in the public
zones that are using IDNA2008. By contrast, for example, mDNS DNS tree for zones that are using IDNA2008. By contrast, for
normally uses UTF-8. example, mDNS 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 (or there is such a diacritic in the label. Labels in mDNS names (or
other resolution technologies) may contain upper case characters, so other resolution technologies) may contain upper case characters, so
the profile will need either to restrict the use of upper case or the profile will need either to restrict the use of upper case or
come up with a reliable and predictable (to users) convention for come up with a reliable and predictable (to users) convention for
case folding even in the presence of diacritics. case folding even in the presence of diacritics.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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.
Some resolvers -- particularly those that are used in mixed DNS and
non-DNS environments -- may be aware of different operational
conventions in different parts of the DNS tree. For example, it may
be possible for implementations to use hints about the boundary of an
organization's domain name infrastructure, in order to tell (for
instance) that example.com. is part of the Example Organization while
com. is a large delegation-centric zone on the public Internet. In
such cases, the resolution system might reverse its preferences to
prefer plain UTF-8 labels when resolving names below the boundary
point in the DNS tree. The result would be that any lookup past the
boundary point and closer to the root would use LDH-labels first,
falling back to UTF-8 only after a failure; but a lookup below the
boundary point would use UTF-8 labels first, and try other strategies
only in case of negative answers. The mechanism to learn such a
boundary is beyond the scope of this document.
5. Acknowledgements 5. Acknowledgements
The author gratefully acknowledges the insights of Stuart Cheshire, The author gratefully acknowledges the insights of Joe Abley, Stuart
Kerry Lynn, and Dave Thaler. Kerry Lynn deserves special gratitude Cheshire, Paul Hoffman, Kerry Lynn, and Dave Thaler. Kerry Lynn
for his energy and persistence in pressing unanswered questions. deserves special gratitude for his energy and persistence in pressing
unanswered questions. Doug Otis sent many comments about visual
confusability.
6. IANA Considerations 6. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
7. 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. It makes no additional security-specific
security. requirements. Issues arising due to visual confusability of names
apply to this case as well as to any other case of internationalized
names, but interoperation between different resolution systems and
conventions does not alter the severity of those issues.
8. Informative References 8. Informative References
[I-D.ietf-dnsop-dns-terminology] [I-D.ietf-dnsop-dns-terminology]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-ietf-dnsop-dns-terminology-03 (work in Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
progress), June 2015. progress), September 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.
skipping to change at page 10, line 13 skipping to change at page 10, line 36
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-01 Note to RFC Editor: this section should be removed prior to
publication.
A.1. 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.2. draft-ietf-dnssd-mdns-dns-interop-01
Alter text to make clear that the main issue is the way the public Alter text to make clear that the main issue is the way the public
DNS is currently administered, not system resolvers. I suppose this DNS is currently administered, not system resolvers. I suppose this
should have been clear before, but I didn't do that. Many thanks to 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 Kerry Lynn for penetrating questions that illuminated what I'd left
out. out.
A.2. draft-ietf-dnssd-mdns-dns-interop-00 A.3. 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.3. draft-sullivan-dnssd-mdns-dns-interop-01 A.4. 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.4. draft-sullivan-dnssd-mdns-dns-interop-00 A.5. 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. 15 change blocks. 
29 lines changed or deleted 66 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/