Knowledge Base ISC Main Website Ask a Question/Contact ISC
Classless in-addr.arpa subnet delegation
Author: Cathy Almond Reference Number: AA-01589 Views: 428 Created: 2018-03-06 18:42 Last Updated: 2018-03-26 16:05 0 Rating/ Voters

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

Requirements
  1. You are the owner of subnet 192.0.2.0/24 for which you maintain zone 2.0.192.in-addr.arpa
  2. You want to delegate 192.0.2.0/26 to a third party content provider exemplary.examples.com whose nameservers are:
    • ns1.example.com
    • ns2.example.com
  3. 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:

0.2.0.192.in-addr.arpa
1.2.0.192.in-addr.arpa
...
63.2.0.192.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:

0-63.2.0.192.in-addr.arpa

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 zone

Although 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-63.2.0.192.in-addr.arpa.  IN   NS  ns1.example.com.
0-63.2.0.192.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 - 63.2.0.192.in-addr.arpa, except that they're going to have an additional name label in the zone, so something like this:

1.0-63.2.0.192.in-addr.arpa.  IN   PTR  super.example.com.
2.0-63.2.0.192.in-addr.arpa.  IN   PTR  fantastic.example.com.
...
63.0-63.2.0.192.in-addr.arpa.  IN   PTR  amazing.example.com.

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

If someone queries their resolver for 2.2.0.192.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-63.2.0.192.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):

1.2.0.192.in-addr.arpa IN CNAME 1.0-63.2.0.192.in-addr.arpa.
2.2.0.192.in-addr.arpa IN CNAME 2.0-63.2.0.192.in-addr.arpa.
...
63.2.0.192.in-addr.arpa IN CNAME 63.0-63.2.0.192.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-63.2.0.192.in-addr.arpa.


If they will permit this, consider slaving the zone you delegated to the third party

This 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.




© 2001-2018 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Quick Jump Menu