- dns-wg - mailman.ripe.net

outcome from DNSSEC TAR Task Force
by Jim Reid 30 Apr '08

30 Apr '08

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

2 1

DNS WG Agenda for RIPE 56
by Peter Koch 28 Apr '08

28 Apr '08

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] <http://www.ripe.net/ripe/wg/dns/dns-actions.html> 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. =============================================================================

1 0

RIPE 56: Call for Agenda Items
by Peter Koch 01 Apr '08

01 Apr '08

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 <dns-wg-chair(a)ripe.net>. We'll also have the usual reports (volunteers still welcome) and some open action items to discuss. -Peter

1 0

Re: [dnssec-deployment] [dns-wg] Re: .SE releases report on consumer broadband routers
by Dave Piscitello 24 Mar '08

24 Mar '08

I seriously doubt that any vendor would sell a product under the category "Middle Boxes". Middlebox is an abstraction (see RFC 3234?). Certain broadband access devices (oh, my, the acronym "BAD" applies here!) are real world implementations of that abstraction. At the consumer/broadband level, precision with respect to technical language is wholly disregarded in favor of something familiar (router or firewall, in this case, and remarkably so) or something that sounds impressive (the NetScream TurboAccess Millenium 4000 FX). Patrik Fältström wrote: > > On 26 feb 2008, at 11.18, Stephane Bortzmeyer wrote: > >> If they mess with DNS data, they are not routers (a layer 3 device, >> neutral with respect to the content), they are middleboxes (a layer 1 >> to 9 device, able to break anything). > > Well, it is more complicated than that. Many people do think that NAT > boxes are layer 3 devices, and if you have a double-nat mechanism then > "messing around with DNS packets" is a needed feature. Sure, then one > start walking from layer 3 towards layer 9.... But... > > Anyway, this is not when we should fight about wording. We all know what > we talk about, and I think we should thank Patrik and others what they > have done. > > Patrik > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list <dnssec-deployment(a)shinkuro.com>. > To unsubscribe, E-mail to: <dnssec-deployment-off(a)shinkuro.com> > A public archive is available here: > <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/> > and older material is at > <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/> >

1 0

Draft RIPE 55 DNS WG Meeting Minutes
by Peter Koch 03 Mar '08

03 Mar '08

Dear DNS WG, with the registration for RIPE 56 already open, it's now really time to publish the draft minutes for the RIPE 55 DNS WG sessions. Please find a text version below and at <http://www.ripe.net/ripe/wg/dns/r55-minutes.html> a more stylish one. Please read through the minutes and let Jaap, Jim, or myself know of any comments or corrections you'd like to see applied. The comment period shall end Monday, 2008-03-31, 12:00 UTC Thanks to Adrian Bedford, who provided the notes on time, as usual. -Peter

1 0

.SE releases report on consumer broadband routers
by Patrik Wallstrom 26 Feb '08

26 Feb '08

"Three of the ten routers that .SE has tested, have passed the test specification without any remarks. The other seven have had severe problems when using what might be considered plain Domain Name System (DNS). The majority of the routers does not manage to pass on DNSSEC to the client, which gives you problems when there are applications on the client that want to handle their own DNSSEC validation." http://iis.se/about/press?id=135 The Excel document describing the result of the tests in more detail is available on request. -- Patrik Wallström Project Manager, R&D .SE (Stiftelsen för Internetinfrastruktur) E-mail: pawal(a)iis.se Web: http://www.iis.se/

4 3

Re: [dnssec-deployment] .SE releases report on consumer broadband routers
by Patrik Fältström 26 Feb '08

26 Feb '08

Patrik, let me be one of the first that thank you and your team for the hard work in doing this testing. Specifically as I early in this process "complained" that it was hard for us as Cisco to get to know which one (if any) of our products where involved. Thanks! Patrik On 26 feb 2008, at 11.06, Patrik Wallstrom wrote: > "Three of the ten routers that .SE has tested, have passed the test > specification without any remarks. The other seven have had severe > problems when using what might be considered plain Domain Name System > (DNS). The majority of the routers does not manage to pass on DNSSEC > to the client, which gives you problems when there are applications on > the client that want to handle their own DNSSEC validation." > > http://iis.se/about/press?id=135 > > The Excel document describing the result of the tests in more detail > is available on request. > > -- > Patrik Wallström > Project Manager, R&D > .SE (Stiftelsen för Internetinfrastruktur) > E-mail: pawal(a)iis.se > Web: http://www.iis.se/

1 0

ANNOUNCEMENT: RIPE NCC Training Courses.
by RIPE NCC Training Services 21 Feb '08

21 Feb '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

1 0

IANA introduces AAAA record for K-root
by Anand Buddhdev 13 Feb '08

13 Feb '08

Dear Colleagues, Yesterday, 4 February 2008, at around 17:00 (UTC), IANA introduced AAAA records for six of the root servers in the root server system. One of these servers is k.root-servers.net (2001:7fd::1), which is managed by the RIPE NCC. This change allows the root zone to be queried over IPv6. The K-root IPv6 prefix is currently anycast from the two global nodes, located in Amsterdam and Miami. The introduction of the AAAA records went smoothly, and we are monitoring the query rate and pattern. We are also collecting more detailed information for future analysis. A graph showing the IPv6 query rate for the last 24 hours can be viewed at: http://ripe.net/news/k-root-aaaa-announcement.html More information about AAAA records in the root zone is available at: http://www.iana.org/reports/root-aaaa-announcement.html Regards, -- Anand Buddhdev DNS Services Manager, RIPE NCC

3 3

DNSSEC trust anchors for unsigned zones
by Alexander Gall 30 Jan '08

30 Jan '08

Hi The current set of trust anchors distributed by RIPE NCC (<https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt>) includes the domains disi.nl example.net pwei.net None of these currently have any DNSSEC resource records (i.e. they are insecure), which effectively brakes those zones for everybody who uses that particular set of trust anchors. I guess this shows one of the operational problems with trust anchor management. These zones are not maintained by RIPE NCC itself and the administrators probably didn't bother to tell them that they've disabled DNSSEC (if they know or remember at all that their keys are distributed by a third party). I guess it would be more prudent for RIPE NCC to only distribute the keys for their own zones (those listed on <https://www.ripe.net/projects/disi//keys/>). -- Alex

5 7