Re: [Add] I-D Action: draft-reddy-add-enterprise-split-dns-08.txt

[Paul Wouters <[e-mail]>]

On Mon, 24 Jan 2022, Ben Schwartz wrote:

>       That is not clear from the text at all. In that case, yes you cover all
>       the cases of split-dns but then I wonder how the external server will
>       somehow "confirm authorization" of "corp.example.com" on the internal
>       server if the externl server returns NXDOMAIN or REFUSED because the
>       domain is internal only ? Especially because the connecting client is
>       supposedly sending this query over its own trusted (encrypted) resolver
>       to the public nameserver, reachin the public nameserver's external
>       "view".
> 
> In this case, "corp.example.com" would be publicly visible

You have now redefined split-dns again to be only the cases where the
zone exists in both internal and external views. The problem we were
addressing was internal zones that do not exist in any kind of form
externally.

> , presumably as an "empty" zone (containing only its own
> NS records, NS IPs if in-bailiwick, DNSSEC records, etc.).  The client would fetch the NS records for this zone,
> and check the NS names against the DNR ADNs.  A query for "asdf.corp.example.com" would then flow to the local DNR
> resolver, which serves a non-NXDOMAIN response.

Now you have created an additional binding between the administrators
of the internal and external versions of the internal-only
"corp.example.com". Now internal DNSSEC adminstrators need to sync
up with the external ones. These might be different departments and
different providers.

> Alternatively, the local resolver can claim the "example.com" zone, and corp.example.com can be NXDOMAIN publicly.

Yes, it could claim example.com, but again then there needs to be two
different example.com zones that are in need of a sync for DS records,
and two different views - one for the internal and one for the external
one, since they differ in corp.example.com. So the internal one claiming
"example.com" cannot just forward to the public one. But for data
outside of corp.example.com it should not really be authoritative, so
again a human/third-party sync is needed between internal and external
DNS. So these workarounds are prone to failure due to their administrative
overhead that requires continuous cooperation between two different
systems/groups.

An ideal situation would make the internal DNS fully independent of the
external DNS. Again, if you look at RFC 8598 IKEv2 Split DNS, it conveys
all the information through provisioning which has its own trust anchor.
It leaves the operation of internal and external DNS independent of each
other.

Additionally, if I want to steal gmail.com, couldn't I just claim ".com" ?
I replay some externally valid DNSSEC records and then when they are
trying to visit gmail.com, I route the IPs of ns*.google.com to my
own servers (eg via NAT or by squatting the public IP space). I might
not be able to run HTTPS for gmail.com, but at least I've prevented
the user on the network from accessing the real gmail.com.

>       > What's newly excluded in this draft are domains like "example.faketld", i.e. names whose parent (in
>       this case the root) did not
>       > give permission for this use.
>
>       Please do clarify that in the draft.
> 
> 
> Sorry, I meant "newly excluded in this draft revision", compared to -07.  I believe this is quite explicit from
> the "NXDOMAIN camping" text in -08.

Re-reading it, I agree. I think the confusion could be reduced by using
common terms like domain hijacking and nxdomain hijacking instead of the
word camping.

>       If you ask the public view for internal.example.com you get no NS
>       records and no DS records.
> 
> This draft effectively requires that any "claimed zone" has publicly visible NS records.

Yes, and I have commented from the start that this is not a realistic
operational requirement. People want to hide their internal zones. If
they didn't they would have put a public placeholder domain there
already. They don't want to reveal their internal domains in a public
downloadable list via DNS records.

> No, because each "claimed zone" is presumed to be a publicly visible zone enclosing the internal-only names.  This
> may be the zone itself, or a parent.

I commented on this already earlier in this response.

> I think this shows that the internal and external DNSSEC views may be incompatible, so they cannot share a cache.

RFC 8598 has text on how to deal with multiple caches:

    When an IKE Security Association (SA) is terminated, the DNS
    forwarding MUST be unconfigured.  This includes deleting the DNS
    forwarding rules; flushing all cached data for DNS domains provided
    by the INTERNAL_DNS_DOMAIN attribute, including negative cache
    entries; removing any obtained DNSSEC trust anchors from the list of
    trust anchors; and clearing the outstanding DNS request queue.

At least on the system / OS level, there are existing hooks to deal with
this already for the main operating systems. I am not very familiar with
how browsers deal with their DNS cache when a "network disconnect/connect"
event happens. I assume they must do something similar.

> However, I see no reason that we need a separate trust anchor.  The internal resolver can provide a valid chain
> for internal names that goes all the way to the root, while external resolution receives an NSEC instead.

You need a seperate trust anchor because the internal and external DNS
is run by different humans in different departments using different
third parties with different software.

>       My comment
>       was that this document provides no method or normative reference to
>       a method to obtain this. In IKEv2 split-DNS, we added both a domain list
>       and their DS/DNSKEY records as provisioning information the IKE layer
>       conveys. This document only provides the names of domains, not their
>       trust anchors.
>
>       Paul

And now I understand that additionally, one must publish their internal
only domains in public DNS. I do not think that is a practical solution
from an operational point of view. Instead, operators will just want to
take all DNS queries from connecting clients, and will inform the users
to disable their third party DNS solutions.

Paul