Reverse DNS in a CIDR world
Solution 1:
Delegating a /22 is easy, it's delegation of the 4 /24s. A /14 is delegation of the 4 /16s, etc.
RFC2317 covers the special cases with a netmask longer than /24. Basically there's no super-clean way to do delegation of in-addr.arpa zones on anything but octet boundaries, but you can work around this. Let's say I want to delegate 172.16.23.16/29, which would be the IP addresses 172.16.23.16 -> 172.16.23.23.
As the owner of the 23.16.172.in-addr.arpa zone, I might would put this in my 23.16.172.rev zone file to delegate this range to my customer:
16-29 IN NS ns1.customer.com
16-29 IN NS ns2.customer.com
16 IN CNAME 16.16-29.23.16.172.in-addr.arpa.
17 IN CNAME 17.16-29.23.16.172.in-addr.arpa.
18 IN CNAME 18.16-29.23.16.172.in-addr.arpa.
19 IN CNAME 19.16-29.23.16.172.in-addr.arpa.
20 IN CNAME 20.16-29.23.16.172.in-addr.arpa.
21 IN CNAME 21.16-29.23.16.172.in-addr.arpa.
22 IN CNAME 22.16-29.23.16.172.in-addr.arpa.
23 IN CNAME 23.16-29.23.16.172.in-addr.arpa.
So, you can see that I'm defining a new zone (16-29.23.16.172.in-addr.arpa.) and delegating it to my customer's name servers. Then I'm creating CNAMEs from the IPs to be delegated to the corresponding number under the newly delegated zone.
As the customer to whom these have been delegated, I would do something like the following in named.conf:
zone "16-29.23.16.172.in-addr.arpa" {
type master;
file "masters/16-29.23.16.172.rev";
};
And then in the .rev file, I would just make PTRs like any normal in-addr.arpa zone:
17 IN PTR office.customer.com.
18 IN PTR www.customer.com.
(etc)
That's sort of the clean way to do it and it makes savvy customer happy because they have an in-addr.arpa zone to put the PTRs in, etc. A shorter way to do it for customer who want to control reverse DNS but don't want to set up a whole zone is to just CNAME individual record to similar names in their main zone.
In this case, we, as the delegators, would have something like this in our 23.16.172.rev file:
16 IN CNAME 16.customer.com.
17 IN CNAME 17.customer.com.
18 IN CNAME 18.customer.com.
19 IN CNAME 19.customer.com.
20 IN CNAME 20.customer.com.
21 IN CNAME 21.customer.com.
22 IN CNAME 22.customer.com.
23 IN CNAME 23.customer.com.
So it's similar in concept to the other idea, but instead of creating a new zone and delegating it to the customer, you're CNAMEing the records to names in the customer's already-existing main zone.
The customer would have something like this in their customer.com zone file:
office IN A 172.16.23.17
17 IN PTR office.customer.com.
www IN A 172.16.23.18
18 IN PTR www.customer.com.
(etc)
It just depends on the type of customer. Like I said, it just depends on the customer type. A savvy customer will prefer to set up their own in-addr.arpa zone and will think it very odd to have PTRs in a domain-name zone. A non-savvy customer will want it to "just work" without having to do a ton of extra configuration.
There are likely other methods, just detailing the two I'm familiar with.
I was just thinking about my statement about how /22 and /14 are easy and thinking about why that's true but anything between 25 and 32 is hard. I haven't tested this, but I wander if you could delegate the entire /32 to the customer like this:
16 IN NS ns1.customer.com.
17 IN NS ns1.customer.com.
(etc)
Then, on the customer side, you catch the entire /32:
zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)
And then in the individual file you would have something like this:
@ IN PTR office.customer.com.
The obvious downside is that one file per /32 is kind of gross. But I bet it would work.
All the stuff I mentioned is pure DNS, if any DNS server didn't let you do it it's because it's restricting the full functionality of DNS. My examples are obviously using BIND, but we've done the customer side of this using Windows DNS and BIND. I don't see a reason it wouldn't work with any server.
Solution 2:
Yes, RFC 2317, a very good reading, is the way to go.
Also, my article (in French).