A practical example of classless rDNS delegation

When delegating reverse DNS entries, you are normally limited by the byte-boundaries of an IP address. This means that you are not able to delegate a subnet that is smaller than /24 to another DNS server. For that reason, https://datatracker.ietf.org/doc/html/rfc2317 exists, which explains a way to accomplish classless subnet delegation. This would work, in theory, for all subnet sizes that exist.

In this post, I want to show a practical example of how one would set this up. Both for the delegating party (e.g., a hosting provider) and the delegation receiver (e.g., a subnet customer). This post is also my personal reference since I find this topic quite hard to understand and did not find many resources. I’ll be using internal IPs, but this should be applicable to any IP ranges.

The setup #

We assume the following setup:

• Provider nameservers: ns1.provider.com, ns2.provider.com
• Customer nameservers: ns1.customer.com, ns2.customer.com
• Provider Subnet: 192.168.10.0/24
• Customer Subnet: 192.168.10.64/26

The provider now wants to delegate the customer’s range to the customer’s nameserver, but – how? Simply put, we rely on CNAME and NS records to achieve this. Since the provider controls the 10.168.192.in-addr.arpa zone, they can create and choose any subdomains. Strictly speaking, there are no limits to how this subdomain would be built, but common techniques imply the usage of slashes or dashes.

Let’s first focus on the slash-method:
The provider would create 2 NS records:

64/26.10.168.192.in-addr.arpa NS ns1.customer.com
64/26.10.168.192.in-addr.arpa NS ns2.customer.com

Since the provider controls the zone, this is a totally valid record. It’s not a valid rDNS Address, but it doesn’t need to be.

When using a dash, we can use the start- and end-address and describe it as an actual range:

64-127.10.168.192.in-addr.arpa NS ns1.customer.com
64-127.10.168.192.in-addr.arpa NS ns2.customer.com

Now, the provider needs to redirect queries that are in the customer’s range to the customer’s nameservers. This is done by adding a CNAME record for every IP in the range. This is not beautiful, but it’s the only way that is universally understood and defined in the RFCs.

64.10.168.192.in-addr.arpa   CNAME 64.64-127.10.168.192.in-addr.arpa
65.10.168.192.in-addr.arpa   CNAME 65.64-127.10.168.192.in-addr.arpa
66.10.168.192.in-addr.arpa   CNAME 66.64-127.10.168.192.in-addr.arpa
67.10.168.192.in-addr.arpa   CNAME 67.64-127.10.168.192.in-addr.arpa
...
125.10.168.192.in-addr.arpa CNAME 125.64-127.10.168.192.in-addr.arpa
126.10.168.192.in-addr.arpa CNAME 126.64-127.10.168.192.in-addr.arpa
127.10.168.192.in-addr.arpa CNAME 127.64-127.10.168.192.in-addr.arpa

Over at the customer’s nameserver, a zone needs to be created that matches the name of the NS entries created by the provider. Let’s continue with the dash (range) approach, meaning the customer needs to create a zone 64-127.10.168.192.in-addr.arpa. Now, normal PTR records can be created in this zone, which will resolve correctly:

67.64-127.10.168.192.in-addr.arpa PTR  customer-website.com.

When a query for 67.10.168.192.in-addr.arpa hits the provider’s nameserver (since it’s the authority for the 10.168.192.in-addr.arpa zone), it gets redirected by the CNAME RR, leading to a lookup at the customer’s nameserver.

It should be noted that this is a way to scale very well, meaning providing the subnet size or IP range directly in the CNAME records is not prone to errors since you’re literally writing out what you are delegating. In theory, the provider could also decide to name the NS records customer.10.168.192.in-addr.arpa – It’s literally not important what the name is, just that it’s the same across all occurrences and all nameservers involved in the delegation.

Et voilà, this way, we can delegate single IPs’ whole or partial subnets to another nameserver, even when hitting a byte boundary.