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:

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

No it is not. Please read RFC 8598 on how this is not the case for IKEv2
split-DNS. You can provision a DNSSEC trust anchor for corp.example.com
out of band. This never appears in any public DNS server that serves
example.com.

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

While it can be, it almost never is.

> (You can even use a single version of the zone, with the public secondary
> configured to REFUSE all queries except for the apex NS.)

Where can I find this option at the gui or api for cloudflare, godaddy, route53, NS1, Microsoft DNS?

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

But you have still not offered one of a very common split-dns deployment
where the internal domain is only ever visible internally.

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

I agree, but what you are describing is "NOT split-dns". This draft is
exactly about everything that is not what you propose in your sentence
here.

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

I did not realise this additional constraint.

So if I have 250 internal domains, do I need my DNR server to have a
certificate with 250 SAN's ? What if these domains are hosted at very
different parties publicly? I guess my only option is to get all of
those domains to use ACME with DNS, since I cannot use ACME with HTTP?


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

No it is not. It appears you have only redefined what "public" means,
and you call an "empty zone with the internal only name in the public
zone" effectively a "private only domain". And I disagree with that.

> Child and parent domains are often run by different people and software with limited coordination.  The
> cooperation required here is not any higher.

As long as we disagree on the definition of a "internal only domain
name", then further discussion on what is workable or not seems moot.

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

I see two possible outcomes with the current document:

1) It will lead the browsers ignoring ADD/DNR for security reasons.
2) Operators of internal-only zones will just require users to bring
    up a VPN to properly provision split-DNS.

Neither solution would require this document.

I would however, like to solve the issue of browsers and organizations
handling split-DNS domains so both browsers/endusers and organizations
can have optional DNS functionality, security and privacy.

Paul