Re: [Add] some background on split DNS with DNSSEC

[Dan Wing <[e-mail]>]

On Nov 9, 2021, at 3:09 PM, Paul Wouters <paul.wouters=[e-mail]> wrote:
...
> I have been at a hotel chain that blocked priceline.com. Coffeeshop
> wifi might prevent certain domains to prevent things like Google Meet
> or other domains that make people use a lot of bandwidth and stay very
> long. Schools might grab facebook to block it. While I think network
> owners should be able to dictare terms on their clients, I don't think
> the current ADD split-dns is the right mechanism for that.
> 
> And then we have the issue of this document of split DNS having a run-in
> with censorship, either by nationstate or as a security service. In
> those cases, the goal is to take over all DNS for the protection of the
> user. When that happens, it overrides the split-dns network configuration.
> But of course, enforcing of that is impossible and a race of DoH against
> the administrator ensures.

The split-dns draft does not enable such blocking, except by the domain owner of priceline.com, facebook.com.  That is, the hotel could not use split-dns to block priceline.com.  That is exactly the attack the query to the public DNS prevents.  During Q&A, I was encouraged to document that attack and how it is mitigated better.  We plan to add that explanation to an updated version.

...
> Putting a solution in the stub would be good.  I think ADD can specify something
> here, but it would really be part of (and authenticated by) the enterprise
> provisioning. Which could be as simple as a URI via DHCP option to a signed
> list by a CA that I installed. I am not sure dancing around in different
> DNS views would be particularly useful. And it would still allow
> outsiders to see those public DNS queries which are supposed to remain
> private. And I still don't understand the updates to the document from
> this Monday, that adds some packet flaw images, but no DNS query
> information. I still don't understand it :(

RFC8801's PvD are doing that (albeit using IPv6 RA rather than DHCP as you suggest).  I am not a fan of the IPv6 requirement for RFC8801's PvDs.  Enterprises continue to avoid deploying IPv6 internally.  

The current split-dns document validates the PvD returned by querying public DNS.  If that validation fails, the dnsZones claim in PvD is considered bogus ("lying") by the split-dns document.


This conversation is giving me another idea which I will explore next week.

-d