Forward-confirmed reverse DNS (FCrDNS), also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards supporting many DNS-reliant protocols. David Barr published an opinion in RFC 1912 (Informational) recommending it as best practice for DNS administrators, but there are no formal requirements for it codified within the DNS standard itself.^[1]

A FCrDNS verification can create a weak form of authentication that there is a valid relationship between the owner of a domain name and the owner of the network that has been given an IP address. While weak, this authentication is strong enough that it can be used for whitelisting purposes because spammers and phishers cannot usually by-pass this verification when they use zombie computers for email spoofing. That is, the reverse DNS might verify, but it will usually be part of another domain than the claimed domain name.

Using an ISP's mail server as a relay may solve the reverse DNS problem, because the requirement is the forward and reverse lookup for the sending relay have to match, it does not have to be related to the from-field or sending domain of messages it relays.

Other methods for establishing a relation between an IP address and a domain in email are the Sender Policy Framework (SPF) and the MX record.

ISPs that will not or cannot configure reverse DNS will generate problems for hosts on their networks, by virtue of being unable to support applications or protocols that require reverse DNS agree with the corresponding A (or AAAA) record. ISPs that cannot or will not provide reverse DNS ultimately will be limiting the ability of their client base to use Internet services they provide effectively and securely.

Applications

• Most e-mail mail transfer agents (server software) use a FCrDNS verification and if there is a valid domain name, put it into the "Received:" trace header field.
• Some e-mail mail transfer agents will perform FCrDNS verification on the domain name given on the SMTP HELO and EHLO commands. This can violate RFC 2821 and so e-mail is usually not rejected by default.
• The Sender Policy Framework email anti-forgery system uses a FCrDNS check in its "ptr:" mechanism. However, the use of this "ptr:" mechanism is discouraged since the first standardization of SPF in 2006 (in RFC 4408).
• Some e-mail spam filters use FCrDNS checks as an authentication method for domain names or for whitelisting purposes, according to RFC 8601, for example.
• SpamCop uses the FCrDNS check, which sometimes causes problems for SpamCop users who are also customers of Internet service providers who do not provide properly matching DNS and rDNS records for mail servers.
• Some FTP, Telnet and TCP Wrapper servers perform FCrDNS checks.
• Some IRC Servers perform FCrDNS checks to prevent abuse.

References