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

[Ben Schwartz <[e-mail]>]

[Some history removed for density]

On Mon, Jan 24, 2022 at 11:21 AM Paul Wouters <paul.wouters=
[e-mail]> wrote:

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

Your original message said "internal-only domains", and I described how to
offer internal-only domains within a publicly visible zone.  However,
internal-only zones are also supported.  Those zones must chain up to a
publicly visible zone at some point.

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

Yes: corp.example.com needs a signature from the example.com keys in order
for DNSSEC to be valid.  This is intrinsic to DNSSEC.

Other than that, there is no special binding.  "corp.example.com" is an
ordinary child to "example.com", and both the internal (populated) and
external (empty/trivial) versions of "corp.example.com" can be operated by
a single administrative entity.  (You can even use a single version of the
zone, with the public secondary configured to REFUSE all queries except for
the apex NS.)

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

There are many possible deployment architectures here.  Which one to use
may indeed depend on how your organization is structured.

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

I think the ideal situation is to make the internal DNS fully verified from
the public DNS, so that there is only a single trust anchor, and no
opportunity for an attacker to hijack zones they don't own.

Additionally, if I want to steal gmail.com, couldn't I just claim ".com" ?
>

Not unless you have a valid certificate for "a.gtld-servers.net".  (The
client validates the DNR server's name and matches it against the NS record
for each claimed zone.)

...

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

I hope it's clear that this is entirely possible within the framework
described in the draft.

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

Child and parent domains are often run by different people and software
with limited coordination.  The cooperation required here is not any
higher.  You can even hang the internal names from a separate registrable
domain (example-internal.com) if your two divisions can't talk to each
other for some reason.

I can certainly imagine that there are organizations that would be unable
to deploy a compatible architecture due to internal bureaucracy, but it's
not actually hard to set one up.

...

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


This does not seem substantially worse than adding a new DNSSEC trust
anchor.  It might even be better: at least that operator can't forge DANE
certificates for hijacked domains.