• Print
  • Share
  • Dark

Classless in-addr.arpa subnet delegation

  • Updated on 28 Sep 2018
  • 2 minutes to read
  • Contributors 

This article is a worked example of one of the simpler cases of classless in-addr.arpa subnet delegation, as described in RFC2317 (BCP 20): https://tools.ietf.org/html/rfc2317.


  1. You are the owner of subnet for which you maintain zone 2.0.192.in-addr.arpa.

  2. You want to delegate to a third party content provider exemplary.examples.com whose nameservers are:

  • ns1.example.com
  • ns2.example.com
  1. The problem is that IPv4 labels in dot-notation in DNS only have dots at the label boundaries you can see above, but you need to be able to delegate a subdomain that breaks right in the middle of one of those labels.

Sample solution

As the owner of zone 2.0.192.in-addr.arpa, you can delegate something.2.0.192.in-addr.arpa, but you need to find a way of making that delegated subdomain provide the resolution for queries for reverse addresses in the range:

This is a problem that is specific to DNS (it's not just in BIND). The way we get around it is by creating CNAMEs to something else that you can delegate, for each and every address in the range of addresses that you need to handle this way.

So let's start with the delegating part.  Consider this sub-domain:


This is a perfectly legitimate delegation - you are authoritative for 2.0.192.in-addr.arpa, what you delegate can have any subdomain label that you wish, and 0-63 is a legitimate label for a zone name. 

A reverse (PTR) zone is just a DNS zoneAlthough by convention an in-addr.arpa zone is being used for PTR RRs, it is still just a DNS zone and a delegated subdomain doesn't have to follow the exact pattern of the IPv4 address labels in dot notation.

So this is what you'd put in your zone to create the delegation to Exemplary Examples:

0-  IN   NS  ns1.example.com.
0-  IN   NS  ns2.example.com.

Meanwhile, over at Exemplary Examples, the administrators should be creating records in this zone that have the hostnames associated with -, except that they're going to have an additional name label in the zone, so something like this:

1.0-  IN   PTR  super.example.com.
2.0-  IN   PTR  fantastic.example.com.
63.0-  IN   PTR  amazing.example.com.

There's just one final piece that needs to be put in place.

If someone queries their resolver for, then following the delegation from the in-addr.arpa nameservers down, their resolver will reach your nameserver that is authoritative for 2.0.192.in-addr.arpa. From here you want to tell that it needs instead to send the queries to ns1.example.com and/or ns2.example.com, and instead of 2.0.192.in-addr.arpa, to be querying for 2.0-

This is achieved by adding a set of CNAME RRs to the 2.0.192.in-addr.arpa zone on your server, causing a redirection (that the resolver will follow): IN CNAME 1.0- IN CNAME 2.0-
... IN CNAME 63.0-

You can (if you wish) use $GENERATE as a shortcut to adding all of these RRs individually to your zone ($GENERATE causes named to construct the RRs for you automatically as it populates the zone when loading it):

$ORIGIN 2.0.192.in-addr.arpa.
$GENERATE 0-63 $ IN CNAME $.0-

If they will permit this, consider slaving the zone you delegated to the third partyThis is optional, but will enable your servers to respond directly to queries with both your CNAME RR and the target PTR RR provided by the third party, and will speed up DNS resolution by eliminating the additional query that resolvers would otherwise be obliged to make.

Problems with this site? Email us at marketing@isc.org