November 2006 - dns-wg - mailman.ripe.net

Last Call: Lameness Checking Proposal (AI 52.3)
by Peter Koch 04 Dec '06

04 Dec '06

Dear DNS WG, with reference to <http://www.ripe.net/ripe/wg/dns/dns-actions.html> action item 52.3, the NCC has drafted a proposal for lame delegation checks, that was sent to the WG's list in September: <http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00157.html> Some refinements have been made and the proposal's current status is available at <http://www.ripe.net/ripe/draft-documents/dns-lameness.html>. In accordance with the minutes of our RIPE 53 meeting, this starts a Last Call ending Monday, 2006-12-11 12:00 UTC. Please send comments to this list. -Peter

1 1

Maintenance Announcement
by Brett Carr 28 Nov '06

28 Nov '06

[Apologies for duplicates] Dear Colleagues, On 30 November 2006, authoritative Reverse DNS Services on ns-pri.ripe.net will be unavailable between 09:00 and 10:00 UTC. During this time we need to carry out important server maintenance work. We apologise in advance for any inconvenience. If you have any questions or concerns about this, please send an e-mail to dns-help(a)ripe.net. Regards, -- Brett Carr Ripe Network Coordination Centre Manager -- DNS Services Group Singel 258 Amsterdam NL GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8

1 0

New RIPE Document available: RIPE-393
by RIPE NCC Document Announcement Service 21 Nov '06

21 Nov '06

New RIPE Document Announcement -------------------------------------- A new RIPE Document is available from the RIPE Document store. Ref: ripe-393 Title: Evaluating the Effects of Anycast on DNS Root Nameservers Author: Lorenzo Colitti,Erik Romijn, Henk Uijterwaal & Andrei Robachevsky Format: PDF= 2,871,296 Date: October 2006 Obsoleted by: Obsoletes: Updates: Updated by: This document is the result of a DNS WG action on the RIPE NCC. Accessing the RIPE Document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ripe-393.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. Kind Regards, RIPE NCC Document Announcement Service

2 2

Last Call on 51.3 "ns*.ripe.net secondary service policy"
by Peter Koch 21 Nov '06

21 Nov '06

Dear WG, regarding action item 51.3 <http://www.ripe.net/ripe/wg/dns/dns-actions.html>, Lars-Johan Liman Draft a proposal on the future of the RIPE NCC Secondary DNS Service. To be dealt with on cooperation with the NCC Services WG. the NCC announced in June <http://www.ripe.net/news/review-secondary-dns.html> a change in the eligibility criteria. During the recent meeting in Amsterdam, Liman suggested that the action item was 'overtaken by events' and should be considered closed (marked 'done'). The room unanimously agreed, so I'd like to ask for confirmation of this suggestion here. If you disagree with closing 51.3, please speak up until 2006-11-17, ideally providing specific suggestions at the same time. Thanks, Peter

2 2

Last Call: DNS WG meeting minutes for RIPE 53
by Peter Koch 21 Nov '06

21 Nov '06

Dear WG, there were minor remarks to the draft meeting minutes which were addressed in the second draft posted on October, 25th in <http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00173.html> and made available under <http://www.ripe.net/ripe/wg/dns/r53-minutes.html>. This is the real Last Call for comments on the minutes, to end in two weeks, Wed 2006-11-15 23:59 UTC. Thanks, Peter

1 1

Maintenance Announcement
by Brett Carr 07 Nov '06

07 Nov '06

[Apologies for duplicates] Dear Colleagues, On 9 November 2006, authoritative Reverse DNS Services on ns.ripe.net will be unavailable between 10:00 and 11:00 UTC. During this time we need to carry out important server maintenance work. We apologise in advance for any inconvenience. If you have any questions or concerns about this, please send an e-mail to dns(a)ripe.net. Regards, -- Brett Carr Ripe Network Coordination Centre Manager -- DNS Services Group Singel 258 Amsterdam NL GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8

1 0

ns.ripe.net missing NS records
by Christian Storch 03 Nov '06

03 Nov '06

Hi, is there any reason for ns.ripe.net missing NS records of /24 reverse zones out of /16 reverse zones? Anyway we've a problem resolving ip addresses out of a couple of /16 reverse zones when asking ns.ripe.net as one of the secondaries for such a zone. Any thoughts or hints? Thanks, Christian

2 3

Re: >>: Re: [dns-wg] retiring old ccTLDs
by Max Tulyev 02 Nov '06

02 Nov '06

Hi Dmitry! Yeah, I see the big difference and using double-standards about two domains SU/EU are both not in ISO list :( But hope we can help to move it right way ;) Dmitriy V Menzulskiy wrote: > > Hi Max ! Hi everybody ! > > Now I understand: people who want to destroy Soviet Union - they still > want to destroy it comletely :-((( > > Maybe, it's time to start CIS TLD ? > > WBR, > > Dmitry Menzulskiy > > ----- Переслано: Dmitriy V Menzulskiy/BeeLine дата: 02.11.2006 13:39 ----- > > dns-wg-admin(a)ripe.net написано 02.11.2006 13:30:47: > >> On Thu, 2006-11-02 at 11:34 +0300, Max Tulyev wrote: >> > Doug Barton wrote: >> > >> This domain grows even it have huge price ( >> > >> http://www.nic.ru/en/index.html ). So people really need it. >> > > >> > > A) Wanting something is not the same as needing it. >> > >> > The magic is who decides what I need and what I don't need. >> >> That you _prefer_ .su doesn't mean that the TLDs it's been split into >> can't meet your _needs_. >> >> preferences != needs >> >> > >> > > B) My feeling is that what you're saying here (substantial >> > > registration growth in spite of the high price) speaks more to the >> > > motivations of the SU operators for maintaining their domain than it >> > > does for the necessity of keeping it in the root. >> > >> > Nobody push people to buy .SU domains. Only issue they do it - they need >> > it. Am I wrong? >> > >> >> Are anybody pushing people to avoid .su? I.e. how much effort are >> the .su-maintainers putting into convincing people to use the individual >> ccTLDs instead? ;-) >> >> >> >> -- >> >> >> Per Heldal - http://heldal.eml.cc/ >> -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 4

DRAFT RIPE 53 DNS WG minutes
by Peter Koch 02 Nov '06

02 Nov '06

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.t…> [[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 -----------------------------------------------------------------------------

16 35