Thousands of DNS requests for domain

Block port 53 and use a VPN if running on a droplet. Open resolvers are bad.

Ah, yeah as @DL6ER mentioned, do that! Are they all coming from the same client?

See our nice wiki article on how to easily set up a VPN. I wrote the tutorial while working on an Ubuntu droplet.

They're coming in from one or two ip addresses, and using iptables -A INPUT -s <offending ip> -j DROP doesn't seem to be blocking the requests. I'm also unable to blacklist the . domain through pihole.

Wouldn't using OpenVPN on the droplet route all of my traffic through the droplet? I'm already hovering around 50% memory usage, and don't want to nuke my server. Also wouldn't the client only use the DNS when OpenVPN is active, and unfiltered when inactive?

Would using non-standard ports work? So on my clients I could add :3018 or whatever port?

Assuming you're using the base level package for your VPS, you should be fine when installing and using openVPN. It doesn't have a major memory impact.

Running OpenVPN itself might not, but wouldn't routing all my network traffic drive it up?

In standard configuration*: Yes.

[*]: Standard configuration is that the server tells the clients to route all traffic through him

See

I'm not eager to setup OpenVPN, as it would require per-device configuration rather than per-network config.

Is there a way to whitelist clients DNS queries while rejecting all other traffic?

Sure, you can explicitly ALLOW certain clients to be able to reach port 53 while DROPing all other requests using iptables.

How difficult would it be to implement a client white/blacklist that's accessible via the web ui? I'm very interested in the ability to blacklist malicious clients without having to maintain a whitelist of all of my device ip addresses.

Are you referring to OpenVPN? There won't be any OpenVPN specific settings on the Pi-hole web page. That would go certainly beyond the scope of the web interface of being something nice an comprehensive for Pi-hole matters.

See e.g. this: GitHub - Chocobozzz/OpenVPN-Admin: Install and administrate OpenVPN with a web interface (logs visualisations, users managing...)

Installing OpenVPN admin can cause problems with pihole? There will be conflict for port 80, right?

They say:

Web server (NGinx, Apache...)

so you may just clone this repo into a different folder in /var/www/html/ and use your existing lighttpd server for this. If that does not easily enough, you can of course also follow their instructions and change the port of the apache2 websever to something like 8080 afterwards. Or you could maybe configure it to use SSL only (port 443) and access it there. But I'm not an expert when it comes to apache2 configurations...

So, using port other than 80 just works fine...

No, not OpenVPN. I was referring to how pihole uses iptables to open a hole for DNS and web server on ports 53 and 80. I am attempting to ALLOW requests on port 53 from my ip address, while DENYing any other requests for port 53.

Since pihole prepends three rules to iptables (ALLOW all to port 53 udp/tcp and port 80 tcp, even before ufw rules), these rules supersede any custom firewall rules regarding these ports. Due to another unrelated issue, I have to run the basic\ install.sh command with the --unattended flag on ever boot. This command however readds the iptables rules if I have previously deleted them. I'm interested in seeing a way to opt-out of prepending the iptables rules, or a way to manage them (possibly including whitelisting ip's) via the web ui.

It would be better to resolve the need to run the installer on every boot. We can look at the firewall issue which should only fire if the ports are blocked, and if that logic needs to be adjusted, then we'll look at that. But first would be addressing the problem of adding the rulesets back in on every boot with the installer.

Also having similar issues, I noticed the other day 250,000 requests from a single IP and an identical amount for a single domain. There were also a few in the 10000-20000 request range from other IPs.

I'm running it on ubuntu in the cloud, so it was easy to block all the IPs making the requests ("ufw deny from 1.2.3.4" if anyone is wondering), and that worked for all but one - an ip in korea that for some reason ufw is refusing to block, or it's somehow getting through the block, anyone have any ideas for that? These are all going to a . domain too.

Edit: also not wanting to install a VPN as I use it on my entire networks both at home and at work and straight up refuse to entertain the idea of setting that up for 40+ devices (no router support), plus a few friends use it on their smart tvs and stuff so would like to still have the option open for them.

I had the same issue, but resolved it by deleting the three iptables rules that pihole adds on installation (allow tcp/udp port 53, allow tcp port 80). Try this:

sudo iptables -D INPUT -p tcp -m tcp --dport 80 -j ACCEPT
sudo iptables -D INPUT -p tcp -m tcp --dport 53 -j ACCEPT
sudo iptables -D INPUT -p udp -m udp --dport 53 -j ACCEPT

sudo ufw allow from <your.ip.here> to any port 53
sudo ufw deny 53

This should work until you update pi-hole (which will re-add the rules). I'm looking into saving the rules with iptables-persistent right now, I'll let you know if that works.

UFW isn't catching the requests because these auto-installed rules are superseding UFW, since UFW is a thin abstraction layer over iptables and rule order is critical in iptables.

Thanks for that, iptables had no entries on it though which is weird.

What I did now is deleted all ufw rules (/lib/ufw/user.rules) and set default to deny everything (ufw default deny incoming), then added back in my work, home, friends etc ips to 53 and 80, and so far that seems to be working perfectly. Will update if anything changes but this seems like the way to go for me at least.

We are reviewing a code change that will prompt for user approval prior to installing any rulesets. This will also remove the firewall configuration from the --unattended so that any changes to firewalls is done with a whiptail confirmation.