On Sat, Mar 18, 2017 at 09:27:11PM -0700, Doug Barton wrote:
As to why DNS-native zone operations are not utilized, the challenge is that reverse DNS zones for IPv4 and DNS operations are on octet boundaries, but IPv4 address blocks may be aligned on any bit boundary.
Yes, deeply familiar with that problem. Are you dealing with any address blocks smaller than a /24? If the answer is no (which it almost certainly is), what challenges are you facing that you haven't figured out how to overcome yet? (Even < /24 blocks can be dealt with, obviously, but I'd be interested to learn that there are problems with /24 and up that are too difficult to solve.)
Hypotheically: 10.11.0.0/16 (11.10.in-addr.arpa) is managed by ARIN 10.11.16.0/20 is ARIN space 10.11.32.0/20 is RIPE space If ARIN delegated 32.11.10.in-addr.arpa through 47.11.10.in-addr.arpa to a RIPE nameserver, there's no good way for RIPE to then delegate, say, 10.11.34.0/24 (34.11.10.in-addr.arpa) to the nameserver of the entity to which RIPE has allocated 10.11.34.0. (Sure, it can be done, using the same techniques as are used for allocations of longer-than-/24, but recipients of /24 and larger reasonably expect to have the X.X.X.in-addr.arpa delegated to their nameservers.) So, instead, RIPE communicates to ARIN the proper delegations for 32.11.10.in-addr.arpa through 47.11.10.in-addr.arpa, and ARIN merges those into 11.10.in-addr.arpa. One way for RIPE to communicate those delegations to ARIN is to put then into some other zone, which ARIN could then zone-transfer. But ARIN would still need a process to merge the data from that other e with the real 11.10.in-addr.arpa zone. But that has the same risks as the current process, which apparently communicates those delegations via something other than zone-transfer. -- Brett