Name "ripe" in the e164.arpa zone
Dear Colleagues, A question has been raised on why the resource record "ripe.e164.arpa" exists in the e164.arpa zone. Our DNS provisioning tools, which read the information held in objects in the RIPE Database and generate the appropriate DNS zone files, create this extra name "ripe" in the zone for the benefit of the other Regional Internet Registries (RIRs). The provisioning system generates zone files mainly for the in-addr.arpa zones, and some address ranges from one /8 allocation are actually allocated to other registries. So each registry generates "zonelets" that are transferred to the majority RIR of a particular /8. The tools that transfer these zonelets rely on this extra piece of information in the TXT record for consistency checks. Similarly, AfriNIC, ARIN and APNIC also generate zones for their /8 allocations with records named "afrinic", "arin" and "apnic". The e164.arpa zone does not really need this "ripe" record in it, since it is not shared among the registries in any way. However, because the e164.arpa zone is generated automatically from the RIPE Database by the same tools, it automatically receives this extra name. Currently, there is no way to stop the zone receiving this extra entry. But it has no negative effect on the zone or on ENUM operations. Regards, -- Anand Buddhdev DNS Services Manager RIPE NCC
On Jan 17, 2008, at 14:56, Anand Buddhdev wrote:
The tools that transfer these zonelets rely on this extra piece of information in the TXT record for consistency checks. Similarly, AfriNIC, ARIN and APNIC also generate zones for their /8 allocations with records named "afrinic", "arin" and "apnic".
The e164.arpa zone does not really need this "ripe" record in it, since it is not shared among the registries in any way. However, because the e164.arpa zone is generated automatically from the RIPE Database by the same tools, it automatically receives this extra name. Currently, there is no way to stop the zone receiving this extra entry. But it has no negative effect on the zone or on ENUM operations.
Hmmm. This smells like a bug. Why are the DNS provisioning tools for e164.arpa generating data that isn't needed and inserting that data into the DNS? I wonder what will happen if the ITU one day decides that "ripe.e164.arpa" should be delegated to someone....
At the moment ripe.e164.arpa is needed they will made a fix for it, making a fix before that moment isn't needed if you ask me. With kind regards, Met vriendelijke groet, Mark Scholten Stream Service Web: http://www.streamservice.nl/ E-mail: mark@streamservice.nl NOC: http://www.mynoc.eu/ NOC e-mail: noc@streamservice.nl Tel.: +31 (0)642 40 86 02 KVK: 08141074 BTW: NL104278274B01 ----- Original Message ----- From: "Jim Reid" <jim@rfc1035.com> To: "Anand Buddhdev" <anandb@ripe.net> Cc: <enum-wg@ripe.net> Sent: Thursday, January 17, 2008 4:55 PM Subject: Re: [enum-wg] Name "ripe" in the e164.arpa zone On Jan 17, 2008, at 14:56, Anand Buddhdev wrote:
The tools that transfer these zonelets rely on this extra piece of information in the TXT record for consistency checks. Similarly, AfriNIC, ARIN and APNIC also generate zones for their /8 allocations with records named "afrinic", "arin" and "apnic".
The e164.arpa zone does not really need this "ripe" record in it, since it is not shared among the registries in any way. However, because the e164.arpa zone is generated automatically from the RIPE Database by the same tools, it automatically receives this extra name. Currently, there is no way to stop the zone receiving this extra entry. But it has no negative effect on the zone or on ENUM operations.
Hmmm. This smells like a bug. Why are the DNS provisioning tools for e164.arpa generating data that isn't needed and inserting that data into the DNS? I wonder what will happen if the ITU one day decides that "ripe.e164.arpa" should be delegated to someone....
--On Thursday, 17 January, 2008 15:55 +0000 Jim Reid <jim@rfc1035.com> wrote:
Hmmm. This smells like a bug. Why are the DNS provisioning tools for e164.arpa generating data that isn't needed and inserting that data into the DNS? I wonder what will happen if the ITU one day decides that "ripe.e164.arpa" should be delegated to someone....
If they did, I trust RIPE NCC would reject the request/ decision and do so loudly because (i) the authorizing documents only authorize RIPE NCC to install delegations for numeric zones associated with E.164 codes and (ii) since requests for delegations are not permitted to originate with the ITU but only with parties who want to operate such zones, such a "decision" on the part of the ITU would be invalid on its face. So "what would happen" is nothing, plus or minus a small dust-up on the way to "nothing". john
Hmmm. This smells like a bug.
Yes but there are bigger bugs in the world to deal with. I advocate allowing the operators decide when and if they want to get rid of it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused.
On 2008/01/20 15:01, Edward Lewis <Ed.Lewis@neustar.biz> wrote:
Hmmm. This smells like a bug.
Yes but there are bigger bugs in the world to deal with.
I advocate allowing the operators decide when and if they want to get rid of it.
Same here. I'm confident that RIPE NCC will find a solution if this ever becomes an issue. Right now, I don't see the need to waste more time and electrons on this. /ol -- // Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg
participants (6)
-
Anand Buddhdev -
Edward Lewis -
Jim Reid -
John C Klensin -
Otmar Lendl -
Stream Service || Mark Scholten