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

[Paul Wouters <[e-mail]>]

On Thu, 5 May 2022, Ben Schwartz wrote:

>       I don't think this update resolves the core question on how the
>       document handles split-dns networks.
>
>       It defines the most common type of split-DNS, the scenario where an
>       internal subdomain only exists in the internal view as "improper",
>       and out of scope which to me would mean this document cannot obtain
>       realistic deployment at large.
> 
> 
> This is not correct.  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.

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 ?

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

> 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

Problem #2: it leaks the internal name publicly. Also it means sysadmins
cannot make up internal names without coordinating with their public DNS
admins. The latter is a bigger problem than the former.

Problem #3: Some DNS resolvers filter RFC1918 space in answers to avoid
common DNS rebinding attacks (which otherwise can turn browsers into
LAN scanners)

>       It kinda Updates: (without doing so) the IKEv2 split-DNS case by
>       suggesting this new mechanism can be trusted enough to override
>       what RFC 8598 clearly punts to the authorized and authenticated
>       provisioning part. Which is even more troublesome because of the
>       next point.
>
>       The draft still conflates data origin protection (DNSSEC) with transport
>       protection (eg DoH, DoT) by calling the authentication of data that
>       is needed "tamperproof" and defining that as "a method that is not
>       subject to interference by the local network operator". Of course,
>       DoH and DoT are still vulnerable to a non-local network operator if
>       there is no DNSSEC to prove data was unmodified.
> 
> 
> No, this section says:
> 
>    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" and should be on the public
DNS, not the internal trust anchors (yet). 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.

>       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? Which then brings us back to
the point where this protocol can be abused to claim any public domain
name as its own.

> In my view, the coercive aspect that you've highlighted is sufficient reason to avoid the "trusted network" mode whenever possible.  I think this
> draft shows a better way that covers most use cases, though not all.

A better way than "avoid the trusted network mode whenever possible" ? I
disagree. If we look at the Abstract:

    When split-horizon DNS is deployed by a network, certain domains can
    be resolved authoritatively by the network-provided DNS resolver.
    DNS clients that don't always use this resolver might wish to do so
    for these domains.  This specification describes how clients can
    confirm the local resolver's authority over these domains.

The _only_ valid use case I can think of for taking over domain names
is the enterprise case, and that case should do so via authorized and
authenticated user/device provisioning protocols. The home use case
could be seen as an enterprise case too (although in reality, that all
goes via mDNS/DNS-SD as home users tend to not have their own domain
names)

In all other use cases, the enduser should simply avoid trusting the
local network as much as possible for anything, which means not giving
it (encrypted or not) DNS queries or non-TLS HTTP queries at all.
I understand that this is not what coffeeshops, hotels or telcos want,
as they want to monetize on the user's private data and they would like
to coerce to user into giving it to them in exchange for internet
access. I don't think the IETF should be standardizing such efforts.



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

The user can immediately see if this is part of the company or not. If
the company wants "gmail.com" that looks fishy. If you are at starbucks,
and it asks you for "toronto.starbucks.com", you can shrug and grant it.

If we use one of the IETFs recent captive portal protocol parts, perhaps
this can be added to the captive portal signups, perhaps it can be cached
with ESSIDs/pubkeys, etc.

The case where this is not very feasible is where the local network has
dozens of domains it wants, but arguably it should place those under
its more global public (DNS) name.

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, makes me believe this set of documents is not a
working solution.

Paul