Step by Step: How to Fix your server’s DNS Resolver within 5 minutes

Emails can be scary. Especially if they’re not coming from @gmail, @hotmail, or whatever, but from a damn government agency—and not just once. But the culprit is not you; it’s your DNS Resolver.

tl;dr

Start at Step 1.

Luckily, I had done my homework when I chose my server and can now enjoy the tears in /r/hosting where people – despite a million warnings – open posts and beg for help to get out of GoDaddy’s contract. GoDaddy, and this must be said once and for all, is the absolutely shittiest, cheapest (I don’t mean the price), and most scammy hosting provider out there!

E-Mail from Hell

Alright, since this is clear now, let’s continue with the emails. So, every few weeks, I’d receive an email from Hetzner, immediately scaring the shit out of me.

Sender: [email protected].
Subject line: [AbuseID:112F9G4A:1B]: AbuseBSI: [CB-Report#20260218-10003814] Offene DNS-Resolver in AS24940¹

Recipient: me 😬

That doesn’t sound good, I remember thinking, not good at all. Hetzner is a German company. I am a German citizen. And I’ve been busted before for torrenting a shitty German movie I thought nobody, but my then-girlfriend, would care about anyway. Well, as it turned out, one of these law firms that always has one or two partners (“Wehler, Henkel & Secht” or something) did care, and their care had a price tag: €1,000 EUR, please. I paid the same day.

Federal Office for Information Security

I immediately thought of this rather forgotten day in my life and hastily skimmed the email. Hetzner’s scary [email protected] handle had only redirected an email they had received (I let my email client translate it into English, only for you!):

The real reason for this was buried in the email history at the end. No translation here, because only the highlighted part meant something:

So, the Federal Office for Information Security had been asking me for months, if not years, via the CERT Bund to close my open DNS resolver. No problem, if I only knew how. But that’s exactly where Cherry Studio, my desktop AI client, came into play. I have “assistants” for nearly everything, all carefully fed with system instructions to get the best out of each model.

So it was only natural that I also had a “Server Guy,” whom I fed with all conceivable information about my dedicated server, the websites they host, its technology, and so on. My LLM of choice was GLM-4.7, which costs me nothing, so there’s that. Not even 5 minutes later, I was done.

A’ight, let’s get our hands dirty and shut this DNS Resolver down!

Step 1: Login

Spin up the terminal of your choice and SSH into your server (you must be root, obviously). Here’s mine, for the curious ones:

Step 2: Identify the Server

To see what’s running, use one of the two commands:

systemctl status named
# OR
systemctl status bind9

systemctl status named
# OR
systemctl status bind9

Right at the top of the output, you’ll see named.service, and behind that what’s actually running. In my case BIND Domain Name Server.

Step 3: Check if it is an open DNS Resolver

grep -A 10 "allow-recursion" /etc/named.conf

grep -A 10 "allow-recursion" /etc/named.conf

You’ll get some text, but look out for this:

allow-recursion {
  any;
};

allow-recursion {
  any;
};

You can already see what I flagged. It’s the “any” that the Federal Office for Information Security doesn’t like—an open DNS resolver. Because it can be hijacked for DDoS attacks.

Step 4: Change DNS Resolver

Open the file (nano /etc/named.conf) and switch the any to localhost, like this:

allow-recursion {
	127.0.0.1;
	::1;
};

allow-recursion {
	127.0.0.1;
	::1;
};

Step 5: Last Steps

1. Verify

named-checkconf

named-checkconf

No output? That’s how it should be.

2. Reload BIND

systemctl reload named

systemctl reload named

3. Verify it’s running

systemctl status named

systemctl status named

Save, exit, and be happy you’ll never get scary emails again. At least not from Hetzner.

Checks (optional)

But since we’re professionals and don’t get our servers at GoDaddy (or anything else for that matter!), we do a quick check.

From your local machine, swap the the IP to your server’s IP, and run:

dig @75.31.131.28 google.com # Change IP to your server's IP

dig @75.31.131.28 google.com # Change IP to your server's IP

This should give you some output with the words REFUSED on SERVFAIL. That means recursion is now blocked.

Last check, this time on your server (No need to change anything here):

dig @127.0.0.1 google.com

dig @127.0.0.1 google.com

Here, however, recursion must work. If you see anything from the above, check for missing commas or semicolons in /etc/named.

What do we learn from this story? How to close the DNS resolver, of course. And that not every email with “abuse” in its name is to be taken literally.

1. Numbers changed for security reasons ↩︎