Subject: [mdnsext] Differences between mDNS and DNS names.

From: Simon Kelley <[email-masked]>
Date: Tue, 06 Nov 2012 23:41:26 +0000

At the BOF it was pointed out that mDNS names are UTF-8 and DNS names 
are not. DNS names are encoded using IDNA, which is specified in RFC 3490.

This shouldn't be a problem: both UTF-8 and IDNA are encodings for 
unicode, they're just different ways to represent a string of unicode in 
an octet stream which has some arbitrary constraints. As such, 
interconverting between the two representations is well defined, 
lossless, and fairly straightforward.

You can't use the wire format of mDNS packets as unicast DNS packets or 
vice versa*, but you can convert one to the other at higher level.

Cheers,

Simon.

* and not just because of the name encoding, there are other subtle 
differences, for example mDNS reply packets don't include the question 
section, whilst unicast DNS replies do.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 7 Nov 2012 07:09:06 +0100

There might be a few differences.

First of all, IDNA compatible strings can be A-LABEL (encoded in punycode) or U-LABEL (unicode strings). There is a 1:1 mapping between the two.

There would be a larger difference in the cases mdns requires (or not) some normalization of a unicode string before it is UTF-8 encoded. And that must be defined or else comparison of UTF-8 strings in mdns is undefined.

   Patrik

On 7 nov 2012, at 00:41, Simon Kelley <[email-masked]> wrote:

> At the BOF it was pointed out that mDNS names are UTF-8 and DNS names are not. DNS names are encoded using IDNA, which is specified in RFC 3490.
> 
> This shouldn't be a problem: both UTF-8 and IDNA are encodings for unicode, they're just different ways to represent a string of unicode in an octet stream which has some arbitrary constraints. As such, interconverting between the two representations is well defined, lossless, and fairly straightforward.
> 
> You can't use the wire format of mDNS packets as unicast DNS packets or vice versa*, but you can convert one to the other at higher level.
> 
> Cheers,
> 
> Simon.
> 
> * and not just because of the name encoding, there are other subtle differences, for example mDNS reply packets don't include the question section, whilst unicast DNS replies do.
> 
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Nov 2012 07:35:57 -0500

Dear colleagues,

On Tue, Nov 06, 2012 at 11:41:26PM +0000, Simon Kelley wrote:
> At the BOF it was pointed out that mDNS names are UTF-8 and DNS
> names are not. DNS names are encoded using IDNA, which is specified
> in RFC 3490.

It is actually slightly more complicated than that.

First of all, DNS names _can_ have UTF-8 in them.  RFC 1034 and 1035
are perfectly clear, and if they weren't 2181 made it perfectly clear,
that labels are octets, and that they can therefore contain anything.
So at one level, DNS labels _might_ be UTF-8.  And indeed, several
enterprise-aimed systems have used this feature of the DNS in order to
offer internationalization in their systems. 

But, IDNA (RFC 3490 is obsoleted by RFCs 5890-5895) effectively makes
IDNA2008-aware applications never look up labels that contain such
UTF-8, instead processing the candidate U-labels into A-labels and
then looking those up in the DNS.  We've just spent many years
convincing applications that they need to handle this UTF-8 input by
peforming a transformation on it, so backing off that position seem
unreasonable about now.

Slightly worse, IDNA2008 doesn't actually allow some of the things
that mDNS wants to permit.  For instance, the latest multicastdns
draft (-15) includes punctuation and spaces as desiderata for mDNS
labels.  But IDNA2008 explicitly excludes punctuation on purpose, so
the code point U+0027 (') isn't permitted under IDNA2008.  Also, just
for grins, using IDNA2008, Andrew == andrew, but André is not a legal
U-label at all (because it has an upper case character in it).  The
application is supposed to do something (probably case fold to andré),
but that of course loses information (the capitalization).  Similarly,
as near as I can tell mDNS permits all manner of things that IDNA does
not, and has no bidi rule, so that the edge cases are bound to be very
hard to cope with.  What do you do when confronted with conjoining
Hangul Jamo, for instance, in mDNS?  Because in IDNA2008, it's not
allowed.  One can argue that these are all corner cases, but there are
enough corners so as to round out the problem.

As long as mDNS remains by definition in a purely local context (and
is a separate protocol), there is nothing wrong with these
differences, because you are always looking up using one protocol or
the other.  If, however, the two protocols are to be presented as
having a single scope, then we have a problem because the user has to
have a theory of which protocol is in use in order to make correct
guesses about which kind of label will work.  If you think working
TSIG is hard for users, imagine explaining to them why it's Andrew's
Laptop but andrewslaptop.mystuff.example.com.

I believe that we are more likely to have some success if we figure
out ways to make the two different protocols somehow complementary to
one another, and we establish ways in which one can move from one
context to another with minimal disruption.  I'm not sure how to do
that yet, but maybe sleep will improve matters and I'll have something
useful to say about this aside from, "Boy, this is tricky."

Best,

A

-- 
Andrew Sullivan
[email-masked]