A reverse zone allows people to backtrack your domain name from your IP address. Think about it like allowing people to check your ID. There are any number of reasons for people to want to do this. What is becoming the most important reason is that they want to make sure that email they receive is actually coming from a real source. Spammers tend to spoof their location to prevent reprisal.

This connection between IP address and domain name is carried out using a PTR record. The format for the connection is a PTR record that has the four octets of the IP address placed in reverse order with in-addr.arpa. appended. Below is a classic example of a reverse zone for a class C Subnet.


The first two NS records are the same as you would find on any zone. Even a reverse zone needs name servers. The last octet (or in this case because it is reversed, the first octet) is not included because the reverse zone applies to the entire collection of addresses on the subnet. The last two PTR records associate the two IP addresses presented in Sample 1 with canonical names. The reason mail.example.com is used instead of ns1.example.com is because there can only one PTR record per IP address. If you have multiple A records for one IP address, give mail preference. Mail is far and away the service most commonly concerned about reverse records.

Classless Subnets

One area where a lot of people have problems is dealing with delegations of reverse zones in classless subnets. One thing that is often misunderstood is that forward zones and reverse zones do not necessarily correspond. Having authority for a forward zone does not automatically give you authority for any particular reverse zone.

Most reverse zones are subzones of the in-addr.arpa. zone, and are generally delegated by and to whoever controls the specific IP numbers. That's probably your ISP, meaning that if you want to control DNS for your reverse zone, you'd need to have your ISP delegate it to you.

The ISP Side

There is no universal example to give for how this works; there are simply too many ways that the delegation could be formatted. However, below is a typical example of a classless subnet reverse zone delegation by an ISP, isp.com for a customer, customer.com.


This example provides reverse NS records, ISP’s name servers, and PTR records for resolving ISP’s name and mail servers. There could easily be thousands of records dealing with reverse delegations for customers other then customer.com. For the sake of the example, Customer will be ISP’s first and only customer.

CNAME records create aliases for the reverse records for the IP addresses in the classless delegation to customer.com. The canonical names chosen for the CNAME records are arbitrary: They can be anything, so long as they can be resolved back to some zone that the customer controls. If your ISP is delegating a reverse zone to you, you’ll need to ask what canonical names they are using so your PTR records will match.

The Customer Side

The delegated reverse zone for customer.com will look something like this:

ISP’s reverse zone associates the reverse IP address with an arbitrary label. The PTR records in customer.com’s reverse zone associate the arbitrary label with a domain name.