6 ms·

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 o

by krylon 8y ago

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. :)

dbg31415 8y ago
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 https://install.pi-hole.net | bash || https://pi-hole.net/ https://pi-hole.net/
- yaleman 8y ago
  The docker image is pretty trivial to set up too, so it's even easier :)
dspillett 8y ago
That and handy for network level filtering, such as PiHole.
sascha_sl 8y ago
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.
skrause 8y ago
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.
- deleted 8y ago
  [deleted]
- ingenium 8y ago
  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.
kingo55 8y ago
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 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.
- kakarot 8y ago
  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?
  - klodolph 8y ago
    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.
    - kakarot 8y ago
      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.
acranox 8y ago
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/ https://code.google.com/archive/p/namebench/ ) it still says cloudflare and google are faster than my local resolver. (not by a lot though)
- deleted 8y ago
  [deleted]
- ingenium 8y ago
  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.
agumonkey 8y ago
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.
tracker1 8y ago
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.

by krylon 8y ago

dbg31415 8y ago

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 https://install.pi-hole.net | bash || https://pi-hole.net/ https://pi-hole.net/

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

dspillett 8y ago

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

sascha_sl 8y ago

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.

skrause 8y ago

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.

deleted 8y ago
[deleted]
ingenium 8y ago
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.

kingo55 8y ago

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 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.

kakarot 8y ago
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?
- klodolph 8y ago
  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.
  - kakarot 8y ago
    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.

acranox 8y ago

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/ https://code.google.com/archive/p/namebench/ ) it still says cloudflare and google are faster than my local resolver. (not by a lot though)

deleted 8y ago
[deleted]
ingenium 8y ago
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.

agumonkey 8y ago

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.

tracker1 8y ago

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.