You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
58 |
Working Group: |
DNS |
Status: |
Final |
Revision Number: |
1 |
DNS Working Group Minutes
RIPE 58 - Amsterdam, the Netherlands
Session Chair: Peter Koch
Scribe: Adrian Bedford
Jabber: Wolfgang Nagele
120 Participants
A. Administrative Matters
Peter opened the meeting and dealt with administrative matters. He directed attendees to the WG home page and advised anyone who would like to send mail to the WG Chairs to use [email protected].
The minutes from RIPE 56 and 57 were approved without comment and the WG website pages updated to reflect this.
B. Action Item Walk Through
51.4 Choosing values in DNS SOA records for small and stable zones:
Peter is continuing work on ripe-203. He has collated some interesting feedback and he will incorporate this into the next version.
This is ongoing.
57.1 DLV for NCC maintained TAs:
The RIPE NCC will find out about the key signing keys for those zones managed by the RIPE NCC. Anand will report on this later in the session.
C. Reports
C.1: IETF Report - Peter Koch
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/dns-updates.pdf (file not available)
There are two working groups dealing with DNS (DNS Extensions and DNS Operations). There is also the IAB, which from time to time issues RFCs connected with the DNS: eg RFC 5507.
Stephane Bortzmeyer of AFNIC asked about possible future work on forgery resilience. Peter pointed to discussion about which of the many proposals to follow besides DNSSEC, but added that the WG has yet to make up its mind on which path to take.
C.2: ICANN/IANA Report - Rick Lamb, ICANN
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/icann-iana-update.pdf
There was a question about whether the ITAR would be signed. Rick pointed out the need to create a wider web of trust, as the ITAR is a signed root and should have high-level protection.
Jim Reid praised the work done on the ITAR and asked if there was yet any feedback from the consultation exercise run last year.
Rick confirmed that discussions were continuing; some of which remained confidential. However, based on public information, the progress made in various working groups and what emerged at the APRICOT meeting, he felt confident enough to suggest that the root would be signed by the end of 2009.
Jaap Akkerhuis pointed out that Paul Twomey had publicly pledged to have the root signed by December 2009.
There was a question about whether users would need to choose between DNSKEY or DS records. Rick clarified both would be valid.
Richard Barnes echoed the favourable feedback on the project and asked that the group stick to their plans upon decommissioning it. He felt we should rely on the ITAR as it creates a single model.
Richard questioned the use of a Godaddy CA for the beta ITAR. Rick stated that the choice came not so much out of any conscious decision. Godaddy met all security and operational requirements that were needed for the beta ITAR.
C.3: Report from the Trust Anchor Task Force - Peter Koch/Jim Reid
Jim had no presentation; instead, he gave a verbal update to the WG.
The TF needs to judge if the IANA ITAR delivers on expectations. There were insufficient people around at this meeting for the TF to meet, but hopefully this will happen at RIPE 59 in Lisbon.
C.4: Global DNS SSR - John Crain
This was a small working group/symposium formed to look at risk involved with the DNS that was not well documented. The main purpose of the group was to look at both known and so far unexplored risks. The focus was not solely on DNSSEC, though it became a focus.
The group found that risk awareness with DNS was very low outside of the expert community. There was also a lack of monitoring tools for DNS operators.
The group work lead to considerable useful networking and the report is now available at:
http://www.gtisc.gatech.edu/pdf/DNS_SSR_Symposium_Summary_Report.pdf
It remains unsure as to whether there will be a second such meeting until the purpose of any further work is defined. John encouraged all to read the report and work how out individuals and organisations can help with solutions, rather than see it as a set of problems.
There was a question from Edward Lewis over Jabber, asking about documented reports into damage caused by DNS attacks. John has seen nothing documented that DNSSEC would have resolved.
Keith Mitchell pointed to the ISOC/OARC incident ticketing system. It is under-used and he would welcome input into how to share notifications and coordinate responses.
There was a short discussion about how any future symposium might be planned in terms of the actual agenda and who the community is targeting.
In conclusion, John stressed that the symposium was experimental and there were few expectations.
C.5: BIND10 - Shane Kerr
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Kerr-BIND_10.pdf
Dmitry Burkov wished to offer sponsorship.
Jim Reid praised the idea though had concerns that sponsor needs might be given undue priority.
Shane stressed that the aim behind BIND10 is 'DNS for everyone' and noted it will meet all RFC standards. ISC projects are targeted at delivering public benefit. There is no question of only paying/donating sponsors driving any project to their own benefits to the detriment of community needs.
One of the goals for BIND10 is a proactive, open development process. ISC maintain public mailing lists and now have a technical writer on staff to help document the project and spread the word more widely.
All ideas about design and decisions along with rationale will be publicly available for discussion. The aim is to make the process very much community driven.
D. Update from the RIPE NCC - Anand Buddhev
Anand talked first about AP 57.1: The RIPE NCC supports signing of the root. They planned to upload their trust anchors into the ISC DLV but noted that this somehow happened without RIPE NCC knowledge. Contact has been made with ISC to investigate how this came about.
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Buddhdev-RIPE_NCC_DNS_Update.pdf
Some parts of the talk will be followed up in the NCC Services WG.
Wilfried Woeber wished to follow up on the slides regarding the overhaul of provisioning methods. He wished to get the draft solution proposal distributed to the DB WG. Wilfried stressed this was a chance for the community to provide input.
ACTION POINT 58.1: RIPE NCC to followup on the inclusion of RIPE NCC's TAs into ISC DLV
ACTION POINT 58.2: RIPE NCC to document the overhaul of provisioning methods to submit the Trust Anchors of zones signed by the RIPE NCC into ISC DLV. The draft solution to be distributed to the DB WG.
George Michaelson observed that given the different approaches used by sister RIRs, this might provide a chance to engineer some form of convergence.
Mohsen Souissi asked about the representation of IPv6 in Anand's figures. Anand offered to discuss this outside the session.
E. DNSSEC Update for CZ - JaromÌr TalÌr
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Talir-DNSSEC_in_CZ.pdf
Jim Reid praised the work and asked if the training materials were available in English. Jaromir said the courses are in Czech and aimed at local users. However it is possible to translate these and prepare documents for a wider audience.
Jaromir was asked about any problems faced by registrars. He said that on the whole, the process had been smooth with little difficulty reported.
A question was asked about the ease of moving between registrars where one supports DNSSEC and the other does not. Jaromir noted that on the whole this has not proven to be problematic. There are separate objects for keys and domains, so the transfer is straightforward.
Session Chair: Peter Koch
Scribe: Adrian Bedford
Jabber: Wolfgang Nagele
110 Participants
F. Lameness in Reverse DNS - Anand Buddhev
Anand was asked to make the template for the notification mails available, and he agreed to do so.
Picking up on Anand's comment that there is currently no tool available for users to check that they have corrected their lame delegations, Brett Carr of Nominet suggested the reverse delegation tools be used. Anand felt the tools had subtle differences that wouldn't make this possible. Brett suggested the tools be tweaked to achieve some level of convergence and Anand agreed this would be a good idea.
Anand was asked why the RIPE NCC engineered their own tools rather than reuse existing ones. Anand responded that the tool needed to carry out specific queries on the RIPE Database (e.g.: email contacts) that existing tools could not do.
Shane Kerr of ISC initiated a lively discussion about the future of the tool asking whether it ought to be the job of the RIPE NCC to constantly inform those responsible for lame delegations about the state of their DNS setups. He questioned the actual value to community and suggested that the metrics produced were weak and if the work was to continue would need considerable refinement. The metrics ought to examine the actual impact on users. He noted that with the RIPE NCC acting as parent for most of these domains it ought to be able to measure the number of domains 'lost' and give an estimate of how many users are impacted. He felt strongly that before any further work is done, the metrics be improved.
Bill Manning supported Shane feeling that the aim of the project was somewhat sterile and that the notifications might prove annoying. Users can, he noted, run their delegations however they choose.
Anand disagreed and could see little benefit from turning a blind eye to lameness in the DNS. He felt the community ought to strive for improvement. Bill questioned how the RIPE NCC defined improvement. Anand pointed out the RIPE NCC would take no action if people didn't make change, but the overall response he has picked up on was that the notifications were broadly welcome and pointed users could always choose to 'opt out' of the service.
Others in room who have worked with similar projects agreed that their user bases had found such information useful.
Olaf Kolkman backed Shane's concerns that maybe resources are not being used in the right way and that the real priority ought to be to judge impact. For this, he felt there was a need for stronger metrics.
Anand was asked if the lameness checks are only for the reverse tree. He confirmed this to be the case.
The discussion continued with some parties expressing support for the project based on their own experiences and others questioning whether the work ought to be curtailed. Time meant the discussion had to be cut short with an agreement that the RIPE NCC continue with their work, refining and tightening up metrics and report back at RIPE 59.
The discussion had to be cut short to bring things back on time, with a suggestion to continue with their work and do some analysis and report back next meeting.
ACTION POINT 58.3: RIPE NCC to evaluate feedback on Lameness Delegation checking and incorporate this into any future work. Report back at RIPE 59.
G. OpenDNSSEC - Patrik Wallstrˆm
Mohsen asked if there was anything to allow for dynamic updates or signing on the fly. Patrik said this wasn't currently available, though confirmed plans to take the tool in this direction.
Peter Koch asked about opportunities to tailor the tool to the needs of other registries. Patrik confirmed this should be possible under the BSD licence.
Speaking for NLNetLabs and acting as a development partner, Olaf Kolkman noted that the plan was to develop the ultimate DNSSEC signing tool: a piece of deployment trivial software that could act as a black box with an easy to use GUI. The presentation today was more to establish proof of concept.
Peter asked about project support and Olaf replied that it will happen, but at this stage it might be premature to commit to anything too specific.
Carsten Strotmann informed the group that Men and Mice are testing openDNSSEC integration with the aim of possibly providing commercial support.
Olaf stressed that the choice for a BSD licence was deliberate to encourage and support commercial buy-in.
H. Autotrust - An Implementation of RFC 5011 Style TA Update - Matthijs Mekking
There were no questions
I. Survey of Pre-delegation Checks - Joao Damas
Due to time constraints, Joao skipped to the questions at the end of his presentation.
Mohsen Souissi said AFNIC have been running ZoneCheck for some time for pre-delegation checks in .fr. A small group of users voiced concerns, but overall it was agreed that such checks have improved technical quality across the zone.
Joao asked if AFNIC supports the principle being applied at every level. Mohsen said he did.
There was support elsewhere in the room for the principle with Antoin Verschuren of SIDN sharing his experiences of running pre-delegation checks at .nl. He noted the only complaints came from those wishing to commercially register domain names. He added that although local policy ought to define what is actually checked, there needs to be uniformity about how the checks are done at each ccTLD.
Johan Ihren of Autonomica raised a note of caution when it came to what he called excessive domain checking. For all this, he did agree with the need for such checks, adding that he could support checks on delegations that are actually running. He stressed such checks ought to take priority over those not yet in operation. Pre-delegation checks do, by definition, check services on which people do not yet rely. He was unable to accept the concept of standardising checks across all ccTLDs.
Jim Reid agreed and pointed to the variety of policies and operational needs of different top-level operators.
Peter Koch spoke of pre-delegation checks running for some time at DENIC. These had seen general support from a majority of registrars. Like those before him, Peter felt unable to support standarisation in how these checks were done.
Peter moved discussion onto the checks run from the root zone, making it clear that there was a necessary policy difference because the root zone "registry" does not have the same attributes or requirements as those for a TLD.
Joao asked why DENIC had not insisted on carrying out the same checks across .net and Peter offered to look into this outside of the session.
Peter also asked about earlier IANA consultations on pre-delegation checks and questioned the lack of published feedback. Joe Abley of ICANN offered to look into whether the results of the IANA consultation could be made public. He added that the IANA carries out a range of technical checks but none of these currently result in communication back to the operator.
J. DNS Root Zone Scaling - Johan Ihren
Joao Damas asked about the unbound growth situation and how it differs between the root and .com. Johan replied that from a technical point of view, there was no difference. The consequences for the work were more
noticeable.
Jim Reid wanted to ask if the WG could participate or give input into the scaling issue to either ICANN or the group working on it presently. Johan was unaware of any way for this to happen since his area of work is purely technical and there is little crossover to policy forums. Johan did, however, single out the RIPE Task Force mechanism on dealing with the TAR signing post RIPE 54 as an excellent model.
K. Plenary Follow-up Discussion
This was cancelled due to time restraints
Y. Action Item Summary
57.1 - Ongoing
58.1: RIPE NCC to followup on the inclusion of RIPE NCC's TAs into ISC DLV
58.2: RIPE NCC to document the overhaul of provisioning methods to submit the Trust Anchors of zones signed by the RIPE NCC into ISC DLV. The draft solution to be distributed to the DB WG.
58.3: RIPE NCC to evaluate feedback on Lameness Delegation checking and incorporate this into any future work. Report back at RIPE 59.
Z. A.O.B.