Hi Håvard, At 0:52 +0200 25/4/02, Havard Eidnes wrote:
Hi,
I may not have had my attention in focus when this was discussed the last time around, so I hope you will excuse me for asking some simple questions which may already have been given their reply.
I understand that what is happening is that the "master source" for the affected registrations is being moved from (in our case) ARIN to the RIPE NCC.
o I suppose this means that in-addr.arpa updates will after this change be done only against the RIPE database for those pieces of address space which is transferred?
Yes, the main goal of the exercise is to simplify the current process, which is a hassle for everyone involved.
o Can the RIPE NCC shed some light on how the in-addr.arpa zone generation will happen "behind the scenes" after this change? E.g. what would the typical latency be between "update of registration data in the RIPE DB" to "visibility in the DNS"?
The in-addr.arpa zone will (already has?) 256 entries, with delegations to nameservers of the RIRs for each /8. For each /8 one of the RIRs will be the primary. Which it is will be decided by counting the number of registrations on each /8 (ARIN has already done this). If there are registrations for several RIRs in a particular /8 then the RIR that are not the primary will send information to the primary for inclusion in the zone file. The proposed frequency of update is, I recall correctly, at least twice a day.
o After the move of the authority for the data, what information will the ARIN database return when queried via whois? A pointer to the RIPE NCC (as happens now for the larger RIPE address blocks), or a "slave" copy of of the data from the RIPE database?
A pointer seems to be the more favoured approach right now.
I think this looks otherwise fine -- I suspect some of us will have to do some tidy-up work in the aftermath of the move no matter what.
A good thing, even though it is a bit of a pain. regards João