Re: [Add] WG Adoption Call draft-reddy-add-enterprise-split-dns

[Ben Schwartz <[e-mail]>]

On Fri, May 6, 2022 at 12:33 PM Paul Wouters <[e-mail]> wrote:

> On Thu, 5 May 2022, Ben Schwartz wrote:
>
...

> > The draft does enable local resolution of domains that do not exist
> globally.
>
> [This speaking as an individual with no hats on]
>
> The mechanism for that is:
>
>     To validate the network's authority over a domain name, participating
>     clients MUST resolve the NS record for that name.  If the resolution
>     result is NODATA, the client MUST remove the last label and repeat
>     the query until a response other than NODATA is received.
>
>     Once the NS record has been resolved, the client MUST check if each
>     local encrypted resolver's Authentication Domain Name appears in the
>     NS record.  The client SHALL regard each such resolver as
>     authoritative for the zone of this NS record.
>
> So let's say I have internal.nohats.ca served by ns1.internal.nohats.ca
> on IP 10.1.1.1.
>
> Let's assume that the first paragraph means "using a non-local
> preconfigured DNS server" because we can't yet trust the local one.
>
> Problem #1: The enterprise would not want to allow DoT/DoH, but to
> entice the client to not use it, it has to use it first. So the
> network cannot block it.
>
> If one queries for NS of internal.nohats.ca using DoH/DoT, one would
> get:
>
> paul@bofh:~$ dig ns internal.nohats.ca
>
> ; <<>> DiG 9.16.24-RH <<>> ns internal.nohats.ca
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60608
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> Note that NXDOMAIN is not NODATA.
>

Yes, in this case the NS record needs to exist publicly.

Now, if you meant to use the internal / local server for this, then I am
> confused as well. Let's say we got an ADN for "internal.nohats.ca", I
> think the text states it must have an NS record for internal.nohats.ca,
> but those can be arbitrarilly created. So finding things on the local
> server doesn't help me prove anything ?
>

Clients can only prove ownership through the local resolver if the zone is
signed and the client is fully validating, as described in Section 6.2.

> The only thing this draft declares as out of scope, in effect, are
> domains with a fake TLD.  If you use a real TLD, then this draft can be made
> > to work.  You just have to register the registrable part and delegate it
> (or a sub-zone that contains local names) to your local resolver.  There
> > is no need for this nameserver to be reachable publicly, and if it is
> reachable, it does not need to serve the same zone contents as the local
> > version.
>
> So what record would I need to add to the public nameserver that both
> authorizes internal.nohats.ca without leaking the existance of
> internal.nohats.ca?
>

You have three options:

1. Claim all of nohats.ca, and provision the local resolver with a
certificate for ns1.nohats.ca (or another name appearing in the NS record
for nohats.ca).
2. Publish an NS record for internal.nohats.ca, and structure your names as
<confidential>.internal.nohats.ca.  This is typical in large enterprises
(e.g. payroll.corp.example.com).
3. Register a new domain (e.g. nohats-internal.ca) for this purpose.  This
is also common in large enterprises.

> As noted in Section 7, this means that payroll.internal.example.com can
> be made resolvable internally, even though internal.example.com is "lame"
> > or empty externally.  This "internal.example.com" or "corp.example.com"
> structure is likely the most common split-DNS arrangement in enterprise
> > settings.
>
> Reading this, I think you mean there would be something like:
>
> internal.nohats.ca.     IN      NS      ns1.internal.nohats.ca.
> ns1.internal.nohats.ca. IN      A       192.168.1.1
>

No, this is not what I'm suggesting.  Rather, you should either:

1. Publish this NS record as a non-apex record in the public nohats.ca
zone.  No A/AAAA record is required, and there is no zone cut in the public
zone.
2. Create a real zone cut and operate a public nameserver for
internal.nohats.ca that has an empty zone file (except for necessary
records like NS, A, SOA, and DNSSEC records).

Either way, the client will resolve NS for "internal.nohats.ca", and
determine that the answer is "ns1.internal.nohats.ca".  That's all it needs
to know.

...

> >    Clients SHOULD
> >    apply whatever acceptance rules they would otherwise apply when using
> >    this resolver (e.g. checking the AD bit, validating RRSIGs).
>
> The VPN DNS configuration comes with its own DNSSEC Trust Anchors to
> support split-DNS with DNSSEC on both views. It is exactly that point
> that made the TLS people very worried wrt TLSA records being overridden.
> This "SHOULD" should therefor be a "MUST"


I think that's a reasonable change.

and should be on the public
> DNS, not the internal trust anchors (yet).


I don't follow.  What is an internal trust anchor?

But such a "MUST" is not
> possible on currently deployed devices and does not seem to be imminent
> either, and thus this draft will only be usable if one omits the
> security requirement of DNSSEC.
>

No, the normative text is "Clients SHOULD apply whatever acceptance rules
they would otherwise apply when using this resolver".   The following
clause provides examples of possible acceptance rules, and is not
normative.  Changing the SHOULD to a MUST would not require the client to
adopt any specific acceptance rules; it would only require the client to
apply its rules consistently.

>       For example, deployments
> >       of mandatory DoH/DoT servers by ISPs or nations that perform domain
> >       overrides that this document would still consider "tamperproof"
> which
> >       in the presense of DNSSEC could not be possible, but this document
> now
> >       enables.
> >
> > No, it doesn't.  If domain overrides are prevented by DNSSEC despite a
> compromised resolver, that must mean that the client is validating DNSSEC,
> > in which case the clause above ("validating RRSIGs") applies and the
> client will also enforce DNSSEC during these checks.
>
> While good that this all requires DNSSEC, how realistic is this at the
> moment? Will Operating Systems of laptops and phones really start doing
> DNSSEC to support this split-DNS scenario? Or will they use it ignoring
> the DNSSEC reuqirements of this document?


This document does not require any use of DNSSEC.  The only requirement is
"if you're already doing DNSSEC, you have to keep doing DNSSEC".


> Which then brings us back to
> the point where this protocol can be abused to claim any public domain
> name as its own.
>

If the client is not DNSSEC-validating, or the zone is unsigned, and the
client is using a third-party resolver for tamperproof resolution (Section
6.1), then this abuse is only possible if the local network resolver and
the third-party resolver are both hostile.  In the absence of this draft,
the client was going to use one of those resolvers anyway, so they would
still be vulnerable to that abuse.  Thus, this change hasn't made anything
worse in this regard.

Taking a step back, what is it that we really want to accomplish?
>
> If I connect to the office network, I need to resolve the corporate
> domain using the office nameservers, eg:
>
>         The network is requesting ownership of the domain name "
> internal.nohats.ca."
>         Allow this? Y/N
>

As someone who has worked on end-user UIs for DNS configuration, I would
have grave concerns about implementing a feature like this.  I would expect
coercive use of such a feature to appear very shortly after it is
implemented.  That's why I believe we should pursue an alternative that can
operate securely without user intervention and can support as many use
cases as possible.

...

> The complexity suggested by this document and it companion documents for
> a very partial fix, specifying security requirements that are simply not
> available on most mobile devices and are not being planned to be rolled
> out on those devices,


The only client-side requirements for this draft are DoT or DoH (already
widely implemented on mobile devices) and DNR.


> makes me believe this set of documents is not a
> working solution.
>

In a sense, I agree!  This document depends on DNR, which is still not
quite final and certainly not widely implemented.  The point of this
document is that DNR, somewhat unexpectedly, enables a new approach to the
split DNS problem.