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

[Andrew Sullivan <[e-mail]>]

On Mon, Jul 20, 2015 at 11:32:56AM +0200, Douglas Otis wrote:
> A split horizon DNS configuration is often used by
> enterprises

Yes.

> space as a valid security method to exclude external

No.  We know that split horizon systems leak stuff all over the place.
There is no reason at all to suppose that names in a split horizon
environment successfully keep any name secret.  Split horizon is
extremely popular snake oil.  

> queries.  Such split horizon DNS might be used within local
> environments as a method to overcome WiFi limitations.

I don't know what this means.

> There should be no expectation that a locally defined domain
> conforms with IDNA2008 and does not deserve an out-of-hand
> dismissal.

There is no expectations that any domain conforms with IDNA2008.
There is no protocol rule that DNS names are encoded in any way at
all.  What we know is that names near the root of the DNS have, as a
matter of policy, a restriction on what they'll accept, and it
conforms with IDNA.

If your argument is that someone with a split horizon has made up for
themselves some TLD (say, "corp"), and are sending queries toward that
which sometimes leak, well, they're doing the stupidest possible thing
you can do in the DNS, which is to make up a name that is not
registered and try to use it in the DNS.  If such names leak, well,
too bad.  That's what you get for making up a random name and using it
on the global Internet.

> This relates to Ambiguous Local Qualified Domain Name
> (ALQDN) space (see RFC7368), such as .home as suggested by
> the hybrid draft, or even a domain expressed using UTF-8
> label locally recognized (not encoded and without the 'xn--'
> prefix) can represent locally defined domains that contain
> sensitive information.  As such, the profiles you are
> attempting to construct might even consider bolstering such
> exclusions as an element in any developed profile.

No, because the profile that I'm attempting to describe the principles
for will _by definition_ produce things that are suitable for the DNS.
If what you're saying is that there might be stuff that by policy is
just as unlikely to appear in the public DNS near the root as raw
UTF-8, then I'm just as happy to refer to it.  But excluding the ALQDN
won't work, because the ALQDN only works if you can query it
somewhere, and this profile is intended to restrict the number of
things you can query.

> 
> Again, the general statement made in section 4.3 third sentence:

[&c.]  I think I already agreed to how this could change, so I'm
eliding this part.

> Remove any indication that DNS-SD structures contained in a
> locally defined domain are automatically assumed global.

There is no such assumption.

> It seems you misunderstood the objection to your statements
> regarding absolute assertions of TLDs seen within a local
> environment.

What are "TLDs seen within a local environment"?  If I do tcpdump on
my box, I see lots of .com and .org.  I presume that's not what you
mean?
 
> There are indeed separate global and local namespaces which

Yes, but _we don't know_ in principle which place we're supposed to
look something up.  If we knew that, we wouldn't need any of this
absurd stuff.

> expected in .local TLD.  A locally defined domain may not
> always be .home

You don't get to just make up TLDs and configure them locally.  I
should have thought that Verisign's site finder made this painfully
obvious to people, though the experience with home, corp, and mail
gives one pause.

> When a domain is locally defined and locally accessible, why
> not include encoding exceptions with a reasonable strategy
> how such zones are ascertained?

Because you have no idea whether a domain is "local", however that
works, or not.

> Our differences seem to relate to securing locally defined
> TLDs such as Ambiguous Local Qualified Domain Name (ALQDN)
> space referenced in RFC7368.

Well, it's hinted at by 7368.  It's not actually specified anywhere
yet.

> Placing such resources into locally defined and only locally
> accessible domains

There is no such thing as this beast.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]