From pk at DENIC.DE Mon Mar 3 17:59:25 2008 From: pk at DENIC.DE (Peter Koch) Date: Mon, 3 Mar 2008 17:59:25 +0100 Subject: [dns-wg] Draft RIPE 55 DNS WG Meeting Minutes Message-ID: <20080303165925.GI28133@x27.adm.denic.de> 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 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 -------------- next part -------------- RIPE 55 Amsterdam DNS Working Group Session 1. (24 October 2007) Session 2. (25 October 2007) Session 1 Date: Wednesday, 24 October 2007 Time: 14:00 - 15:30 (UTC +0200) Chair: Jaap Akkerhuis Minutes: Adrian Bedford J-Scribe: Caz Merrison A. Administrative Matters * Welcome * Select a scribe * Finalise agenda B. Review of Action Items * 49.2 DNS Server Migration Documents - Jim Reid This action point from RIPE 49 was to update an earlier document produced by Fernando Garcia. A small group had been formed to discuss this and although there was some useful comment, little progress was made. Jim has already posted an updated version of the document to the working group mailing list. After initial comments, there has been no follow up. Jim suggested allowing further discussion over the coming weeks. He will work with his co-chairs to summarise the discussions and formulate a new RIPE Document. Jim will keep the working group updated through the mailing list. There was no objection, work is ongoing. * 51.4 Update on ripe-203 Discussion - Peter Koch - pdf [ 31 KB ] This action point dates from RIPE 51. Peter circulated a new draft document to the WG mailing list on 24 October. His presentation summarized the background and ways to move forward. http://www.ripe.net/meetings/ripe-55/presentations/koch-ripe203bis.pdf There was some input from the room although discussion is to mainly take place on the WG mailing list. The main points made were: It is possibly worth looking at what was recommended when the RIPE NCC developed its delegation checking tool. Delchecker: for example negative TTL. It was noted that some users fail to correctly format e-mail addresses, often forgetting to escape parts of them. It may be worth making an explicit mention of this in any future draft of the document. A question was asked about whether it is safe to always assume that the email address encoded in the MNAME field should be reachable over the Internet. One participant expressed the opinion that if explicit notify lists are to be used for a zone, having an absent MNAME in the form of a dot should be seen as legitimate. Time restraints meant that the discussion was curtailed, but will continue on line through the working group mailing list. C. Update from the RIPE NCC - Andrei Robachevsky http://www.ripe.net/ripe/meetings/ripe-55/presentations/robachevsky-dns-update.pdf During the presentation, Jim Reid asked about the RIPE NCC's ongoing Secondary DNS Service, pointing out that it is still being supplied to a number of domains where a commercial alternative is now available. For domains that can get this service elsewhere, it was agreed that the RIPE NCC would continue dialogue to back gracefully out where possible. Following Andrei's presentation, there was a question about why the number of signed zones had decreased since RIPE 54. He explained that this was because some test zones were created for that meeting and have since been cleaned up. The RIPE NCC has not actually stopped signing any zones. D. IETF Working Group News Update - Antoin Verschuren http://www.ripe.net/meetings/ripe-55/presentations/verschuren-ietf-update.pdf There were no questions. E. Leftover Items from Plenary Session This part of the agenda was left for any potential items that were left from the plenary. The matter of progress on the letter sent to ICANN to request signing of the root zone (initially mooted at RIPE 54) was mentioned. There had been no report following the letter sent from the RIPE community. David Conrad from ICANN was in the room and was able to confirm that IANA was almost ready technically to sign the root, .arpa, .int and others. Politics tend to get involved whenever changes are proposed for the root zone. Signing .arpa was being held up by the work involved in finding a suitable range of secondaries for the .arpa zone. He agreed to push for a response to the RIPE community approach. Patrick Faltstrom announced that the Internet community in Sweden, backed by the Swedish government, would shortly sign a note and send it to ICANN to support the signing of the root zone. F. DNSSEC Key Repository Task Force - Jim Reid http://www.ripe.net/ripe/meetings/ripe-55/presentations/reid-taskforce-report.pdf Jim asked the working group to say whether they agreed with the proposal for work suggested by the Task Force. The overall consensus was that the task force should ask the RIPE NCC to come up with high-level specs for the service, taking into account the requirements identified by task force members. A requirements document will be circulated to the working group mailing list. One thing that the RIPE NCC was keen to stress is that this offering would not compete with other services and that it would have a clear exit strategy. Although there was some discussion of specific details, Jim stressed that this was not the time to start thrashing out specifics. He noted that discussion should continue on dedicated mailing lists, given the time restraints of the working group session. Minutes from the task force session at RIPE 55 are already available in an on line archive. Jim will take this forward. G. New DNS Technologies in the LAN - Carsten Strotmann There were no questions. Session 2 Date: Thursday, 25 October 2007 Time: 09:00 - 10:30 (UTC +0200) Chair: Peter Koch Minutes: Adrian Bedford J-Scribe: Rob Allen H. Community DNS - Paul Kane http://www.ripe.net/ripe/meetings/ripe-55/presentations/kane-community-dns.pdf There was a question asked about CommunityDNS having a copy of F-root. Paul confirmed that the root server had been cloned to allow for stable testing. OARC Update - Keith Mitchell http://www.ripe.net/ripe/meetings/ripe-55/presentations/mitchell-oarc-update.pdf After the presentation, it was noted that version 1.0 of DNSCAP is now uploaded and available. K. BIND-DLZ - Experience Providing DNS Services - Lars-Goeran Forsberg http://www.ripe.net/ripe/meetings/ripe-55/presentations/forsberg-bind-dlz-experience.pdf Following the presentation, there was a discussion about how BIND-DLZ compares with core DNS, seeing as it operates with all servers running as masters with no back-up slaves. Lars-Goeran replied that it offers neither advantages nor disadvantages over a more traditional set-up, but that it would be easy to subsequently use anycasting. There are also no dependencies on connectivity between servers. When asked about running a hidden master with a hidden DLZ front end, Lars-Goeran noted that he could think of no problems with running such a configuration, but that the set-up he advocates works well for systems that require frequent bulk provisioning updates. In answer to a question about the use of relational databases, Lars-Goeran clarified that MySQL is not a part of BIND-DLZ, it is used for provisioning due to its ease of set-up. It was suggested that having so few variations across the board might have disadvantages. For example, if a bug occurs, it could impact the entire set-up; Lars-Goeran agreed that this was a valid point and noted that plans were already advanced for any future installations to use a range of servers, some having different firmware versions or operating systems and to provide an alternative DNS server to act as back-up for zone transfers. There was a question about figures given in the presentation comparing BIND-DLZ with other DNS Servers. Lars-Goeran explained that the comparisons were done against published benchmarks. Finally Lars-Goeran was asked about the motivation for using BIND-DLZ. He explained that the system was chosen for its capacity to hold records for many customers without the need to reload every few minutes. L. Using IPv6 Name Servers in the Registration Process - Ruri Hiromi http://www.ripe.net/ripe/meetings/ripe-55/presentations/hiromi-ipv6-name-tree.pdf There was a short discussion where the focus was on the ongoing lack of support for running name servers on v6. A show of hands suggested that around 20 people in the room were running v6, including half a dozen TLD operators. Most had found little problem injecting glue records. Even where connectivity appears to be a problem, some v6 queries are being made, suggesting that they are not completely blocked. Registrar awareness needs attention. It was noted that registrars and registries need to work together and understand where the obligations of each lie. There will continue to be problems with service delivery, glue and testing reachability in v6 where a lack of connectivity gets in the way. It places a registrar in a difficult position when trying to register v6 glue that cannot subsequently be reached for testing. Ruri confirmed that she finds she faces what marketing departments call "a lack of take up". She stressed that DNS is a social infrastructure that needs to prepare better for v6 environments. The discussion ended with an offer to Ruri from the Czech domain for registration within v6. M. Implementing DNSSEC for .JP- Kentaro Mori It was noted that the work was extremely valuable. A question was asked about whether the source code would be made public. Kentaro said that he hopes to make it available as open source, though doing so will depend upon his employer. Olaf suggested the most useful place to make this available would be the dnssec.net portal. Z. A.O.B. Olaf Kolkman of NLnetLabs asked for volunteers to join a small test group for Unbound: a recursive caching name server and DNSSEC validator. Volunteers should contact Olaf (olaf at nlnetlabs.nl) or Wouter (wouter at nlnetlabs.nl). A presentation on Unbound is promised for RIPE 56. ------ From dave at corecom.com Mon Mar 24 16:22:37 2008 From: dave at corecom.com (Dave Piscitello) Date: Mon, 24 Mar 2008 11:22:37 -0400 Subject: [dnssec-deployment] [dns-wg] Re: .SE releases report on consumer broadband routers In-Reply-To: References: <20080226100631.GB3828@vic20.blipp.com> <20080226101854.GA15743@nic.fr> Message-ID: <47E7C73D.6080503@corecom.com> 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 . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dave.vcf Type: text/x-vcard Size: 220 bytes Desc: not available URL: