Dear WG, please find below the draft minutes of last week's two DNS WG sessions. Thanks to Susannah for being the Jabber Proxy and to Adrian for the fast delivery of the minutes. All errors are still mine. There were no new action items generated for the DNS WG last week, but a couple of old ones made progress or were closed, in some cases pending mailing list approval. Please expect some 'last calls' soon. Please review the minutes, especially if you are quoted by name. The deadline for this first round is October, 30th. Thanks! -Peter ----------------------------------------------------------------------------- D R A F T [1] RIPE DNS WG minutes for RIPE 53, Amsterdam ----------------------------------------------------------------------------- WG: DNS Meeting: RIPE 53, Istanbul Date-1: Wednesday, 4 October 2006 Time-1: 16:00 - 17:00 (UTC +0200) Chair-1: Peter Koch Minutes-1: Adrian Bedford Jabber: xmpp:dns@conference.ripe.net J-Scribe-1: Susannah Gray J-Script-1: TBD Audio-1: TBD WG URL: http://www.ripe.net/ripe/wg/dns/ Material-1: http://www.ripe.net/ripe/meetings/ripe-53/presentations/wednesday.html Agenda: http://www.ripe.net/ripe/meetings/ripe-53/agendas/dns.html ----------------------------------------------------------------------------- A. Administrative Matters - Working Group Chairs <http://www.ripe.net/ripe/meetings/ripe-53/presentations/dns_agenda1.pdf> Appointment of scribe -- Adrian Bedford (RIPE NCC) Jabber monitor -- Susannah Gray (RIPE NCC) Agenda bashing -- no changes ----------------------------------------------------------------------------- B. Status Reports - Working Group Chairs IETF, DNSEXT, DNSOP and others (Olaf Kolkman, NLNet Labs) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/dns_wg_update.pdf> Questions: Ole Jacobsen asked about the team set up to discuss operational aspects of DNS security. Although the aim of the team was to lead the rapid deployment of the technology, little has been heard since it inception almost two years ago. Olaf replied that the DNSSEC deployment initiative led by Steve Crocker is essentially a web-based forum. There is a move to involve more people. It certainly remains a good place to go to find information or help with the deployment of DNSSEC in any organisation. In terms of results, Olaf feels there is much going on behind the scenes. He clarified that there is no formal liaison between the forum and the IETF. ICANN/IANA Update (John Crain, ICANN) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/icann_dns_wg.pdf> Questions: Rob Blokzijl asked why there was a move to retire old ccTLDs. He could see no technical reason to do this. John agreed that there was no compelling reason. He added that the question remained about whether this should be done. Rob pointed out that current guidelines preclude reuse of ISO3166 country codes for a period of five years. New guidelines will change this to 50 years. Carsten Schiefner commented that .cs was reused recently. Previously it was the code for Czechoslovakia; it was then used for Serbia and Montenegro. CENTR (Marcos Sanz, DENIC) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/centr.pdf> Questions: Peter Koch asked if interested operators might be able to present at the normally closed CENTR meetings. Marco said that active participation in the meetings was encouraged, provided there was not a confidential matter under discussion. ----------------------------------------------------------------------------- C. Action Items Review (Working Group Chairs) The action list for the working group was reviewed. <http://www.ripe.net/ripe/wg/dns/dns-actions.html> 48.1 Peter Koch has written this up in an Internet draft. <http://www.ietf.org/internet-drafts/draft-koch-dns-unsolicited-queries-00.txt> [[Ongoing]] 48.2 Mans Nilsson -- TSIG/SIG(0) for ns.ripe.net [[Ongoing]] 48.4 David Malone -- AAAA misbehavior. <http://www.ripe.net/ripe/meetings/ripe-53/presentations/aaa.pdf> Dave Wilson gave a short presentation on the issue on behalf of Dave Malone. The document has been written and circulated to the list. There is a question about whether this document would just repeat work done elsewhere in the Internet Protocol Journal. After a show of hands, it was decided to mark the item done and regard the IPJ article as the authoritative source. [[Done, pending mailing list approval]] 49.1 Peter Koch -- DNS Hostcount successor requirements Peter is to discuss this with RIPE NCC staff. [[Ongoing]] 49.2 Jim Reid -- Server Migration Document A document will go to the review panel after this meeting and be circulated through the working group mailing list. Hopefully, this can be marked as completed in time for RIPE 54. [[Ongoing]] 51.1 RIPE NCC -- K-Root anycast measurement The publication of the report from the RIPE NCC is nearing publication. After this happens, the working group will then need to decide whether to ask the RIPE NCC to look into other types of measurement. [[Ongoing, draft RIPE document to be last called]] 51.3 Lars-Johan Liman -- NCC Secondary Service Policy Lars commented that the RIPE NCC has announced it will limit involvement in provision of slave servers for TLDs. Lars suggested this be closed for now and marked as overtaken by events. The working group agreed. [[Done, pending mailing list approval]] 51.4 Peter Koch -- ripe-203 Update [[Ongoing]] Brett Carr gave an update on the various outstanding actions on the RIPE NCC <http://www.ripe.net/ripe/meetings/ripe-53/presentations/ncc_dnswg_update.pdf> 52.1 Report into the causes for extra DNSSEC network traffic. [[Ongoing]] 52.2 Report numbers of signed zones and delegations in reverse tree Jim suggested this be considered closed, but ask the RIPE NCC to give regular updates once or twice a year. As a result, this will remain a standing item on the working group agenda. [[Done]] Questions: Max Tulyev asked why there are so few DNSSEC delegations. Brett replied that the answer for this would lie with the community. He agreed with comments from Max that people need to understand the benefits and that implementation is easy. 52.3 Lame delegation proposal WG Last call to be issued, chairs to discuss and declare consensus [[Ongoing]] 52.4 Automate and streamline ENUM delegation process. [[Done]] 52.5 Carsten Schiefner -- Proposal for regular lameness checks in e164.arpa Carsten has reported on this in the ENUM working group. They will come up with a task force to take this work forward and report at RIPE 54. Carsten suggests that the DNS working group mark this action as closed. [[Done]] ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- Date-2: Thursday, 5 October 2006 Time-2: 11:00 - 12:30 (UTC +0200) Chair-2: Jim Reid Minutes-2: Adrian Bedford J-Scribe-2: Susannah Gray WG URL: http://www.ripe.net/ripe/wg/dns/ Material-2: http://www.ripe.net/ripe/meetings/ripe-53/presentations/thursday.html J-Script-2: TBD Audio-2: TBD ----------------------------------------------------------------------------- D. Plenary Follow Up (Working Group Chairs) There was a discussion around the issues raised by Duane Wessels on problems with DNS and Steve Gibbard on DNS Infrastructure Distribution. Jim Reid commented that much of what Duane had said was reasonably valid and much was already good practice, such separating out authoritative and caching-only nameservers and issues surrounding lameness. Jim however did take exception to was the talk of using TCP-based DNS queries. He pointed out that most DNS clients will make a single DNS lookup before taking any action. Using TCP for this seemed somewhat inefficient, considering the small amounts of data that are being transferred. It would also add to latency. A high latency, low bandwidth network or one with a busy nameserver might find handling short-lived TCP connections painful. Olaf Kolkman mentioned that he had heard that under a DoS attack, an operator had first sent back a result with a TC-bit leading to a re-test on TCP, after this the UDP source was white listed. Duane confirmed that there is a company producing software that can create a white list in this way. Replying to Jim's concerns about using TCP on busy servers, he stated that there are applications that can handle large volumes of queries each second. He also agreed that maintaining state for TCP would be painful. Lars Liman asked Duane to clarify if he thought TCP should be a preferred transport. Duane said that he did suggest this. Lars voiced the general mood that high TCP loads would be painful for a server. Duane commented that it would still be preferable to a DDos attack. Lars clarified that he was not against using TCP, but felt unable to advocate using it as his preferred mode of transport. The first defence against a DDos attack would be to rate limit the traffic in his upstream router. Ed Lewis favoured the expansion of DNS beyond its use in root servers; it is a quick reacting database. Recommending using TCP as a default way of contacting DNS goes against its very nature. He also recognises that the way UDP uses DNS manifests considerable problems, which is perhaps why Duane sees TCP as the best way to go. Ed felt the group should first look at the UDP problem in terms of operational practices, buffers and the brakes put on its use. The working group might like to look into suggestions for time-outs and back-offs, maintaining statistics about efficient routing and so on. Jim concurred that this was a good point. There was a short discussion about whether the DNS Working Group is the right arena for such investigation. Jim suggested that it might be worth the working group gathering information about the work done by various parties and put them into a single document identifying key elements of operational best current practice. Lars asked if anyone had previously measured the difference between DNS over UDP and DNS locked down to TCP. It would appear that little specific work has been done already in this area. Peter Koch commented that creating a RIPE Document or bibliography style web page containing links to the various best common practices within DNS operation is not a bad idea. Lars pointed out that an operator facing a problem might not first think of looking at the RIPE Document Store for information about how to resolve his problems. Keith Mitchell commented that a project to address this was under way with ORAC. Lars Liman suggested that this might be well incorporated into a conventional book. ----------------------------------------------------------------------------- E. Software Update (Joao Damas, ISC) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/software_update.pdf> There was a short discussion after Peter Koch asked who in the room was already using BIND 9.4 and had found issues with how it handles zones. It was clear this needed some attention, introduction of checks on sibling glue seems to have caused some problems. Joao replied that there is no solution as yet. The change simply produces warnings, although it can produce many of these depending on the zone in question. He pointed out that it is possible to disable that check. Jim asks about the new resolver library. He wanted know if this now meant that the lightweight resolver library (LWRES) was to be phased out. He asked if anyone was using LWRES. Joao said it was impossible to say. ----------------------------------------------------------------------------- F. PowerDNS Update (PowerDNS Recursor) (Bert Hubert, PowerDNS/Netherlabs) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/powerdns_update.pdf> Tomas Simonaitis asked if PowerDNS was scalable. Bert replied it can scale as each instance operates independently and does not communicate with another. They do not share a cache. There is a chance that in the future, PowerDNS will look at cache sharing. Roy Arends asked if dnsreplay, dnsstat and dnsscope are publicly available. Bert confirmed that they were all in the PowerDNS repository. Roy asked if the recursor also dealt with unknown records. Bert said that it did. ----------------------------------------------------------------------------- G. OARC Update (Keith Mitchell, ISC) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/oarc_update.pdf> Lars Liman commented that it was important to be aware of problems with protecting privacy laws when researching DNS data. There are some nations that impose far stricter rules on how such data can be used than others do. Keith replied that the OARC secretariat is aware of these rules and the various regulations around data protection. ----------------------------------------------------------------------------- H. CADR (Bill Manning) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/caadr_update.pdf> After the presentation, Bill did a demonstration using live data. There were no questions on the presentation. Geoff Huston asked if the web interface was necessary to do the work. Bill replied that this was necessary to ensure any updates were made correctly. Ed Lewis asked how do I find all the other delegations to change when changing glue records. Bill replied that it did not really matter as changes did not need to be synchronized between all of them. The child would change the list. Host records are equivalent in peering terms, to a registry or delegation. To change the attributes for a record, it is necessary to log in as an administrator and change the glue records. Ed felt that although the application demonstrated by Bill was useful, it might not suit all registries due to the different issues each faced. Bill agreed that not everything should be run the same way throughout the DNS. Peter Koch wondered if it might be better to feed the glue from the data that has been verified through DNSSEC, rather than from host registrations. Bill agreed that it would and that it should work in 98% of cases. Jim Reid mentioned Keyman used by .se. He wondered if CADR could be used in the .se environment. Bill felt Lars could answer better on this. Lars gave his personal opinion on this. There is a fundamental difference between CADR and Keyman models. The difference lies in authorisation. Keyman is based on individual generating a certificate that has to be signed by a selected group of CAs. The certificate is installed into a browser that then handles authentication. Although both models pick up their data from live DNS, CADR relies on DNS signatures. Bill clarified that the CADR web interface relied on user ID and password authentication. Anyone could request the change, but if it was not visible in the nameservers, then nothing would happen. ----------------------------------------------------------------------------- X. I/O with other WGs Already dealt with under action item 52.5. ----------------------------------------------------------------------------- Y. AOB No other items were raised. ----------------------------------------------------------------------------- Z. Wrap Up and Close -----------------------------------------------------------------------------