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 PTR A

2- Another common scenario, but using CNAME record PTR CNAME A

3 – Or something as weird as this one: PTR CNAME CNAME A A

4- Reverse DNS output using classless delegation (more detailed below) CNAME 100.0/
100.0/ PTR A

Now, a common failure could be something like this: PTR A (failure)

Or something like: PTR A (good) A (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 (IP1) has the PTR record

And, has the A record (IP2)

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

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

 09  ...
 10 (  171.254 ms  170.826 ms  170.933 ms
 11 (  170.865 ms  170.692 ms  170.689 ms
 12 (  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 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 “” 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 ““.

Reverse DNS path delegation
A reverse mapping for IP looks like

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 and you want to delegate the block from to (/29) to one of your customers.

In this case, you must configure the parent zone “” and delegate the small block to the customer’s dns servers as follows (bind syntax):

0/ IN NS
0/ IN NS

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/ (qualified format)
2 IN CNAME 2.0/ (qualified format)
3 IN CNAME 3.0/29 (short format)
4 IN CNAME 4.0/29 
. . .

Your customer must add the zone: “0/” (pay attention to NS and SOA values), and configure PTR records as any other zone:

1.0/ IN PTR
2.0/ IN PTR
. . .

You may use a hyphen instead of a slash. For example: the zone could be configured as “0/” (using slash) or “” (using hyphen). Just make sure you always use the same separator in the configurations thereafter.

Your IP: (