Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

1 Answer 1

up vote 26 down vote accepted

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? No, the right hand value should not be an alias.
( 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, despite the lack of clear labeling, is also Informational. 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 synch 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.

share|improve this answer
    
The specific case of sshd responding slowly can be avoided by putting UseDNS no in sshd_config. (But even though you can work around the problem it is of course still not acceptable, if reverse DNS times out or produce a server failure response.) –  kasperd Sep 14 at 9:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.