For those of y’all unfamiliar with DNS, I recommend reading the rest of the series up till this point first before reading this one. Some of the concepts and terms I will be using here have been explained in those previous posts so I will not be explaining them again here.
What is getting encrypted in encrypted DNS?
When I refer to the concept of encrypted DNS I am specifically referring to transport encryption. What does that mean? Essentially the path between you and your DNS resolver is protected so that no parties in the middle can read what’s in those packets and potentially interfere with them.
More specifically, it is the path between your stub resolver and your recursive resolver. I am not talking about the path between a recursive resolver and various authoritative nameservers. That path cannot yet be widely encrypted.
Why are we encrypting DNS queries?
The primary reason is privacy. Unencrypted DNS queries are readable by anyone who is able to intercept them. This includes a hostile ISP, government or another malicious entity. Everything you do on the internet starts with a DNS query so your DNS queries can reveal a lot about you, what you are interested in and can be used to build a profile of you. The DNS Privacy project has a good summary of the problem.
Encrypting DNS query transport also prevents anyone in the middle of the path from modifying the DNS query answer. For example, if you are trying to avoid DNS based censorship done by your local network, ISP or government.
How are we encrypting DNS queries?
There are two major protocols in this space that I am going to be talking about: DNS over HTTPS (DoH) and DNS over TLS (DoT).
DNS over HTTPS (DoH)
DoH simply put is encapsulating your DNS query within a HTTPS request. So think instead of asking for and getting the contents of a website (HTML, CSS, JavaScript) you send a DNS query instead and receive a DNS response instead. The HTTPS part does the transport encryption.
According to RFC 8484 – DNS Queries over HTTPS (DoH), a DoH request looks like this and a response looks like this. Not quoting them here because my theme doesn’t really format the text all that well. It’s not strictly necessary to know the format if you are a non-technical user but it may be informative if you want to know more about how the protocol works.
Since DoH uses HTTPS it uses the default HTTPS port 443 to send outbound traffic. This two important benefits: first, since so much traffic from any network connected machine nowadays is HTTPS, DoH doesn’t stand out and essentially lets you hide the needle in the haystack. Second, since it uses the commonly used outbound port 443 if a network admin wants to block the DoH traffic they would have to block individual DoH endpoints instead of outbound traffic on the port.
DoH also has much wider client support than DoT i.e it is implemented in more pieces of software, major browsers like Mozilla Firefox and Google Chrome support using DoH within the browser. For Firefox, see their FAQ entry for further details. Operating systems like Windows 11 and latest versions of iOS and macOS support using DoH at a operating system level.
An aside about Firefox, DoH and ECH
Once cool thing I noticed while doing research for this post is that Mozilla Firefox enables use of a new TLS extension called Encrypted Client Hello (ECH) when using DoH within the browser. They have a FAQ on this here. ECH and ESNI are out of scope for this blog post but if you are interested Cloudflare has a good explainer on both ESNI and ECH.
DNS over TLS (DoT)
DoT is encapsulating your DNS query within a TLS session. Simplifying things, the main differences between DoT and DoH are – First, DoT doesn’t use the HTTP verbs since its not using HTTPS at all. Second, DoT uses a different port number for outbound client traffic, 853.
There are two relevant RFCs for DoT – 7858 and 8310. In my honest opinion, DoT is much less interesting to me as a protocol. Its use of a separate well known port makes it much simpler for network admins to block usage of DoT. DoT is also not supported by major browser vendors like Firefox and Chrome. Overall, I’m not seeing a situation where using DoT is a better idea than using DoH.
How does one use encrypted DNS?
There are multiple layers of the network where encrypted DNS can be used
In order of specificity:
- Router/Gateway device forwarder to DoH or DoT endpoint
- Personal device OS level forwarder to DoH or DoT endpoint (think your laptop or desktop)
- Application level forwarder to DoH or DoT endpoint (this is usually a web browser like Firefox or Chrome like I mentioned earlier)
What’s a DoH or DoT endpoint?
A DoH or DoT endpoint is any recursive resolver that supports DoH and/or DoT.
Large public resolvers that support DoH and/or DoT:
How do I use encrypted DNS?
My home network distributes two plain text DNS resolvers via DHCP. The primary is a Raspberry Pi 4 running pi-hole, the secondary is a forwarder running on my Mikrotik gateway device.
The Raspberry Pi has a Wireguard tunnel connection to a VPS in Linode Toronto I manage. I run an instance of unbound on that server and it listens on the Wireguard tunnel interface. pi-hole forwards DNS queries to that unbound instance over that Wireguard tunnel. This is a non-standard way of doing transport encryption for DNS queries. To me at least it was easier than dealing with the hassle of self-hosting a DoH/DoT server, especially as the Wireguard tunnel was already set up.
The forwarder running on the Mikrotik device uses DoH to send queries to NextDNS. I have been using NextDNS for a couple years now and I like using their service, it provides me with a reliable resolver with pi-hole like ad/tracker blocking functionality.
On my iPhone I have the NextDNS app installed and configured to use NextDNS when not on my wi-fi SSID. This allows me to have encrypted DNS functionality while I’m out and about using cellular data.
Other Frequently Asked Questions
Should I use encrypted DNS?
If you are able to, yes. There is no significant downside (for most people) to using it and the upside is that your DNS queries are encrypted in transport. Only caveat is for people on high packet loss internet connections (mobile/wireless/satellite). The increased latency from DoH or DoT may not be worth it in those cases.
Should I use DoH or DoT?
DoH. You’ll have a easier time getting started.
Which public resolver should I use?
That’s up to you. I recommend reviewing each one’s website for features, privacy policy etc. before making a decision.
Do my ISP’s resolvers support encrypted DNS?
Unlikely, ISP resolvers usually suck. But you can ask your ISP that to confirm.
What about DNS over QUIC?
DNS over QUIC is a very new protocol. It was only standardized last year and as such both server and client support for it is still lacking. The use of the QUIC protocol offers improved latency as compared to DoH and DoT.
Further reading about QUIC:
Conclusions
I know its been two years since I wrote the last post in this series but I am finally in the mood to be writing such posts again. Let me know on the fediverse what you thought of this and what other posts in a similar vein you’d like to see in the future.