I know this is not for everyone, but I strongly prefer to run my own recursive resolver at home. Performance is great, plus I get regular DNS for the machines on my home network. Also, it was a fun little project. :)
I recently switched my home network DNS forwarder from Bind to DNS Crypt Proxy (https://github.com/jedisct1/dnscrypt-proxy). You can get ad/content filtering lists along with some little privacy enhancements like DNS Crypt and DNS over HTTPS support for encrypted DNS queries to supported services, like CloudFlare.
Having traffic analysis in your threat model is an extreme choice, typically it means your adversaries include law enforcement agencies or state-level actors. Sending DNS over VPN might just mean that you don’t trust your ISP and think they might intercept the request and forge a response—something which does happen, and I’ve personally observed it at two different ISPs.
My ISP probably forges responses because they have no problem injecting html/js and hijacking ad space on unencrypted connections.
As far as timing attacks, an example would be such: Even though you are at a coffee shop in an undisclosed location miles away from home, if LE has a reason to profile the IP you're broadcasting from at home they could do look at request times and try to link a request from the coffee shop to your home DNS server.
If you use a public DNS server, you have the same benefit of using a public VPN vs a private VPN, in that your traffic gets bundled with everyone else's and obfuscated. It's harder to establish a link between you and the DNS server using network analysis because potentially thousands of connections are being made to that same DNS server from the same VPN node at the same time.
This is wrong, you should not expect political dissidents, whistleblowers, and other people in the same category to use similar techniques to protect themselves.
If you are protecting yourself from different threats, then it is not unreasonable to use different methods to protect yourself. There is an inherent tradeoff between security and usability. If law enforcement or state-level actors are in your threat model, you're going to have to make some extreme usability sacrifices just to keep yourself safe. That means using different systems than other people use.
> Even though you are at a coffee shop in an undisclosed location miles away from home, if LE has a reason to profile the IP you're broadcasting from at home they could do look at request times and try to link a request from the coffee shop to your home DNS server.
You're describing a different system. The system described by kingo555 is just for home.
> As far as timing attacks, an example would be such: Even though you are at a coffee shop in an undisclosed location miles away from home, if LE has a reason to profile the IP you're broadcasting from at home they could do look at request times and try to link a request from the coffee shop to your home DNS server.
That's just traffic analysis. The term "timing attack" refers to something else.
If you're a political dissident, whistleblower, or someone else with law enforcement / state-level actors in your threat model, everything changes. Presumably if you are worried about law enforcement, you put the VPN endpoint outside their jurisdiction. This can make it extremely difficult to do traffic analysis, depending on who your adversary is.
I think it makes sense that not everyone has law enforcement and state-level actors in their threat model.
I don't know how you can say I'm wrong when I was making the general conjecture that people in these categories use privacy-enhancing systems. I don't think you understood me well. I was not specifically referring to any particular set of techniques or systems.
> You're describing a different system. The system described by kingo555 is just for home.
This system is not meant to be used when roaming? Or is this a use case?
> The term "timing attack" refers to something else.
Which is why I specifically listed both timing attacks and traffic analysis separately. They can be interrelated at times but that's not something I feel like discussing.
> If you're a political dissident, whistleblower, or someone else with law enforcement / state-level actors in your threat model, everything changes. Presumably if you are worried about law enforcement, you put the VPN endpoint outside their jurisdiction. This can make it extremely difficult to do traffic analysis, depending on who your adversary is.
I appreciate the lesson in OPSEC but I only asked a simple question and you've devolved into trying to tear apart my comment for errors and lecturing me about things I already know about instead of simply answering the question. In this case, the answer is apparently "Well, your question isn't really relevant because this system is just meant for home use." One helpful sentence, no assumptions and no negativity.
> I think it makes sense that not everyone has law enforcement and state-level actors in their threat model.
Cool. No one was saying anything to the contrary.
kingo555 described a home network, but I don't think it matters. kingo555's threat model doesn't appear to consider traffic analysis, excluding it from the threat model, and that's a very reasonable choice. The system doesn't make any timing attacks easier.
> In this case, the answer is apparently "Well, your question isn't really relevant because this system is just meant for home use." One helpful sentence, no assumptions and no negativity.
I thought that was what I did here: https://news.ycombinator.com/item?id=19095304 But I was wrong, and sometimes it takes an entire conversation to discover the differences in assumptions and definitions.
For a full local resolver, you can configure it to use and serve expired records, with a 0 TTL. In the background it will then lookup all records used, so that it's refreshed for next time. Cloudflare does this. Likewise, you can configure it to prefetch frequently requested records before they expire.
I find it's still best to defer to an upstream forward server vs. root resolution. Most of the providers mentioned have multiple points of presence and will likely be closer and resolve MUCH faster for most cases. DNS resolution time can be a huge factor in web responsiveness.
Also, as counterintuitive as it might seem, when I use namebench ( https://code.google.com/archive/p/namebench/ ) it still says cloudflare and google are faster than my local resolver. (not by a lot though)
In my experience, Google's DNS has so many servers that even on subsequent requests, you hit a different server and it has to do the full lookup again (likely querying a root unless it's a popular domain). It's not really decreasing the load on the root servers that much, if at all. It might actually increase the load.
One trick you can do to speed up your local recursive resolver is allowing it to serve expired records. Unbound in pfsense allows for this. If the record has been previously retrieved but is expired, it returns the record with a 0 TTL (to force the client to look it up again next time). This includes internally using expired NS records, for example to lookup a different subdomain. Meanwhile, in the background, it looks up all the records used to refresh the TTL, and serves/uses this next time. Generally speaking, expired records still work fine. I noticed that Cloudflare DNS does this as well, and regularly serves 0 TTL records.
I've found that this consistently makes my local resolver faster than any public DNS server, except sometimes the very first time it looks up a domain. The slowest DNS queries are records which use lots of nested CNAMES on different domains with short TTLs, such as www.microsoft.com / most sites using akamai, which takes 500ms for the first lookup. There was a domain I saw the other day which had 4 or 5 layers of CNAMES which took 1-1.5 seconds to resolve initially.
But this isn't a problem... DNS caching works very well. I've been running my own nameservers for over two decades.
No, you don't, that's the whole point of a recursive resolver. I've been running against the root servers and neither query statistics nor observed performance match frequent issues due to short TTLs, or excessive number of external queries.
* Pi-hole®: A black hole for Internet advertisements – curl -sSL https://install.pi-hole.net | bash || https://pi-hole.net/