[dnssd] draft-ietf-dnssd-mdns-dns-interop and draft-otis-dnssd-scalable-dns-sd-threats

[Douglas Otis <[e-mail]>]

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