More people should do this.

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.

Even with DNS/HTTPS and such, wouldn't using a home DNS resolver with a VPN on both ends of the connection still make you a little more vulnerable to network analysis and timing attacks since your DNS requests are guaranteed to go through a specific IP which only serves you?

Not sure what timing attacks you are talking about.

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.

It's not in my threat model per se, but it's something I give a lot of thought to because systems like this are expected to be used by political dissidents, whistleblowers and other persecuted individuals who are subject to such threat models.

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.

> It's not in my threat model per se, but it's something I give a lot of thought to because systems like this are expected to be used by political dissidents, whistleblowers and other persecuted individuals who are subject to such threat models.

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.

> This is wrong, you should not expect political dissidents, whistleblowers, and other people in the same category to use similar techniques to protect themselves.

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.

> This system is not meant to be used when roaming? Or is this a use case?

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.

I have to go around my VPN provider for DNS because they intercept and alter DNS requests.

Which provider is this? Why do you still use them if they do something like that?

I really like the flexibility of CoreDNS for that. I use Cloudflare with dnscrypt as my resolver and still get to use intranet things at work because I can just forward the zones I need there elsewhere.

I like to share the cache of the DNS resolver with as many people as possible because that's what gives you the best performance. A local resolver just for me can't really do that.

Google DNS (and likely others) doesn't really work that well for this unless it's a very popular domain because of the sheer number of servers that they run and the short TTLs on most records. Even on subsequent lookups, you're likely to hit a different backend server that doesn't have a record cached that you just looked up. Google's servers don't seem to share their cache between one another. Even reddit.com often has to do the full lookup.

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.

Most home routers already do this for you, it's a bit abstracted but there, just need to specify the network and have it in the list of networks to resolve for DHCP. Or you can DIY it on another box.

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.

I use pdnsd as a local cache. It used to make browsing lightning fast. Although I might have messed up something since because dns resolution seems laggy. But in theory it is of great benefits.

That's great and all, but you still need to pick an upstream DNS server. The conventional advice is to use one of these public services, or your ISP's resolvers, to avoid hitting the root servers constantly. A lot of services these days have very short TTLs, so running your own recursive resolver still causes a lot of requests to get forwarded.

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)

You actually don't have to. The TTLs on NS records are generally pretty long, especially the root servers (6 days for root, 2 days for both .com and my domain's NS). You will hit the .com for example the first time you go to a domain, but so does Google.

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.

I know all that. IMHO in that configuration the root servers are your upstream servers. That’s what I was trying to convey. And serving expired records does generally work, but is not suggested practice.

Technically, you don't have upstream DNS servers in that configuration. The root servers are not recursive resolvers like an upstream.

But this isn't a problem... DNS caching works very well. I've been running my own nameservers for over two decades.

potato potato

> That's great and all, but you still need to pick an upstream DNS server.

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.

In that case you are using the root servers as your upstream. That’s the point I was trying to make, but I guess I didn’t explain it well. :/

I love my Pi Hole! Great for blocking ads on everything.

* Pi-hole®: A black hole for Internet advertisements – curl -sSL https://install.pi-hole.net | bash || https://pi-hole.net/

The docker image is pretty trivial to set up too, so it's even easier :)

That and handy for network level filtering, such as PiHole.