in-addr.arpa zone data in RIPE database

 keith at pipex.net (Keith Mitchell) writes:
 * 
 * This is a bit of an aside to the debate above, but there is
 * something that has struck me as obvious which would make the
 * management of in-addr.arpa much easier for everyone, and help with
 * the above issue.
 * 
 * Why not get all of 193.in-addr.arpa delegated to the RIPE NCC, and
 * have it in turn delegate xx.193.in-addr.arpa to the service
 * providers ?
 * 
 * That way we don't have to deal directly with the creaking NIC, but
 * authority is still delineated clearly by existing DNS mechanisms.
 * This has not been possible in the past, due to the restriction of
 * in-addr DNS delegations needing to be on byte boundaries, *but*
 * that is exactly how the RIPE supernet block is being assigned.
 * 
 * Or have I missed a good reason why this won't work ?

You have not missed anything. Even better yet, currently there is a dummy
193.in-addr.arpa server running at the NCC all in preparation of the full
delegation of 193.in-addr.arpa from the NIC. We are indeed planning to
further delegate blocks down to service providers.

So, good idea, and almost implemented. We are just waiting for the NIC to
officially delegate the zone, then all of that will be done. We are in the
process of writing some guidelines for further delegation of blocks, because
there are things like: a customer of yours has IP numbers from your block,
and has properly registered in-addr through you (you have the block in-addr).
What happens with the in-addr for this customer if he decides to go to the
provider next door, because he is much cheaper ? Of course you will have to
continue providing the delegateion RRs for this customer, but then what if
the other provider cannot or will not talk to you (IP wise). There is more of
these things that need to be written down carefully.

Still, there are the issues of the DNS versus the DB, but I feel that others
are already dealing with that one ;-)

-Marten