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

On Mon, Jan 24, 2022 at 12:55 PM Paul Wouters <paul.wouters=
40aiven.io@dmarc.ietf.org> wrote:

> On Mon, 24 Jan 2022, Ben Schwartz wrote:
>
> ...

> > (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?
>

I'm not familiar with those, but you might be able to do it using Google
Cloud DNS's Response Policy system [1].  Regardless, I don't think we
should constrain ourselves to the functionality presently available from
service providers.

[1]
https://cloud.google.com/blog/products/networking/introducing-cloud-dns-response-policies

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

This draft requires that the internal resolver be authoritative for a
public zone that encloses the internal names.  It does not require that the
internal names, or even the zone that contains them, be public.

I think there are a large number of cases (including "asdf.corp.example.com")
where this arrangement is sensible and sufficiently convenient to deploy.

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

The draft provides a definition of split DNS.  Feel free to propose a
different one if you think we haven't captured the concept correctly.

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

No.  If you have 250 internal domains, spread across 5 zones, all of which
include "ns1.corp.example.com" in their NS RRSet, then you need one SAN.
Otherwise, you may need more SANs, enough to match one entry in each zone's
NS RRSet.

These SANs do not have to be in the same certificate, thanks to SNI.  They
don't even have to be served from the same IP address, thanks to DNR.

> What if these domains are hosted at very
> different parties publicly?

There are many ways to solve this.  For example, you might decide to use
vanity names (within a zone you control) to identify the third-party
nameservers, so that you can acquire certificates for those names.

> I guess my only option is to get all of
> those domains to use ACME with DNS, since I cannot use ACME with HTTP?
>

You could use either ACME mode to acquire certificates for the nameserver
names.

...

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

The document's purpose is to provide guidance for how a client with a
particular threat model can increase its use of DNR.  That seems like the
opposite of this.

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--
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>