Subject: [dnssd] dnssd WG agenda, London

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Sun, 9 Feb 2014 17:37:56 +0000

Tim and I have put together a tentative partial agenda for our London meeting, which I've included below.  Please respond to us by Friday, Feb 14 with requests for additional agenda slots.

Discussion of revised WG document: draft-ietf-dnssd-requirements, 30-45 minutes
Discussion of DNS/mDNS interoperability: draft-sullivan-dnssd-mdns-dns-interop, 20-30 minutes
Discussion of service discovery naming architecture, 15-20 minutes

- Tim and Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Feb 2014 20:52:26 -0500

I included a small typo in my previous e-mail.  The draft agenda include these topics:

Is there any interest on the part of WG participants who won't be in London in arranging for meetecho service during the WG meeting?

- Ralph

On Feb 9, 2014, at 12:37 PM 2/9/14, Ralph Droms (rdroms) <[email-masked]> wrote:

> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Feb 2014 10:08:12 -0500

> Discussion of DNS/mDNS interoperability: draft-sullivan-dnssd-mdns-dns-interop, 20-30 minutes

My impression was that nobody else thinks this is a problem: the only
people who responded in the discussion more or less told me I was
talking about stuff that can't possibly be a problem.  

While I disagree, I'd hate to waste 20 minutes of people's lives for
something nobody else thinks to be a problem.  Is there anyone else
who thinks this is worth discussing?  If not, we could return the time
to the WG.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Feb 2014 10:12:34 -0500

> who thinks this is worth discussing?  If not, we could return the time

I think it's worth talking about.   I'd be a little surprised if people really don't think it needs to be talked about.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Feb 2014 10:19:13 -0500

> who thinks this is worth discussing?  If not, we could return the time

Well ... *I* think it's worth discussing and I'll guess Kerry thinks so, as well.  He and I have been poking around a little at the theory and practice and are trying to identify:

(a) any pitfalls that arise in the specific case of DNS-SD
(b) any simplifying assumptions that we can make, based on that use case

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 13 Feb 2014 16:25:16 -0500

On Thu, Feb 13, 2014 at 10:19 AM, Ralph Droms <[email-masked]> wrote:

> >> Discussion of DNS/mDNS interoperability:
> draft-sullivan-dnssd-mdns-dns-interop, 20-30 minutes
> >
> Well ... *I* think it's worth discussing and I'll guess Kerry thinks so,
> as well.  He and I have been poking around a little at the theory and
> practice and are trying to identify:
>
> I would count myself in the group of people who don't completely understand
the problem (and perhaps this set has only one member) .  Let me check my
understanding:

- There seems to be general agreement that DNS messages can transport, and
  DNS servers will store, arbitrary 8-bit data.

- The LDH convention for labels became established because of limitations
  in certain applications in the 1980's.

- IDNA specifies the conversion of restricted forms of labels containing
non-
  ASCII codepoints (U-labels) into A-labels that conform to the LDH
convention.

- There seems to be concern (based on experience?) that some resolver
  libraries or middle boxes may surreptitiously convert U-labels to A-labels
  on behalf of the client.

Where I lose the plot is that underscores in labels have been around since
[RFC 2782].  Such labels are non-LDH and not U-labels (so they cannot be
converted to A-labels).

I assume the underscore labels are stored in the DNS?  How do the resolver
libraries of concern treat labels that cannot be converted by IDNA?

Now Stuart has pointed out that DNS-SD (Bonjour) resolver libraries are
available from Apple for OS X and Windows.  Linux has Avahi.  I think it's
safe to say these transparently pass whatever name is passed in the query.

So what exactly is the problem and how do we characterize it?  I think this
deserves a time slot, if only to get everyone on the same page concerning
this question.  Hopefully we can continue discussing it on the list over the
next two weeks.

Regards, -K-

> https://www.ietf.org/mailman/listinfo/dn<https://www.ietf.org/mailman/listinfo/dnssd>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Feb 2014 18:48:45 -0500

Hi,

>   DNS servers will store, arbitrary 8-bit data.

Yes.  More exactly, every DNS label (the part between the dots in
presentation format -- the dots don't exist in the protocol and are
there for human consumption) is made up of a series of octets that is
at most 63 octets long.

>   in certain applications in the 1980's.

Sort of.  The DNS was launched into a world in which applications had
rules about what qualified as a host name (this is the "host name
syntax") and this got enshrined in the "preferred syntax" specified in
RFC 1034.  But approximately, yes.  

>   ASCII codepoints (U-labels) into A-labels that conform to the LDH

Yes.  

>   libraries or middle boxes may surreptitiously convert U-labels to A-labels

I don't think this is quite right.  We knew that there were middle
boxes and, more importantly, deployed applications that would spit up
on non-LDH names if fed them.  That was the reason to do IDNA in the
first place.  Otherwise, we could have just put UTF-8 labels into the
DNS.  The problem was that we wanted names to work everywhere no
matter what, because they're such an important substrate for
everything.  

But, having adopted the IDNA approach for DNS names, we sort of
encouraged the idea that some of the intelligence could be pushed down
into the resolver layer.  And this is in fact consistent with the
overall drift of system resolver libraries, which protect applications
from knowing what kind of name they're looking up.  There's extensive
discussion of this in RFC 6055.  It makes the following recommendations:

   Instead, conversion to A-label form, or any other special encoding
   required by a particular name-lookup protocol, should be done only by
   an entity that knows which protocol will be used (e.g., the DNS
   resolver, or getaddrinfo() upon deciding to pass the name to DNS),
   rather than by general applications that call protocol-independent
   name resolution APIs.  

[…]

   That is, a more intelligent DNS resolver would be more liberal in
   what it would accept from an application and be able to query for
   both a name in A-label form (e.g., over the Internet) and a UTF-8
   name (e.g., over a corporate network with a private namespace) in
   case the server only recognizes one.  However, we might also take
   into account that the various resolution behaviors discussed earlier
   could also occur with record updates (e.g., with Dynamic Update
   [RFC2136]), resulting in some names being registered in a local
   network's private namespace by applications doing conversion to
   A-labels, and other names being registered using UTF-8.  Hence, a
   name might have to be queried with both encodings to be sure to
   succeed without changes to DNS servers.
    
Stuart seems to believe that the layer contemplated above will be able
to tell when a query going through this resolver is being made for
DNS-SD (so it should be in UTF-8, except of course we might spew UTF-8
queries at the root and TLD servers, but that's just how DNS-SD is
defined).  I am less convinced, so I thought a profile would be helpful.
 
> [RFC 2782].  Such labels are non-LDH and not U-labels (so they cannot be

Correct.  But they're generally metadata labels (they're effectively
used as an alternative namespace extention mechanism because people
didn't know how to do RRTYPEs).  So the application issues don't apply
to these, and resolver libraries know that these underscores have to
be handled as throughput.  Also, we don't have two ways to handle
underscores.

> libraries of concern treat labels that cannot be converted by IDNA?

In this case, they're _never_ candidates for IDNA, so there's no problem.

> safe to say these transparently pass whatever name is passed in the query.

I heard someone claim in the last DNS-SD meeting that the Windows
resolver does try to do IDNA for the system.  I don't know what that
means, and I also don't know whether DNS-SD tries to use that system
resolver.  The issue I see is that, if there _is_ such a resolver in
the way, it may take the label "Téléviseur 1: 2ième étage" and try to
pass it through the IDNA function, determine it's a DISALLOWED
putative U-label, and throw an error.  If we think that will never
happen, then I am worried about nothing.  If we think it might, then
we ought to say something about it.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Feb 2014 16:35:12 -0800

> be handled as throughput.  Also, we don't have two ways to handle

These resources can still be shared globally and used with things like email.

> we ought to say something about it.

Dear Andrew,

I agree. There is a problem needing to be resolved, but it should not affect all levels of DNS equally. Problems involved with firewalls might be helped by simply replacing problematic ASCII punctuation and spaces with '_' within label while using a TLD depth rule.  Such simplistic techniques may get closer to something that can be implemented within a short timeframe.  The draft I wrote contains several errors I'll attempt to repair.  mDNS also talks about DNSSEC, but mDNS lacks transaction IDs, SOAs, etc.  It is hard to imagine how mDNSSEC could work unless completely translated into DNS.  

Apple has offered some good examples of how mDNS DNS-SD might be cobbled together using Kerberos, DNS, and likely LDAP. 
https://tools.ietf.org/html/rfc6281

Ways the RFC6281 breaks can be helped with use of RBridge solutions. Speaking with someone in the Trill WG might clarify what would be involved.  I also suspect this approach would overcome many homenet issues without the need for "trust anchors".  Not an easy problem to solve with few good examples. 

http://www.univention.de also offers a Debian based platform that can support something like BTMM, for example.

In Asia, it is fairly common to see websites using a mixture of UTF-8 and A-Labels within their own domains to afford users a better experience.  I suspect many users might be using XP which has reached its End of Life but still enjoys a significant portion of the market. :^(

Regards,
Douglas Otis

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 13 Feb 2014 19:05:30 -0800

> defined).  I am less convinced, so I thought a profile would be helpful.

Let me offer a little refinement on this topic.

When we started DNS-SD, Punycode TLDs (or SLDs) did not exist, so it was a non-problem. Even today, the overlap between people using wide-area DNS-SD and people using Punycode TLDs (or SLDs) is little-to-none, so for now it remains a largely theoretical problem.

Should we enjoy a great success, and use of wide-area DNS-SD with Punycode parent domains becomes significant, then we have a couple of choices how to proceed:

1. Decide that it’s acceptable to have a UTF-8 query to a parent name server followed by the Punycode equivalent, and leave it as is.

2. Make the name servers a little smarter, so that instead of rejecting the UTF-8 query, they answer it. This could be done two ways: (a) by modifying the server software, or (b) by modifying the zone file.

In technique (a) if an authoritative name server receives a query for a name containing UTF-8 octets, and it has no matching name, then before returning NXDOMAIN it first checks if it has the corresponding Punycode name. If it does, then it treats it effectively as an alias, and returns the corresponding rdata. The authoritative name server is just being smarter -- if it can reasonably predict that a failed UTF-8 query will be followed immediately by the Punycode equivalent, it can save a round-trip by just recognising this and directly giving the client the data it wants.

In technique (b), we don’t touch the server software and instead edit the zone file. For every Punycode name in the zone file we add the corresponding UTF-8 name with the same rdata. This is easy to do and works with today’s existing name server software -- indeed, I was using UTF-8 DNS names back in the 1990s using BIND 4. By putting both names in the zone file, you give clients the choice of querying with a UTF-8 name or querying with the Punycode equivalent, but both queries return the same rdata.

Andrew, I think you and I agree on what the problem is, and we may be pretty close to agreeing on how best to solve it. I think this is an important issue to resolve, and worthy of face-to-face discussion time on the London meeting agenda.

Stuart Cheshire