I've noticed on a few of the Pi-hole discussion and support channels that people in general seem to be completely unaware that it's dangerous to have a DNS resolver open to the world on a public server, and many have done so because of the ease of setting up and using Pi-hole.
Would others agree that maybe it would be good to have a warning during installation to instruct people that it's not a good idea to open port 53 to the internet on your Pi-hole installation?
Wouldn't that imply that we have to hand the IP of any installation to some service that tries to detect if the port is open? I do see a privacy issue connected to this.
Nothing like that, no detection. Just a general text disclaimer or warning during installation.
I think it is quite likely that many users do not even know if they have a port open to the Internet when they install Pi-hole on a droplet and don't have that much of experience or clue what is actually going on behind the scenes.
Hence, I doubt that a simple text message will be causing any effect in the end.
The only effective thing might be a flashy message which we can - of course - only show if an actual threat has been detected.
It's actually a rather rare occurrence, but it happens to get a lot of notice when it does occur. I can't think of any DNS server package that does display any kind of warnings when installed so my vote would be to not show any message for now, but keep the idea open for possible inclusion if the situation starts to happen more frequently.
There are quite a few pi-holes out there. Like 1500 of them.
https://www.shodan.io/search?query=pi-hole
That's actually a scary number
Thanks for reminding me of Shodan! Totally forgot that site existed.
Edit: Yeah, so of those 1011 unique IPs, "only" 250 are open resolvers.
Dont know if thats great (advertising Pi-Hole) or the fools dont know what they are doing.
For example DNS amplification attacks can be mitigated quite easily by just firewalling UDP for DNS as then the clients will fallback to TCP.
And you'll need to protect against syn-flood attacks and few others.
But makes you wonder if these people have any idea of the risks.
All pihole installs would have defaulted to listening on the WAN interface. But that meteorite was averted.
To answer the OP, there is already a warning about it - "Make sure your pihole is firewalled". But first and foremost, the default config now never listens to WAN requests.
I absolutely don't think so!
There is a frighteningly high rate of users that do think that others will never-ever be able to find their droplet, because first they have to know the IP address. Since many of them don't understand how IP addresses work, they assume that 143.110.221.233 is as good as any other 15 characters password and hence, they erroneously feel safe by obscurity. If they are even interested, they are shocked when you explain them how addresses work and that you can actually pretty straightforwardly probe all public IP addresses within less than a day (or even faster).
Even worse, there are also users that don't even think of any other users that might exist on Earth. They create a droplet, install Pi-hole and use the IP on all of their devices as manually configured DNS server. They don't at all have the idea of other users that might also use "their" droplet...
The list of extremely obvious mis-behavior of users that just don't know any better, but nevertheless rent (partially quite powerful) virtual machines out there is alarmingly high.
Partially, I have to say, it is also the fault of the big providers like Vultr or DigitalOcean that they do not (by default!) have a minimal firewall. I'm thinking about a simple INPUT rule that drops everything except SSH and possible other applications you already installed alongside when spinning up the droplet.
The current default behavior for fresh installs is no. 2 in your picture? Why? Simply because dozens of users encountered issues with the first option, that is that when dnsmasq comes up before the networking interfaces are ready, it fails to start altogether. I know that Raspbian recently updated dnsmasq to a version where this misbehavior is fixed, but since we officially support Debian Jessie (where we cannot be sure that a recent version of dnsmasq is available everywhere), we cannot make option 1 the default. Obviously, we don't want option 3 to be the default...
That's a link to a pic you previously posted. My default is #2 
The piadvanced script I'm working on includes using iptables to create a very secure firewall. One of the things I am looking at implementing is using iptables to only answer requests for access to pihole to device on the local network, and via VPN
(53, 22, 67, 68, and the lightttpd interface)
Work in progress
We have spoken about open resolvers in several places over a long span of time. Based on some of the discussions here, I think the note on the settings page satisfies the feature request.
I'd like to use Pi-hole as a public DNS server.
The correct and easy solution for that would be to just disable DNS recursion when you select the Permit all origins option.
But it turns out, Pi-hole uses dnsmasq under the hood, which doesn't have this option...
And I guess you wouldn't want to switch to a more feature-rich DNS server. That's very sad...
Yes, hosting an open resolver is very sad indeed...
This would be foolish, and you would quickly become a scourge on the internet.
I obviously meant I would like to use it as a public, non-recursive DNS server:
The correct and easy solution for that would be to just disable DNS recursion when you select the
Permit all originsoption.
Don't be so toxic, guys. You got what my original intent was 
No toxicity here. Open Resolvers are inherently dangerous.
Maybe you are missing the reason this Feaure Request exists?
The correct solution is Don't Run A Public DNS server. Don't use Pi-hole as a public DNS server.
Plus I dont see how above would work out for you:
$ dig +norecurse @pi.hole pi-hole.net a
[..]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 32075
Vs:
$ dig @pi.hole pi-hole.net a
[..]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35676
[..]
;; ANSWER SECTION:
pi-hole.net. 238 IN A 3.18.136.52