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]

Reply via email to