Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-01.txt

[Andrew Sullivan <[e-mail]>]

On Wed, Jul 08, 2015 at 12:48:41AM -0700, Douglas Otis wrote:
> 
> Section 4.3 seems to conflate DNS as always meaning fully
> public global DNS. In the case of mDNS, this is likely not
> the case

I don't know what you mean by "conflate DNS as always meaning fully
public global DNS".  It is true _by definition_ that "the DNS" entails
a single tree with a single root.  It's certainly true that you can
arrange things just right so that query-originators to you will see
things that query-originators to other name servers will not see.  But
once you've put things in the DNS, any hope that you have that it will
be private -- even in your split-brain arrangements -- are just
wishful thinking.  We have learned this over and over again, and I
don't see why it ought to be controversial; I also don't know how it's
relevant here.

I also don't know what you mean by the second sentence here, since "in
the case of mDNS" is by definition not the public global DNS -- it's a
completely different protocol.

> Change to:
> Operators of internationalized domain names frequently
> publish such names in the DNS as A-labels; these A-labels
> will be subject to the profile. Any namespace not included
> in the profile should be excluded from resolving in a global
> context.

As I said last time, I don't see what "these A-labels will be subject
to the profile" adds and I find it confusing.  Moreover, we _cannot_
rule out resolution in the DNS "from resolving in a global context".
Here's an example of why.

As Stuart has pointed out repeatedly, some enterprises already use
DNS-SD in its "wide area" form -- that is, in the DNS.  Such a name
might have the following form:

    3rd Floor Copier Printer.West Wing.example.com

In a zone file, that is encoded as

    3rd\ Floor\ Copier\ Printer.West\ Wing.example.com

The hex encoding of this to the wire format is left as an exercise,
but the key point is that when you query (for instance) the
example.com zone for that you send the entire owner name as the qname
you're trying to look up.  Your formulation would prohibit this, and
we heard in previous meetings that the WG explicitly does _not_ want
that, but instead wants a fallback to the DNS-SD (and for that matter
non-IDNA) forms.  I think, moreover, that anything that attempts to
insist on formal backward incompatibility is doomed to failure.

> Rather than omitting an important consideration, state the
> need for global exclusions.

But see above.  There is not in fact such a need; rather, stating such
a need would be false.

> 
> The point missed seems related to risks caused by not
> differentiating local and global namespaces as illustrated
> in the following examples.

You seem to think that there are "local" and "global" namespaces and
we know which is which in advance.  But we don't.  That's _exactly_
the problem.  If we knew that in advance, we would know which
resolution system to use, and we would have no issue at all.
 
> A DDoS risk occurs whenever RFC6763 DNS-SD resources are
> given Internet accessed from either mDNS or DNS servers.

There is no such thing as an mDNS server.  I'm having an increasingly
hard time understanding what you're talking about, and I'm
decreasingly convinced that this is because of a fault in my own
understanding.  DDoS is a risk from large answers in the DNS; this is
well known.  I do not believe that this document is the place to
attempt to discuss that in detail.  To begin with, DNSOP is another
WG.  I see nothing wrong with writing a document from DNSOP saying,
"Large answer sets present a danger to DNS operations," but I don't
believe that one needs to repeat that advice in every single document
anywhere that mentions the DNS.

> See RFC6763 Section 7.2. Granting brows-able access to
> DNS-SD resources using either mDNS or DNS resolvers allows a
> wildcard at an instance location to respond with as many as
> 839 separate and combined resources. Blocking wildcard use
> defeats its intended use, normally safe on a local network.

So, do you want the security considerations section to have a sentence
that says, "Any use of the DNS that follows the outlines of this
document necessarily incurs all DDoS risks resulting from the use of
DNS"?  I'm prepared to add that if you like.

> It is not clear why mDNS resources moved to DNS

I don't have any clue what that means.  There are no "mDNS resources"
that "move to DNS".  Those are different protocols.

> DNS-SD is structured differently.  It combines a large
> number of sizable service RRsets below an Instance node.

Sure.  It's a use of the DNS.  You seem to be making an argument that
DNS-SD is unsafe for use on the Internet, period.  If that's your
argument, then please publish "DNS-SD considered dangerous in the DNS"
or something like that.  This draft is about what you would do to make
DNS-SD work predictably _assuming_ that you wanted to use more than
one resolution mechanism, one of which is DNS, and I think including
text about why DNS-SD is dangerous is going to be mighty confusing.
If the WG concludes that DNS-SD is in fact dangerous for Internet use,
then obviously this draft shouldn't be published at all because you
shouldn't try to do any of these things in the first place.

> Labels do not afford operational protection from DDoS or
> vulnerability exposure whether defined as A-labels, U-labels
> or neither.

Yes.  The current draft has nothing to do with DDoS risk from the use
of the DNS, and I agree it is completely silent on that topic.  I
think that's a feature, but I'm willing to include the sentence noted
above if that will help.

> mDNS is inherently safer because it normally is
> only accessible from the local network.  An issue this draft
> continues to ignore, even when confronting a CERT notice!

Uh, the CERT notice you sent was complaining about mDNS _not_ being
accessible only from the local network, which is what the problem was.
That has absolutely nothing to do with DNS-anythingelse
interoperation.

> DNS-SD describes a structure intended to be browsed and
> displayed having user friendly encoding.

Wait.  So your issue is that DNS-SD owner names are intended to be
seen by humans?  

> Tools to browse DNS-SD DO NOT employ encoding used by
> IDNA2008

Yes, which is why only the <Domain> portion is treated as though it
needs to be processed by IDNA.  This is mostly because that's where
the names will be in the DNS.  The rest of the Service Instance Name
continues to work according to the DNS-SD specification, and there are
no mitigations of any sort about the possibly large number of names
below the <Domain> portion of a Service Instance Name.  That's because
we're using DNS-SD.

> to be applied, but these actions are normally NEVER needed.

The point of the draft, which I think is explained pretty clearly in
the introduction, is that you'll need the IDNA processing for the
<Domain> portion or else DNS will just return RCODE 3 and you won't
find what you're looking for.

> > I disagree.  mDNS uses the full repertoire of octets available in the
> > DNS.  DNS operators as a matter of fact (for various reasons explained
> > elsewhere) use a subset of those octets.
> 
> DNS is able to use the SAME octets as used by mDNS.

Yes, which is entirely consistent with what I said.  

> There
> might be cases where global DNS and local DNS wish to share
> a common zone for reasons likely related to use of
> certificates or minimizing servers.

What exactly is "local DNS"?

> We see the problem differently.  There is a real danger
> attempting to combine these two different namespaces,

I think what you're saying is that the goal of the draft is dangerous
and bad.  That's ok with me, but it seems really to be an argument
that the WG shouldn't try to do what it is chartered to do, no?

A
-- 
Andrew Sullivan
[e-mail]