Re: in-addr.arpa zone data in RIPE database
In <9303021347.AA06706@mcsun.EU.net>, <Piet.Beertema@mcsun.EU.net> wrote:
Interaction is fine. But RIPE stepping into someone else's authority is quite something different! I don't see any problem with that as long as we (european networking people) agree to send update to the RIPE-NCC instead of sending them to the NIC. RIPE-DB and DNS are entirely different objects. I would like RIPE to notify me *in some cases* about discrepancies between my entries in the RIPE-DB and my DNS entries, but I do *NOT* want RIPE to step into my authority by asking or telling the NIC to change *MY* DNS info because they found discrepancies: I may well have good reason why those discrepancies exist.
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 ? Keith Mitchell Network Manager Public IP Exchange keith@pipex.net 216 The Science Park keith@unipalm.co.uk Cambridge, UK Phone: +44 223-424616 Fax: +44 223-426868
keith@pipex.net (Keith Mitchell) writes:
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 ?
We are working on this one too! It will be in place soon, NIC permitting. But a lot of nets are not in 193 ..... Daniel
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
participants (3)
-
Daniel Karrenberg -
keith＠pipex.net -
Marten Terpstra