From pk at DENIC.DE Tue Apr 1 15:08:44 2008 From: pk at DENIC.DE (Peter Koch) Date: Tue, 1 Apr 2008 15:08:44 +0200 Subject: [dns-wg] RIPE 56: Call for Agenda Items Message-ID: <20080401130844.GF3355@x27.adm.denic.de> Dear DNS WG, it's only five weeks left until we meet in Berlin and even though some presentations have already been proposed, here's the official "call for agenda items" for the RIPE 56 DNS WG meeting. We'll have two slots again this time, Wed 1400-1530 and Thu 1100-1230. If you'd like to talk about a particular issue or know someone else who has an interesting topic, please let Jaap, Jim and myself know at . We'll also have the usual reports (volunteers still welcome) and some open action items to discuss. -Peter From jim at rfc1035.com Sun Apr 27 18:41:22 2008 From: jim at rfc1035.com (Jim Reid) Date: Sun, 27 Apr 2008 17:41:22 +0100 Subject: [dns-wg] outcome from DNSSEC TAR Task Force Message-ID: Colleagues, the work of the task force has to some extent been overtaken by events. IANA's plans for a trust anchor repository (TAR) are progressing and the consensus of the task force is that the RIPE community should support that effort. The task force has produced a set of requirements for a TAR. It feels there is no need to do anything more at this stage: moves towards an alternate TAR may not help the IANA initiative. So on behalf of the task force, I'd like to ask the WG to consider these requirements and endorse them as a statement from the RIPE community which could be sent to ICANN. [A bit like our "sign the root" statement last year.] The proposed text is below. If the WG is happy with this letter, I suggest the task force declares victory (for some definition of victory) and either goes into hibernation or shuts down. Your comments about this letter and the suggested future for the task force would be appreciated. Is the upcoming RIPE meeting a reasonable deadline for comments? Dear Barbara, Thank you for your note about the proposed DNSSEC key repository for TLDs. The RIPE DNS working group (DNS WG) welcomes this development. We would like to see IANA establish this DNSSEC Trust Anchor Repository (TAR) as soon as possible. We have developed a set of requirements for such a repository. As these may be useful for you when implementing the service, we offer them here: [1] The TAR should be technology neutral. It should not exclude or prevent different flavours of trust anchors from being published, provided those trust anchors conform to the relevant standards. [2] The TAR should be OS/DNS implementation neutral. Tools and documentation should be provided for use of the repository with common DNS resolver and name server platforms. Comment: IANA should publish such documentation and tools, or pointers to them. Once we know details of repository, we can help putting together this documentation. [3] The TAR should verify that the keying material it receives comes from an authorised source, verify it is correctly formatted and verify it is consistent with what is published in the TLD zone before publishing it. There should also be a secure channel for authenticating the repository and any data it is publishing. Comment: Using the same channels IANA uses to process update requests to the root zone from TLDs should be fine. We do not mean special new channels. https delivery and possibly checksums are sufficient for publication. [4] A process is needed to revoke a trust anchor and notify those who may be using the now withdrawn or invalid trust anchor. Comment: An opt-in mailing list for operational news should be sufficient to satisfy this. [5] The TAR should be clear what support, if any, is available. [6] The TAR must have a published exit strategy. Comment: The proposal includes that. [7] The TAR should only publish keying material with the consent of the respective key manager. Please let us know any the details of the repository as well as the time-line for implementation as soon as they become available. Please feel free to make our support for this repository known publicly or within ICANN. Kind Regards RIPE DNS WG Jim Reid Chair From jim at rfc1035.com Sun Apr 27 19:40:42 2008 From: jim at rfc1035.com (Jim Reid) Date: Sun, 27 Apr 2008 18:40:42 +0100 Subject: [dns-wg] Updated DNS migration document Message-ID: <298D662B-2646-4197-99E0-5145484ECFC1@rfc1035.com> Here is the latest version of the DNS migration document. I've included the comments made by Joao and Jarle. Does anyone have anything else to add? -------------- next part -------------- A non-text attachment was scrubbed... Name: DNSmigration Type: application/octet-stream Size: 39262 bytes Desc: not available URL: -------------- next part -------------- From Antoin.Verschuren at sidn.nl Mon Apr 28 10:08:04 2008 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Mon, 28 Apr 2008 10:08:04 +0200 Subject: [dns-wg] Updated DNS migration document References: <298D662B-2646-4197-99E0-5145484ECFC1@rfc1035.com> Message-ID: Hi Jim, all, Following the observations made on the IETF DNS-operations mailinglist (http://lists.oarci.net/pipermail/dns-operations/2008-February/002526.html) I think we're missing a step in chapter 3. In order for the old and new master server to serve the same data, and to give caches the opportunity to update to the new NS set, it is advised that an old master server starts serving the zone as a secondary for a period of time at least equal to the expire time of the zone once the delegation has been changed at the parent. It will prevent the undesired behavior that caches keep updating against the old master. One could say that deleting the zone from the old master will also update the caches, but this will require more queries and involves queries to the parents which are not needed when the old master replies the correct data when running secondary. Also, changing a master server usually also involves competitive dns-operators. Usually the change is done because the new operator offers a service the old operator could not, and they want this change in the zone as soon as possible. They will not wait for the change to be fully propagated, which results in 2 master servers serving different data. I would say to change 3.7 and include that an old master server should run secondary for a period of time at least equal to the expire time once the parent changed the delegation, before deprovisioning it and no longer answering for the zone, as the most optimal solution. The last paragraph in section 3.0 is also not clear enough on this. Should one not update, or update on the new master only ? And how should these changes be propagated to the old master ? Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren at sidn.nl W http://www.sidn.nl/ > -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of > Jim Reid > Sent: Sunday, April 27, 2008 7:41 PM > To: dns-wg at ripe.net > Subject: [dns-wg] Updated DNS migration document > > Here is the latest version of the DNS migration document. I've > included the comments made by Joao and Jarle. Does anyone have > anything else to add? From pk at DENIC.DE Mon Apr 28 14:58:56 2008 From: pk at DENIC.DE (Peter Koch) Date: Mon, 28 Apr 2008 14:58:56 +0200 Subject: [dns-wg] DNS WG Agenda for RIPE 56 Message-ID: <20080428125856.GA4159@x27.adm.denic.de> Dear WG, here is the most recent agenda for our two DNS WG sessions in Berlin. Thanks to all the volunteer contributors. Presenters, please calculate ~5 minutes for discussions (during or after your presentation). To avoid interruptions due to hardware switch procedures and to assist remote participants, please make your slideware available to the wg co-chairs in advance. The material will be posted on ROSIE during the meeting. See you in Berlin! -Peter ============================================================================= AGENDA for the DNS WG at RIPE56 ============================================================================= $Id: agenda.txt,v 1.6 2008/04/28 12:24:44 pk Exp $ ============================================================================= 2008-05-07 (WED) 1400-1530 // IPv6 ============================================================================= 0) Agenda Bashing and Administrivia [ 5 min] 1) Action Item Walk through [18 min] 48.1 [Wishlist for "lost" delegations] Peter 49.2 [DNS migration document] Jim 51.4 [RIPE203bis] Peter 2) Reports 2.1) Results of the Trust Anchor TF [ 7 min] Jim Reid/Daniel Karrenberg 2.2) IETF report [10 min] Antoin Verschuren IETF report for IETF70/71 (Vancouver and Philadelphia) 2.3) ICANN/IANA report [15 min] N.N., ICANN/IANA IDN fast track, DNSSEC, bogus PTR queries 2.4) ICANN SSAC [10 min] Patrik F?ltstr?m Recent publications, current topics 3) IDN.IDN with DNAME in JP [15 min] Yoneda Yoshiro 4) PIR DNSSEC Survey [10 min] Jakob Schlyter ============================================================================= 2008-05-08 (THU) 1100-1230 // EIX ============================================================================= 5) Update from the RIPE NCC [20 min] N.N., RIPE NCC 6) Unbound: A DNSSEC Validating Resolver [25 min] Wouter Wijngaards 7) Progress on DNSSEC for .CZ and 0.2.4.e164.arpa [10 min] Ondrej Sury 8) DNS issues in new MS operating systems [15 min] Carsten Strotmann 9) tcpdump filter rules for capturing DNS traffic [10 min] Shane Kerr 10) Experiences from changing a TLD's auth [10 min] name server's address Peter Koch 99) A.O.B. ============================================================================= From brettlists at gmail.com Wed Apr 30 12:50:59 2008 From: brettlists at gmail.com (B C) Date: Wed, 30 Apr 2008 11:50:59 +0100 Subject: [dns-wg] outcome from DNSSEC TAR Task Force In-Reply-To: References: Message-ID: <5c494b510804300350q4e1e187awcb62e5113eb79e9b@mail.gmail.com> I'd like to offer my support to the statement below, in the absence of a signed root this seems like the 'next best thing' and hopefully should help the deployment of dnssec on two levels: 1. Encourage more tld's to sign their zones and publish their keys. 2. Make it easier and simpler for resolver admins to maximise the amount of keys they support and minimise the work involved in keeping them configured. Thanks to Jim and the rest of the task force for the work they did. Brett Carr Nominet UK. On Sun, Apr 27, 2008 at 5:41 PM, Jim Reid wrote: > Colleagues, the work of the task force has to some extent been overtaken > by events. IANA's plans for a trust anchor repository (TAR) are progressing > and the consensus of the task force is that the RIPE community should > support that effort. The task force has produced a set of requirements for a > TAR. It feels there is no need to do anything more at this stage: moves > towards an alternate TAR may not help the IANA initiative. > > So on behalf of the task force, I'd like to ask the WG to consider these > requirements and endorse them as a statement from the RIPE community which > could be sent to ICANN. [A bit like our "sign the root" statement last > year.] The proposed text is below. > > If the WG is happy with this letter, I suggest the task force declares > victory (for some definition of victory) and either goes into hibernation or > shuts down. Your comments about this letter and the suggested future for the > task force would be appreciated. Is the upcoming RIPE meeting a reasonable > deadline for comments? > > > Dear Barbara, > > Thank you for your note about the proposed DNSSEC key repository for > TLDs. The RIPE DNS working group (DNS WG) welcomes this development. We > would like to see IANA establish this DNSSEC Trust Anchor Repository > (TAR) as soon as possible. We have developed a set of requirements for > such a repository. As these may be useful for you when implementing > the service, we offer them here: > > > [1] The TAR should be technology neutral. It should not exclude or > prevent different flavours of trust anchors from being published, > provided those trust anchors conform to the relevant standards. > > [2] The TAR should be OS/DNS implementation neutral. Tools and > documentation should be provided for use of the repository with common > DNS resolver and name server platforms. > > Comment: IANA should publish such documentation and tools, or pointers > to them. Once we know details of repository, we can help putting > together this documentation. > > [3] The TAR should verify that the keying material it receives comes > from an authorised source, verify it is correctly formatted and verify > it is consistent with what is published in the TLD zone before > publishing it. There should also be a secure channel for > authenticating the repository and any data it is publishing. > > Comment: Using the same channels IANA uses to process update requests > to the root zone from TLDs should be fine. We do not mean special new > channels. https delivery and possibly checksums are sufficient for > publication. > > [4] A process is needed to revoke a trust anchor and notify those who > may be using the now withdrawn or invalid trust anchor. > > Comment: An opt-in mailing list for operational news should be > sufficient to satisfy this. > > [5] The TAR should be clear what support, if any, is available. > > [6] The TAR must have a published exit strategy. > > Comment: The proposal includes that. > > [7] The TAR should only publish keying material with the consent of > the respective key manager. > > Please let us know any the details of the repository as well as the > time-line for implementation as soon as they become available. Please > feel free to make our support for this repository known publicly or > within ICANN. > > Kind Regards > > RIPE DNS WG > Jim Reid > Chair > > -------------- next part -------------- An HTML attachment was scrubbed... URL: