Privacy issues with DNS

Continuing the discussion from New Post: I (Finally) Fired Google:

and @ajlok

If you’re running your own DNS …

In my opinion, the single biggest question is: Does your own DNS server simply rely on another DNS server (be it your ISP’s or Google’s or someone else’s) or does it perform a full traversal from the DNS root servers?

If you simply rely on another DNS server then

  • you are making it very easy for that DNS server to record all your lookups, and then deal in that logged information in ways that you may not agree with or approve of or accept (including but not limited to monetisation), and
  • you cannot be certain how it in turn produces a reply to your DNS request (e.g. a third party DNS server might just forward the request on to Google, which may give you limited or no privacy from the Google monster)

If a customer had concerns that the ISP was intercepting (and/or interfering with) DNS requests that were not directed to the ISP then some kind of encryption is needed e.g. DoT, DoH or IPSec or more all-encompassing solutions like a VPN.

However that then still leads to questions about exactly where your DNS requests ultimately funnel through, if anywhere.

As an example: In Firefox if you enable DoH then the default provider is Cloudflare, and the only other standard option is NextDNS - and I have exactly zero idea how either of those providers then resolve my DNS query.

Another complication is geofencing or other georelevant content. If your DNS request ends up being resolved in a different geo then you may have problems (and those problems may or may not be helped if you just send everything through a VPN, where the VPN endpoint is itself in a different geo).

Unbound traverses downwards beginning at the root, delivering only a small portion on each request traversing down.

Additionally you can provide it with known privacy-oriented forward-adresses.


Firefox: From my understanding it might address whatever DNS it likes. Your router is handing over the request to the DNS of its choice which is the Pi-Hole that grabs any DNS-request.

Nevertheless, i will have to research that topic (wether Pi-Hole can look into a DoH-request).


Geofencing: Although not having tested it myself, Pi-Hole in newer version seems to provide fine-granular groups which can be permitted special settings. That might be usable for certain known routes.

Best regards

Yes, if you don’t use DoH.

For normal DNS use, Firefox DNS requests will be resolved exactly the same as any other DNS request. However I would assume that either DoT or DoH cannot readily be interfered with by PiHole, which is both a good thing and a bad thing.

In Firefox you can configure a custom DoH server. So if PiHole supports DoH then you can direct Firefox to use PiHole. If PiHole is local (which it usually would be) then there would not be much point setting up such a DoH arrangement - and if PiHole is local, you would want it to relay the DNS request with at least the same level of security and privacy as the original DNS client used e.g. relay via DoH (where relay is happening at all).

Assuming, you’ve got the network under your control:

You could set your browser, not to use DoT/DoH as all other clients in your network and delegate the DoT-/DoH-part to your Pi-Hole instance combined with Unbound Reverse Resolver.

Your Client openly requests DNS-infos from your Pi-Hole. Besaid does it’s magic. If the request is allowed to go out, Pi-Hole forwards it to Unbound.

Unbound on one hand does its reverse traversal. On the other hand you can easily configure it to use DoT. A little less easily to use DoH (as it involves HTTP/2). Which actually gives you DoT/DoH before the informations leave your secure area.

That way you’ve got both:

  • control
  • (increased) privacy

That thought solves the question wether Pi-Hole can look into your DoH (MITM would be possible, but would involve quite a bit of certificate juggling.

My approach is to host my own DNS and have it perform recursive resolution itself. There’s no reason if you are already going to the trouble of setting up a DNS server, to then have it forward requests on to another resolver, the local DNS server has everything it needs to contact root, TLD, and domain name servers itself on your behalf and it’s easy to set up. I also do not use DoH, DoT, or a VPN in general, because I have a trustworthy ISP.

So at that point the privacy concerns are focused on the fact that your ISP can inspect the DNS traffic leaving your home and going to out root, .com/org/etc, and the DNS servers for individual domain names, along with which records you are requesting, since DNS is a plain text protocol.

By the way, this is a similar privacy concern to using HTTPS, as currently the initial part of the HTTPS request uses SNI unencrypted so that you can tell the remote web server which domain you want to connect to, so if it is a web server hosting multiple HTTPS sites, it can present you with the correct certificate. Before the days of SNI administrators had to set up HTTPS sites each on their own IP address. So your ISP can also learn about all of the hosts you are connecting to over HTTPS. If the majority of your traffic is HTTP/HTTPS then you are leaking about the same amount of information with HTTPS and DNS. Of course if you use other protocols in addition to HTTPS, then DNS would leak more.

I don’t use, and am generally not a fan of using, DoH or DoT because they are simply a protocol-specific VPN. My opinions on this are far from mainstream, especially in the security community. I feel like creating a VPN specifically for one protocol doesn’t make sense from a security or privacy perspective, or a complexity perspective.

If I don’t trust the local ISP my DNS traffic goes over, then I shouldn’t trust it for HTTPS traffic or anything else that will expose the same information in plain text. Instead, I should locate a trustworthy ISP (and a VPN provider essentially acts like your ISP) and forward all of my traffic over the untrusted network inside an encrypted tunnel, to exit at the network I trust. Or just use Tor. Adding DoH/DoT to the mix forces me to delegate trust to two entities (DoT/DoH provider and VPN provider) instead of just one. And a lot of the DoH/DoT entities out there aren’t necessarily any more trustworthy from a privacy perspective than the long list of shady VPN providers.

2 Likes

I use DoH for few years right now. There are 3 reasons:

  1. Privacy (using DNS-server from a well known privacy NGO)
  2. Avoiding censorship (German provider started DNS-blocking without court order)
  3. I have no idea how to solve 1) and 2) in another and better way.

I also have installed Tor for some activities, but even Tor has some downsides.

From a just-user-perspective without enough technological knowledge: Is there any problem with it that can be solved in a better way (for non-technician)? In my opinion I have done what I could even if I know there are still some unsolved issues.

1 Like

To add to that: Once you are hosting your own local DNS, you should be caching lots - so an intercepting party (whether your ISP or your government or a hacker) gets a reduced picture of your total surfing as gleaned from intercepting DNS.

I believe that if you are traversing from the DNS root servers then DNS “rules” require you to cache.

(However as you say, some of that spying can be gathered alternatively by looking at unencrypted SNI or of course unencrypted HTTP.)

For the benefit of other readers, there is now ESNI (Encrypted Server Name Indication). The war continues. :wink:

I guess this is 100% just a question of perspective but to me DoH or DoT is just about the transport. Originally DNS only supported two transports: UDP (by far the most common) and TCP. So adding two additional transports doesn’t change the underlying architecture.

Unfortunately in my country, ISPs are required by law to be untrustworthy. Exactly how concerning that is may be determined by the individual customer but it should always be considered.

2 Likes

For my own needs at home, here is the direction I am heading in (not fully achieved yet i.e. some work still to do).

  • redundant pair of local DNS servers handed out by DHCP so used by all devices on the local network, typically accessed by vanilla UDP
  • local DNS servers do anti-Google and some ad blocking i.e. selected domains are “blocked”
  • local DNS servers may also do anti-poisoning i.e. selected domains that might be poisoned upstream may be overridden locally
  • local DNS servers relay the request to one of my ISPs (plaintext) for those domains where geo is known to be a problem
  • local DNS servers relay the request encrypted to one of my VPSs by default for all other domains
  • VPS does traversal from DNS root server

Everyone’s needs are different. Some would consider the above to be excessive. In some respects I am just interested in learning and in exploring what is possible.

I’m really glad you brought this up–it’s a point that I don’t think many people realize when they are thinking about DNS privacy. If you outsource your DNS to a third party, that third party sees every DNS request you make (minus OS cache). If you host your own DNS, anyone sniffing your Internet traffic only sees uncached queries. Now granted, while name server TTLs are still relatively long, in the modern day hostname TTLs (time to live) are often short (often measured in seconds), but it still means that the DNS queries someone can view won’t equal the number of DNS queries you make.

2 Likes

Seeing as we are getting down and dirty with DNS … for the exact same domain, the actual TTL that you see will depend on whether you are

  • asking the authoritative name server for that domain
  • asking your ISP or some other intermediate server and getting a cached response

In the former case, you will get the true TTL as set by the domain owner (which, yes, may sometimes be quite short anyway).

In the latter case, you will get the true TTL reduced by the amount of time that the intermediate server has had it cached.

So this is another reason to prefer doing traversal from a DNS root server.