Credit and thanks to Alexandru Jercaianu for implementation work
DNS over HTTPS (DoH) in the DNS client exited preview and became a supported feature with the Windows Server 2022 and Windows 11 releases. Unlike plain-text DNS, DoH requires a template in addition to knowing the IP address of the resolver. If only the DoH template is known, the domain name from the template must first be resolved (likely over plain-text DNS) before the DoH server can be used. To avoid the potential for attack on this bootstrapping query, Windows currently requires both the IP address and the DoH template to be known in advance.
What if the client wants to be able to discover the DoH template dynamically? In our previous post on encrypted DNS, we mentioned that we are coauthoring an IETF draft to do exactly that called Discovery of Designated Resolvers (DDR). We have co-developed an end-to-end implementation of DDR in partnership with Quad9 and Cisco’s OpenDNS. This allows Windows to bootstrap a DoH connection when it is only given an IP address for a plain-text DNS recursive resolver.
Here is how it works: Windows starts knowing only about a plain-text DNS server (knowing only an IP address for a resolver). Hoping to encrypt its traffic, Windows sends a DNS SVCB query for “resolver.arpa”, a new special use domain name that refers to the resolver receiving the query as opposed to a name within the DNS hierarchy. If an SVCB record is returned, it carries a DoH template along with either IP address hints or additional A/AAAA records for the DoH template name.
The DoH configuration cannot be immediately trusted because it arrived over plain-text DNS. To verify its validity, the client tries to make a TLS connection to the DoH server. The connection is only used for DoH traffic in place of the original plain-text resolver if the TLS certificate of the server can claim ownership of the original resolver IP address. This ensures that the DoH server and the original plain-text DNS server are both under control of the owner of the TLS certificate.
Try out DDR in Windows by installing the latest Windows Insider build from the Dev channel then configuring one of the DDR-supporting resolvers from OpenDNS and Quad9 below using the Settings app or Control Panel. When using the Settings app, leave the “DNS over HTTPS” field to “Off”.
- 146.112.41.2
- 9.9.9.9
- 149.112.112.112
- 2620:fe::fe
Run the following command in an elevated prompt to allow DDR globally.
netsh dns add global doh=yes ddr=yes
For each interface you want to test, run the following command with the interface name (list which interface names are available by using `netsh interface show interface`).
netsh dns add interface name=”<interface-name>” ddr=yes ddrfallback=no
If Windows should fall back to plain-text DNS when DDR fails, the ddrfallback parameter can be changed to “yes”. The settings should be picked up right away but try a reboot in the event of no change in DNS behavior.
Once DDR is configured, and if DDR succeeds, the only traffic over port 53 sent to that resolver should be the DDR SVCB queries for the DoH configuration. All other DNS queries should be going over an HTTPS connection to the DoH server designated by the configured server.
You can see an example of these DDR records below as captured by Wireshark. The selected and expanded record is the DoH configuration response from a Quad9 server. The other, unexpanded SVCB record is the same resolver’s configuration for using DoT. Notice that the only packets revealed by a port 53 capture are DDR requests and responses.
To reverse the DDR configuration and return Windows to its original state, simply run these commands.
netsh dns set global ddr=no
netsh dns set interface name=”<interface-name>” ddr=no ddrfallback=no
The full text of DDR can be found here. Discussion about DDR and other implementations can be found on the ADD WG mailing list (subscribe here). We encourage everyone to check it out, voice support, and look into adopting DDR for their own stub or recursive resolvers.
Posted at https://sl.advdat.com/3El6l0G