Lately I saw many topics, where people running Pi-hole on a server on the internet without being aware that they also run an open resolver.
Would it be possible to add a big warning to the Dashboard when a user runs such a setup? Maybe checking for Pi-holes IP address and if it is not in the range of private networks, display that warning.
First of all: Pi-hole already has a rather effective prevention for this in place: limiting the allowed origin of queries to be maximum one hop away. This typically means that the servers in direct vicinity of your, e.g., VPS in the cloud, could directly query your Pi-hole but not "the Internet". You explicitly go to the settings, ignore the explicit warning that your Pi-hole needs to be firewalled when doing this and change the listing mode to "everything from anywhere" or to the Internet-facing interface. - I have not heard about a single installation where this default protection didn't work.
Yes, I think this is doable. Earlier feature requests suggested "probing" the server's IP address from the outside (the only way to be really sure) but this felt wrong as it would be similar to telemetry sent upstream to Pi-hole. Not something we want to do here.
But I guess we need to add option to somehow disable this warning. Assume users do indeed run their Pi-hole on a VPS but have firewalled it correctly, either only allowing the VPS itself to use the Pi-hole or maybe some other clients through a VPN network. Both are perfectly legitimate use cases and not something we want to stop. To more definitely decide on the is-or-not-a-public-resolver, we'd indeed have to query from the outside which is not possible because of aforementioned reasons.
I'd expect any IPv6-capable machine to sport at least one public IPv6 IP address, so I don't think that would make for a reliable test.
A public IP address on one of the machine's IP network interfaces would not indicate whether Pi-hole is actually accessible from public internet, anymore that you could deduce you wouldn't run an open resolver if the machine would only carry link-local IPs (e.g. a router could just forward port 53 and NAT requests).
One symptom that would strongly indicate an open resolver would be if Pi-hole has received requests from public IP addresses, which is similar to the existing warning Ignoring query from non-local network.
Yet that may raise a false flag in some edge cases: We had a few reports where a router used its public IP to send DNS requests to Pi-hole when using it as its upstream.
Still, I'd probably support such a warning.
However, we should stay aware that even an absence of such requests does not allow to deduce that the system isn't running as an open resolver (in the case of NATted requests, or it may not have been found or used as one yet).
which means nothing else than that these requests have been ignored - although publicly reachable, still not really an open resolver (there will never be an answer).
Me too, but the issue I'm having right now is that I cannot see how Pi-hole could be an open resolver "right from the start". Yes, if users go and click the "permit all origins" listening method, they can very easily create an open resolver. But there are warnings around this option.
If they intentionally ignore them, what would another warning be good for? Probably just something they will be annoyed about and disable in a subsequent step.
Don't get me wrong - I'm not against public resolver detection, but I just want to be sure that what we do is a useful addition.
Following @Bucking_Horn's advise above I would probably put the number much lower, probably ~ 4ish, maybe even just 2. We have seen a few users setting Pi-hole to "all origins" and hen further restrict access on their firewall. We would not be able to detect such scenarios with any passive means.
The best approach would be having a third-party testing tool. But is this okay privacy-wise? I really don't know.
It could be as simple as:
Pi-hole -> server: HI
server -> Pi-hole: QUERY A localhost.
3.1. if no reply is received within 4 seconds, server reports OK
3.2. if reply is received within 4 seconds, server reports BAD
If we host such a service ourselves, we can assure that no IP logging is done but would users see this as some hidden kind of metrics collection? I really don't know (but I currently tend more towards yes than no), totally open for discussion here.