keith@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