- dns-wg - mailman.ripe.net

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

Announcement DNS for LIRs Training Courses
by RIPE NCC Training Services 31 Oct '06

31 Oct '06

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Friday 26 January 2007 Time: 09:00-17:00 Location: Ljubljana, Slovenia And Date: Friday 9 March 2007 Time: 09:00-17:00 Location: Edinburgh, United Kingdom And Date: Friday 30 March 2007 Time: 09:00-17:00 Location: Lisbon, Portugal 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

Action Item 48.4 (AAAA anomalies) Last Call
by Peter Koch 30 Oct '06

30 Oct '06

Dear WG, action item 48.4 reads <http://www.ripe.net/ripe/wg/dns/dns-actions.html>: Write up a draft RIPE Document summarising the observations made regarding AAAA resolution problems. Circulate to the list, initiate discussion what to do, i.e. who to approach with the list of errors/problems seen. After the presentation given by Dave Wilson (stepping in for David Malone) <http://www.ripe.net/ripe/meetings/ripe-53/presentations/aaa.pdf>, and also judging from the previous discussion, the majority of the wg seemed to agree that a separate RIPE document would not be necessary. David had already published his findings in the publicly accessible Cisco IPJ, volume 8.1 <http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-1/ipj_8-1.…> The wg chairs would like to thank David and Dave for their work and contributions and propose this AI be considered done. If you disagree, please speak up until October, 27th, preferrably with identification of any issue(s) you feel still need to be addressed. My understanding is that David is happy to continue his monitoring efforts, but as far as the WG is considered, the goal of raising awareness has been achieved. -Peter PS: Silence will be taken as consent.

1 1

DNS WG Action Items 52.2 and 52.4 closed
by Peter Koch 12 Oct '06

12 Oct '06

Dear WG, action items 52.2 and 52.4 <http://www.ripe.net/ripe/wg/dns/dns-actions.html> will now be marked "done": 52.2 RIPE NCC Report number of signed zones and signed delegations in the reverse tree. Addressed in the thread starting at <http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00151.html> as well as the presentation given at RIPE 53 <http://www.ripe.net/ripe/meetings/ripe-53/presentations/ncc_dnswg_update.pdf> The NCC agreed to continue collecting and reporting of statistics. 52.4 RIPE NCC Automate and streamline the process for ENUM delegations, including checks similar to those applied to the reverse tree. Reported in <http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00141.html> Action item 52.1 {Investigate causes for extra DNSSEC network traffic (in excess of the predicted growth) and extra CPU cycles} requires further investigation and is therefore "ongoing". -Peter

1 0

DRAFT DNS WG Agenda for RIPE 53
by Peter Koch 02 Oct '06

02 Oct '06

Dear WG, here's the draft agenda for next week's Wed and Thu. -Peter

1 2

2005-02 implementation: IP assignments for anycasting DNS
by leo vegoda 26 Sep '06

26 Sep '06

Dear Colleagues, We are pleased to announce that we will be able to accept e-mailed requests for assignments for anycasting DNS servers from 2 October 2006. The request form and supporting notes will be available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/internet-registries.html We will make a separate announcement when it is possible to make requests via the LIR Portal. Assignments for anycasting DNS will come from reserved blocks: * IPv4 Anycast Assignments (/24) from 194.0.0.0/18 * IPv6 Anycast Assignments (/48) from 2001:0678::/29 You may want to update your filters. Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Lameness Checking Proposal
by Brett Carr 25 Sep '06

25 Sep '06

Dear Colleagues At RIPE 52, the RIPE NCC presented figures on the levels of lame DNS in the reverse tree within its service region. We were asked to propose a procedure for checking and reporting on the level of lameness. We sent a proposal to the DNS Working Group and received some comments. We have incorporated this feedback into a draft RIPE Document that you can find at: http://www.ripe.net/ripe/draft-documents/dns-lameness.html We will include this in a DNS presentation at the upcoming RIPE Meeting in Amsterdam. We welcome your comments and suggestions. Regards -- 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

DNS Lameness Checking Proposal
by Brett Carr 22 Sep '06

22 Sep '06

As per the dns-wg Action point 52.3 from RIPE 52 "post questions and proposal to wg mailing list on how to deal with lame delegations when either the NCC is responsible for maintaining the parent or for running a (secondary) server for the child that is or is about to become delegated lame due to an unavailable *xfr source." Please find attached "dnslamecheckAug2006.txt" a proposal on how the RIPE NCC should test for lameness and what the resulting actions could be. Your feedback and discussion on this proposal is welcomed. 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

3 4

dnssec statistics action point 52.2
by Brett Carr 19 Sep '06

19 Sep '06

At the RIPE 52 meeting, the DNS Working Group asked us to provide statistics on secured delegations within RIPE NCC hosted zones. At the time of this e-mail, the figures are as follows: Total number of zones hosted as a primary by RIPE NCC - 113 Total number of primary zones that are signed - 72 Total number of NS records in all zones - 521,811 Total number of DS records in all zones - 61 We are of course happy to answer any questions about these numbers. Background Information: The RIPE NCC hosts the majority of the 41 unsigned zones on behalf of third parties. We can and will continue to expand the list of signed zones. The current keys for all zones that we sign are available at: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt We accept signed delegations (DS records) for all in-addr.arpa zones where we are primary. We cannot currently accept signed delegations (DS records) for those zones in ERX space, where we are not primary for the zone. The two graphs attached to this e-mail show the distribution of both NS and DS records. 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

3 3