Dear Tore,
Alternatively, the transfer policy could require that in such a case the "surrounding" /24 has to be delegated to the RIPE NCC, who will manage this address space in a neutral way for an indefinite period of time. This would, however, have an impact on RIPE NCC operations, and I do not think I would support such a proposal.
Maybe I am being dense, but I am really struggling to understand your concern. After all the surrounding address space is already delegated to the RIPE NCC's name servers, which then sub-delegate based on the domain objects the resource holder inserts into the database. So I don't see how this proposal would have an impact on RIPE NCC operations in this regard (beyond the one-time job of permitting classless delegation for PA space in the same way as for PI).
Let me try to explain my understanding of things by example...
Thank you for the detailed example. I now understand what you are saying. The problem is that this does not work with allocations larger than a /16. In this case the /16 is usually already delegated to the LIR. An analogy with your example would be that 47.185.in-addr.arpa is already delegated to you. In this case the NCC could not insert the 0-127.43.47.185.in-addr.arpa delegation in the 185.in-addr.arpa zone. I see two solutions to this: - the NCC "revokes" the /16 delegation and replaces it with 255 /24 delegations, and two /25 delegations - you delegate 43.47.185.in-addr.arpa back to the NCC Neither of them is appropriate in my view. By the way, as I pointed it out on the DNS WG list, I think this obligation to provide appropriate DNS services for an indefinite time is not necessarily specific to address space smaller than a /24, as any transfer smaller than a /16 out of an allocation of at least a /16 has a somewhat similar problem. Best regards, Janos
185.47.43.0/24 is part of an ALLOCATED PA delegation from the RIPE NCC to my LIR. When it comes to reverse DNS, the allocation chain goes like this, starting from the root:
. NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine)
[The NS records for "40.47.185.in-addr.arpa." happens to be there because I've inserted the corresponding object into the RIPE database and it's based on those objects the RIPE NCC generates the "185.in-addr.arpa" zone.]
Let's now assume that you and I agree that 185.47.43.128/25 should be transferred to your LIR. I would then expect that the delegation chain would part ways in the 185.in-addr.arpa sone, like so for my /25:
. NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 0-127.43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine)
..and like so for your /25:
. NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 128-255.43.47.185.in-addr.arpa. NS ns*.iszt.hu (yours)
[As before, we would of course both need to insert appropriate domain objects into the RIPE database for the final delegation to our own authoritative name servers to show up in the 185.in-addr.arpa zone.]
Even though I would be the "selling" LIR here, I do not understand why I would be required to play a part in delegating reverse DNS for the /25 you "bought" for an infinite period of time (or any period of time at all for that matter). What am I missing here?
Tore