Classless Reverse Map Delegation doesn't work with "dig -x". Does it affect anything?

Question

The web Zytrax.com, where I learned about Classless Reverse Map Delegation, says that dig -x <ip address> isn't supposed to work in this if this method of delegation (using CNAMES) is used.

For Example:

This isn't supposed to work: dig -x 192.168.23.66

And this is supposed to work: dig 66.64/27.168.192.IN-ADDR.ARPA

And it does work when I modify it a bit (specify the server where it was delegated to and that I want PTR record): dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA

It seems to work as described in the tutorial:

I set similar delegation and it behaves as described above: When I use dig -x with an ip address from the delegated range, the delegating name server tells me who has authority over 66.64/27.168.192.IN-ADDR.ARPA. The server where the classless network was delegated to works only with the third command (dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA).

Is it OK and safe?

As it doesn't work with dig -x (or nslookup), I wonder if there are more things that don't work. Can resolvers resolve such IP addresses without issues? For instance, can email servers perform reverse lookup without issues if this method of delegation is used? Are there any reasons why not to use it?

My example (slightly modified):

dig @ns1.example.com -x 192.168.134.1

;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60  IN  CNAME   1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN   NS      ns2.example.com.


dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.

;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR     1st_super.example.com.

Why it didn't work

The name of the zone to which I delegated was wrong and as used the wrong name in the second query, I got an answer (the two mistakes partially canceled each other).

Wrong (not reversed):

0-127.192.168.134.in-addr.arpa.

should have been:

0-127.134.168.192.in-addr.arpa.

With this error fixed and with delegating server being slave for the delegated zone, the dig -x <ipaddress> works.

Answer 1

TL;DR

If you create a RFC2317-style classless in-addr.arpa delegation, it's entirely normal that you cannot query the authoritative nameserver for the sub-delegation directly with the reverse mapping of the IP address.
What really matters is that a resolver server can look up the reverse name (eg dig -x 192.0.2.1 @8.8.8.8, for whatever IP address and resolver server combination that is relevant in your environment / to your use-case).

RFC2317 explanation

The overall problem that RFC2317 provides a kind of workaround for is how the convention-based mapping from IPv4 address to reverse name in DNS (eg 192.0.2.1 -> 1.2.0.192.in-addr.arpa) predates classless delegations, and effectively locks the possible delegation points to /0, /8, 16, /24, /32. (You can only delegate at each label, and the mapping is defined to simply make each octet of the IPv4 address a label, in reverse order.)
The mapping would have had to be defined differently, mapping into some more fine-grained naming scheme to actually allow something like a /27 delegation.

RFC2317 does NOT change the fundamental situation, it actually does not change the protocol in any way.
All it does is to suggest a scheme that human operators can use to work around the limitation that classless delegations are not possible.

That scheme can be summarized as:

1. You define aliases (add CNAME records) for some set of names in the actual reverse zone (according to the naming convention), mapping these to new names in a new namespace
   (The new namespace can really have any name, but RFC2317 suggests using a descriptive name and having the new namespace as a child of your existing zone somewhere under in-addr.arpa)
2. You delegate the zone corresponding to this new namespace as necessary

The result is that the a resolver server asked to look up 1.2.0.192.in-addr.arpa will simply do that normally and run into that CNAME record instead of the PTR that it was really looking for.
It then simply follows the CNAME into the new namespace without needing any knowledge of RFC2317 even existing, and if things were set up as suggested by RFC2317 it will find a PTR that it can use at that new name.

If you for example were to have a 2.0.192.in-addr.arpa. zone on ns1.other.example. that included this:

1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.

The lookup process for the actual reverse name (1.2.0.192.in-addr.arpa.) would result in the CNAME, and the resolver would just handle the CNAME normally, following it wherever it leads.

In this example it leads to 1.0/27.2.0.192.in-addr.arpa., and there is also a delegation for the zone 0/27.2.0.192.in-addr.arpa. to ns7.example.com., so the resolver can just continue the lookup process for the new name and it will all work out.

If, on the other hand, you were to send a query for 1.2.0.192.in-addr.arpa. to ns7.example.com. it will know nothing about it.
ns7.example.com. does not have the reverse zone for that address, it only has a loosely related zone that the actual reverse zone refers to by these aliases.

To check that a RFC2317-style delegation works, first of all, you could check if an actual resolver succeeds in looking up the names.
But, digging into the details, you would check what the nameserver for the real reverse zone responds with (should be a CNAME in this case), check where the canonical name (the CNAME "target") is delegated, and then check if that nameserver responds as intended for the canonical name as specified by the CNAME record.