Forward-confirmed reverse DNS
FCrDNS, or forward-confirmed reverse DNS, also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a situation where a given IP address has forward (name-to-address) and reverse (address-to-name) DNS entries that match each other. The process of checking this is as follows (described as a Proposed Standard by RFC 5451, section 3; and previously outlined in RFC 1912, especially section 2.1):
- First a reverse DNS lookup (PTR query) is performed on the IP address, which returns a list of zero or more PTR records.
- For each domain name returned in the PTR query results, a regular 'forward' DNS lookup (type A or AAAA query) is then performed on that domain name.
- Any A or AAAA record returned by the second query is then compared against the original IP address, and if there is a match, then the FCrDNS check passes. Example:
DNS query type PTR on 192.0.2.4 --> returns PTR-record="hostname.example.com" (1 result) DNS query type A on "hostname.example.com" --> returns A-record=192.0.2.4 (1 result) Matches original IP address, therefore check passes
Some system may need to do a reverse DNS lookup. This could be for things like logging of connecting clients or authenticating clients. Iprev is a way to verify that the result of the reverse DNS is really the proper hostname. An attacker that just has control over the reverse DNS would then not be able to fake the hostname of the connecting client, because the hostname would resolve back to a different IP address. When this test fails it's usually a good indication that the reverse lookup should not be trusted for anything.
It's not recommended to use this for authentication without authentication of the DNS itself with something like DNSSEC.
It's considered good practice that all reverse DNS is forward confirmed, following the instructions in RFC 1033 on "Adding a host".
Network verity [edit]
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 can not usually by-pass this verification when they use zombie computers for mail spoofing. That is, the reverse DNS might verify, but it will usually be part of an other domain than the claimed domain name.
A failed verification does not mean that there is no relation between the domain name and the IP address. There are various reasons why it may be impossible, impractical or not desirable to set up forward confirmed reverse DNS in the correct domain including being on a dynamic IP address, not having control over the reverse DNS, 1 IP address might be hosting more than 1 domain name, wanting to hide services and so on. It is therefore not recommended to take a failed verification as proof of anything. It is how,ever a mandatory internet requirement, according to RFCs that each and every host has a valid reverse lookup. If your connection for sending mail is on a dynamic IP, which does not allow a reverse lookup, then the logical choice is to use your ISP's mail server to relay for you.
However there are systems that take having no reverse DNS, a failed verification, reverse DNS in an other domain or something that looks like the reverse of a dynamic IP address into account because they see a correlation between that and spam, but correlation does not imply causation, however reverse records are easy to setup and impossible to fake, and thus rejecting mail based on a failed reverse lookup is a very good first line of defence, and prevents further wasteful processing by the downstream antispam system on a message already deemed to be faulty or suspect. Therefore it's recommended to set up reverse DNS for outgoing email servers when possible and have it forward confirmed so that it's more likely that your email won't get wrongly rejected as spam. As of 2012 almost all ISPs now take the setting of reverse DNS as a standard requirement.[citation needed].
In some cases ISPs won't set up reverse DNS for their clients, nor delegate it to them. This causes problems for people using that ISP because they can't set up the forward-confirmed reverse DNS and so might get email rejected on this basis. It is very effective and filtering out spam, and is typically common practice for discerning mail systems to check the pointer records and reject those that fail the test.
Using your ISPs mail server as a relay will solve the reverse DNS problem, because, contrary to what some believe, the requirement is the forward and reverse lookup for the sending relay only has to match, it does not have to be related to the "from" or sending domain of emails it relays. For example, joe (at) example.com might wish to relay through smtp.someisp.com (ip a.b.c.d), provided the forward and reverse lookup for smtp.someisp.com matches with its ip of a.b.c.d the test passes. So there is no excuse not to have this set correctly under any legitimate circumstances.
Another way to establish a relation between an IP address and the domain when using email is using the Sender Policy Framework and the MX record. It is however unclear whether systems that try to check that an IP address belongs to some domain take this as alternative to the reverse DNS check.
Common DNS misconfigurations are outlined in RFC 1912, of particular note is section 2.1 that states, under the heading "Inconsistent, Missing or Bad Data", "Make sure your PTR and A records match." Those ISPs that will not or cannot configure reverse DNS will generate problems for hosts on their networks, by virtue of RFCs being contravened when communicating with hosts that do follow the RFC guidelines. From a technical perspective reverse DNS is trivial to implement correctly and there is no reason not to implement it for hosts providing regular internet services. 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.
Uses [edit]
- 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 e-mail anti-forgery system uses a FCrDNS check in its "ptr:" mechanism.
- Some e-mail spam filters use FCrDNS checks as an authentication method for domain names or for whitelisting purposes; for example, according to RFC 5451.
- 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 their mail servers. [1] [2]
- Some FTP, Telnet and TCP Wrapper servers will perform FCrDNS checks.[citation needed]
- Some IRC Servers perform FCrDNS checks to prevent abuse.
