Odd reverse DNS entries keep coming up from time to time. So I think we are due for a quick public service announcement about reverse DNS.

Reverse DNS can be a valuable to find out more about an IP address. For example:

$ dig +short -x 73.53.237.51
c-73-53-237-51.hsd1.fl.comcast.net.

This tells me that the IP belongs to Comcast and is probably located in Florida. 

$ dig +short -x 189.154.91.153
dsl-189-154-91-153-dyn.prod-infinitum.com.mx.

the "dyn" part usually indicates that this is a dynamic IP address. For example, mail servers will often mark e-mail received from them as spam. In particular spam filtering relies often on reverse DNS. In order to configure reverse DNS, you typically need to be assigned an IP address block from your ISP, and the ISP needs to make your DNS server authoritative for the block by adding respective NS (name server records). This can not be done for dynamic IPs and typically requires at least a /24 assignment (some ISPs allow updating reverse IP addresses via web applications to allow small business users with /29s or individual IPs to update reverse DNS records).

So what is the problem? Let's take a look at this IP that our reader John noted in his e-mail server logs:

$ dig +short -x 123.28.192.74
localhost.

That's right. This IP resolves to "localhost". This isn't exactly a new trick. Sometimes I think this is just done out of laziness. But the effect is that e-mail from this IP may slip past some spam filters, and it is a bit more difficult to find the actual owner of the IP. A quick sample suggests that all IPs in 123.28/16 resolve to localhost.

The problem with reverse DNS is that the owner of the IP address is in charge of reverse DNS, not the owner of the domain the IP resolves to. Anybody who has control over reverse DNS for an IP address block can make the address reverse resolve to "isc.sans.edu" (or localhost).

Some access control mechanisms use hostnames instead of IP addresses, and as a result, rely on reverse DNS for access control. This is BAD!

To trust reverse DNS, you need to at least make sure that forward and reverse DNS matches. This way, both the owner of the domain, as well as the owner of the IP address, have to enter matching configurations. For example, if you are adding form="*.example.com" to your ssh authorized_keys file, sshd will make sure forward and reverse resolution match. Same if you try to figure out if a particular IP address But even in this case, you are still using DNS, a not very robust protocol, for security decisions. This is fine as an additional constraint, for example in addition to an ssh key, or for spam filtering in which case you do not have to be perfect.

If you are using reverse DNS as part of your incident response process, then you also need to be aware that whoever operates the authoritative name server for that IP will likely learn of your requests. The attacker may be affiliated with the operator. This is mostly a concern for more sophisticated attackers, but overall it may be a good idea to at least use a more "anonymous" recursive name server like Google, OpenDNS or Quad9.

RFC1912 actually states that every IP should have a name (and with that, a PTR record). But note it says should, not must. I believe it is a good idea to configure reverse DNS. But keep in mind that it should not leak information. I like the system that most ISPs use, that essentially use something like [ipaddress].example.com. This way, a reverse lookup will still point to the right owner of the IP, but it will not leak any information beyond that. A "whois" lookup would give you the same information, but whois tends to be slower, more difficult to update, and more difficult to parse then DNS. Unless your system is a mail server, in which case you want to make sure that forward and reverse DNS matches to avoid spam filter problems.

And don't forget to make sure that you sanitize and properly encode reverse DNS results before using them. They should never be treated as "trusted".

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
STI|Twitter|