[DNSOP] Re: Client authentication for encrypted DNS — interest check

Paul raises a fair point — VPN is a viable path for managed deployments. But the use cases I have in mind also include unmanaged clients: a user subscribing to a private DoH resolver, or an ISP authenticating customers at the DNS layer without requiring a VPN on every device.


There's also a practical issue with IP-based authentication (the common workaround today): mobile clients, CGNAT, and roaming cause the source IP to change constantly, making persistent identity impossible at the network layer. VPN doesn't solve that — it changes the source IP, it doesn't bind identity to a client credential.


In those scenarios, transport-layer authentication within the TLS handshake (as Bill suggests with DANE + client certs) is simpler and more robust — no tunnel management, no IP churn problem.


The draft isn't trying to replace VPN — it's about the cases where VPN is operationally out of scope.


Enviado desde mi iPhone

El 10 jul 2026, a las 15:50, Paul Wouters <[email protected]> escribió:

On Fri, 10 Jul 2026, Bill Woodcock wrote:

Hi.  Speaking for Quad9 (and by extension other recursive resolver operators) yes, there is huge demand for client authentication.  Also, it will be needed to fulfill some of the requirements of DIEM.  My very strong preference is that we not invent anything new here, and simply use DANE and TLS client certs.

When will I get DANE requiring DNSSEC support on my mobile devices?

Honestly, the straightforward solution here is to add a VPN
configuration to the DNS resolver IPs. This is all existing
technology and you can define the tunnel to only cover
the QuadX IP addresses.

VPN technologies already allow a wide variety of authentications,
using X.509 and/or REST API calls or using PAM, etc.

Not every technology needs a DNS variant.

For my iOS device, it's just a simple .mobileconfig file. No need to
wait for Apple to implement some encryption-within-dns-packet format.

Paul

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]