Arnold Dechamps

The State of Reverse DNS

Arnold Dechamps

7 min read


Most people know DNS for the part that resolves a domain name to an IP address. Reverse DNS, as the name suggests, works the other way around, and is generally less talked about. The question is, when people do implement reverse DNS, are they taking steps to keep it secure?

Reverse DNS offers a way to get a nice fully qualified domain name (FQDN) from an IP. For many, its importance lies mainly in the fact that it can be used to identify spam. How so?

Well, setting up a proper reverse-DNS record on a mail server can be hard to do, so when you see it, you can usually be sure you're not looking at a random SMTP server put together by a spammer. This has led many to adopt the practical assumption: if no reverse DNS, then spam. In other words, doing reverse DNS has become necessary if you want to be treated as a legitimate mail server.

This approach has its downsides. For one thing, it means that homemade or self-hosted mail servers also get treated as spam. But nevertheless, doing proper reverse DNS can be considered a way to maintain good hygiene on the Internet.

DNSSEC and reverse DNS

And when it comes to doing reverse DNS, as with doing any DNS at all, it's important to keep things secure. The way DNS works allows for a man-in-the-middle (MITM) attacks at various levels. By inserting rogue responses, attackers can redirect users to malicious sites. For resolvers, we can establish a chain of trust with DNSSEC. That way, we can guarantee integrity of the replies from the authoritative DNS straight up to the root.

Although DNSSEC is best practice, implementing and maintaining the system can be complex. So here, I wanted to ask: how many people who do reverse DNS also take the extra step of doing DNSSEC?

But first, what does reverse DNS look like in practice?

It's surprising how many people asked this question when I've talked about this project, so I thought I would write up an answer here. Basically, when you do a host command on a hostname, you will get an IP in return. Then, if you make the host request again with the IP, you will get a hostname back.

~ % host has address has IPv6 address 2a02:578:8525:152d:588e:78ff:fec5:a9eb

 ~ % host 2a02:578:8525:152d:588e:78ff:fec5:a9eb domain name pointer

As you can see, when doing the reverse DNS lookup, the "host" program will run a request where it just takes the IPv6, inverts it, adds a dot between every hex character, and terminates it with In IPv4, it will do it per byte basis and append with

IPv6 does it that way because one hex character includes far more data and also because it makes more granular DNS delegation possible (if you get a part of the prefix). IPv4 reverse DNS was defined when we still used classful prefixing. So there's no point going lower than a byte for granularity. Delegating based on CIDR was later made possible with RFC2317 (yet another legacy problem that IPv6 fixes)

As one of the five RIRs, the RIPE NCC provides reverse DNS delegations for its address space. When a domain object is created in the RIPE database a reverse DNS delegation to a member controlled name server is added.

So, why this article?

While creating a new domain object in the RIPE database, I saw that checks where run against the creation of ghost objects in their DNS config. This is certainly a good thing, but it did lead me to wonder if periodic checks were performed on the servers and whether they are all well maintained.

Another thing I noticed is that, while the documentation to implement DNSSEC exists, it's written in a way that it doesn't exactly leap off the page. This documentation shows a basic functional config without mentioning the existence of DNSSEC until point 4. But, since the user should have got things working at point 3, I suspect few are likely to proceed to point 4 at all.

I wanted to take a look with actual data.


I wrote a script on github that uses a daily sanitised dump of the RIPE-NCC database available at this location. The idea is to read which objects have a DNSSEC config and compare it to the total, but also to test if the DNS servers reply correctly and are still authoritative for their zone.

Once that script is working, I run it with the same datadump at the same time from four different machines available on four different ASNs with four different DNS configs.


MacBook Air Home-Machine Hetzner HSBXL
Mac OS 14.3 Debian 12 Debian 12 Debian 12
AS62392 Fosdem AS9031 EDPNET AS24940 Hetzner AS62383 (IPv4) Wireless Belgie ; AS6939(IPv6) HE
Fosdem DNS Google DNS Hetzner DNS HSBXL DNS


sha256sum ripe.db.domain :


Test performed on 04/02/2024 at 15:10
MacBook Air Home Hetzner HSBXL
Total Number of Objects 851901 851901 851901 851901
DNSSEC configured 7414 7414 7414 7414
Working DNS servers 753845 770444 751533 727203


As we can see, the working DNS servers are ok. It's a good 88.12% on average. That still means that approximately 20% are broken. Maybe it could be possible to implement a system where periodical tests of the zones are run and if it stays offline for a while, an email gets sent...

For DNSSEC, we are at 0.87% implementation. That is VERY low. I expected it to be low, but not that low. For that one, maybe editing the documentation so that DNSSEC shows up higher in it might be a good option. Keep in mind, those are only the results of the amount of objects that have it configured. Not that have it working.


Today, most reverse DNS objects seems to be working. However, progress can still be made when it comes to their maintenance. For DNSSEC, existing documentation should probably be updated if we want to actually define DNSSEC enabled reverse DNS as a standard.

Interesting related resources: (extensive zone tests)

Zonemaster RIPE (extensive zone tests, but from RIPE)

Reverse-DNS RIPE documentation

Reverse-DNS Domain object structure

BIND9 DNSSEC configuration doc


Github of my own testing program


About the author

Arnold Dechamps Based in Brussels

Network Engineer of possible. I do things with stuff. Generally curious about tech and things that tend to turn into very deep rabit holes, I like to understand how things work and I try to break them. That way I can understand problems and correct them before someone exploits them. You can find me somewhere between a datacenter and a hacker event ;-)

Comments 3