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

[Ben Schwartz <[e-mail]>]

On Mon, Jan 24, 2022 at 10:45 AM Ralf Weber <[e-mail]> wrote:

> Moin!
>
> On 24 Jan 2022, at 16:20, Ben Schwartz wrote:
> > I think this is fine.  You just publish DS records for both the internal
> > and external DNSKEYs.  Validation will then succeed for records signed by
> > either key.
> But then I give away that corp.example.com exists and that it has a
> DNSKEY.
>

If you don't want "corp.example.com" to be mentioned publicly, then your
internal resolver has to "claim" example.com.  Assuming all zones are
signed, you can do this either by signing a pair of conflicting records (an
external NSEC denying corp, and an internal DS delegating corp) with the
same key, or you can publish two DS records in the "com" zone (for the
internal and external keys).

(As Ted said, in my examples I've been assuming that the "corp" label is
public, and any "hidden" names are under "corp", but the logic is the same
if we go up one label.)

>> Also keep in mind that if
> >>         corp.example.com
> >> is NXDomain externally you need a special/different
> >>         example.com
> >> internally to delegate corp.example.com.
> >>
> >
> > Agreed.  The claimed zone (which could be "example.com" or "
> corp.example.com")
> > must resolve differently internally and externally, or you haven't
> actually
> > "split" anything.
> I have. example.com is different externally then internally. Externally
> it is
> missing the corp.example.com delegation.
>

Yes.

>> I’ve always envisioned DNSSEC split horizon needing an internal trust
> anchor
> >> because of this ideally in the recursive resolver and stub resolver.
> >>
> >
> > I don't think there's any need for a separate trust anchor.
> In the above example there is, as corp.example.com does not exist in
> public space
> or are you saying that the case I described is not split DNS?


 This is split DNS, but there's no need for a separate trust anchor.