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

[Ben Schwartz <[e-mail]>]

On Sun, Jan 23, 2022 at 3:08 PM Paul Wouters <paul.wouters=
[e-mail]> wrote:

> On Fri, 21 Jan 2022, Ben Schwartz wrote:
>
> >       I am not sure if reducing the scope of split-dns is the way
> forward. A
> >       lot of split DNS is specifically for internal only domains, so I
> feel
> >       this document is now going to be very confusing for offering a
> split-dns
> >       solution without actually offering a split-dns solution.
> >
> > I'm not sure what you mean by "internal-only domains".  To be clear, a
> domain like "asdf.corp.example.com" is "properly rooted
> > in the global DNS" if it is done with the permission of "example.com",
> even if "asdf.corp.example.com" is NXDOMAIN on the
> > public internet.
>
> 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, 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.

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


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


>
> > ...
> >       If DNSSEC is required for split-dns, then it is also very
> conceivable
> >       that DNSSEC is used for the internal domains. For IKEv2 split-dns
> we
> >       offered the option to signal DS/DNSKEY's for the internal view. I
> don't
> >       think any of the add related drafts offers this option? If I
> missed it,
> >       please let me know how a client that decides to pick "example.com"
> >       resolving via the internal view of the split, can obtain the
> required
> >       DS/DNSKEY's of those internal zones ?
> >
> > I don't understand the question.  These names are properly rooted in the
> DNS, so DNSSEC validation of signed zones proceeds as
> > usual, without any need for additional trust anchors.
>
> 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.  If the zone is (publicly) signed, then it must also
have publicly visible DNSSEC records.


> As far as it is concerned, the domain
> you queried for does not exist, and you are given DNSSEC proof
> that it does not exist.
>

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.

Once the document is fixed to somehow contain the proofs of the internal
> view that "internal.example.com" should be queried for at 10.10.10.10,
> then if you want internal.example.com to be signed and have a valid
> trust anchor that you normally get from the parent zone via DS record,
> you now need an alternative method to get that trust anchor.


I think this shows that the internal and external DNSSEC views may be
incompatible, so they cannot share a cache.  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.


> 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