Re: [Add] WG Adoption Call draft-reddy-add-enterprise-split-dns

[Paul Wouters <[e-mail]>]

On Thu, 5 May 2022, Ben Schwartz wrote:

> Subject: Re: [Add] WG Adoption Call draft-reddy-add-enterprise-split-dns
> 
> I would like to note to the group that the title of this draft, and also much of the content, has changed in this revision.  The title is now
> "Establishing Local DNS Authority in Split-Horizon Environments", reflecting a narrower technical focus.
> 
> One major adjustment, compared to previous versions, is that the draft is no longer restricted to networks that use Provisioning Domains (PvD)*. 
> Section 4 now notes ways that this approach can be used in conjunction with a variety of configuration mechanisms, including plain DHCP.

Speaker as an individual,

I don't think this update resolves the core question on how the
document handles split-dns networks.

It defines the most common type of split-DNS, the scenario where an
internal subdomain only exists in the internal view as "improper",
and out of scope which to me would mean this document cannot obtain
realistic deployment at large.

It kinda Updates: (without doing so) the IKEv2 split-DNS case by
suggesting this new mechanism can be trusted enough to override
what RFC 8598 clearly punts to the authorized and authenticated
provisioning part. Which is even more troublesome because of the
next point.

The draft still conflates data origin protection (DNSSEC) with transport
protection (eg DoH, DoT) by calling the authentication of data that
is needed "tamperproof" and defining that as "a method that is not
subject to interference by the local network operator". Of course,
DoH and DoT are still vulnerable to a non-local network operator if
there is no DNSSEC to prove data was unmodified. For example, deployments
of mandatory DoH/DoT servers by ISPs or nations that perform domain
overrides that this document would still consider "tamperproof" which
in the presense of DNSSEC could not be possible, but this document now
enables.

In short, this document tries to solve the battle between the enduser
and the network operator, and I think that is a battle that cannot be
won by either side.

The only real solution I see is one similar to the IKEv2 split-DNS case,
one where there is basically an authenticated and authorized
provisioning step that enables the user to join an "enterprise network"
wich can demand all or a subnet of DNS traffic which the user is required
to opt-in to. And even that is tricky when a user is kinda forced to
accept to get any connectivity, say in a hotel or coffeeshop (or
repressive regime)

Paul