Classless IN-ADDR.ARPA delegation

Classless IN-ADDR.ARPA delegation is a way to delegate reverse DNS authority for desired records without delegating the entire (sub)network. This means that ISPs can delegate control of reverse DNS for your IP addresses without also giving you control of other customers IPs in the same (sub)network.

Remember a few key points.

DNS delegation usually happens on the dot boundary for a sub-domain.
Reverse DNS prepends the IP address, in reverse octet order, to the in-addr.arpa domain.
Sub-domain(s) of the in-addr.arpa domain are then delegated to different authorities.

I.e.

Entity A is responsible for 10.0.0.0/8 / 10.in-addr.arpa
Entity B, a delegate of Entity A, is responsible for 10.20.0.0 / 20.10.in-addr.arpa
Entity C, a delegate of Entity B, is responsible for 10.20.30.0 30.20.10.in-addr.arpa

Unfortunately this scheme does not lend its self to delegating part of a class, hence it's name classLESS in-addr.arpa delegation. This why you would traditionally have to have your ISP manage reverse DNS for your 10.20.30.40 / 40.30.20.10.in-addr.arpa. Thankfully there are some options that can be used.

There are some things to consider when choosing how to perform Classless IN-ADDR.ARPA delegation.

Classless IN-ADDR.ARPA delegation does work, but some things have problems with the CNAME when looking up PTR records.
PTR delegation works well, but can lead to a lot of tiny (3 record) zones.
Cross IN-ADDR.ARPA delegation uses fewer zones but requires some additional knowledge of the class that it is being crossed with.

I have used each method (RFC 2317, then PTR delegation and now Cross Delegation) with remarkable success. The only problem that I ran in to with RFC 2317, was when a bot for a notorious spam black list chocked on RFC 2317. At which point in time I switched to PTR delegation. Recently I switched to Cross IN-ADDR.ARPA delegation b/c of the large number of tiny zones that PTR delegation requires.