- dns-wg - mailman.ripe.net

Announcement DNS Training Course
by RIPE NCC Training Services 07 Feb '06

07 Feb '06

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Monday 10 April 2006 Time: 09:00 17:00 Location: London, United Kingdom And Date: Thursday 11 May 2006 Time: 09:00 17:00 Location: Amsterdam, Netherlands And Date: Tuesday 13 June 2006 Time: 09:00 17:00 Location: Riyadh, Saudi Arabia Hosted by:ZAJIL International Telecommunications Co. W.L.L. And Date: Thursday 22 June 2006 Time: 09:00 17:00 Location: Munich, Germany The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: 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 __________ RIPE NCC Online Learning...at your own pace in your own space https://e-learning.ripe.net

1 0

DNSSEC rollout announcement
by Brett Carr 10 Jan '06

10 Jan '06

[Apologies for duplicates.] Dear Colleague, The RIPE NCC has been moving ahead with the signing of DNSSEC reverse zones. We are pleased to announce that we have reached the stage where all IPv4 reverse zones are signed. You can find details of the zones and relevant public keys at: https://www.ripe.net/projects/disi/keys/ We are now also accepting signed delegations (DS Records) for all IPv4 zones. Details on how to request a secure delegation can be found at: https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html During the month of January, we will phase in the signing of IPv6 reverse zones. Further notification of this will be sent when the process is complete. Brett Carr -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8

1 0

Announcement DNS Training Course
by RIPE NCC Training Services 13 Dec '05

13 Dec '05

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Friday, 27 January 2006 Time: 09:00 17:00 Location: Limassol, Cyprus And Date: Wednesday, 15 February 2006 Time: 09:00 17:00 Location: Manama, Bahrain Hosted by: 2Connect: http://www.2connectbahrain.com/ The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: 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

unsubscribe jkuijer@dds.nl
by jkuijer＠dds.nl 30 Nov '05

30 Nov '05

Citeren dns-wg-request(a)ripe.net: > Send dns-wg mailing list submissions to > dns-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/dns-wg > or, via email, send a message with subject or body 'help' to > dns-wg-request(a)ripe.net > > You can reach the person managing the list at > dns-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dns-wg digest..." > > > Today's Topics: > > 1. unsubscribe jkuijer(a)dds.nl (jkuijer(a)dds.nl) > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Brett Carr) > 3. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > > --__--__-- > > Message: 1 > Date: Tue, 29 Nov 2005 12:24:05 +0100 > From: jkuijer(a)dds.nl > To: dns-wg(a)ripe.net > Subject: [dns-wg] unsubscribe jkuijer(a)dds.nl > > Citeren dns-wg-request(a)ripe.net: > > > Send dns-wg mailing list submissions to > > dns-wg(a)ripe.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.ripe.net/mailman/listinfo/dns-wg > > or, via email, send a message with subject or body 'help' to > > dns-wg-request(a)ripe.net > > > > You can reach the person managing the list at > > dns-wg-admin(a)ripe.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of dns-wg digest..." > > > > > > Today's Topics: > > > > 1. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Randy Bush) > > > > -- __--__-- > > > > Message: 1 > > From: Alexander Gall <gall(a)switch.ch> > > Date: Mon, 28 Nov 2005 12:02:49 +0100 > > To: "Brett Carr" <brettcarr(a)ripe.net> > > Cc: <dns-wg(a)ripe.net> > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > On Mon, 28 Nov 2005 11:24:45 +0100, "Brett Carr" <brettcarr(a)ripe.net> said: > > > > >> -----Original Message----- > > >> From: Alexander Gall [mailto:gall@switch.ch] > > >> Sent: 28 November 2005 08:47 > > >> To: Brett Carr > > >> Cc: dns-wg(a)ripe.net > > >> Subject: Re: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > >> > > >> Brett, > > >> > > >> What's going on with 195.in-addr.arpa? All DNSSEC records > > >> are gone, e.g. > > >> > > > > > We saw some zone file corruption during the early hours of the morning, > > this > > > caused a failsafe operation to takeover and hence the zones were > published > > > without signatures. I've investigated and fixed the corruption and so now > > > everything is back to normal. > > > > Thanks. Having such a failsafe procedure is probably a good idea. > > However, it caused my sub-zone to be marked as bogus, which is bad > > (i.e. my cache with only the key for 195.in-addr.arpa configured as > > trusted key returned SERVFAIL for all queries within > > 176.195.in-addr.arpa). I think that you must not leave the DS records > > in the zone when all other DNSSEC RRsets are removed (and the DS > > record for my zone was definitely there). Otherwise, a verifier will > > find a DS record but is unable to check its authenticity and has to > > declare the zone as bogus. > > > > -- > > Alex > > > > > > > > -- __--__-- > > > > Message: 2 > > From: Randy Bush <randy(a)psg.com> > > Date: Mon, 28 Nov 2005 06:01:50 -1000 > > To: "Brett Carr" <brettcarr(a)ripe.net> > > Cc: dns-wg(a)ripe.net > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > > We saw some zone file corruption during the early hours of the > > > morning, this caused a failsafe operation to takeover and hence > > > the zones were published without signatures. > > > > considering the obvious attack paths this opens, one assumes that > > this 'failsafe' would not be part of the operation of a secure > > zone in normal, as opposed to trial, operation. > > > > randy > > > > > > > > > > End of dns-wg Digest > > > > > > > --__--__-- > > Message: 2 > From: "Brett Carr" <brettcarr(a)ripe.net> > To: "'Alexander Gall'" <gall(a)switch.ch> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > Date: Tue, 29 Nov 2005 16:38:58 +0100 > > > > > -----Original Message----- > > From: Alexander Gall [mailto:gall@switch.ch] > > Sent: 25 November 2005 15:22 > > To: Brett Carr > > Cc: dns-wg(a)ripe.net > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > Brett, > > > > On Fri, 25 Nov 2005 14:41:34 +0100, "Brett Carr" > > <brettcarr(a)ripe.net> said: > > > > >> -----Original Message----- > > >> From: Alexander Gall [mailto:gall@switch.ch] > > >> Sent: 25 November 2005 11:48 > > >> To: Brett Carr > > >> Cc: dns-wg(a)ripe.net > > >> Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > [...] > > > > >> > > >> However, I think there is a problem with ns.ripe.net. It doesn't > > >> return DNSSEC RRsets when the DO flag is set in the query: > > >> > > > > [...] > > > > > I found a small config typo, which I have fixed, it should > > be ok now though. > > > > Thanks, it looks good now. > > > > Did you have a chance to look (or have somebody else have a > > look :-) at > > <https://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi> for the > > zone 176.195.in-addr.arpa? I can see two problems: > > > > - For some reason, the tool doesn't get replies to queries for NS and > > DNSKEY records at our name servers {merapi,scsnms}.switch.ch with > > the DO flag set. The tool then (erroneously) concludes that these > > RRsets are inconsistent among the servers for the zone. > > > > I see the queries coming in on our servers from 193.0.0.214. Could > > it be that the replies are filtered somwhere in your network (having > > strange flags and all that)? > > > We have now fixed this after finding some strange (udp fragment) filtering > behaviour on our Juniper router, We will be carrying out more (lab based) > tests on this and will report the results to Juniper. > > Regards > > Brett > > -- > Brett Carr RIPE Network Coordination Centre > Systems Engineer -- Operations Group Amsterdam, Netherlands > GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 > > > > > --__--__-- > > Message: 3 > From: Alexander Gall <gall(a)switch.ch> > Date: Wed, 30 Nov 2005 08:59:37 +0100 > To: "Brett Carr" <brettcarr(a)ripe.net> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > On Tue, 29 Nov 2005 16:38:58 +0100, "Brett Carr" <brettcarr(a)ripe.net> said: > > >> Did you have a chance to look (or have somebody else have a > >> look :-) at > >> <https://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi> for the > >> zone 176.195.in-addr.arpa? I can see two problems: > >> > >> - For some reason, the tool doesn't get replies to queries for NS and > >> DNSKEY records at our name servers {merapi,scsnms}.switch.ch with > >> the DO flag set. The tool then (erroneously) concludes that these > >> RRsets are inconsistent among the servers for the zone. > >> > >> I see the queries coming in on our servers from 193.0.0.214. Could > >> it be that the replies are filtered somwhere in your network (having > >> strange flags and all that)? > > > > We have now fixed this after finding some strange (udp fragment) filtering > > behaviour on our Juniper router, We will be carrying out more (lab based) > > tests on this and will report the results to Juniper. > > Thanks! > > -- > Alex > > > > > End of dns-wg Digest >

1 0

RIPE NCC DNSSEC on the reverse tree update.
by Brett Carr 30 Nov '05

30 Nov '05

Dear Colleagues, As part of the project to deploy DNSSEC in the RIPE NCC service region, the RIPE NCC has further expanded the signing of zones from the reverse tree. The following zones are now signed: ripe.net ripencc.com ripencc.net ripencc.org ripe-ncc.com ripe-ncc.net ripe-ncc.org 89.in-addr.arpa 90.in-addr.arpa 213.in-addr.arpa 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa. 212.in-addr.arpa. 194.in-addr.arpa. 145.in-addr.arpa. If you want to configure your resolvers to verify these zones using DNSSEC, *key signing keys* for these zones are available at: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt For information about how to use the keys, and for further details about DNSSEC deployment at the RIPE NCC, please see: http://www.ripe.net/projects/disi/keys/ The following zones will now accept secure delegations (DS Records) via the addition of a "ds-rdata:" record in the whois domain object for the zone: 89.in-addr.arpa. 90.in-addr.arpa. 213.in-addr.arpa. 193.in-addr.arpa. 195.in-addr.arpa. Regards Brett Carr RIPE NCC

3 13

unsubscribe jkuijer@dds.nl
by jkuijer＠dds.nl 29 Nov '05

29 Nov '05

Citeren dns-wg-request(a)ripe.net: > Send dns-wg mailing list submissions to > dns-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/dns-wg > or, via email, send a message with subject or body 'help' to > dns-wg-request(a)ripe.net > > You can reach the person managing the list at > dns-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dns-wg digest..." > > > Today's Topics: > > 1. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Randy Bush) > > --__--__-- > > Message: 1 > From: Alexander Gall <gall(a)switch.ch> > Date: Mon, 28 Nov 2005 12:02:49 +0100 > To: "Brett Carr" <brettcarr(a)ripe.net> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > On Mon, 28 Nov 2005 11:24:45 +0100, "Brett Carr" <brettcarr(a)ripe.net> said: > > >> -----Original Message----- > >> From: Alexander Gall [mailto:gall@switch.ch] > >> Sent: 28 November 2005 08:47 > >> To: Brett Carr > >> Cc: dns-wg(a)ripe.net > >> Subject: Re: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > >> > >> Brett, > >> > >> What's going on with 195.in-addr.arpa? All DNSSEC records > >> are gone, e.g. > >> > > > We saw some zone file corruption during the early hours of the morning, > this > > caused a failsafe operation to takeover and hence the zones were published > > without signatures. I've investigated and fixed the corruption and so now > > everything is back to normal. > > Thanks. Having such a failsafe procedure is probably a good idea. > However, it caused my sub-zone to be marked as bogus, which is bad > (i.e. my cache with only the key for 195.in-addr.arpa configured as > trusted key returned SERVFAIL for all queries within > 176.195.in-addr.arpa). I think that you must not leave the DS records > in the zone when all other DNSSEC RRsets are removed (and the DS > record for my zone was definitely there). Otherwise, a verifier will > find a DS record but is unable to check its authenticity and has to > declare the zone as bogus. > > -- > Alex > > > > --__--__-- > > Message: 2 > From: Randy Bush <randy(a)psg.com> > Date: Mon, 28 Nov 2005 06:01:50 -1000 > To: "Brett Carr" <brettcarr(a)ripe.net> > Cc: dns-wg(a)ripe.net > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > We saw some zone file corruption during the early hours of the > > morning, this caused a failsafe operation to takeover and hence > > the zones were published without signatures. > > considering the obvious attack paths this opens, one assumes that > this 'failsafe' would not be part of the operation of a secure > zone in normal, as opposed to trial, operation. > > randy > > > > > End of dns-wg Digest >

1 0

Announcing a covering prefix for the K-root server
by Andrei Robachevsky 07 Nov '05

07 Nov '05

Dear Colleagues, As you probably know, the RIPE NCC have been deploying two types of anycast mirror instances of K-root server: global nodes and so-called local nodes, intended to serve only a local ISP community. To limit propagation of the K-root prefix for the local nodes we are using a NO_EXPORT community. Unfortunately this may lead to a situation when some of multihomed networks don't see K-root prefix at all, even for a global node. For more detailed description see http://www.merit.edu/mail.archives/nanog/msg13358.html. Thank you, Randy, for spotting this. This is not specific to anycast and has never appeared to be particularly widespread. To remedy this problem we plan to start announcing a covering prefix 193.0.14.0/23 from AS25152 from our global node to our peers at AMS-IX without the NO_EXPORT community. We will announce the covering prefix at 10:00 UTC on Thursday, 10th November 2005. In parallel we will be monitoring and measuring changes in traffic distribution for further analysis. We will then proceed with other global nodes. Regards, Andrei Robachevsky RIPE NCC

2 1

RIPE NCC Start Signing selected in-addr.arpa. zones
by Brett Carr 03 Nov '05

03 Nov '05

Dear Colleagues, As part of the project to deploy DNSSEC in the RIPE NCC Service region, the RIPE NCC has started signing three zones from the reverse tree. The following zones are now signed: ripe.net ripencc.com ripencc.net ripencc.org ripe-ncc.com ripe-ncc.net ripe-ncc.org 89.in-addr.arpa 90.in-addr.arpa 213.in-addr.arpa If you want to configure your resolvers to verify these zones using DNSSEC, *key signing keys* for these zones are available at: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt For information about how to use the keys, and for further details about DNSSEC deployment at the RIPE NCC, please see: http://www.ripe.net/projects/disi/keys/ We will shortly start accepting secure delegations. There will be more information about this soon. Regards Brett Carr RIPE NCC

1 0

Planned network maintenance 3-11-2005
by Ruud de Kooter 02 Nov '05

02 Nov '05

Dear Colleagues, This is to let you know that we will carry out planned network maintenance tomorrow, Thursday, 3 November from 20:00 to 22:00 UTC. We don't expect this to disrupt any RIPE NCC services, though you may notice some small delays. This maintenance is necessary after a high load on one of our border routers caused some service disruption on 29 September 2005. Since then, we have made configuration changes to improve load balancing between the border routers. Unfortunately this has not been as beneficial as we had hoped, and the load continues to increase. The router is approaching its maximum capacity. We have decided to replace the router with a more powerful one. We apologise for inconvenience this may cause. If you have any questions, please send e-mail to <ops(a)ripe.net>. Regards, Ruud de Kooter

1 0

RIPE51 Minutes
by Jim Reid 28 Oct '05

28 Oct '05

Colleagues, here are the WG minutes from the sessions at last week's RIPE meeting. These will also be available from the web site in the next day or so. Please send any comments or corrections to the list. Special thanks are due to Adrian Bedford for scribing and promptly producing an excellent set of minutes. This made it very easy for your co-chairs to get the minutes published so quickly and we are grateful to him. Thanks Adrian! RIPE 51 Amsterdam DNS Working Group Session 1 - 12 October 2005 Chaired by Peter Koch Scribe: Adrian Bedford A & B - Administrative Matters: The group approved the minutes from RIPE 50 with no changes: http://www.ripe.net/ripe/wg/dns/r50-minutes.html Updates were provided for the various action points outstanding for the group. http://www.ripe.net/ripe/wg/dns/dns-actions.html 48.1: Peter Koch sent a draft to the working group mailing list before RIPE 50. After detailed feedback from Ed Lewis, the proposal is to be redrafted. Peter hopes to have made progress on this by RIPE 52. Status - Ongoing. 48.2: Måns Nilsson is negotiating on funding to revise the wording of his proposal. Although this is currently stalled, he hopes to be able to sort this out within the coming two months and provide a rough draft in time for RIPE 52. Status - Ongoing. 48.4: David Malone agreed to continue to provide updates on his work. There has been no draft circulated as yet. Status - Ongoing. 49.1: Peter is stalled on this. A proposal was sent to the NCC Services Working Group Mailing List. Peter encouraged members of the DNS WG to investigate this. Status - Ongoing. 49.2: A small group is working on this, but has not yet got too far. Jim Reid hopes to incorporate changes suggested by Fernando Garcia to a Draft RIPE Document by the end of October. Status - Ongoing. 50.1: This will be covered by a presentation at this session from Lorenzo Collitti. Status - Ongoing. 50.2: This has been completed. Jim explained the background. It appears to have come down to a misunderstanding and subsequent poor communication from the IANA. A problem with zone generation for the root zone when communicated suggested a change in IANA policy. This was in fact not the case. IANA fixed the issue and promised that greater care will be taken with future communication. All letters sent to IANA and their replies are available within the mail archive of this working group. Status - Done. C1. IETF DNS Report – DNSEXT and DNSOP Olaf Kolkman - NLnetLabs: Olaf gave updates on IETF Working Group documents for both DNEXT and DNSOP. http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- ietf-dns-report.pdf C2. IETF CRISP WG Marcos Sanz - DENIC Marcos provided an update from an IETF meeting that recently took place in Paris, looking at different documents related to the deployment of CRISP. There were no slides. AREG - The Address Registry profile for IRIS reached Version 12 and Last Call was over at the end of September. Some IESG comments will lead to a further edit and a new version will soon be available. This is close to becoming an RFC. DCHK - This is a paper dealing with a lightweight version of IRIS running on top of LWZ (A UDP transport for IRIS). Documents are advancing. XPC - There are no BEEP large-scale deployments, this meets a need for an alternative, simpler transport for IRIS. It is based on TCP with a small binary header. RREG - Routing Registry profile for IRIS. This is an individual draft and not a working group draft. It provides information about prefixes, Autonomous Systems and contacts. The purpose of the document remains unclear; maybe a mirroring mechanism is what Internet routing registries actually need. Discussion goes on, whether to adopt it into the CRISP working group. Additionally, the .br TLD registry announced their DCHK and LWZ implementations. Shane Kerr commented that those interested in the RIPE NCC deployment of IRIS should attend the Database Working Group session on Friday morning. C3. EPP – The Next Step Jaap Akkerhuis – on behalf of Scott Hollenbeck - Verisign Jaap outlined work by Scott to improve the quality of papers and move them to draft status, using the ietf-provreg(a)cafex.se mailing list. He emphasized that Scott welcomes all comments, questions and feedback from the group. http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-epp-rfc.pdf Peter Koch announced that Policy Proposal 007 (DNSSEC) had now completed its run through the formal Policy Proposal Process and the chairs of the DNS WG had decided that there had been no formal objections. They declared consensus had been reached. http://www.ripe.net/ripe/policies/proposals/2005-7.html Peter asked if the group found updates from IETF useful. He requested feedback on this after the session. Peter also let the group know that the co-chairs welcomed any suggestions of things that the group would like to see discussed or presented at future RIPE Meetings. D: Effect of anycast on K-root: early results Lorenzo Colitti – RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- anycast_k-root.pdf After the presentation, Ladislav Vobr asked about whether anycast technology had been tested before being put into production on K- root. There was interest in how testing had been done and what convinced those behind the project that it was suitable? Daniel Karrenberg, who was involved in the development, explained that the main goal was resilience. The motivation was to increase the protection against Distributed Denial of Service (DDoS) attacks. Prior to deployment, the setup underwent testing. A discussion followed about the merits of anycast and DNS over TCP, with questions asked about whether UDP would be a more appropriate protocol to investigate persistent switching and packet fragmentation. As chair of this session, Peter Koch stated that he felt that it had been discussed at length in the past and added this should be taken up out of this session, as time was limited. The previous discussion is available in the mailing list archive. It was suggested that the RIPE NCC might consider a presentation on how anycasting is working out at RIPE 52. Jim Reid picked up on the scientific paper that Lorenzo mentioned. He asked if this might be published as a RIPE Document. Lorenzo did not see any reason why it could not be. E: DNS Guru Contest Carsten Strotmann -- Men & Mice http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dnsguru-quiz.pdf Carsten encouraged everyone to log on, take the DNS Guru test, and provide feedback. Olaf Kolkman asked about prizes for those taking part. Session 2 - 13 October 2005 Chaired by Jim Reid Scribe: Adrian Bedford Carsten Strotmann announced that there was a prize for those who took part in the DNS Guru Test. He explained that there are polo shirts available to the ten people who score highest. F: DNS Restructuring Update at the RIPE NCC Brett Carr – RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-restructure.pdf Mohsen Souissi of AFNIC commented that while deploying DNSSEC, one of his servers had encountered problems. It caused some fragmentation for IPv6 when using Fedora with a Symmetrical Multi-Processor front end. AFNIC had found a workaround by switching to mono-processor that worked fine. He is still awaiting feedback on a final solution from Fedora core developers. G: Deprecation of ip6.int Andrei Robachevsky – RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- deprecation-ip6.int.pdf Peter Koch asked, how the date would be set and when the RIPE NCC would publicly announce it. Andrei replied that the RIRs had met to discuss this. The probable date they had settled on would be 1 June 2006. The date was set to be sufficiently far enough in the future to allow any discussion to follow the Policy Development Process (PDP). There will be no formal announcement until this date is certain. Andrei asked the group how the RIPE NCC should proceed with this. He suggested three possible courses of action: 1. Just go ahead and present this as an operational issue 2. Enter the PDP system with the suggestion 3. Wait and see Lars-Johan Liman suggested that the RIPE NCC favour the first option, this received support from those in the room and is now an action on the RIPE NCC. H: Key Rollover Paper and Tools Johan Ihren – Autonomica http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- cadr-dnssec.pdf Johan stressed that the presentation he was giving was based on his own private work with Bill Manning and was not representative of the views of Autonomica. The presentation was followed by a live demonstration of the tool. Mohsen Souissi asked how a network operator could be sure that data was correctly configured. He wondered if Johan planned to add additional features to the software to carry out further authentication checks. Johan explained that this would come down to the policy set by each registry. Each would still need to decide on appropriate policies or safeguards before accepting any changes, regardless of how they were submitted. I: RIPE NCC Secondary Service Policy Lars-Johan Liman – Autonomica http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-nodns.pdf Lars-Johan raised the issue of the future of the RIPE NCC Secondary DNS Service. Axel Pawlik asked why this was being discussed within the DNS Working Group and not within NCC Services. The reply was that an agreement was made at RIPE 50 to first float the idea in this group and discuss it before taking any concrete suggestions to the other group. Axel agreed that the proposal made by Lars-Johan made good sense. The RIPE NCC has a basic principle that it would never compete in any area where its members are offering services. Lars-Johan commented that keeping track of this must be difficult as the business plans and strategies of its members are constantly changing. Axel reiterated that he felt in this case, the situation was quite clear. Rob Blokzijl had three remarks to make. He felt that Lars-Johan had stated that the RIPE NCC should focus purely on IP Address administration and little else. He disagreed with this, adding that this was not why the RIPE NCC was created. It was set up as a permanent secretariat to RIPE with a mandate to do coordination activities for the Internet. He added that he fully agreed that the RIPE NCC should not offer a service that a member was also offering. He then wished to clarify the history behind the offering of this service. It was most likely an activity started when there were different circumstances and was valid at a time when there was no DNS industry. He personally felt that if the membership agrees that the RIPE NCC should revisit this activity, he would offer support. He warned that he felt a gradual phase out was preferable to a sudden stop. Some African ccTLDs might find it hard to move to a fully commercial service. They may need to continue using the RIPE NCC service for some time to come. In principal, Rob feels that the NCC should go through all of the ‘non paying customers’ for the service and see how they could rationalise the list. Daniel Karrenberg wished to explain why the RIPE NCC took over ns.eu.net. Whilst he fully agreed with the reasoning behind the proposal, he wanted to clarify some points made in the presentation. The RIPE NCC did not take on ns.eu.net as an ‘act of charity’. At the time when the system was in financial trouble, there was panic, both operationally and politically. There was much talk about greater regulatory powers being given to governments and the RIPE NCC acted to protect the stability of the Internet. Everyone agreed that it was a good thing for the RIPE NCC to do at the time. If ns.eu.net had collapsed, we would see a very different registration and regulatory environment to the one we have now. He felt that the three options offered at the end of Lars-Johan’s proposal needed modification. The options to do nothing or impose a fee and launch this as a RIPE NCC service, were both impractical and not worth pursuing. He favoured the idea of the RIPE NCC withdrawing from its ccTLD Secondary DNS Service, though agreed with earlier speakers that initially this could not be done entirely. He stated that we live in a world where stability and security of the DNS remains a political issue. He suggested we needed a fourth proposal. The community needed to ask the RIPE NCC to look at the obvious beneficiaries who are well able to procure the service commercially and politely ask them to leave. He did not feel that it would be wise to set any actual rules about who can stay and who should leave at this stage. He felt to do this would hamper the work of emerging ccTLDs, who may wish to stay with the RIPE NCC for a while. Daniel was recently in Africa and made the point that the service offering currently still delivered good PR and political benefits. Lars-Johan accepted the points made, but warned against starting to expect any commercial service to be out of the reach financially of emerging ccTLDs. A pricing structure would have to take account of different customer needs. He felt it should not always be seen as a bad thing to force everyone into the same business model. It could work out. Daniel Karrenberg felt that “could” was not good enough here. DNS is seen by the world as the holy grail of communication and the RIPE NCC must avoid making any unpredictable moves. He advised that any changes would need careful consideration. Carsten Schiefner commented that if the RIPE NCC stopped serving secondary servers for ccTLDs, the ccTLDs would most likely then organise something amongst themselves. It would not follow that they would all want to start paying for a service and the problem as such would not go away. Jaap Akkerhuis wished to comment on why ns.eu.net ended up at the RIPE NCC. He recalled that at the time, it was down to a toss of the coin whether the service ended up with the RIPE NCC or SIDN. He added that he agreed with what was being suggested. He also observed that the larger ccTLD registries do indeed tend to arrange things amongst themselves. Jaap pointed out that, although he cannot speak for SIDN anymore, it always had been SIDN policy to help a limited number of ccTLD nameservers (up to around 20). As far as he knows, they still have room to do so. Antoin Verschuren of SIDN confirmed this to be the case. Joao Damas stated that he did not feel that the market would simply go away by the RIPE NCC making changes. He thought it would be wrong to get rid of a competent player in the field. As a DNS user, his primary concern remained stability. He feared that if the service was no longer offered free of charge, some operators might be tempted to look for the cheapest possible solution, which may not always be an optimal one. Lars-Johan understood Joao’s concerns. He felt that the only way towards a stable system in the end would be if economical drivers converged with the needs of the community. It was, he said, important that money be funnelled in the right way. Rob Blokzijl agreed with Lars-Johan. To reach stability, he felt a sudden switch off was not the answer. He agreed with many of the other points made by speakers. He did not think that the RIPE NCC taking any action would resolve what is essentially a business problem for Lars-Johan overnight. He cautioned against any sudden moves in the current climate. Politicians could see this as rocking the boat; there remains a level of ignorance about how the Internet works. It could lead some to point fingers at the RIPE NCC for ‘selling off’ a community service. Lars-Johan again agreed. His intent was not to stop this tomorrow. He wanted to ask if this was something that should now be considered. He agreed that simply stopping this cold was not the answer; he welcomed discussion for what was likely to be a ‘long term’ solution. Jim Reid rounded up the discussion. He pointed out that stability of the DNS system was vital, but added that we needed to be aware of the political dimensions pointed out by Daniel. On the other hand, this could be seen as the RIPE NCC potentially competing with its member’s interests. He put it to the room and nobody felt it a bad idea to work further on this. Daniel Karrenberg felt that the next step would be for Lars-Johan to put together a proposal to take into the NCC Services Working Group. J: DNSSEC in Sweden Jakob Schlyter – SUNIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dnssec-se.pdf There were no questions. K: Update to RIPE 203 – Recommendations for SOA Values Peter Koch – DENIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-ripe203.pdf Olaf Kolkman asked whether Peter thought it might be an idea to put fixed values or ranges with reasons as to why anyone might choose to sit on the higher or lower end. Peter Koch felt fixed values would avoid problems with poorly aligned intervals. Gerhard Winkler felt that the group should discuss MNAME in more detail. He thought it would be useful for people to see which secondary or slave loaded from which master. Maybe different MNAME fields for different masters would make sense. Peter felt this discussion would fit better on the IETF namedroppers mailing list: http://ops.ietf.org/lists/namedroppers/ The protocol does specifically state that there should be one unique Master Name server. The document is aimed at a very particular set of zones, it does not try to give a general condition or case for the MNAME field. It is constrained to smaller, stable zones. If Gerhard had proof that these zones tended to be loaded from different databases or sources, Peter would welcome any new text. He added that it was important to take into account if this would be relevant to the target audience of the document. Talking about ripe-203, Gerhard commented that a disclaimer might help in case anyone was using the document as an authoritative source of information. Peter Koch replied that he doubted anyone should use ripe-203 as a policy document, since the subject matter had a specific focus but was not ‘set in stone’. It should not be regarded as general technical advice. He wanted to see more discussion on the wording of the document through the mailing list and see the issue of MNAME taken to the namedroppers list. Mohsen Souissi said that having read the discussion on the mailing list, felt the document should state whether having an MNAME within a zone with an RFC1918 name was good or bad practice. He noticed that recent discussion through the DNS Working Group mailing list discouraged it. Peter Koch asked Mohsen to provide some specific text. There was nobody who disagreed with the need to update the document. L: ENUM DNS Predelegation Checks Peter Koch – DENIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-enum-predelegation.pdf Peter explained that have been a very small number of lame or stale delegations. This appears to be largely due to human error. Along with Carsten Schiefner (co-chair of the ENUM Working Group), Peter proposed that the predelegation checks currently applied to reverse mappings by the RIPE NCC before entering a delegation into the respective IN-ADDR.ARPA zone, be applied automatically to e164.arpa delegations. The proposal was universally accepted and Carsten will now draft some text and submit it to the RIPE PDP system. Andrei Robachevsky stated he felt that inconsistencies might have come about when further changes were applied to delegations. The child zone may not be aware that it needs to change something within the parent zone. It would also be worth looking at processes in place to avoid problems in the future. Carsten replied that it might be preferable if the RIPE NCC could perform ongoing checks. This should cover both the parent zone and child zones, either by using their own or third party tools such as Zonecheck. Andrei agreed that there were several ways to do this and that there were ways in which the quality of checks could be improved. Carsten emphasized that e164.arpa downwards delegation is important and there should be some mechanism in place to provide an early heads up if there could be an issue with a zone. Andrei agreed. Niall O’Reilly wished to add his support for the suggestions made by Andrei about periodic checking. Jim Reid asked if it was a good idea to also look into signing the e164.arpa delegations. AOB Carsten Strotmann told the group that over the past three weeks, he had received several customer enquiries about the Open Root Server Network System (ORNS). He wondered if anyone had opinions about whether customers should use it or not. The issue seems to have arisen from an article in CircleID by Paul Vixie where he states he favours ORNS over the IANA root network: http://www.circleid.com/article/1219_0_1_0_C/ Joao Damas of ISC stated that Paul was speaking in his own private capacity. His request to run one of ORSN servers has nothing to do with either ISC or the operation of the F-root server. Lars-Johan Liman, speaking as a maintainer of I-root, pointed out that there is an RFC (2826) maintained by the IAB on this subject. The RFC clearly states the need for a single root. It should leave nobody in doubt that it is a good thing. The single root is currently maintained by the IANA and he feels this works well. Daniel Karrenberg supported the comments made by Lars-Johan. He suggested that if a customer asks for this service, it would be wise to ask why. Do they want a root server that almost everyone uses or one that is used by just a few? Peter Koch pointed to another CircleID piece by Milton Mueller: http://www.circleid.com/article/1227_0_1_0_C/ The article tries to make the case for ORSN being simply an alternative root. ORSN claims that it is identical to the current root, up until the point where it decides to stop being identical. This is, he feels, a precise definition of an alternative root. Claiming it is a copy of the ICANN route is just incorrect. It could also have strange consequences for DNSSEC. Daniel Karrenberg concluded the discussion by stating that a choice has to be made about whom you trust to provide information and quality of service.

2 1