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

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 08 Mar 2017 04:24:25 -0800

Review is partially done. Another review request has been registered
for completing it.

Reviewer: Jürgen Schönwälder
Review result: Not Ready

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. (As an outsider, I am puzzled by documents that
say that for some portions of the DNS name hierarchy this is not true
and it is left vague how to precisely determine where in the
namespace
IDNA has to be used and where not.)  So now that you understand my
ignorance, I hope you understand what follows below may just be plain
wrong...

In section 2, I do not understand this statement:

   The greater problem is that the "infrastructure" types of DNS
service
   -- the root zone, the top-level domains, and so on -- have
embraced
   IDNA and refuse registration of raw UTF-8 into their zones. As of
   this writing there is (perhaps unfortunately) no reliable way to
   discover where these sorts of DNS services end.

Not sure what this is trying to convey. Are you saying that using
plain UTF in DNS labels is OK if it is far enough from the root?  Why
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. 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.)

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

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? 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. And at the end, the limitation is the result of the DNS /
IDNA approach, so you get what you asked for. (Again, please recall
the disclaimer).

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).

Bottom line: I am the wrong reviewer for this document. I think the
authors should specifically seek reviews and comments from people
active in the DNSOP working group.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Mar 2017 10:44:59 -0500

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:
 
> 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?

> 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

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.  

> 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
> 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.)

> 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
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Mar 2017 12:25:31 +0100

Andrew,

your response is helpful for me to understand things better. The
situation indeed seems complicated.

> every reader, so many people understood LDH to be a DNS restriction,

This was clear to me since I am well aware that the DNS protocol ships
octets.

> what its encoding scheme is -- UTF-8, JIS, ISO-8859-n, or what all.

Yes, but historically (if I understand things right), the character
set was effectively restricted to LDH (ASCII) - the restriction was
not part of the protocol but imposed by other 'recommendations'.

> outside the ASCII range).  The possibilities are discussed at some

With a time machine available, we should probably have moved from LDH
(ASCII) to UTF-8 (or a subset of UTF-8). Multiple different character
_encodings_ in the label space can't really be a feature. Note that I
consider further restrictions (i.e., use of white space) something
separate from the encoding scheme used.

I think I recall that people said back in a day that moving from LDH
to UTF-8 may be risky since we do not know whether all DNS
implementations got the "DNS ships octets" thing right. And there may
be situations where entering a UTF-8 name correctly may not be
feasible on certain devices. Looking back in time, these may have been
valid concerns back then but they are likely less so today and instead
of having a transition plan to have UTF-8 encoded labels we went for a
solution that gives us complexity forever. [And yes, I do not know all
the details of the discussions and so I am likely summarizing things
up very wrongly.] But from an outsider perspective, it seems that
having (i) a transition plan to UTF-8 encoding of labels and (ii) a
clear separation of further label restrictions from the encoding
aspects would have been desirable.

> some zones will definitely not permit UTF-8 labels in their zones.

Well, obviously, this is the clunky result we have now.

> more introductory material help to make this plain?

For me personally, it would have been good to know more about what is
out there. I understand traditional LDH labels and I understand
IDNA2003 and IDNA2008 labels. I understand that mDNS says UTF-8 and
pretty much no restrictions on instance portion of a service name.
Are there significant deployments out there that use other encodings
or restrictions?

> at all is permitted in the DNS.

The protocol ships octets. The question is how to interpret them. If
there would be agreement that the octets by default represent UTF-8
encoded characters life would start to be somewhat simpler. This would
solve the encoding part, it does not solve the 'which restrictions
apply to this label part'. OK, I am ignorant of the complexity of
deploying this but a decent transition plan to something simpler may
be better long term than more layeres of things that do not play well
together.

> permitted (and some resolvers may automatically convert U-labels to

Yes, sounds like a decent conflict asking for surprises.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Mar 2017 17:17:32 +0000

Hi,

> On 12 Mar 2017, at 11:25, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Andrew,
> 

The discussion below is useful, and I suspect many people will have similar comments to Juergen's. One question is therefore whether additional or different wording would help better set the context of the document. I think the meat of the text is good, and Andrew has done a great job in pulling together the input that’s been made, but we’ve been staring at it for some time now in dnssd, and are perhaps overly familiar with it. 

Any suggestions are very welcome!

>> those are going to have potentially ambiguous i18n encodings in the

Perhaps “included” works better than “implicated", but that’s pure personal preference.

> Yes, sounds like a decent conflict asking for surprises.

Best wishes,
Tim (dnssd co-chair)