RIPE - ARIN cooperation when registering signed legacy reverse zones?
I hope this is the appropriate place to raise this. There are legacy network allocations whose reverse zone is managed via RIPE, but actually delegated from higher level reverse zones run by ARIN. To take a specific example, 131.111/16 is allocated to the University of Cambridge, we manage the delegation info for 111.131.in-addr.arpa via RIPE, but 131.in-addr.arpa belongs to ARIN. Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and https://www.arin.net/resources/dnssec/ indicates that they may be accepting signed delegations Fairly Soon Now (depending on what you think "the first part of 2010" means). Is it understood yet how (or even if) this will work for legacy network allocations? Ideally, this would just be a matter of supplying RIPE with the "ds-rdata" attributes as described in https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html and they would get transferred seamlessly into the ARIN zones (and signed there). -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
Dear Chris, Chris Thompson wrote on 02-02-2010 16:31:
I hope this is the appropriate place to raise this.
There are legacy network allocations whose reverse zone is managed via RIPE, but actually delegated from higher level reverse zones run by ARIN. To take a specific example, 131.111/16 is allocated to the University of Cambridge, we manage the delegation info for 111.131.in-addr.arpa via RIPE, but 131.in-addr.arpa belongs to ARIN.
Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and
https://www.arin.net/resources/dnssec/
indicates that they may be accepting signed delegations Fairly Soon Now (depending on what you think "the first part of 2010" means).
Is it understood yet how (or even if) this will work for legacy network allocations? Ideally, this would just be a matter of supplying RIPE with the "ds-rdata" attributes as described in
https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
and they would get transferred seamlessly into the ARIN zones (and signed there).
Yes, that's the idea. The RIRs are looking at necessary changes that need to be done to the management of the shared reverse zones to support this. There is no timeline yet, but we should have a better idea mid 2010. Regards, Andrei Robachevsky CTO, RIPE NCC
On Feb 2 2010, Andrei Robachevsky wrote:
Chris Thompson wrote on 02-02-2010 16:31: [...]
Is it understood yet how (or even if) this will work for legacy network allocations? Ideally, this would just be a matter of supplying RIPE with the "ds-rdata" attributes as described in
https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
and they would get transferred seamlessly into the ARIN zones (and signed there).
Yes, that's the idea. The RIRs are looking at necessary changes that need to be done to the management of the shared reverse zones to support this. There is no timeline yet, but we should have a better idea mid 2010.
Do we have any clearer idea about mechanisms and timescales yet? I've been perusing the RIPE-60 presentations at http://www.ripe.net/ripe/meetings/ripe-60/archives.php?day=thursday without finding anything relevant as yet. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
Chris,
Do we have any clearer idea about mechanisms and timescales yet? I've been perusing the RIPE-60 presentations at http://www.ripe.net/ripe/meetings/ripe-60/archives.php?day=thursday
without finding anything relevant as yet.
Jim asked Anand during the working group session. I think the relevant bit of the stenographer's transcript is this:
JIM REID: Anand, very interested to hear what is happening with reverse zone signing for ERX space and I realise it's complicated because it involves other interactions with RIRs specifically ARIN. Can you expand on information you gave. You say there is a project underway, you are discussing things with the other RIRs, have you a rough feel or a gut feel as to when that may be ready and if there is a possibility for members say of this organisation to participate in trials with a new system which will dealing with signing for reverse zones in ERX space?
ANAND BUDDHDEV: These discussions are happening at the RIR level and I don't have an exact time frame for when these discussions will be concluded, but I am hoping that by the next RIPE meeting, we may have something to tell you, but I think Andrei is coming up and he might have something to add to this.
JIM REID: If it must be like DNSSEC and it will be done within six months?
AUDIENCE SPEAKER: An dry, this is being discussed and that requires some changes in our provisioning system, from user experience point of view I don't think at least for the RIPE region users, it shouldn't have any changes. With regards to time?line, as I replied to the mailing list, maybe midyear we will have more accurate plans on the roll I couldn't tell of this service and how we tackle this address space. And that also goes in line that other areas are deploying DNSSEC, they are at different stages of the deployment and that also somehow determines the urgency of this activity.
Rob
Rob Evans wrote on 11/5/10 9:41 AM: [...]
AUDIENCE SPEAKER: An dry, this is being discussed and that requires some changes in our provisioning system, from user experience point of view I don't think at least for the RIPE region users, it shouldn't have any changes. With regards to time?line, as I replied to the mailing list, maybe midyear we will have more accurate plans on the roll I couldn't tell of this service and how we tackle this address space. And that also goes in line that other areas are deploying DNSSEC, they are at different stages of the deployment and that also somehow determines the urgency of this activity.
This is correct, and the audience speaker was me. Regards, Andrei
Rob & Andrei - thanks for the information. Jim - thanks for keeping this on the agenda. As far as I can make out, ARIN haven't started accepting DS records from their own customers yet - i.e. "Phase 3" in https://www.arin.net/resources/dnssec/index.html ("First part of 2010" is so marvelously flexible, isn't it? The part consisting of 364 days, maybe ...) -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
Chris Thompson wrote:
I hope this is the appropriate place to raise this.
I think so :-)
There are legacy network allocations whose reverse zone is managed via RIPE, but actually delegated from higher level reverse zones run by ARIN. To take a specific example, 131.111/16 is allocated to the University of Cambridge, we manage the delegation info for 111.131.in-addr.arpa via RIPE, but 131.in-addr.arpa belongs to ARIN.
Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and
Looking at this from a slightly different angle (with ERX in mind) ... Excerpt from the above webpage: "Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors,..." Seems to indicate that ARIN has the complete and exclusive control over the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA?
indicates that they may be accepting signed delegations Fairly Soon Now (depending on what you think "the first part of 2010" means).
Is it understood yet how (or even if) this will work for legacy network allocations? Ideally, this would just be a matter of supplying RIPE with the "ds-rdata" attributes as described in
https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
and they would get transferred seamlessly into the ARIN zones (and signed there).
Wilfried
Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and
Looking at this from a slightly different angle (with ERX in mind) ...
Excerpt from the above webpage:
"Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors,..."
Seems to indicate that ARIN has the complete and exclusive control over the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA?
Wilfried
plz see the ietf - Protocol Action: 'Nameservers for IPv4 and IPv6 Reverse Zones' to BCP --bill
Bill, thanks for the pointer to http://www.ietf.org/id/draft-jabley-reverse-servers-01.txt ! I feel that my question was not properly worded :-( bmanning@vacation.karoshi.com wrote:
Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and
Looking at this from a slightly different angle (with ERX in mind) ...
Excerpt from the above webpage:
"Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors,..."
Seems to indicate that ARIN has the complete and exclusive control over the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA?
My reading was or rather is: ARIN is managing all zones/master servers for the complete set of 1. level delegation points *below* in-addr.arpa and ip6.arpa. Apologies for still using flawed DNS terminology, maybe, and/or misreading the quoted paragraph!
Wilfried
plz see the ietf - Protocol Action: 'Nameservers for IPv4 and IPv6 Reverse Zones' to BCP
--bill
Wilfried.
On Wed, Feb 3, 2010 at 12:28 PM, Wilfried Woeber, UniVie/ACOnet <Woeber@cc.univie.ac.at> wrote:
Bill,
thanks for the pointer to http://www.ietf.org/id/draft-jabley-reverse-servers-01.txt !
I feel that my question was not properly worded :-(
bmanning@vacation.karoshi.com wrote:
Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and
Looking at this from a slightly different angle (with ERX in mind) ...
Excerpt from the above webpage:
"Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors,..."
Seems to indicate that ARIN has the complete and exclusive control over the full (IPv4-) Reverse Tree? If so, what's the situation for IP6.ARPA?
My reading was or rather is:
ARIN is managing all zones/master servers for the complete set of 1. level delegation points *below* in-addr.arpa and ip6.arpa.
Apologies for still using flawed DNS terminology, maybe, and/or misreading the quoted paragraph!
Well The sentence on the ARIN web page quoted: "Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors" Seems incorrect to me, I think the other RIR's might be surprised to find they are contractors to ARIN. I guess you might regard those bit's of the space that are shared between the RIR's as kind of contracted out in some way but it still seems like a bizarre way of describing it to me. It does seem strange that in-addr.arpa is delegated to the root servers but ip6.arpa is delegated to ICANN but I suspect there is some history and/or a story here :) Brett
On 11 Feb 2010, at 22:27, B C wrote:
"Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors"
Seems incorrect to me, I think the other RIR's might be surprised to find they are contractors to ARIN.
Brett, IMO it would have been better if ARIN had used the word "partners" instead of "contractors". I'm fairly sure that's what ARIN meant even if it wasn't what they said in the statement you quoted. ARIN will know that the other RIRs are not contractors to ARIN when it comes to reverse DNS space. As do the other RIRs. Who will presumably be happy to remind their cousins at ARIN of that fact. The situation with DNS service for in-addr.arpa doesn't lend itself to soundbites. So I wouldn't worry too much about soundbites on a web page which by definition won't tell the whole story in painstaking detail. As I'm sure you know, some parts of the tree are managed by the other RIRs (who then have mutual arrangements for DNS service for "their" domains). [As an example, 195.in-addr.arpa is managed by the NCC and the zone's NSRRset includes name servers operated by APNIC and ARIN.] Other parts are handled by ARIN's name servers and its contractors (Neustar/Ultra IIRC). Then there's the AS112 project for RFC1918 space. And the unallocated or reserved space, etc, etc. Now someone could explain all of this in fine detail. But would it help or hinder understanding of whar ARIN's doing wrt DNSSEC?
On Fri, Feb 12, 2010 at 12:03 AM, Jim Reid <jim@rfc1035.com> wrote:
On 11 Feb 2010, at 22:27, B C wrote:
"Today, delegations under in-addr.arpa are served by servers operated by ARIN and its contractors"
Seems incorrect to me, I think the other RIR's might be surprised to find they are contractors to ARIN.
Brett, IMO it would have been better if ARIN had used the word "partners" instead of "contractors". I'm fairly sure that's what ARIN meant even if it wasn't what they said in the statement you quoted. ARIN will know that the other RIRs are not contractors to ARIN when it comes to reverse DNS space. As do the other RIRs. Who will presumably be happy to remind their cousins at ARIN of that fact.
Indeed of course I am aware of this already just thought it was worth replying to Wilfreds e-mail for the benefit of other people on the list who may be confused and/or interested.
The situation with DNS service for in-addr.arpa doesn't lend itself to soundbites. So I wouldn't worry too much about soundbites on a web page which by definition won't tell the whole story in painstaking detail. As I'm sure you know, some parts of the tree are managed by the other RIRs (who then have mutual arrangements for DNS service for "their" domains). [As an example, 195.in-addr.arpa is managed by the NCC and the zone's NSRRset includes name servers operated by APNIC and ARIN.] Other parts are handled by ARIN's name servers and its contractors (Neustar/Ultra IIRC). Then there's the AS112 project for RFC1918 space. And the unallocated or reserved space, etc, etc.
Now someone could explain all of this in fine detail. But would it help or hinder understanding of whar ARIN's doing wrt DNSSEC?
Well no not directly but being accurate and explaining some of this in detail (in the correct place) could help people who are new to this wg or the industry in general understand what is going on, that was my point I guess, maybe I didn't get it across well enough but hey that's e-mail for you :) Brett
participants (8)
-
Andrei Robachevsky -
B C -
bmanning＠vacation.karoshi.com -
Brett Carr
-
Chris Thompson -
Jim Reid -
Rob Evans -
Wilfried Woeber, UniVie/ACOnet