You may have noticed recently that Comcast and a number of ISPs have started to fight with Google and Mozilla after the makers of Chrome and Firefox announced that they were going to start support the use of DNS over HTTPS (DOH) and DNS Over TLS (DOT) recently. If you’re not familiar with what this is, a short explanation. First, Domain Name Service (DNS) is responsible for converting www.google.com to 172.217.9.206. DNS normally operates on UDP port 53. The packets are unencrypted which means that anyone who is able to capture the packets going across the wire are able to inspect them and see what sites you are browsing. Comcast and other ISPs love this because they have full visibility of this traffic (it’s going across their cables) and it gives them a way to monitor what you are looking at which they can then sell to the highest bidder.
DOH takes DNS and puts it into an HTTPS packet. This packet is fully encrypted which prevents the ISP from observing where you are going. Comcast has started to lobby Congress that this is bad because Firefox and Chrome are forcing their users into this, and that is being consolidated to use only Google and Cloud Flare DNS servers which would give these two companies full visibility of a large part of the Internet.
Both Google and Mozilla have released information that states that they aren’t changing your DNS provider. The only thing that they are changing is that if your provider supports DOT, they will use DOT instead of DNS. If your provider doesn’t support DOT, then nothing changes. There are a number of stories out there that debunk a lot of the fear that Comcast is putting out there.
So if Comcast is just fear mongering, then DOT must be a great idea. I agree, DOH is a great idea except….. When looking at a network from a security perspective, DNS traffic is a treasure trove of information (there’s a reason why Comcast loves it), much of which can be useful for defending the network. Take for example a computer that gets owned and is beaconing to badguynetwork[.]com. There are a number of techniques out there that utilize DNS traffic to find the “tail” of network traffic to identify rare destinations. Part of being able to find that rare destinations means that I have to see all of the destinations that are out there. As a network defender, my favorite way to do that is to put a Zeek sensor on the network and just sniff traffic. This is something I do on my own home network.
With DOH, I lose visibility of this traffic. So how do I use DOH and still have visibility of my traffic? For my home network, and really any relatively small network I recommend the use of the Pi-hole. Pi-hole is an open-source project that turns your Raspberry Pi into a DNS server.
This setup offers a few advantages that I like. First, it gives me a central single location that I can use block DNS names that I want to. Pi-hole by default can be configured to by default drop DNS calls for things like advertising sites, pornography, and other things you may want to prevent your systems from talking to. I will point out, that all of this traffic between the various systems and the pi-hole occurs over DNS. That’s ok though because it’s all occurring on my LAN that I control.
Now where this gets good is the fact that pi-hole obviously has to forward all of its DNS requests to an actual DNS server. This all occurs over DOH. All of the traffic from the pi-hole to the actual public DNS server is done over DOH which means it’s all fully encrypted. On top of it, because I am running my DNS server, I can setup centralized logging of all DNS traffic which means at this point, I don’t even have to sniff the traffic over the wire, I can just import the logs.
So how does this work with larger enterprise networks. Truth is I don’t know. This isn’t a use case that I’ve tried out. With an active directory domain for example, it is critical that the hosts are using the domain controller as their DNS server or a lot of things break. Under the normal design, hosts us the domain controller for DNS, and then the domain controller forwards external requests out. What I would propose (try this at your own risk) is that you use a beefed-up pi-hole and use that as the forwarder for the domain controller.