Classless in-addr.arpa subnet delegation
- Updated on 28 Sep 2018
- 2 minutes to read
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.
You are the owner of subnet 192.0.2.0/24 for which you maintain zone 2.0.192.in-addr.arpa.
You want to delegate 192.0.2.0/26 to a third party content provider exemplary.examples.com whose nameservers are:
- 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.
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:
0.2.0.192.in-addr.arpa 18.104.22.168.in-addr.arpa ... 22.214.171.124.in-addr.arpa
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.
So this is what you'd put in your zone to create the delegation to Exemplary Examples:
0-126.96.36.199.in-addr.arpa. IN NS ns1.example.com. 0-188.8.131.52.in-addr.arpa. 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 0.2.0.192.in-addr.arpa - 184.108.40.206.in-addr.arpa, except that they're going to have an additional name label in the zone, so something like this:
1.0-220.127.116.11.in-addr.arpa. IN PTR super.example.com. 2.0-18.104.22.168.in-addr.arpa. IN PTR fantastic.example.com. ... 63.0-22.214.171.124.in-addr.arpa. IN PTR amazing.example.com.
There's just one final piece that needs to be put in place.
If someone queries their resolver for 126.96.36.199.in-addr.arpa, 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-188.8.131.52.in-addr.arpa.
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):
184.108.40.206.in-addr.arpa IN CNAME 1.0-220.127.116.11.in-addr.arpa. 18.104.22.168.in-addr.arpa IN CNAME 2.0-22.214.171.124.in-addr.arpa. ... 126.96.36.199.in-addr.arpa IN CNAME 63.0-188.8.131.52.in-addr.arpa.
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-184.108.40.206.in-addr.arpa.