Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Isn't it that Pi-hole uses dnsmasq (a recursive DNS resolver) itself that you can point to any DNS server you want? Why the need to use another DNS resolver? Did I miss something? Maybe better would be to setup a DoH (DNS over HTTPs) to enhance the privacy?
Isn't it that Pi-hole uses dnsmasq (a recursive DNS resolver) itself
dnsmasq is a DNS forwarder that can cache results. Unbound is a recursive resolver that can also cache results. If dnsmasq doesn't have the answer, it will pass the query to the upstream DNS, which can be anything you want, including Unbound.
Maybe better would be to setup a DoH (DNS over HTTPs) to enhance the privacy?
I don't know enough to say. I think with recursion, it makes sense to minimize middle men who get the query. With DoH I think that would introduce a middle man. So my setup would go from:
client -> unbound -> authoritative DNS
to
client -> DoH -> Google -> authoritative DNS
So there is nothing preventing Google from storing the query, which is not something I want 😅
The GitHub issue I linked to has another link to a longer discussion for the caching optimization (which requires disabling dnsmasq caching), and may have more specifics
Comment hidden by post author - thread only visible in this permalink
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
No, no, no. Pi-hole comes by default bundled with dnsmasq (at least on my Arch). The client is pointing his/her DNS settings to DNS resolver under Pi-hole control so Pi-hole can intervene and return not-found or invalid IP for blocked domains. That's the whole point.
So by default you have: client -> Pi-hole DNS (dnsmasq) -> recursive query to Google, Quad9, CloudFlare, OpenDns, Level3, Comodo, DNS.WATCH
You'd introduce additional DNS resolver in the middle somewhere which has no obvious benefit to me.
It's all in the Pi-hole settings. Pi-hole has predefined settings to access all aforementioned DNS providers over IPv4 or IPv6. There's nno need to configure any additional DNS resolver.
BTW, whether the resolver is recursive or not is matter of configuration rather picking another resolver. Dnsmasq, unbound, knot or plain bind can all act as recursive caching resolvers. Even from command line the tool dig can act as recursive or not. dig @8.8.8.8 docs.google.com +recurse +trace
Regarding DoH, there might be some misunderstanding. The DoH tunnels your DNS request over HTTPS, encrypted from the point within your browser or Pi-hole to the last exit node, which then resolves it and relays the answer back over the same HTTPS tunnel. The obvious benefit is that nobody on the path, be it your hotel WiFi provider, his ISP or sneaky admin can see the DNS requests you are sending. Then if thousands of users are using it it looks like a single public IP address is resolving all possible DNS records and it is not easily possible to track the DNS requests back to you.
The DoH providers are not Google and without investigators having access to the logs of the DoH provider it is not possible to trace DNS requests back to you.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
You seem to be right, dnsmasq does not support recursive queries. However using unbound does not solve your privacy concerns as unbound in recursive mode sends all DNS requests to your preconfigured upstream DNS anyways. so docs.google.com sends DNS requests for ".", "com", "goole.com" and "docs.google.com". If your concern is Google tracking you, use different DNS provider or public DoH (like the one by Mozilla in Firefox).
No, no, no. Pi-hole comes by default bundled with dnsmasq (at least on my Arch). The client is pointing his/her DNS settings to DNS resolver under Pi-hole control so Pi-hole can intervene and return not-found or invalid IP for blocked domains. That's the whole point.
Yes, I understand this. But it doesn’t know where legitimate sites are. Its these requests that are forwarded to an upstream, recursive server. Unbound is that server for me. Cloudflare and Google are big providers and susceptible to attackers. Using Unbound as a local recursive DNS server reduces this risk. I thought that was cool and wanted to use it and that's why it was chosen.
Like I said in the post, I think Pi-hole is really great out of the box software, but it wasn't what I wanted. You're welcome to disagree with that. There is a lot I didn't explain in the post and linked to that could be read for additional context, and that was intentional.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Cloudflare and Google are big providers and susceptible to attackers
Well I have to disagree with that. They are IMHO least susceptible to attackers. It is far more easier and less suspicious to poison local DNS cache than that of Google or CloudFlare protected by numerous technologies, constantly monitored on all possible ISO/OSI layers, where millions of worldwide users would notice if something is off immediately and start reporting over their servicedesk and on Reddit. That simply does not make any sense.
Isn't it that Pi-hole uses dnsmasq (a recursive DNS resolver) itself that you can point to any DNS server you want? Why the need to use another DNS resolver? Did I miss something? Maybe better would be to setup a DoH (DNS over HTTPs) to enhance the privacy?
dnsmasq is a DNS forwarder that can cache results. Unbound is a recursive resolver that can also cache results. If dnsmasq doesn't have the answer, it will pass the query to the upstream DNS, which can be anything you want, including Unbound.
I don't know enough to say. I think with recursion, it makes sense to minimize middle men who get the query. With DoH I think that would introduce a middle man. So my setup would go from:
to
So there is nothing preventing Google from storing the query, which is not something I want 😅
The GitHub issue I linked to has another link to a longer discussion for the caching optimization (which requires disabling dnsmasq caching), and may have more specifics
No, no, no. Pi-hole comes by default bundled with dnsmasq (at least on my Arch). The client is pointing his/her DNS settings to DNS resolver under Pi-hole control so Pi-hole can intervene and return not-found or invalid IP for blocked domains. That's the whole point.
So by default you have:
client -> Pi-hole DNS (dnsmasq) -> recursive query to Google, Quad9, CloudFlare, OpenDns, Level3, Comodo, DNS.WATCH
You'd introduce additional DNS resolver in the middle somewhere which has no obvious benefit to me.
It's all in the Pi-hole settings. Pi-hole has predefined settings to access all aforementioned DNS providers over IPv4 or IPv6. There's nno need to configure any additional DNS resolver.
BTW, whether the resolver is recursive or not is matter of configuration rather picking another resolver. Dnsmasq, unbound, knot or plain bind can all act as recursive caching resolvers. Even from command line the tool
dig
can act as recursive or not.dig @8.8.8.8 docs.google.com +recurse +trace
Regarding DoH, there might be some misunderstanding. The DoH tunnels your DNS request over HTTPS, encrypted from the point within your browser or Pi-hole to the last exit node, which then resolves it and relays the answer back over the same HTTPS tunnel. The obvious benefit is that nobody on the path, be it your hotel WiFi provider, his ISP or sneaky admin can see the DNS requests you are sending. Then if thousands of users are using it it looks like a single public IP address is resolving all possible DNS records and it is not easily possible to track the DNS requests back to you.
The DoH providers are not Google and without investigators having access to the logs of the DoH provider it is not possible to trace DNS requests back to you.
You seem to be right, dnsmasq does not support recursive queries. However using unbound does not solve your privacy concerns as unbound in recursive mode sends all DNS requests to your preconfigured upstream DNS anyways. so docs.google.com sends DNS requests for ".", "com", "goole.com" and "docs.google.com". If your concern is Google tracking you, use different DNS provider or public DoH (like the one by Mozilla in Firefox).
Yes, I understand this. But it doesn’t know where legitimate sites are. Its these requests that are forwarded to an upstream, recursive server. Unbound is that server for me. Cloudflare and Google are big providers and susceptible to attackers. Using Unbound as a local recursive DNS server reduces this risk. I thought that was cool and wanted to use it and that's why it was chosen.
Like I said in the post, I think Pi-hole is really great out of the box software, but it wasn't what I wanted. You're welcome to disagree with that. There is a lot I didn't explain in the post and linked to that could be read for additional context, and that was intentional.
Well I have to disagree with that. They are IMHO least susceptible to attackers. It is far more easier and less suspicious to poison local DNS cache than that of Google or CloudFlare protected by numerous technologies, constantly monitored on all possible ISO/OSI layers, where millions of worldwide users would notice if something is off immediately and start reporting over their servicedesk and on Reddit. That simply does not make any sense.
Your comments are not constructive. Please do not comment on this post again. Thanks