Re: [dnssd] Partial review of draft-ietf-dnssd-mdns-dns-interop-04

[Andrew Sullivan <[e-mail]>]

Hi,

Thanks for the review.  I think there is an issue here that is
apparently not clear enough to you as a reader, so it's really helpful
to learn that.  I'd like to figure out how to make it clearer.

On Wed, Mar 08, 2017 at 04:24:25AM -0800, Jürgen Schönwälder wrote:
 
> Disclaimer: I regret that DNS does not use UTF-8 in its labels, to me
> , as an outside observer, it seems IDNA was a big mistake. But given
> the IETF standards we have, it seems one has to properly IDNA encode
> UTF-8 in DNS labels. 

This isn't exactly correct, and I think that it may be the source of
the problem you had with the document.

DNS as such makes literally no restrictions on what "characters" can
appear in a label, except for length.  A label can have 63 octets.
Any octet is permitted.  Perhaps unfortunately, however, in the
original specification ASCII was treated specially in two ways.
First, labels are matched "case insensitively" in ASCII.  Second, STD
13 recommended the letter,digit,hyphen rule for labels to maximise
compatibility with deployed hostnames.  Because STD 13 was written
before RFC 2119 keywords were in use, the distinctions among good
operational practice and protocol restrictions was not always clear to
every reader, so many people understood LDH to be a DNS restriction,
but it wasn't.

Apart from the special treatment of ASCII, DNS also makes no rules
about character sets.  So, there's no way to tell, for a given label,
what its encoding scheme is -- UTF-8, JIS, ISO-8859-n, or what all.

It is because of the above that we ended up with IDNA.  Nothing about
IDNA prevents other schemes for labels (including using characters
outside the ASCII range).  The possibilities are discussed at some
length in RFC 6055.

At the same time, we know that the root zone and a very large number
of TLDs (maybe all, but I bet not) restrict delegations to LDH, and
that they use some variation of IDNA (including non-IETF IDNA variants
based on UTS#46 -- this is how some TLDs allow registering emoji,
since they weren't "emoji" when IDNA2003 came out and many of the code
points were undefined under Unicode 3.2.  Emoji are DISALLOWED under
IDNA2008 because they're not "letters or digits" in any writing
system).  So, given the distributed administration of the DNS, there
is no way to be sure how a given octet sequence ought to be
interpreted, but we can be fairly sure that some administrators of
some zones will definitely not permit UTF-8 labels in their zones.

This is the problem the I-D is intending to highlight, and it sounds
like it wasn't clear to you.  Is any of the above clearer?  Would any
more introductory material help to make this plain?

> would that be? I looked up RFC 6055 and I am surprised to read text
> about 'intelligent (stub) resolver' there as this seems to be asking
> for trouble. 

Yes :) That's the trouble I think we're in, and it's why I worked on
this I-D in the first place.

> To me, it sounds like you are saying 'some portions of
> the name hierarchy may use raw UTF-8 labels while other portions may
> not and we do not tell you how to set them appart in a reliable
> way'. If this is the approach, then the approach is in my personal
> view broken. (And please recall the disclaimer above.)

It may be broken, but it is the reality in a distributed system with
distributed administration.  One cannot make rules about what other
people put in their zones, and the DNS is already clear that any octet
at all is permitted in the DNS.

> In section 3, what does the term 'implicated' mean?

Would "involved" make it clearer to you?  The point is that different
portions of a DNS-SD name have different properties, and only some of
those are going to have potentially ambiguous i18n encodings in the
DNS.  

> What I do not understand: Why is it desirable to treat DNS labels
> that
> carry DNS-SD Service Instance Names different than any other labels
> that may contain UTF-8 characters? 

Because DNS-SD says that the labels should be raw UTF-8 in the DNS,
and because of IDNA some zones have a policy where raw UTF-8 is not
permitted (and some resolvers may automatically convert U-labels to
A-labels).

> If the IETF believes IDNA is the
> solution for the DNS, why do we then not also use IDNA for UTF-8
> DNS-SD Service Instance Names? Yes, there will be some names that
> will
> be impossible to use but then services in the DNS (as opposed to
> mDNS)
> are likely more infrastructure services and less so end use provided
> services.

The WG discussed that approach and came down hard against it.  In
particular, such an approach definitely disallows certain characters
that some people apparently want, and it disallows spaces whenever the
rest of the label is an IDNA label.  (Spaces are allowed in DNS labels
as a general rule, but they're DISALLOWED under IDNA2008.)

> Back to my role as ops-dir reviewer: This document is more a kind of
> a
> problem statement document, I do not see direct operational impact.
> The trouble with DNS labels is more likely a user facing issues than
> it is a network operational issue (except perhaps for helpdesk
> functions, in particular in enterprise networks).

One of the reasons this document has been difficult to get done is
because it lies at the intersection of protocols and operations.
There are operational policies (such as restriction of i18n in zones
to IDNA) that have consequences for how DNS-SD can work.

I'm aware that you think you're the wrong reviewer, but actually this
review has been terribly helpful to me in understanding the degree to
which it's too hard to understand for part of the target audience.  So
anything we can do to improve that would, in my view as editor, be a
big help.

Thanks!

A

-- 
Andrew Sullivan
Dyn
[e-mail]