--- 1/draft-ietf-dnssd-mdns-dns-interop-01.txt 2015-11-01 20:15:19.288888611 -0800 +++ 2/draft-ietf-dnssd-mdns-dns-interop-02.txt 2015-11-01 20:15:19.320889371 -0800 @@ -1,18 +1,18 @@ DNSSD A. Sullivan Internet-Draft Dyn -Intended status: Informational July 4, 2015 -Expires: January 5, 2016 +Intended status: Informational October 31, 2015 +Expires: May 3, 2016 - On Interoperation of Labels Between mDNS and DNS - draft-ietf-dnssd-mdns-dns-interop-01 + On Interoperation of Labels Between DNS and Other Resolution Systems + draft-ietf-dnssd-mdns-dns-interop-02 Abstract Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the @@ -29,21 +29,21 @@ 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 January 5, 2016. + This Internet-Draft will expire on May 3, 2016. Copyright Notice Copyright (c) 2015 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 @@ -60,29 +60,30 @@ 2. Why there could be a problem at all . . . . . . . . . . . . . 4 3. Requirements for a profile for label interoperation . . . . . 5 4. DNS-SD portions . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. The Portion of the Service Instance Name . . . . . . . . . . . . . . . . . . . . . . 6 4.2. The Portion of the Service Instance Name . . . . . . . . . . . . . . . . . . . . . . 7 4.3. The Portion of the Service Instance Name . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 8. Informative References . . . . . . . . . . . . . . . . . . . 8 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 8. Informative References . . . . . . . . . . . . . . . . . . . 9 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 + A.1. draft-ietf-dnssd-mdns-dns-interop-02 . . . . . . . . . . 10 + A.2. draft-ietf-dnssd-mdns-dns-interop-01 . . . . . . . . . . 11 + A.3. draft-ietf-dnssd-mdns-dns-interop-00 . . . . . . . . . . 11 + A.4. draft-sullivan-dnssd-mdns-dns-interop-01 . . . . . . . . 11 + A.5. draft-sullivan-dnssd-mdns-dns-interop-00 . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction DNS-Based Service Discovery (DNS-SD, [RFC6763]) specifies a mechanism for discovering services using queries to the Domain Name System (DNS, [RFC1034], [RFC1035]); and to any other system that uses domain names, such as 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 @@ -209,21 +210,21 @@ 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 + 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 domain name slot, care must be taken by DNS-SD-aware resolvers to 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 will not accidentally undergo IDNA processing. @@ -233,24 +234,24 @@ resolution mechanisms (such as mDNS) could permit labels that IDNA does not, the profile might reduce the labels that could be used with those other resolution mechanisms. One consequence of this is that 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 labels always be stored and 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 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 - both). In particular, the 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. + both). In particular, many labels in the 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. 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 (or other resolution technologies) 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. @@ -351,42 +352,63 @@ true, although in this case the domain operator could simply create a 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 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. + 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 - The author gratefully acknowledges the insights of Stuart Cheshire, - Kerry Lynn, and Dave Thaler. Kerry Lynn deserves special gratitude - for his energy and persistence in pressing unanswered questions. + 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. 7. Security Considerations This memo presents some requirements for future development, but does - not specify anything. Therefore, it has no implications for - security. + not specify anything. It makes no additional security-specific + 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 [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. + Terminology", draft-ietf-dnsop-dns-terminology-05 (work in + progress), September 2015. [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. @@ -431,46 +453,61 @@ DNS", RFC 6672, June 2012. [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. 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 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 +A.3. 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.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 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.4. draft-sullivan-dnssd-mdns-dns-interop-00 +A.5. draft-sullivan-dnssd-mdns-dns-interop-00 Initial version. Author's Address Andrew Sullivan Dyn 150 Dow St. Manchester, NH 03101 U.S.A.