The State of Reverse DNS

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.

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 .ip6.arpa. In IPv4, it will do it per byte basis and append with .in-addr.arpa.

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.

Methodology

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.

Setup

Results

sha256sum ripe.db.domain :

98160486a775b3876a059fb9d73023608d22ea2ead8d152b776d7ba8e57edea0

Observations

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.

Conclusion

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:

Zonemaster.net (extensive zone tests)

Zonemaster RIPE (extensive zone tests, but from RIPE)

Reverse-DNS RIPE documentation

Reverse-DNS Domain object structure

BIND9 DNSSEC configuration doc

RFC2317

Github of my own testing program