This tool will check if an IP address has a configured PTR record. Also, it will resolve the results to check if it points back to the same IP. This is what we call “FCrDNS” or Forward Confirmed Reverse DNS.
There are three possible expected outputs when using this tool.
These are examples of successful Reverse DNS tests:
1 – Most common output for PTR and A records
18.104.22.168.in-addr.arpa PTR mail.example.com mail.example.com A 10.20.30.100
2- Another common scenario, but using CNAME record
22.214.171.124.in-addr.arpa PTR mail.example.com mail.example.com CNAME srv.example.com srv.example.com A 10.20.30.100
3 – Or something as weird as this one:
126.96.36.199.in-addr.arpa PTR mail.example.com mail.example.com CNAME srv1.example.com mail.example.com CNAME srv2.example.com srv1.example.com A 10.20.30.100 srv2.example.com A 10.20.30.100
4- Reverse DNS output using classless delegation (more detailed below)
188.8.131.52.in-addr.arpa CNAME 100.0/184.108.40.206.in-addr.arpa 100.0/220.127.116.11.in-addr.arpa PTR websrv.example.com websrv.example.com A 10.20.30.100
Now, a common failure could be something like this:
18.104.22.168.in-addr.arpa PTR mail.example.com mail.example.com A 22.214.171.124 (failure)
Or something like:
126.96.36.199.in-addr.arpa PTR mail.example.com
mail.example.com A 10.20.30.100 (good)
mail.example.com A 10.20.30.101 (bad)
Reverse Dns validates if an IP has a valid PTR record configured and if its associated name (using an A record) points to that IP.
IP 188.8.131.52 (IP1) has the PTR record ec2-54-233-126-4.sa-east-1.compute.amazonaws.com.
And, ec2-54-233-126-4.sa-east-1.compute.amazonaws.com has the A record 184.108.40.206 (IP2)
Once IP1 matches IP2, then we say that Reverse DNS of IP 220.127.116.11 is valid. Of course, it is invalid otherwise.
In the old days, RFC 1034 (DOMAIN NAMES – CONCEPTS AND FACILITIES) defined the PTR record as follows:
The octets of the IP address are <reversed>, used as name components, and suffixed with “IN-ADDR.ARPA”. A type PTR query is used to get the RR with the primary name of the host. For example, a request for the host name corresponding to IP address 18.104.22.168 looks for PTR RRs for domain name “22.214.171.124.IN-ADDR.ARPA”.
And RFC 1912 (Common DNS Operational and Configuration Errors) states: “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“.
However, much of its popularity came from email services as it was always one of the first protections against poorly configured servers. It is an easy and cheap barrier.
Well, Yes it is.
There are several reasons (i.e. Spamhaus ISP Spam Issues) why you should take care of your reverse mapping (or should enable this feature in you email server configurations):
M3AAWG (a worldwide and most respected antispam organization) states in their Sender Best Common Practices (3.3 – Technical IP Details), section 2 (Reverse DNS):
a. The IP address of the sending server must have reverse DNS (also called PTR or IN-ADDR)
b. There must be only one reverse DNS name configured per IP address.
c. The name must exactly match the primary name chosen as per (1a) above.
As previously mentioned, Reverse DNS is one of the first anti spam barriers email administrators configure. Could this block valid messages? Yes, but it helps to discard much of the spam and garbage in email traffic. It is a trade-off.
You may find how to configure it in the Postfix manual (for example):
reject_unknown_client_hostname, in the smtpd_client_restrictions:
Reject the request when 1) the client IP address->name mapping fails, or 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address.
Traceroute is one of many applications that uses Reverse DNS to format the command output. When tracing the route from one IP to another it shows the associated reverse dns if it exists.
$ traceroute microsoft.com 09 ... 10 be-20-0.ibr01.gru30.ntwk.msn.net (126.96.36.199) 171.254 ms 170.826 ms 170.933 ms 11 be-6-0.ibr01.ewr30.ntwk.msn.net (188.8.131.52) 170.865 ms 170.692 ms 170.689 ms 12 be-5-0.ibr01.dub07.ntwk.msn.net (184.108.40.206) 170.887 ms 170.862 ms 172.018 ms 13 ...
This is a commonly misunderstood difference. Even though they seem the same, they are slightly different.
All IP blocks are distributed by IANA to the Regional Internet Registries (RIR): ARIN, LACNIC, RIPE, AFRINIC and APNIC. Then, those entities allocate the IP ranges to other players known as NIR (National Internet Registries) and down to local ISPs.
If you want to manage your own Reverse DNS zone, you need to contact your IP address provider and ask for a delegation to your own dns servers. The delegation is managed in terms of the octets that are part of the block (i.e. /8, /16, /24, etc). It means the blocks will be delegated to ranges larger than a /24 (at least).
For blocks smaller than a /24, the delegation could be configured in a different format called “Classless IN-ADDR.ARPA delegation” (below).
The hierarchy of domain like ipok.org is read from right to left, starting on the Root Servers (the dot ‘ . ‘), and going down to the most specific nodes. Differently from domain names, in IP address like “192.168.0.100” the most important part is the “192” octet. This is why it is impossible to establish a delegation path from right to left since the octet “100” is not at root level.
To standardize the domain infrastructure, the solution is to reverse the octets and use the default domain “in-addr.arpa“.
A reverse mapping for IP 192.168.0.100 looks like 220.127.116.11.in-addr.arpa.
The “arpa” zone is maintained by IANA as well as its “in-addr” sub-zone. From IANA:
The .arpa domain is the “Address and Routing Parameter Area” domain and is designated to be used exclusively for Internet-infrastructure purposes.
If you need to delegate less than 256 IPs, for example a /25 or /27, this is done using the classless reverse delegation. You may consult RFC 2317 for details.
Instead using PTR records, the technique defined by RFC takes place using CNAME records. Let’s consider using a class C block 10.20.30.0/24 and you want to delegate the block from 10.20.30.0 to 10.20.30.7 (/29) to one of your customers.
In this case, you must configure the parent zone “30.20.10.in-addr.arpa” and delegate the small block to the customer’s dns servers as follows (bind syntax):
0/18.104.22.168.in-addr.arpa IN NS customer-dns1.com 0/22.214.171.124.in-addr.arpa IN NS customer-dns2.com
Note that the syntax is: first address + network mask (both dash ‘-‘ or slash ‘/’ are acceptable).
Also, you must add the CNAME record for each IP of the space address:
1 IN CNAME 1.0/126.96.36.199.in-addr.arpa. (qualified format) 2 IN CNAME 2.0/188.8.131.52.in-addr.arpa. (qualified format) 3 IN CNAME 3.0/29 (short format) 4 IN CNAME 4.0/29 . . .
Your customer must add the zone: “0/184.108.40.206.in-addr.arpa” (pay attention to NS and SOA values), and configure PTR records as any other zone:
1.0/220.127.116.11.in-addr.arpa. IN PTR host1.example.com. 2.0/18.104.22.168.in-addr.arpa. IN PTR host2.example.com. . . .
You may use a hyphen instead of a slash. For example: the zone could be configured as “0/22.214.171.124.in-addr.arpa” (using slash) or “0-126.96.36.199.in-addr.arpa” (using hyphen). Just make sure you always use the same separator in the configurations thereafter.
Your IP: 188.8.131.52 (ec2-35-172-195-82.compute-1.amazonaws.com)