OVERKILL
$100 Site Donor 2021
Most of the prosumer guys on here already know how this works, but for those that don't, figured it might be valuable to have a little post on why DoH (and DoT) is considered an important development and why we are seeing it as an option in browsers, bypassing the system's built-in DNS settings, which can be a pain for network admins who have invested in DNS filtering solutions.
To learn some of the history of how we got here, I recommend these CIRA articles:
Part 1: https://www.cira.ca/en/resources/news/cybersecurity/dns-encryption-evolution-or-revolution/
Part 2: https://www.cira.ca/en/resources/news/cybersecurity/dns-over-https-doh-who-do-you-love/
Under normal circumstances, when you enter a site like "bobistheoilguy.com" in your address bar, a query is sent to whatever DNS server your computer is configured with, which in turn resolves to the IP address hosting that site:
This is how the browser knows how to get to that site, by having that domain and/or hostname converted to the ip address. With HTTPS, there is also a certificate confirming that this IP address is indeed authorized for this domain/hostname. Hostnames can be subdomains like fredserver, so you could have the domain "goofygoober.com" and a specific server/hostname that's hosting the subdomain fredserver.goofygoober.com. On internal networks, often you are just using the hostname, like "billyserver", without appending the domain.
Now, DNS queries are sent in plain text, which means if we run a PCAP on the traffic coming from your computer, or from your router, or from your VPN termination point, we can see what queries are being made, and what the responses are. This is what that looks like (pulled from an old PCAP I had kicking around):
Query made: s.mzstatic.com from 192.168.0.27 to OpenDNS server 208.67.222.222:
Response received: Standard query response 0x40bf A s.mzstatic.com CNAME s.mzstatic.itunes-apple.com.akadns.net CNAME s-mzstatic-applak.itunes-apple.com.akadns.net CNAME mzstatic.com.edgekey.net CNAME e673.dsce9.akamaiedge.net A 23.15.204.33 from 208.67.222.222 to 192.168.0.27
We also see the hand-off between the LAN client (Apple) and the firewall (Cisco Meraki) and vice-versa due to PAT taking place in these exchanges.
So:
- If you are using your ISP's DNS servers, and no VPN, then these queries pass in plain text through all of the network equipment located between you and your ISP's DNS server. This will be a minimum number of hops, often only 1 or 2.
- If you are using a 3rd party DNS provider, and no VPN, then these queries pass in plain text through all of the network equipment located between you and that DNS server. This can be a considerable number of hops.
Here is what that looks like between my computer and CIRA, whose D-Zone DNS filter I use, note that there are only 6 hops:
Interestingly, because of the distributed nature, if I run the same query to Cisco's OpenDNS system, it lands at the same point (TIX, but different IP) also only having 6 hops. Cloudflare has 7 hops from my location, also, not too bad.
- If you are using a VPN and their DNS servers, those queries pass in plain text through whatever equipment exists between the VPN endpoint and the DNS server.
- If you are using a VPN and a 3rd party DNS provider, those queries pass in plain text through whatever equipment exists between the VPN endpoint and that DNS server.
This is where DoH (DNS over HTTPS) and DoT (DNS over TLS) come in.
Instead of the DNS queries traversing in plain text, they are encrypted between your computer, and the DNS server!
Sounds great, right?
From a privacy perspective, absolutely. The only time there's a plain text traversal is if the upstream DNS server has to reach-out to the authoritative DNS server because it doesn't have the entry cached. This definitely improves security/privacy from a snooping perspective.
Because most OS's don't support native DoH and/or DoT, the use of this is typically done in an application. You can have a service running on your desktop that runs as a DNS proxy daemon, where the DNS queries get forwarded over DoH/DoT. Both Firefox and Chrome (and chromium-based browsers) support native DoH (example from Chrome):
The issue of course is DNS filtering. If you are using OpenDNS, CIRA, Cloudflare or some other DNS protection system and the computers you are supposed to be protecting are using Chrome/Firefox/derivatives and DoH, sending the queries to a 3rd party not configured with the protection settings you have setup, ultimately, your degree of protection; your security, is effectively circumvented. This is now emerging as a major issue, as DoH is being utilized in browsers by default.
On my home network, I have DNS queries (TCP/UDP port 53) blocked with a rule allowing queries to CIRA. I also have DoT blocked, but DoH is harder to pin-down, as it's effectively indistinguishable from HTTPS in most firewalls, so blocking it involves using a list of known DoH DNS servers, blocking those IP's so that the queries never make it past the firewall. My browsers are all configured to use the CIRA DoH DNS server as shown in the Chrome screenshot.
You can also setup a local DNS server using something like a Raspberry Pi, that makes all its queries over DoH, and your DHCP options make that the default DNS server. However, you still have to block DNS on the firewall and will still have to try and lock-down DoH due to the browser-level configurations and the fact that many smart devices are hard-coded to use specific DNS servers, typically google at 8.8.8.8. Both of my smart TV's, a Samsung and a Sony Bravia, try and contact Google's DNS servers, despite being configured to use CIRA.
To learn some of the history of how we got here, I recommend these CIRA articles:
Part 1: https://www.cira.ca/en/resources/news/cybersecurity/dns-encryption-evolution-or-revolution/
Part 2: https://www.cira.ca/en/resources/news/cybersecurity/dns-over-https-doh-who-do-you-love/
Under normal circumstances, when you enter a site like "bobistheoilguy.com" in your address bar, a query is sent to whatever DNS server your computer is configured with, which in turn resolves to the IP address hosting that site:
This is how the browser knows how to get to that site, by having that domain and/or hostname converted to the ip address. With HTTPS, there is also a certificate confirming that this IP address is indeed authorized for this domain/hostname. Hostnames can be subdomains like fredserver, so you could have the domain "goofygoober.com" and a specific server/hostname that's hosting the subdomain fredserver.goofygoober.com. On internal networks, often you are just using the hostname, like "billyserver", without appending the domain.
Now, DNS queries are sent in plain text, which means if we run a PCAP on the traffic coming from your computer, or from your router, or from your VPN termination point, we can see what queries are being made, and what the responses are. This is what that looks like (pulled from an old PCAP I had kicking around):
Query made: s.mzstatic.com from 192.168.0.27 to OpenDNS server 208.67.222.222:
Response received: Standard query response 0x40bf A s.mzstatic.com CNAME s.mzstatic.itunes-apple.com.akadns.net CNAME s-mzstatic-applak.itunes-apple.com.akadns.net CNAME mzstatic.com.edgekey.net CNAME e673.dsce9.akamaiedge.net A 23.15.204.33 from 208.67.222.222 to 192.168.0.27
We also see the hand-off between the LAN client (Apple) and the firewall (Cisco Meraki) and vice-versa due to PAT taking place in these exchanges.
So:
- If you are using your ISP's DNS servers, and no VPN, then these queries pass in plain text through all of the network equipment located between you and your ISP's DNS server. This will be a minimum number of hops, often only 1 or 2.
- If you are using a 3rd party DNS provider, and no VPN, then these queries pass in plain text through all of the network equipment located between you and that DNS server. This can be a considerable number of hops.
Here is what that looks like between my computer and CIRA, whose D-Zone DNS filter I use, note that there are only 6 hops:
Interestingly, because of the distributed nature, if I run the same query to Cisco's OpenDNS system, it lands at the same point (TIX, but different IP) also only having 6 hops. Cloudflare has 7 hops from my location, also, not too bad.
- If you are using a VPN and their DNS servers, those queries pass in plain text through whatever equipment exists between the VPN endpoint and the DNS server.
- If you are using a VPN and a 3rd party DNS provider, those queries pass in plain text through whatever equipment exists between the VPN endpoint and that DNS server.
This is where DoH (DNS over HTTPS) and DoT (DNS over TLS) come in.
Instead of the DNS queries traversing in plain text, they are encrypted between your computer, and the DNS server!
Sounds great, right?
From a privacy perspective, absolutely. The only time there's a plain text traversal is if the upstream DNS server has to reach-out to the authoritative DNS server because it doesn't have the entry cached. This definitely improves security/privacy from a snooping perspective.
Because most OS's don't support native DoH and/or DoT, the use of this is typically done in an application. You can have a service running on your desktop that runs as a DNS proxy daemon, where the DNS queries get forwarded over DoH/DoT. Both Firefox and Chrome (and chromium-based browsers) support native DoH (example from Chrome):
The issue of course is DNS filtering. If you are using OpenDNS, CIRA, Cloudflare or some other DNS protection system and the computers you are supposed to be protecting are using Chrome/Firefox/derivatives and DoH, sending the queries to a 3rd party not configured with the protection settings you have setup, ultimately, your degree of protection; your security, is effectively circumvented. This is now emerging as a major issue, as DoH is being utilized in browsers by default.
On my home network, I have DNS queries (TCP/UDP port 53) blocked with a rule allowing queries to CIRA. I also have DoT blocked, but DoH is harder to pin-down, as it's effectively indistinguishable from HTTPS in most firewalls, so blocking it involves using a list of known DoH DNS servers, blocking those IP's so that the queries never make it past the firewall. My browsers are all configured to use the CIRA DoH DNS server as shown in the Chrome screenshot.
You can also setup a local DNS server using something like a Raspberry Pi, that makes all its queries over DoH, and your DHCP options make that the default DNS server. However, you still have to block DNS on the firewall and will still have to try and lock-down DoH due to the browser-level configurations and the fact that many smart devices are hard-coded to use specific DNS servers, typically google at 8.8.8.8. Both of my smart TV's, a Samsung and a Sony Bravia, try and contact Google's DNS servers, despite being configured to use CIRA.
.
