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

[Douglas Otis <[e-mail]>]

On 7/20/15 4:53 PM, Andrew Sullivan wrote:
> 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.

Dear Andrew,

The concern is to isolate specific resources held within
locally defined domains. Indeed these names may be sent to
external resolvers. Nevertheless, such "leakage" does not
makes a split horizon technique invalid, IMHO.

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

mDNS resources are being moved into a locally defined DNS
TLDs to avoid the use of .local that implies an expectation
of mDNS resolution.  In other words, use of potentially
harmful levels of multicast traffic.

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

Agreed, but why expect there will be local policy to enforce
IDNA2008 compliance?  As you suggested, there is also an
advantage when those outside the split horizon receive an error.

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

The concern is not with the names, but with resources
associated with the services.  We both agree global DNS
services should respond with an error instead of the desired
resources.  A good thing.

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

Your view suggests there is NO value isolating locally
defined domains using split horizon DNS or perhaps a BTMM
scheme although this seems to represent what is meant by
ALQDN.  The requested change was to not have your view
implied in this draft and the reason for the change
requested.  A domain where resources are only available when
within a split horizon can be enforced by only responding
when client addresses are also site local.  Yes, query names
will leak.  Again, some desire having a zero-config scheme
where this technique comes fairly close and offers better
protection for that approach.  Nothing is perfect.

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

If you are willing to make this this statement, then why
insist all TLDs must use A-Labels?  Just remove this
statement and remain silent about what is or is not allowed
within locally resolved TLDs.  ALQDN will work within a
network offering a split horizon based on some type of scheme.

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

The statement made regarding the use of A-labels below all
TLDs IS making this assumption in my view.

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

No. Locally defined domains not found in global DNS.  One
method might make use of .home as defined in the hybrid
draft or perhaps a UTF-8 label lacking the 'xn--' prefix to
be friendly for those not using ASCII where entering .home
is not practical.

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

It seems there is also little desire to implement IDNA2008
encoding for locally defined resources as well.

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

A split horizon DNS scheme should override and prevent ill
considered redirection to "partner" sites.

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

The local DNS resolver knows and resolves resources properly
which provides a way of knowing.

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

We seem to consider the validity of various techniques
supporting uniquely resolved local domains differently, such
as that defined in RFC6281.  Many many hold that scheme in
high regard.

Regards,
Douglas Otis