Home

Reverse DNS

Reverse DNS

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.

Notes about Results


There are three possible expected outputs when using this tool.

  • Success: PTR and A records exist and the IPs match. Your Reverse DNS is properly configured.
  • Fail: PTR or A record is missing, or IPs don’t match. Depending the purpose in which you are using this address you will certainly have a problem.
  • Warning: The configuration is not totally incorrect, but there might be scenarios where it could fail.

These are examples of successful Reverse DNS tests:

1 – Most common output for PTR and A records

100.30.20.10.in-addr.arpa PTR mail.example.com
mail.example.com A 10.20.30.100

2- Another common scenario, but using CNAME record

100.30.20.10.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:

100.30.20.10.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)

100.30.20.10.in-addr.arpa CNAME 100.0/25.30.20.10.in-addr.arpa
100.0/25.30.20.10.in-addr.arpa PTR websrv.example.com
websrv.example.com A 10.20.30.100

Now, a common failure could be something like this:

100.30.20.10.in-addr.arpa PTR mail.example.com
mail.example.com A 40.50.60.100 (failure)

Or something like:

100.30.20.10.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)

Notes about Reverse DNS


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.

For example:

IP 54.233.126.4 (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 54.233.126.4 (IP2)

Once IP1 matches IP2, then we say that Reverse DNS of IP 54.233.126.4 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 1.2.3.4 looks for PTR RRs for domain name “4.3.2.1.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.

Is Reverse DNS still so critical ?

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):

  • It allows people to associate and quickly identify IP addresses with domain names. This is useful when reporting spam or abuse.
  • You avoid traffic from lazily configured servers.
  • It could be a useful barrier against malwares or bots sending massive spam messages from compromised home computers.
  • It is a consensus among email administrators to reject connections coming from an IP without at least having a rDNS.
  • Analyzing your server logs (and considering many companies has dedicated IP space), you may see who is visiting your website, application or sending emails (failures, attacks, and so on).

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)
configured.
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.

Reverse DNS and Email Systems

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.

Reverse DNS and Traceroute

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 (104.44.22.86)  171.254 ms  170.826 ms  170.933 ms
 11  be-6-0.ibr01.ewr30.ntwk.msn.net (104.44.19.170)  170.865 ms  170.692 ms  170.689 ms
 12  be-5-0.ibr01.dub07.ntwk.msn.net (104.44.16.113)  170.887 ms  170.862 ms  172.018 ms
 13  ...

What is the difference between rDNS and FCrDNS ?

This is a commonly misunderstood difference. Even though they seem the same, they are slightly different.

  • rDNS means Reverse Dns. It is only the name found when querying a PTR record.
  • FCrDNS means Forward Confirmed Reverse DNS. First we need to find the name associated with the IP address (through PTR record) and then perform a new query to get the A record associated with this name.

Reverse DNS Delegation

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.

Regional Internet Registries

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“.

Reverse DNS path delegation
A reverse mapping for IP 192.168.0.100 looks like 100.0.168.192.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.

Classless Delegation

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/29.30.20.10.in-addr.arpa IN NS customer-dns1.com
0/29.30.20.10.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/29.30.20.10.in-addr.arpa. (qualified format)
2 IN CNAME 2.0/29.30.20.10.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/29.30.20.10.in-addr.arpa” (pay attention to NS and SOA values), and configure PTR records as any other zone:

1.0/29.30.20.10.in-addr.arpa. IN PTR host1.example.com.
2.0/29.30.20.10.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/29.30.20.10.in-addr.arpa” (using slash) or “0-7.30.20.10.in-addr.arpa” (using hyphen). Just make sure you always use the same separator in the configurations thereafter.

Your IP: 128.14.133.58 (survey.internet-census.org)