Do internet standards require reverse DNS for every device?

Question

The requirements surrounding reverse DNS are confusing! People frequently talk about everything breaking if reverse DNS is not present, and that sounds scary. Even in cases where applications don't require reverse DNS, RFCs are frequently cited in support of mandatory PTR record creation.

Some of these RFCs include:

RFC1912: Common DNS Operational and Configuration Errors

Every Internet-reachable host should have a name. ... Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all.

RFC1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE

Adding a host.

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

Despite all of that, some people still insist on saying that PTR record creation is not required by the standards governing DNS administration. What are the actual requirements?

Answer 1

Short Answer

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.

Long Answer

This Q&A is provided with the intent of helping to put to rest a common misunderstanding.

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.