- dns-wg - mailman.ripe.net

Re: [dns-wg] NTIA response - v5
by ololocc＠entratek.com 06 Nov '08

06 Nov '08

Please unsubscribe cc_ololo(a)yahoo.com ------Original Message------ From: Jim Reid Sender: dns-wg-admin(a)ripe.net To: bmanning(a)vacation.karoshi.com Cc: dns-wg(a)ripe.net Sent: Nov 6, 2008 7:25 AM Subject: Re: [dns-wg] NTIA response - v5 On Nov 5, 2008, at 23:01, bmanning(a)vacation.karoshi.com wrote: > much better - wrt the opening statement, I suspect this should > be couched as a response from teh RIPE DNS WG and not the Ripe > community as a whole, since I suspect they have not seen the text > or had a chance to comment on the same. Bill, the algorithm here is: if (no wg consensus by this weekend) give up send agreed WG text to ripe-announce if (ripe consensus by Nov 20th-ish) send letter(we == RIPE community) else send letter(we == DNS WG) Sent via BlackBerry from T-Mobile

1 0

NTIA and RIPE
by Patrik Fältström 30 Oct '08

30 Oct '08

On request, now as text. The original is the PDF though, so I do not guarantee this version is exactly like the current version on PDF. I hope so though! Patrik -- that missed lunch...see some of you in the desert RIPE and NTIA 29th of October 2008 A - DNSSEC is about data authenticity and integrity and not about control. B - The addition of DNSSEC to the root zone must be recognised as a global initiative. C - Addition of DNSSEC must be done in a way that the deployment of DNS is not at risk. D - Deployment should be done in a timely but not hasty manner. E - Any procedural changes introduced by DNSSEC should be aligned with the process for coordinating changes to and the distribution of the root zone. F - Policies and processes for signing the root zone should make it easy for TLDs to participate. G - There is no technical justification to create a new organisation to oversee the process of signing of the root. H - No data should be moved between organisations without appropriate authenticity and integrity checking. I - The public part of the KSK must be distributed as widely as possible. J - The organisation that creates the zone file must hold the private part of the ZSK. K - Changes to the entities and roles in the signing process must not require a change of keys.

5 7

Re: [dns-wg] NTIA and RIPE
by Richard Lamb 30 Oct '08

30 Oct '08

... On 2008Oct29, at 7:30 PM, Edward Lewis wrote: >Regardless of my personally agreeing with such a statement or not, here are my >reactions to some of the bullets. > >At 15:01 +0400 10/29/08, Patrik Fältström wrote: > > > B - The addition of DNSSEC to the root zone must be recognised as a > global initiative. > >I'm unclear on the intent of the B statement. See my comment on E. > > E - Any procedural changes introduced by DNSSEC should be aligned with the > process for coordinating changes to and the distribution of the root zone. > >In some interpretations of B & E, these two could be conflicting. I.e., B implies >that the current state of root zone management is too centered in the US, E evokes >a message encouraging the status quo. > >Mind you - I am not commenting on B or E, but my reading of the two leaves come >confusion in my mind. Perhaps I am misunderstanding B and/or >E as it is presented >here. I take B to mean we want the global Internet community to use and trust it. ..and yes control and operation that is less US centric. Thank you for "translating" E. It does evoke the current state of affairs which unfortunately do not best serve DNSSEC (even envisioned in [1]) and contradictory with B. I dont believe anyone is suggesting changing the current distribution mechnism for the root zone...only changing the creation of that zone to secure it and its new contents effectively. The how and who should be up to the community the root serves. IMHO E needs to be removed. It refers to a "process" that is by no means favored by the whole community nor frozen in stone. Why build it into DNSSEC? I have yet to understand the drivers behind E as there are any number of ways to achieve the same "balance" while simlifying and securing the process. Given the will, making such changes does not take a long time. In a previous life in government I have seen greater issues settled, contracts written, and even $$ doled out in less than a month. All depended on what level pressure is applied. Its your root. Design it and make sure it is what you want. ... > K - Changes to the entities and roles in the signing process must not > require a change of keys. > >I technically disagree with that, if there is a change in the entity performing the >zone signing, the private key material should not have to be transferred out in the >transition. The private key material of concern here is the ZSK, not the KSK. Agreed. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->=- >Edward Lewis +1-571-434->5468 >NeuStar > >Never confuse activity with progress. Activity pays more. Very much agree ;-) Not speaking for my employer on any of this lest I be looking for another career. -Rick [1] http://www.icann.org/en/tlds/agreements/verisign/root-server-management-tra… signed version elsewhere

2 2

ANNOUNCEMENT: RIPE NCC Training Courses
by Training 30 Oct '08

30 Oct '08

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The DNS for LIRs Training Course This course teaches LIRs about the RIPE NCC's DNS-related services. A course outline is available at: http://www.ripe.net/training/dns/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

2 2

Planned maintenance for ns.ripe.net, 4 November 08
by Sjoerd Oostdijck 30 Oct '08

30 Oct '08

[Apologies for duplicate emails.] Dear Colleagues, This message concerns people who have ns.ripe.net listed as a secondary DNS server for their reverse DNS zones. In order to improve the quality of our service, we are adding additional servers to our infrastructure. The effect of this change will be that we will perform zone transfers from more then one IP address within the ranges 193.0.0.0/22 and 2001:610:240::/48 as documented at: http://www.ripe.net/rs/reverse/reverse_howto.html On 4 November 2008 at 11:00 UTC, ns.ripe.net will move to a load-balanced solution. No noticeable downtime is expected. If you would like to make sure that we can properly transfer the zone from your server after the change, we recommend that you follow the following steps: - Increase the serial number in your zone's Start of Authority (SOA) record. - Wait for a zone transfer to be initiated from the 193.0.0.0/22 or the IPv6 address range. - Now you can compare the zone serials on your master server and ns.ripe.net. To compare the serials you can use tools like "dig", "drill" or "host -C" to query the SOA record and compare the serials on both servers. If you have any further questions about this message, please contact us at dns-help(a)ripe.net Regards, Sjoerd Oostdijck DNS Services RIPE NCC

1 0

NTIA and RIPE v3
by Richard Lamb 30 Oct '08

30 Oct '08

Great points but they miss the fundamental importance of providing a secure solution from TLD operator to signed root. So I would recommend the bullet: L - The solution has to balance various concerns, but must provide for a maximally secure technical solution and one that provides the trust promised by DNSSEC. -Rick

2 1

NTIA and RIPE v3
by Patrik Fältström 29 Oct '08

29 Oct '08

This is the third version of the list of issues that we are trying to reach consensus on. This is based on the feedback given during the morning session at RIPE in Dubai. Please send comments to this list as soon as possible as the wg chairs are to determine Thursday morning (Dubai time) whether there is consensus in the wg for them. Regards, Patrik Fältström, Editor

1 0

NTIA and RIPE v3
by Patrik Fältström 29 Oct '08

29 Oct '08

This is the third version of the list of issues that we are trying to reach consensus on. This is based on the feedback given during the morning session at RIPE in Dubai. Please send comments to this list as soon as possible as the wg chairs are to determine Thursday morning (Dubai time) whether there is consensus in the wg for them. Regards, Patrik Fältström, Editor

1 0

Getting the iana.org trust anchor
by Joao Damas 28 Oct '08

28 Oct '08

Givens the near-future availability of the IANA TAR, where can I get securely obtain the trust anchor for the iana.org zone (or the zone where the TAR will be served from) ? Any paper stubs available here at the RIPE meeting, perchance? Joao

2 3

Maintaining DOMAIN objects
by Denis Walker 16 Oct '08

16 Oct '08

[Apologies for duplicate emails] Dear Colleagues, The RIPE Data Protection Task Force advised the RIPE NCC that all objects in the RIPE Database should be maintained. Maintaining Routing Policy Specification Language (RPSL) objects in the RIPE Database was optional for PERSON, ROLE and DOMAIN objects. All the DOMAIN objects in the RIPE Database are now maintained and protected. As there may have been a possibility to exploit this data if any advance warning had been made, the RIPE NCC did not publicly announce that it was going to add maintainers to unmaintained DOMAIN objects before doing so. For further details of what was done, please see this web page: http://www.ripe.net/db/support/security/domain/syntax.html Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0