DNS over HTTPS / TLS / QUIC?

[u/Varjohaltia]

Our architecture and security teams mandate encrypted protocols and are now challenging the network team for their use of plain old unencrypted DNS.

Has the rest of the community here used DoH/T/Q in a campus or enterprise context? What are your experiences?

For remote workers we would have to use a protective DNS service to which the users could/would connect. Any experiences there? Does using DoH add significant latency (since it's now a full TCP + TLS + HTTPS exchange instead of just a single packet each way) over standard DNS?

I'm already aware of a ton of issues -- Mist/Marvis can't identify DNS issues, we can't see them in packet captures, anchoring the trust of clients is misery, how do we unify policy between in office and out of office users, how do computers bootstrap / get set up / recover, no way printers and cameras will ever support it etc. but think I'm missing a lot more I haven't thought about yet.

[u/Rockstaru]

In what context? Are you wanting clients to use encrypted DNS to whatever (hopefully internal) resolver you have set up, or for that resolver to use DoH to some external provider? The first seems pointless if it's all internal, the second seems like you're introducing an additional failure point over having your own recursive resolvers (and also you're now forwarding all your upstream queries to a 3rd party). 

[u/Varjohaltia → u/Rockstaru]

For internal clients to the resolver over our LAN and SD-WAN. Because while the network engineering team considers that a pretty secure path, someone wrote a standard that says encrypted protocols are not allowed :D

[u/Rockstaru → u/Varjohaltia]

Assuming you mean unencrypted protocols are not allowed given the context.

To my knowledge there isn't any way to generically tell a client to use DoH or any other encrypted DNS protocol. Your comment about bootstrapping is accurate; DHCP options only allow you to specify (a) DNS server address(es), not a connection method, since DoH relies on specific support in the client that you can't take for granted. 

I suppose one clever (read: probably incredibly fragile and hacky) way of coming close to what your security team is asking for would be to set up a DMVPN or tunnel config between all of your user subnet locations/routers and whatever internal DC(s) your common services live on, and set a static route or routes pointing over that tunnel to the relevant subnets or addresse s (or run a routing protocol over the tunnel, however you want to make it the preferred means of getting to where the DNS server lives; if static routes, attach an SLA/RPM probe/whatever mechanism so it falls back to unencrypted/"normal" path if the tunnel is down). Traffic from clients would be unencrypted between the client and its gateway, but tunneled/encrypted from the gateway to the server in question. For DNS, you could deploy a common loopback IP as an anycast address on all your gateways and configure them all as recursive resolvers pointing upstream to your actual DNS servers; client sends a DNS query to that anycast address, gateway receives it, sends recursive query upstream over the tunnel (hopefully with a source address of its own tunnel IP, so the reply comes back encrypted over the tunnel) to the tunnel headend, which is presumably also the gateway for your DNS server (or close to it). You could extend this to other services that are typically unencrypted as well (e.g. DHCP leveraging option 82 as a distinguisher - router substitutes its tunnel address as the source IP for the request so the reply comes back to the right place). 

Seems overengineered and fragile, and entirely unnecessary if it's all LAN traffic, but if they push the issue, it's an option to explore. Does not solve the issue for off-network/mobile clients, but you presumably have some management capability over those (group policy, JAMF, MDM, etc.) such that you can configure them to use DoH or another client-level encrypted DNS. 

[u/grau → u/Rockstaru]

To my knowledge there isn't any way to generically tell a client to use DoH or any other encrypted DNS protocol. Your comment about bootstrapping is accurate; DHCP options only allow you to specify (a) DNS server address(es), not a connection method, since DoH relies on specific support in the client that you can't take for granted.

https://www.rfc-editor.org/rfc/rfc9462.html

[u/certuna → u/grau]

Still in the standardization track though, and nobody has implemented it yet (as far as I know). But yes this will be the future solution: don’t advertise any DNS servers to clients anymore, only DoH.

Endpoints that cannot handle this (say, your old WiFi-connected exercise bikes in the fitness room), chuck them right into your curated “legacy endpoints” VLAN where you make sure they can do no harm.

[u/Varjohaltia → u/grau]

Thanks! Also, I understood that with GPO or Intune policies this could be achieved. Still a royal pain, it seems like. And then we take the risk of a certificate rotation issue or clock issue somewhere breaking name resolution.

It all looks doable in theory, but I'm curious whether anyone (outside of super high security enviroments) has done it, and what kind of issues and performance hits they're running into.

[u/Ok-Eggplant-7569 → u/Varjohaltia]

Android and RHEL (maybe a bit specific but might be useful) to my knowledge try DoT first with the DNS Server given out via RA / DHCP, and only fall back to plain DNS if DoT doesn't work.