Subject: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-02.txt

From: [email-masked]
Date: Sun, 01 Nov 2015 20:07:38 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensions for Scalable DNS Service Discovery  Working Group of the IETF.

        Title           : On Interoperation of Labels Between DNS and Other Resolution Systems
        Author          : Andrew Sullivan
	Filename        : draft-ietf-dnssd-mdns-dns-interop-02.txt
	Pages           : 11
	Date            : 2015-11-01

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
   underlying technology and operational environment.  This memo
   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-mdns-dns-interop-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 2 Nov 2015 00:41:46 -0500

Hi,

> 	Filename        : draft-ietf-dnssd-mdns-dns-interop-02.txt

This is the upload I said I'd make.  Again, apologies for the failure
after Prague.  If anyone wants to beat me up in the hall over any of
this, I am prepared to have that discussion, but I don't expect to
discuss it in any meeting here.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Nov 2015 07:39:42 +0900

Dear Andrew,

Your revised version would have been helpful.  My
understanding of what you wish avoided in the threat review,
humorously referred to as advice on juggling spinning
knives, differs from WG agreements reached at the last meeting.

This covers exceptions made by domain owners who are not
prohibited nor assured produce negative answers.  Such
exceptions clearly demarcated with the use of DNS-SD
conventions permit more liberal repertoires to convey
locally defined network space under current protocol
conventions which may be published globally.  Most of these
conventions have or are now undergoing last call.

There was no mention of a parallel A-label namespace to be
created, nor expectations of negative answers becoming the norm.

You assert DNS-SD conventions will result in a significant
increase in DNS lookup traffic of no value. Further you
assert that since adoption of RFC6763, increased use of IDNA
makes the situation worse.  As such, your view is to rule
out considerations regarding this namespace.

The <Domain> Portion of the Service Instance Name includes
what the DNS-SD Scalable Threats document describes as--

<Instance>._<sn>._<Proto>.<SrvDOM>.<ParentDOM>.

<SrvDOM> is described in RFC6763 as <servicedomain> which
encourages use of a more liberal repertoire. At the last
meeting, it seemed agreement had been reached regarding
exceptions for the <SrvDOM> portion of the namespace.

The modicum of advice was to use '_' in place of punctuation
or spaces to reduce errors in administrative review or those
caused by code expecting neither space or punctuation.  This
advice can be removed if the WG considers it not warranted.
 After all, since RFC6763 was written, applications have
become far better at handling UTF-8. The domain owner will
be impacted by any additional queries caused by erroneous
handling of DNS-SD resources and can assess the value of
allowing more liberal repertoires.

RFC6763 states in section
7.2.  Service Name Length Limits
,--
Typically, DNS-SD service records are placed into subdomains
of their own beneath a company's existing domain name.
Since these subdomains are intended to be accessed through
graphical user interfaces, not typed on a command line, they
are frequently long and descriptive.  Including the length
byte, the user-visible service domain may be up
to 64 bytes.
'--

RFC6763 further states in section
4.1.3.  Domain Names
,--
Because Service Instance Names are not host names, they are
not constrained by the usual rules for host names [RFC1033]
[RFC1034] [RFC1035], and rich-text service subdomains are
allowed and encouraged, for example:

     Building 2, 1st Floor  .  example  .  com  .
...

In cases where the DNS server returns a negative response
for the name in question, client software MAY choose to
retry the query using the "Punycode" algorithm [RFC3492] to
convert the UTF-8 name to an IDNA "A-label" [RFC5890],
beginning with the top-level label, then issuing the query
repeatedly, with successively more labels translated to IDNA
A-labels each time, and giving up if it has converted all
labels to IDNA A-labels and the query still fails.
'--

The interop draft overlooks existing conventions surrounding
DNS-SD and offers far less guidance than that given in the
threat review.  If your assertions are correct about the
risk, much more needs to be said and not less.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Nov 2015 17:37:18 -0500

Hi Doug,

I continue to think that you and I are divided here by a common
language.  I do also think that split-brain DNS is, when also mixing
namespaces, dangerous (and yes, the "spinning knives" remark was
intended to lighten a discussion that can otherwise get heated).  But
it sounds like we need to sit down at some point and see whether I can
better understand how you want this draft to change.  It'll be very
difficult this week, though if you want to talk during bits & bytes
this evening I'll be around.  Alternatively, maybe we need to plan to
talk once everyone has made it back home.  We can try to co-ordinate
off-list?

Best regards,

A

On Tue, Nov 03, 2015 at 07:39:42AM +0900, Douglas Otis wrote:
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

-- 
Andrew Sullivan
[email-masked]