PTR delegation

PTR delegation is one of the three methods I discussed in Classless IN-ADDR.ARPA delegation that can be used to delegate the responsibility of reverse DNS on something other than the traditional class boundary.

PTR delegation works by having the upstream provider delegate the specific record of interest via an NS record rather than hosting the traditional PTR record. The NS record delegates control to another tiny DNS zone that has just enough information it it to function; SOA, NS, and the desired PTR.

The reason that this works so well is that it simply reuses the same standard delegation method that is used in all parent zones.

234	IN	PTR	www.example.com.

However, instead of doing the typical thing, we replace the PTR record with an NS record to further delegate responsibility for the 192.0.2.234 IP.

234	IN	NS	ns1.office.example.com.

Thus, the entire delegation chain now looks like this:

Now that we have the final layer of delegation to a different server, we finally reach the 234.2.0.192.in-addr.arpa. zone which contains the pointer. Notice how the pointer record is in the zone apex, and not a record for another host in the zone. (This is the same technique used by Apex Override.)

234.2.0.192.in-addr.arpa.	IN	SOA	ns1.office.example.com. administrator.office.example.com. (2014061600 10800 900 604800 86400)
234.2.0.192.in-addr.arpa.	IN	NS	ns1.office.example.com.
234.2.0.192.in-addr.arpa.	IN	PTR	www.example.com.

I used this exact method for a number of years. The only reason I switched to it's successor, Cross IN-ADDR.ARPA delegation, was the large number of tiny zones that I was amassing with multiple /29 networks. Both methods use the same underlying techniques and mainly differ in the structure of the zone file(s) on the server.