Currently I have pi-hole querying 8 local stubbys that are listening on 8 separate local ports doing dns over tls. I then have the stubbys piped through 8 separate tors. I can easily accomplish adding all of the extra local nameservers(server= entries) to a separate dnsmasq.d file and it happily makes it’s way and works well. But, I was thinking it would be nice to be able to have a simple “add another dns server” selection in pi-hole to be able to add as many as are desired instead of being limited to the 2 custom servers as it is now and having to add more in a separate file.
The second small request would be addition of a check box for the enabling or diabling of the dnsmasq “all-servers” config option. This can accelerate lookups by querying all servers configured for each request and taking the first to answer instead of the default behavior of choosing just one to query in a round robin fashion.
The latter request is especially important for acceleration in my application by pumping 8 dns queries simultaneously over 8 tors and taking the fastest one to come back to help offset latent tor routes. As stated, It works well and I have it all configured and working with the extra dnsmasq.d file but would be nice to be able to do it through the web interface. I feel both requests are pertinent and would add new and applicable features for pi-hole’s overall versatility, long term scalability, and speed.
Thanks for reading, really enjoying working with pi-hole!
Very interested in your solution, wondering how this works.
I have phole + unbound, without
all-servers. Unbound is configured to listen on
I don’t know why, but dnsmasq appears to prefer the IPv6 resolver, even though I have configured only the pi’s IPv4 address as DNS server, using DHCP, on all the clients, some, if not most, devices don’t even have an IPv6 address.
dashboard / Queries answered by:
- blocklist 27.3%
- cache 11.9%
- unbound-ipv6 56.9%
- unbound-ipv4 4 4%
I wonder if:
- When using
all-servers, are the requests to all the resolvers in the
queries table, or just the one served to the client? This would also be visible in the
pihole query log(uses that table)
- How does your `dashboard / Queries answered by graph look like? All resolvers same percentage or actually reflecting the fasted response?
@DL6ER: If this feature request makes it into pihole, obviously the query table (dashboard) could use an additional column
answered by (the IP or name of the resolver), the info is already available in the database.
in reply to @jpgpi250
the requests to all servers are not showing up in the queries table as dnsmasq only accepts the fastest reply and drops the rest. I am showing 8 queries going outbound in the logs and a single reply, that single reply is what is then sent to client and reflected in my query log.
root@94ed689e0c35:~# grep testingtesting.com /var/log/pihole.log Nov 8 10:35:28 dnsmasq: query[A] testingtesting.com from 10.8.0.6 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: forwarded testingtesting.com to 127.0.0.1 Nov 8 10:35:28 dnsmasq: reply testingtesting.com is 184.108.40.206
Hopefully that answers your question? Let me know if you need any more info.
Not sure I’m understanding your query @DanSchaper
Well, honestly, I don’t think this is a “good” feature as it drastically increases traffic. I see why you’re using it in the use case you have, but I’m not yet convinced that an easily accessible switch would be (a) needed and (b) advantageous for most/many users.
Neither, nor. It will be first request made. Regardless, if this one request resulted in the answer finally served to the client. This is a mere optimization decision and a certain inaccuracy, I agree. However, this is still correct in all non-
all-servers scenarios and difficult to implement, otherwise. The main difficulty is in that you probably don’t want to see the very same query eight times being sent to different servers while it does not need to be clear who replies first at the time this particular query is written to the database. This is especially true for slow/unreliable connections. I don’t see it being justified to implement a new
UPDATE queries SET forward = '...' WHERE id = ... kind of thing. Especially also because we’d have to keep track of what was already updated and what not + what ID a query was added as to the database.
Note that database access is handled completely (and only) asynchronously in a non-blocking manner so we cannot simply “change it once” when we see that a reply made it through.
@DL6ER Thanks for the reply. The all-servers feature is simply a feature of dnsmasq. It’s there for a reason, because people use it, and it works for specific scenarios, as I know you already know. If it isn’t integrated into the gui, it’s not a huge deal to me, I can still use it by creating a dnsmasq.d file. I just thought it would be an easy addition for what can be a useful feature. Lets get the focus off of the all-servers config to the more desired “add another dns server” for as many as the user wants to configure(this is simply supporting what dnsmasq already offers again) and is useful in many environments, for many purposes, does not add more traffic or do anything else that could be considered unsavory. I know this would be useful at least for advanced users. A passing thought… perhaps an “advanced options” area to enable these features for systems admins who know what they are doing and why they are doing it.
Once again, it’s ok if these don’t get added, it’s easy to put in the dnsmasq.d file. but it would be nice to be able to do it from the gui since these are all features of the software that pi-hole utilizes. One other thought for a feature request would be a toggle between successive or round-robin on the configured dns servers. Thanks again for the reply @DL6ER