You've come to this page because you've said something similar to the following:
Servers can perform a "double-reverse" DNS lookup on the IP addresses of service clients that connect to them via TCP, for security. It is a requirement of the DNS that an address→name→address mapping yield the original IP address. Where this isn't the case, the published DNS data are wrong and the DNS administrator is incompetent. Double-reverse DNS lookup verifies that a client is known.
This is the Frequently Given Answer to such statements.
"Double reverse" lookup (mapping the IP address to a set of domain names, mapping those domain names to a set of IP addresses, and then comparing the result with the starting point) is not a security measure. It is a half-baked idea from the Half-Baked Ideas Brigade.
If you have a TCP-based service that is performing such address→name→address mappings in the name of security, disable it. It's wrong, and it will cause you grief.
The justification for this half-baked idea is simply false. The DNS doesn't operate in the manner claimed, such DNS data are perfectly legitimate, and it is the users of the half-baked idea, not the DNS administrators, that are at fault.
This half-baked idea doesn't allow one to prove the identities of service clients. The only thing that it actually proves is that those who use it don't know how the DNS operates.
The notion that security is somehow tighter with this check in place, is simply a false one. An attacker who is able to create a TCP connection to one's TCP-based service with a forged client IP address has, of necessity, more than enough access to foil this Half-Baked Idea.
An attacker who can create a TCP connection to a service with a forged client IP address either
Conversely, security based upon client IP addresses is enough to thwart an attacker who is incapable of forging DNS responses, because such an attacker will not have the capability for successfully creating a TCP connection with a forged client IP address, either.
Setting aside the major conceptual flaws of the half-baked idea for the moment:
To perform the address→name→address mapping in the manner described by the Half-Baked Ideas Brigade members, one has to perform name→address lookups for all of the domain names obtained as the result of the address→name lookup.
At the time of writing this answer, the IP address 64.156.26.80 maps to 139 different domain names. In order to perform a "double-reverse" DNS lookup on a client connecting from that IP address, a server would have to perform 140 separate DNS lookups. That's a huge amount of DNS traffic, incurred by the server at the point where the client has done no more than make a connection. (Luckily, in this particular case, because of what is probably a common error on the part of the DNS administrator concerned, described in RFC 1537 § 5, all of the domain names are under a common superdomain. If they weren't, the amount of DNS traffic would be considerably larger still.)
That's a considerable delay to incur between a client making a connection to the server and the server starting to provide actual service.
Moreover, and somewhat ironically, it's quite a hefty denial-of-service amplification tool to hand to malicious third parties. To orchestrate a concerted bandwidth consumption attack on an organisation's content DNS servers, an attacker need only make connections to a group of randomly selected servers, that employ this half-baked idea, from an IP address whose address→name→address lookup involves querying those content DNS servers a lot for some reason. (The attacker doesn't even need to make any use of the actual service.)
The existence of a successful address→name→address mapping does not imply that the client with that IP address is somehow more "valid" than a client whose IP address cannot be so mapped. A client whose IP address cannot be mapped to a domain name, or whose IP address is not included in the result of a double-reverse DNS lookup, is not "unknown".
Mapping an IP address to a set of domain names does not cause one to "know" (in terms of security or validity) anything more about that IP address. One continues to know exactly the same as one knew to begin with. Mapping those domain names back to IP addresses doesn't cause one to "know" anything more about that IP address, either.
The assertions about the way that the DNS operates, justifying this half-baked idea, are simply false. People who make these assertions have a wrong understanding of the DNS. There is nothing in the Internet standards for the DNS that supports these assertions.
There is no requirement upon the DNS that a machine have one, and only one, domain name. Indeed, RFC 2181 § 10 explicitly denies this assertion.
Moreover, the recommendation in RFC 1912 for supporting "localhost." should be enough to prove that most machines have at least two domain names. Some have many more than that.
There is no requirement upon the DNS that all IP addresses be mappable to domain names, despite what those who point to RFC 1912 may assert. (RFC 1912 is an informational document, not a standard. Its recommendation in § 2.1 has no foundation in the actual DNS standards, and is not a requirement upon the DNS. Indeed, its recommendation only exists in the first place because the author noticed that people employ this half-baked idea, which is in turn because the author himself spent the previous several years promoting this half-baked idea as a "security" measure to people. Arguing that this half-baked idea is required by RFC 1912 is not only putting the cart before the horse, it is circular.)
Such a requirement would be a pointless restriction of the freedom of IP address owners, would pad the public DNS database with additional data, and would place a large additional burden upon DNS administrators.
Having an association between an IP address and one or more domain names is a convenience, for the benefit of network (and other) administrators, not a requirement. Indeed, there are vast swathes of the IP address space that have no mappings to domain names. It's perfectly legitimate for an IP address to have no mapping at all to any domain names. It's perfectly acceptable for the owner of an IP address to decide that any domain names that may be associated with that IP address are none of anyone else's business, or to decide that that IP address simply be associated with no domain names whatever.
Put another way: There's no requirement that everyone who possesses an IP address pay to rent a domain name as well.
So "double reverse" lookup is not guaranteed even to be able to perform the initial address→name mapping.
There is no requirement upon the DNS that the name→address and address→name mappings be inverses of each other. The two mappings are entirely independent from each other. The fact that a mapping in one direction exists does not impose the requirement that a mapping in the reverse direction exists.
Indeed, there are good reasons for DNS administrators to ensure that the name→address and address→name mappings are not inverses of each other. DNS administrators are encouraged to make the address→name mappings not the inverses of the name→address mappings by:
So even were it required to exist (which, as already explained, it is not) the address→name→address mapping is not required to be an identity, and for good reasons will not be an identity in practice. "double reverse" lookup is not guaranteed to return to its starting point.