My router supports that out of the box, but unfortunately it's somewhat unreliable compared to regular UDP resolution and I had to turn it back off.
That's more of a proxy than running my own.
> But at some point you have to trust someone.
If I do my own recursive queries from multiple networks, I don't really have to trust anyone. (I mean, that's still trusting authoritative servers, but arguably they're correct by definition.)
Though I could also ask multiple diverse DoH servers to get a similar effect.
Your best bet is something like Dnscrypt or DoH that exposes a resolver locally on your full network.
Your DNS can also do things like block malware, adult content, trackers, social media, or other things. Here's info about cloudflare and mullvad.
# Cloudflare
## Standard
1.1.1.1
1.0.0.1
2606:4700:4700::1111
2606:4700:4700::1001
## Block Malware
1.1.1.2
1.0.0.2
2606:4700:4700::1112
2606:4700:4700::1002
## Block Malware & Adult Content (not useful for this case)
1.1.1.3
1.0.0.3
2606:4700:4700::1113
2606:4700:4700::1003
You can find cloudflare information here[0], and remember to make sure you setup DNS over DoT (TLS) or DoH (HTTPS). Especially for them they will want to have encrypted DNS.Mullvad also offers free DNS[1], which also supports encrypted DNS
# Mullvad
## DoH is port 443 and DoT is port 853
## Standard
dns.mullvad.net
194.242.2.2
2a07:e340::2
## Block Trackers
adblock.dns.mullvad.net
194.242.2.3
2a07:e340::3
## Block Trackers + Malware
base.dns.mullvad.net
194.242.2.4
2a07:e340::4
Mullvad also has block for Adult + gambling and social media (so there are 6 total configurations). You don't need the Mullvad VPN to use these.I should also mention, as this frustrated me a bit, that your browser may implement its own DNS and so just setting these in your router (or pihole) may not completely resolve the issue. In Firefox, go to Settings > Privacy & Security > (scroll all the way down) Enable DNS over HTTPS using > then under either "Increased Protection" or "Max Protection" you can set a DNS resolver (or turn it off). They have defaults for Cloudflare (default!) and NextDNS. While you're there, also check your settings at the top of that page about "Enhanced Tracking Protection"
I am NOT a network/security person and would greatly appreciate replies to this comment with additional information. Especially about setting up things like piholes, TVs, browsers, encrypted DNS (especially this!), host files, and so on.
[0] - https://developers.cloudflare.com/1.1.1.1/ip-addresses/ - https://developers.cloudflare.com/1.1.1.1/setup/#dns-over-ht...
[1] https://mullvad.net/en/help/dns-over-https-and-dns-over-tls
FWIW, when I pinged, quad9 was around ~10ms, cloud ~30ms, and mullvad ~150ms. I'm not sure your 40ms would be too meaningful of a difference, but >100ms definitely will.
I wonder if anyone knows a way that I could script up a means for doing this dynamically? Like I can have a preferred order (let's say mullvad, cloud, quad for example since this is reverse my timing) and then ping occasionally and reorder based on that or a threshold (like <50ms)? Could be useful for like a pihole?
It's definitely better than nothing for small/one-off fetches, but VOD streaming sites usually have to fetch a license file from some API server anyway – so why not direct the viewer/client to the best CDN host based on the client IP address instead?
They actually had a mea-culpa with them a week or so back
> Our DoH/DoT resolvers were intermittently failing DNS lookups. It seemed to start over the Easter weekend. Our DoT/DoH front ends are DNS aware proxies (dnsdist) to back ends running unbound. dnsdist uses TLS to speak DNS to the back ends. Some of the back ends had failed to reload their TLS certificates after renewal, so although the certificates were valid unbound was still serving old certs and they eventually expired. This resulted in broken back ends in the pool, which dnsdist kept trying to bring back into service. The intermittent nature of the failures meant that it wasn't obvious to users, as clients generally retry silently in the background. Of course our monitoring should have caught this! We've fixed the underlying problem which caused unbound not to pick up the renewed certificates, and we've improved monitoring to catch similar problems should they occur in future.
The minute they come to America I'm switching.
I also stand by the claim that local DNS servers are beneficial. Not all of us are 1ms away from the major DNS providers. Transport networks are complicated, and those of us that do not have millions of dollars to build our own fibre directly to a data center where peering is available have to pay a latency price for sub-optimal transport routes. It is a fact that having a local DNS server will save you multiple round trips in such cases when the deployment is architect to do so. I did that because it makes browsing a little bit snappier. Saving a few 20ms RTTs might mean nothing to people living in a large city with a local internet exchange, but it does help those of us in rural remote communities that are distant from that infrastructure.