What Is Reverse DNS?
So far in the Customer Tips blog series we’ve covered everything from what is a hostname? to how to decrease latency with Traffic Director. Now that we’re experts, it’s time to think of DNS backwards, not as S-N-D, but with Reverse DNS.
Reverse DNS, or rDNS, is exactly the opposite of forward DNS. Forward DNS as we know it, maps a hostname to an IP address. rDNS simply means we are mapping the address to a hostname. This may seem a little redundant, after all, why would we do this both ways, but rDNS actually serves a number of different purposes from email to network troubleshooting.
There are of course more benefits of rDNS, which are listed below:
- Adding a label for network troubleshooting tools such as traceroute.
- Populating the “Received:” header field in an SMTP email.
- Preventing commercial mail from being sent by dial up users or residential users.
- Checking for generic reverse DNS such as 1-2-3-4.example.com to identify spammers.
- Verifying a relationship between the owner of a domain name and the owner of the server(IP address).
- Creating a loop where the IP matches the FQDN and the FQDN matches the original IP.
- Writing human readable hostname to the log files for system monitoring tools
- Determining which hostname is affected when maintenance is performed on an IP.
In rDNS, the IP address is flipped, then in-addr.arpa is added to the end. For example the IPv4 address 18.104.22.168 becomes 0/22.214.171.124.in-addr.arpa, with the 0/ being CIDR notation. This can also be dictated as 0-126.96.36.199.in-addr.arpa, the dash vs slash is dependant on ISP. Before venturing into the world of rDNS, just check with your respective ISP to ensure the right notation is used, the slash or dash need to match the delegation with the ISP and are not cross comparable.
As mentioned above, Reverse DNS lookups allow the mapping of a hostname label to an IP address. When a lookup for a rDNS IP address name is performed, a PTR, or Pointer, record type will be returned. This PTR record will contain the forward hostname where the IP is used in regular, or forward DNS mapping. The DIG command can be used to lookup reverse DNS hostnames. DIG has a utility option for mapping out the reverse hostname known as dig -x, the -x option remaps the IP address and sets the query type for PTR. We can test this with an Oracle Dyn nameserver address:
$ dig -x 188.8.131.52
;; QUESTION SECTION:
;184.108.40.206.in-addr.arpa. IN PTR
;; ANSWER SECTION:
220.127.116.11.in-addr.arpa. 86360 IN PTR dyn.com.
If you’d like to skip ahead to the good stuff, we have a full knowledge base that walks through each step of creating an rDNS zone.
If you’d rather take the round-about way, read on!
First off, contact the operators of the parent rDNS zone to see the notation used when creating the DNS names. Generally, the operator is an Internet Service Provider. Once all the correct information has been gathered, it is crucial that a rDNS zone is created with the correct notation. As discussed above, this involved reversing the IP block.
Once reversed, a zone can be created using the rDNS zone name as the Zone Name, just as a forward DNS zone would be created. Then, once the zone has been added into the Managed DNS platform, a node should be defined for each IP address contained within the zone.
The next step in the process is to create a PTR record for each hostname. PTR records are specific to rDNS which allow properly routed queries for resolution.
The next-to-last step is to have an ISP or assigning authority for the IP address blocks append the NS records to reflect the Dyn name servers.
As a final step in the process of setting up a Reverse DNS Classless Address Block zone, you need to add a CNAME record for each host at your ISP. This is done specifically for Reverse DNS zones to ensure requests are properly routed for resolution.
Reverse DNS is something that we often don’t hear about day to day, after all, it is easy enough to configure and doesn’t need to change unless the IP Block and hostnames change. However; it is mission critical that companies today have rDNS configured properly, especially if they are sending email. Many email servers are configured to reject mail from an incoming IP that does not have rDNS setup, as not having the IP mapped can be a sign of spam in the Email Deliverability world. RFC 1912 summed this up nicely, “For every IP address, there should be a matching PTR record”, set yours up today!
We’ve covered a lot in a small blog, and as always, our Technical Support Team is available to answer any questions. Feel free to reach out!