Set up Pi-hole with your own recursive DNS server using DNSSEC(labs.ripe.net)
labs.ripe.net
Set up Pi-hole with your own recursive DNS server using DNSSEC
https://labs.ripe.net/author/johannes_weber/pi-hole-installation-guide/
17 comments
But you still need to trust the root servers right? I’d argue say 1.1.1.1 adds an extra layer of protection from compromised root (hijacked by China for instance; the premise between a rock and a hard place, an US corporation is more trustworthy than an adversarial government, or US government for that matter)
That seems like a uniquely American perspective.
The author states that pihole sending requests to 8.8.8.8 (Google) is worse than sending requests to your ISP. I disagree. I have always had terrible experiences with Comcost's DNS. I trust them less.
It's not sending requests to your ISP, just via your ISP (and readable by your ISP)
Maybe I misunderstood what this does. Is unbound not sending requests to the ISP in this case?
I'm pretty sure it is using pure DNS recursion, so if you ask for abc.google.com, the pi itself will ask the com TLD DNS server for google.com's DNS server, then go and ask google what abc.google.com's IP address is
So you're not asking the ISP for abc.google.com, but because they provide the internet, the ISP will see all your requests, including the UDP request to the .com TLD, google.com's DNS, etc
So you're not asking the ISP for abc.google.com, but because they provide the internet, the ISP will see all your requests, including the UDP request to the .com TLD, google.com's DNS, etc
With a goal being to circumvent tracking I wonder why DNSSEC was used instead of DoH DNS over HTTPS?
DNSSEC and DoH DNS over HTTPS serve completely different purposes. There isn't a choice to be made between them. DNSSEC sole purpose is to validate the integrity of DNS records. DoH DNS over HTTPS protects DNS requests and responses in flight but does nothing to validate that the DNS record returned was actually created by the domain owner.
The author of the article states they don't care about tracking of requests by their ISP, so they don't bother to implement in flight protection of DNS.
The author of the article states they don't care about tracking of requests by their ISP, so they don't bother to implement in flight protection of DNS.
Don't you think it's a bit backwards to deploy pihole to prevent trackers, while being ok with your DNS traffic being tracked?
Agreed though, the DoH recursor should use DNSSEC in actual DNS upstream queries. IMO you want to use both.
Agreed though, the DoH recursor should use DNSSEC in actual DNS upstream queries. IMO you want to use both.
Is there a good guide for how to set that up?
A dnscrypt-proxy or similar tutorial is probably a good starting point
I do agree but my point wasn't about what I think but the thought process of the author.
We need to better define exactly who's tracking we need to get around. I agree that DoH is a better solution to being tracked by your ISP.
On the choice of DNS forwarder: Unbound is very configurable and reliable, however, I went down this rabbit hole recently and decided I wanted a DNS "shotgunner" as latency to a single upstream source had a wide distribution.
Simply, you issue multiple DNS requests and take the fastest one. I use 9 different DNS servers over TLS. This is a bit excessive, two is enough most of the time.
I'm tempted to write my own DNS forwarder but this project is working well for me: https://github.com/mikispag/dns-over-tls-forwarder
Simply, you issue multiple DNS requests and take the fastest one. I use 9 different DNS servers over TLS. This is a bit excessive, two is enough most of the time.
I'm tempted to write my own DNS forwarder but this project is working well for me: https://github.com/mikispag/dns-over-tls-forwarder
Nine? To me this sounds like abuse of a free network resource.
Calling it 'abuse' seems like a leap. It is redundant, sure, but the results get cached, usually for extended periods of time if the TTL isn't set to too short of a duration.
Limited usefulness without ESNI.