Reverse DNS Overview

This article explains the purpose of reverse DNS, and how to use it with Custom and Secondary DNS.

What is Reverse DNS?

Our Custom DNS and Dynamic DNS services provide what is often referred to as forward DNS. That is, these services map host names to IP addresses. Reverse DNS is simply the opposite of this, in that it maps IP addresses to host names.

Please note: If you are trying to solve mail rejection issues due to a dynamic IP address, or lack of reverse DNS records, you might want to try using our MailHop® Outbound service instead.

How does it work?

Forward DNS works by a series of delegations (called the "delegation chain") based on the host name reading from the right to the left. For instance, if you have a host name "www.example.com" the delegation chain starts with the root names servers. These servers are responsible for listing the name servers which are responsible for the COM domain. The COM name servers are then responsible for listing the name servers responsible for EXAMPLE.COM, which in turn are responsible for either resolving "fred.example.com" or listing yet another set of name servers which are responsible for WWW.EXAMPLE.COM.

The DNS query tool "dig" can be used to effective view the delegation chain in action using the "+trace" option. Below is a trimmed down view of an actual query for the host "www.example.com" (we've removed some of the additional root and COM name servers to make the response more readable). 

$ dig +trace www.example.com

; <<>> DiG 9.2.2 <<>> +trace www.example.com
;; global options:  printcmd
.                       288577  IN      NS      A.ROOT-SERVERS.NET.
.                       288577  IN      NS      B.ROOT-SERVERS.NET.
;; Received 292 bytes from 140.186.38.3#53(140.186.38.3) in 4 ms

com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
;; Received 493 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 195 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 113 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 55 ms

www.example.com.        172800  IN      A       192.0.34.166
example.com.            21600   IN      NS      a.iana-servers.net.
example.com.            21600   IN      NS      b.iana-servers.net.
;; Received 129 bytes from 192.0.34.43#53(a.iana-servers.net) in 95 ms

Reverse DNS works the same way, but instead of from right to left, the delegation chain starts at the left and moves to the right. For example: a query the IP address "204.13.248.76" would start with the root name servers, which would list the name servers responsible for for 63.in-addr.arpa zone (reverse zones all end with in-addr.arpa and are often referred to as IN-ADDR.ARPA Zones)

As before, the query tool "dig" can be used to effectively view the delegation chain for a reverse zone. Note the use of the "-x" option. 

$ dig +trace -x 70.109.167.222

; <<>> DiG 9.2.2 <<>> +trace -x 70.109.167.222
;; global options:  printcmd
.                       282510  IN      NS      A.ROOT-SERVERS.NET.
.                       282510  IN      NS      B.ROOT-SERVERS.NET.
;; Received 356 bytes from 140.186.38.3#53(140.186.38.3) in 4 ms

70.in-addr.arpa.        86400   IN      NS      epazote.arin.net.
70.in-addr.arpa.        86400   IN      NS      figwort.arin.net.
;; Received 196 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 97 ms

109.70.in-addr.arpa.    86400   IN      NS      NS4.VERIZON.NET.
109.70.in-addr.arpa.    86400   IN      NS      NS1.BELLATLANTIC.NET.
109.70.in-addr.arpa.    86400   IN      NS      NS2.VERIZON.NET.
109.70.in-addr.arpa.    86400   IN      NS      NS2.BELLATLANTIC.NET.
;; Received 141 bytes from 192.5.6.32#53(chia.arin.net) in 18 ms

222.167.109.70.in-addr.arpa. 86400 IN   PTR     pool-70-109-167-222.man.east.verizon.net.
167.109.70.in-addr.arpa. 86400  IN      NS      ns1.bellatlantic.net.
167.109.70.in-addr.arpa. 86400  IN      NS      ns2.verizon.net.
167.109.70.in-addr.arpa. 86400  IN      NS      ns2.bellatlantic.net.
167.109.70.in-addr.arpa. 86400  IN      NS      ns4.verizon.net.
;; Received 248 bytes from 151.203.0.87#53(NS4.VERIZON.NET) in 34 ms

Reverse DNS in Custom DNS

Custom DNS supports PTR records both in reverse (IN-ADDR.ARPA) zones as well as in forward zones. Because this can be somewhat tricky to setup, we have a separate KB article that covers Reverse DNS in Custom DNS.

Reverse DNS in Secondary DNS

Because this service simply loads a zone from your own primary DNS server, we can support both forward and reverse zones. If you have a block of IP addresses delegated to you, you can publish the necessary IN-ADDR.ARPA zone in your name server, set your server to allow transfer from us and setup the zone in our Secondary DNS server.

Secondary DNS can support entire /8, /16, and /24 blocks as well as smaller blocks using Classless IN-ADDR.ARPA delegation (see RFC 2317 for more info on these).

Secondary DNS also supports IP6.ARPA zones for those of you with delegated IPv6 address blocks.

Do I Need Reverse DNS?

In general? No. There is no general requirement that an IP address have reverse DNS. There is one specific case where a reverse DNS entry can be crucial. Many ISPs block mail from mail servers which don't have valid reverse DNS.

Note the use of the word "valid" in the above. Just what is meant by this. All this means is that the host name which the IP address resolves to has a corresponding A record that points back to the IP address.

For instance, this is perfectly valid: 
$ dig +short example.dnsalias.org
70.109.167.222

$ dig +short -x 70.109.167.222
pool-70-109-167-143.man.east.verizon.net.

$ dig +short pool-70-109-167-222.man.east.verizon.net
70.109.167.222

The fact that the IP address doesn't resolve to "example.dnsalias.org" is OK. It's not ideal, but in itself this should not prevent other mail servers from accepting mail sent by a mail server at that IP address (they might block the mail for other reasons, but not due to a lack of reverse DNS).

How MailHop Uses Reverse DNS to Block Spam

One of the options available in the "Manage DNSBL Settings" section for our MailHop Backup MX, Relay and Forward services is the option to block spam based on "Reverse DNS Verification". When this option is turned on, our MailHop servers will perform a Reverse DNS check on the IP address of an incoming connection and will reject mail from IP addresses which don't have valid Reverse DNS.

In this context, "valid Reverse DNS" means that:

  1. The IP address has a PTR record
  2. The host to which the PTR record points resolves back to the original IP address

The following two records represent a (fictional) example of valid Reverse DNS: 

    3.0.168.192.in-addr.arpa. 86400 IN     PTR     foo.bar.example.com.
    foo.bar.example.com.      86400 IN     A       192.168.0.3

If the IP address does not have a PTR record at all, or if the host to which the PTR record points has an A record pointing back to a different IP address, these would be examples of invalid Reverse DNS.

Please note, "Reverse DNS Verification" is a purely optional feature. It is off by default for all MailHop domains and may be turned on or off for individual domains as desired.