Do I Need Reverse DNS For Every Device?

Do the standards governing DNS operation require that all devices have a matching PTR record? No.

Do the standards for certain protocols require PTR records that agree with corresponding A or AAAA records? Yes.

Do some applications not governed by a RFC have the same requirements? Yes.

Can a PTR record point at a CNAME? Yes, but the CNAME target must must be the unique name of the device in question (and not another CNAME). ( RFC 2181§10.2 RFC1034 §3.6.2 )

Is mandatory PTR record creation a best practice? Commonly believed so, but it has its own problems.

A tragically underquoted section of RFC1796 applies here:

It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal. In fact, each RFC has a status, relative to its relation with the Internet standardization process: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic.

RFC1912 is Informational. RFC1033 is not clearly labeled and has an official designation of UNKNOWN, which means it's so old that it should not be considered a reference for anything. They do not define Standards, nor can they be used to officially augment a standard. They should never be quoted in the context that implies that they are defining a standard.

Think of Informational RFC suggestions as good advice and commonly accepted best practice. The reverse DNS recommendations make sense at a glance: following these guidelines lower your risk of being put into situations where an application fails to work because reverse DNS was necessary and not planned for. You certainly can't expect a DNS admin to know every application/protocol that requires it, and sadly the same tends to be true of the service owners requesting those records.

That said, outside of very good automation, mandatory PTR record creation policies also create pollution.

  • It's extremely commonplace for PTR records to not be kept in sync with their corresponding A/AAAA records as devices are decommissioned, resulting in a creep of bogus PTR data over time. This data only serves to mislead those who attempt to treat that information as credible. Some application owners are eager to jump on it when they're hunting for the cause of a phantom problem. The problem will only continue to get worse as IPv6 adoption becomes more commonplace, particularly for DNS admins responsible for carrier sized IP space.
  • Having multiple PTR records for the same IP address is pretty useless, and adhering to the advice of the Informational RFCs will inevitably result in this. See: Why multiple PTR records in DNS is not recommended?

What is worse: absence of a PTR record, or an inaccurate PTR record? If a protocol breaks because its standard requires valid DNS, both are bad, and the latter could actually be worse. Outside of that, everyone has a different opinion on the matter. That's fine: you are free to put together the policies and tools that work best for your team and company. Just make sure that they scale and yield consistent results, and remember that reverse DNS will only be as accurate as the time and discipline your team members have to give it.

But missing PTR records cause sshd to hang!

Also not true. People often confuse the line between absence of a PTR record (NXDOMAIN), and broken reverse DNS.

A reply of NXDOMAIN will only cause a problem if you are communicating with a service that requires forward confirmed reverse DNS (FCrDNS). Mail servers, Kerberos, Oracle scan VIPs, etc.

Broken reverse DNS is when it's impossible for you to get a NXDOMAIN response in a timely fashion. Many applications (most famously sshd) will block on the reverse DNS lookup if there are problems acquiring a response from upstream sources in a timely fashion, causing delays within the application.

If you have any comments, feel free to post them below or find us on Twitter and Facebook!

- Until next time!

December 20 2019

Add or review comments

Please leave your comment

Existing comments

Comments 0