RIPE 59

RIPE 59 Lisbon
DNS Working Group

Session 1

Date:Thursday, 8 October 2009
Time: 11:00 - 12:30
Chair: Jim Reid
Minutes: Emile Aben
Jabber: Mark Dranse

A. Administrative Matters

B. Matters arising from RIPE 58 minutes

Jim Reid apologised for late posting of RIPE 58 meeting minutes.

C. Review of Action Items

Action Items:

57.1 & 58.1 NCC's KSKs and DLV

RIPE NCC had been asked to give an update and some background on NCC KSKs in DLV. This would be covered during the RIPE NCC report in the WG's afternoon session.

58.2 Review provisioning methods in reverse tree

Child objects for reverse zones in the RIPE database were causing confusion. Since the parent zone was already provisioned objects for the child zone would have no effect which was confusing. The NCC database group is working to clean this up.

58.3 Feedback on lame delegations

Research into the lame delegation project will be presented by Shane Kerr (ISC) later in the agenda.

Older Action Items:

54.7 rev-srv in inetnum objects

After the introduction of domain objects for the reverse tree the rev-srv attributes in the inetnum objects didn't have any use. The RIPE NCC database group has converted the rev-srv attributes into remarks. This Action Item can now be closed.

57.2 forward domain objects:

The WG raised this issue at the Dubai meeting with the Database WG, who opened an Action Item. The Database WG decided for the sake of consistency and quality to get rid of forward domain objects. They have asked the NCC database group to implement this Action Item.

D. IETF report

Presentation by Carsten Strotmann (Men & Mice).

Shane Kerr pointed out Reverse DNS in IPv6 draft includes a proposal to let ISPs know that they don't have to provide reverse entries for IPv6. This is a somewhat contentious suggestion even though population of the reverse tree for IPv6 can be awkward and/or impractical.

E. ITAR Update

Presentation by Dave Knight (ICANN) on behalf of Kim Davies.

Jaap Akkerhuis asked if technical tests on the ITAR are finished. There is one entry in the ITAR which doesn't make sense. Dave deferred to Kim Davies.

Roy Arends (Nominet) asked via jabber if it would be possible for a TLD to submit a key to IANA with the caveat that it does not enter the ITAR. Dave deferred to Kim Davies.

Shane Kerr asked if decommissioning is a goal. Dave indicated there is currently no plan to do it, but is eager to hear opinions from the community on how that should be handled, if it should be handled. Shane Kerr said he'd prefer the ITAR to remain indefinitely.

Peter Koch asked for the exit strategy, or the notion that there will not be one, to be communicated early.

Lyman Chapin (Interisle) strongly recommended that there is only one point of entry for updates, so people don't have to make updates to both the ITAR and to the root in the future.

Jim Reid said there seems to be a consensus in the TAR Task Force that the ITAR met the objectives suggested by the Task Force/WG. Although the Task Force could declare victory and be disbanded, Jim suggested it should remain alive but dormant around to keep an eye on developments. The WG agreed with this approach.

F. DNSwitness: Recent Developments

Stephane Borzmeyer (AFNIC)

Web site: http://www.dnswitness.net/

Daniel Karrenberg (RIPE NCC) asked if data is filtered because of skewed results due to misbehaving resolvers. Stephane answered that it isn't. Thet worst offenders were checked and he tried to contact them. Stephane mentioned the influence of spam campaigns, when he sees lots more MX requests.

G. Provisioning DNSSEC - What Would Operators Do?

Ed Lewis (Neustar) presented the highlights of his slide pack.

Shane Kerr thought this is a good activity, but worries about advancing a standards process that does not have support from registrars. Ed responded he wants to hear from members of the WG what they want to see and how they want to handle this. Shane thought it's worthwhile to go through this activity, even if it fails, but suspects that registrars are going to say no and basically make the DNSSEC depolyment difficult. Ed said he had talked to some registrars that are more advanced in their DNSSEC planning. Neustar's registrar operations have an easier problem because they can talk directly to the registry. Shane asked if Ed had talked to Steve Crocker who is working on the problem of registrar-registrar transfers. Ed responded that one of the slides not shown in the presentation had addresses those issues.

Patrik Faltstrom (Cisco) asked what business case would get the biggest reaction by the registrars: direct communication between the holder of the key for and the registry or via the registrar. Patrick said that there a general need for a protocol to transmit keys from the registrant to the registry. The question was whether EPP would be appropriate for that. The DNSSEC context might be able to move forward if you try to constrain it as a discussion on how a DNS operator that is not a registrar should pass the DS record to the registrar of the domain. Ed responded that that is one sub case. Patrick said that by constraining the problem it might be easier to move forward.

Matt Larson (Verisign) said that the special actions for transfer of DNSSEC enabled domains are not a registry-registrar issue. It's an issue between two registrars or hosting providers. That doesn't mean that we need to encumber the registrar-registry relationship with those special actions. Lars-Johan Liman (Autonomica) said this implies we need to define the role of the DNS operator in this. Edward responded that if somebody in a TLD that has a direct interface to the DNS provider, that probably would need to be involved in the mechanism somehow.

Jim Reid asked what the next steps are. Ed responded that he chose RIPE to start the discussion rather than ICANN or IETF. In some ways a discussion at ICANN would be better than at an IETF meeting, but this isn't an ICANN issue only. A RIPE meeting has operators, registrars and registries in the room, and as a result there was an opportunity for good cross discussion here.

Jim Reid asked if this is something this WG wanted to pick up. Peter Koch had the concern that this topic is discussed in too many fora already. Jim suggested leaving the issue to allow for more discussion on the mailing list. If something materialises that could be for either this WG to pick up or to pass on to one of the other fora Peter mentioned. Ed mentioned that it would be fine for anybody to send him comments privately.

H. Follow up on EOF presentations

There were no comments or followup discussions to Sara Montiero's presentation about the plans for signing .pt.

Incremental Deployment of a Signed Root
Short presentation by Joe Abley (ICANN) and Matt Larson (VeriSign)

Discussion around the root signing initiative.

Ed Lewis (Neustar) asked about the incoherency in time. He wanted to know if giving out the real key is planned before roll-out to all servers and wondered about the timing of these events. Joe Abley answered it was envisioned is that by the end of the whole process the first production KSK roll would be introduced. The Trust Anchor won't be flushed until an audit and security validation has happened. No key publication would happen until that KSK roll had taken place.

Shane Kerr asked about the physical location where L and J are served from, and if these are anycast around the world. Shane wanted to make sure that the same regions of the world would be covered when querying J as any of the other root servers. He suggested getting the signed zone to the root servers that are widely distributed geographically to identify potential problems at an early stage of the roll-out.

Olaf Kolkman (NLnetLabs) said that the order has to do with the kind of problems that are anticipated and how someone tries to measure them. There might be things that are hard to observe because traffic patterns shift. Those patterns can be in the noise of what is happening at each root servers Olaf wanted to know what methodology will be used to observe those shifts and if the methodology and possible problems that are looked for will be shared with the community.

Matt Larson answered that the intent is to make all documentation public and feedback is solicited on them. Matt agreed measuring is a real problem. He said that someone suggested we could look at the number of queries that come in with EDNS buffer size of 512. Matt said the other thing relied on is community feedback. There is a communication plan that is going to be widely published. He said the intent is to have an interval between when the last server is serving the signed zone with the bogus KSK and when the real Trust Anchor is published. So there will be time before the point of no return to accept feedback and find out if there are problems.

Daniel Karrenberg (RIPE NCC) said he thinks this is a neat idea. {applause} Daniel said he thought the crux is in the communications plan. Daniel said this was 95% of the effort and he appreciated ICANN and Verisign taking the lead on this. He thought everyone in this space should be part of the communications plan so the project can not be spun as something bad or destabilising. Daniel also said that the measurement plan is very important and it would be essential to take measurements from various places.

Andrei Robachevsky (RIPE NCC) asked how clients can be aided so they can test whether they have problems. Joe answered that as far as giving clients better tools, getting communications is the most immediate path. Andrei suggested to give people tools to debug alongside with the communications plan. Joe agreed.

Niall O'Reilly (UCD) said that the problem is the feedback channel. He asked how the help desk from his university will be able to not only communicate back any problems but be seriously brought into the channel. Matt said IANA/Verisign have some ideas.

Sara Monteiro (FCCN) asked if NSEC or NSEC3 will be used for signing the root. Joe said NSEC will be used because zone enumeration was not an issue. The root is public. Sara asked how DS records submitted by TLDs would be validated. Joe answered that that's an issue for IANA. Daniel remarked that this is being developed as part of the ITAR, so she should look at that if she wants further information. Joe said that as far as overlap between the root zone and the ITAR, nobody expressed the desire to the IANA to have records automatically moved from the ITAR to the root zone. IANA would not move ITAR data to the root without the consent of the TLD operator.

Lars-Johan Liman said a lot of TLDs, including .org, already have DNSSEC, so problems with large responses have been at least already noticed, if not fleshed out. The crucial difference is the priming query. He expressed concerns on the topic of stats and measurements because it's incredibly hard to see through the noise. An additional problem is that the people with problems are not the ones in the community. A typical response to DNS not working is to restart the server which further messes up the stats. Olaf Kolkman responded that it was possible to come up with a specific footprint of this behaviour and suggested to devise scenarios of things that can go wrong, like the one just mentioned, and try to see what kind of footprint would be expected and tailor measurement to that.

Jim Reid asked if this could be a useful part for the communication outreach activity. Joe said people should expect to hear about things that come up that were not expected. This was why the deployment schedule could not be too short so there was time to examine those footprints and traffic patterns.

Niall O'Reilly thought getting this into the press was important, to get the message out beyond the technical community.

Jim Reid thanked the speakers. He reminded the WG about the statement that was issued after the Tallinn meeting to sign the root. He thought the WG should now also respond with a thank you to ICANN for doing this and to look forward to seeing a signed root next year. {applause} He promised to draft a statement and present it to the WG in the afternoon session.

Session 2

Date:Thursday, 8 October 2009
Time: 14:00 - 15:30
Chair: Jim Reid
Minutes: Emile Aben
Jabber: Chris Buckridge

I. RIPE NCC Report

Presentation by Anand Buddhev (RIPE NCC)

Denis Walker (RIPE NCC) asked what happens if a /16 is created when there is an existing /24. Anand responded that he thought creation of the parent would not be allowed if the child exists and creation of the child would be prevented if the parent exists. Peter Koch suggested taking this discussion off-line and posting the findings to the mailing list.

Ed Lewis asked if ISC gets contacted when a key is changed. Anand explained that ISC is not contacted when keys are rolled. They are not encouraged in any way to import the NCC's Trust Anchors into ISC's DLV registry. The RIPE NCC position on this is that users should always import keys from the NCC's web site. Ed Lewis asked if there are any other TARs out there that Anand is either aware of or concerned about. Anand answered he's aware of SecSpider, which is experimental. Any problems from that experimental TAR would remain with those using it.

Shane Kerr said if arpa is going to be signed and the RIPE NCC /8s are signed but in-addr.arpa isn't signed, effectively nothing had been gained in the reverse space. Joe Abley said he was not aware of any current plans to sign in-addr.arpa. He explained that in-addr.arpa is served by a subset of the root servers. Peter Koch commented that the issue is not about the servers, but who maintains that zone. Others thought that currently was ARIN's responsibility.

Peter proposed to keep action item 58.3 open so that the RIPE NCC can take care of this. He suggested the WG could review that proposal following Shane's presentation, the next item on the agenda. He recommended closing NCC's KSKs and DLV action items (57.1 and 58.1). There were no objections.

J. Findings on lame delegations survey

Lame Delegation Analysis for the RIPE Region
Presentation by Shane Kerr (ISC)

Ed Lewis asked if lameness checks are worthwhile doing? Shane responded by questioning why he would care if someone has bad data if it's never accessed. Daniel Karrenberg responded that he believed the community wants to project the image of having its house in order. There may not be an operational value from that but there is certainly a political value. Shane responded he'd agree if the RIPE NCC would bear the cost of clean-up. Daniel commented that he thought the people doing this clean-up are part of the community, and it is the same community that has an interest in cleaning this up. Shane disagreed. Olaf agreed with Daniel. The industry has a joint responsibility to keep our act together. Olaf was unsure if the RIPE NCC should bear those costs. Shane understood the desire to keep house in order, but thought the community had not fully considered the cost/benefit analysus. Shane thought the benefit very low. In his opinion there were better ways for everyone to spend their time and effort than looking at DNS lameness.

Peter said that most of the suggestions Shane made last time had been taken into account and Shane's suggestion of an annual report to the LIRs might be interesting. Peter proposed to have the RIPE NCC gain some experience with the currently implemented schedule, and be very careful to spot signs of harassment, like people actively ignoring the emails. Shane said he'd be happy to continue discussion on the mailing list. Peter proposed to close Action Item (58.3). The WG agreed.

K. Root zone augmentation impact analysis

Presentation by Duane Wessels (OARC)
Full report at: www.dns-oarc.net/files/rzaia/rzaia_report.pdf

Daniel asked what definition of truncated was used. Duane responded the definition was TC bit set.

L. Root zone scaling effects

Presentation by Lyman Chapin (Interisle consulting group)

Jim Reid voiced his concern that some of this information might be used out of context. Jim pointed out the key point from the survey was that we can either have a signed root, IDN, more IPv6, or new gTLDs, but we can't have all four. So there is a need to prioritise things. Jim thought it important these tasks were done one at a time, and things are back to a stable state before proceeding to the next. Joao Damas (Bondis) responded that 20% of TLDs already have AAAA records, and these are added on demand. He thought a strict interpretation of doing things one at a time doesn't fit with the ongoing process of adding AAAA records.

Olaf Kolkman questioned Jim's phrasing because in the current evolutionary environment such as the root is, things are added fairly slowly now, like TLDs and IPv6 glue are added. Jim responded Olaf was right, adding IPv6 and gTLDs could just be a continuous process, but he thinks we are going to see a significant step change here in a very short amount of time. There could be a situation where lots of IPv6 could be added at once, for instance if there was a last-minute panic as the IPv4 space is exhausted.

Rob Blokzijl classified the four changes in this report in 2 categories: For IPv6, IDN and signing the root zone we know or can estimate how much extra information gets added to the root. These can be introduced in a controlled fashion. For new gTLDs it is an enormous question mark because nobody knows about how many domains we're talking or how frequently they'd get added. In the US legal environment it will also be very difficult to stop adding gTLDs once this has started.

Alexander Mayrhofer said that the OARC study shows there are no technical limits in scaling up the root to 10k TLDs, He agreed with Olaf that the scary part of a signed root is increase in size of responses and the potential number of TCP queries. He said he only expects hundreds, not millions of net gTLDs in the first round, due to the complex process and effort involved.

An audience speaker asked if ICANN and IANA are going to review every signature once you have a newly KSK. Joe answered no.

Peter Koch asked if the assessment of the shape of the curve (how many gTLDs, where will it end, etc) was part of the study.

Lyman answered the study deliberately did not take into account contractual and administrative sources of friction in the system, like the fact that it takes ICANN between 6 and 12 months to complete contract negotiation with a new registry operator.

Glenn Kowack thought Jim's principle is sound except it has to be done in the contact of changes happening all of the time.

Daniel Karrenberg disagreed with Alexander. He did not think the OARC study shows that 10k TLDs are achievable with the current system and processes.

Daniel asked what a root server should do in the hypothetical case where the level of TCP queries seriously affects the service level on the UDP side. Should they take their hands off or should they prefer queries over UDP and EDNS, and would it be useful for root server operators to make a statement on what they intend to do in those cases?

Olaf Kolkman asked if the cause of the TCP traffic is non-compliant devices at the edge of the network and how that problem should be treated.

Shane Kerr said he didn't expect much fallback to TCP because well over 90% of queries to the root zone are junk.

Daniel responded to Olaf that is was unwise to assume that TCP traffic was always an indication of a device that was non-compliant.

Patrik Faltstrom said that even people in the DNS community have a different view of what happens when response size increases, which makes it problematic to have the next discussion on what we are going to do about it.

Daniel Karrenberg voiced his concern that in his hypothetical case half of the community will want TCP queries dropped and the other half not.

Patrik said that we should not have this discussion here, because of complexity.

Jim Reid responded root server operators should be cautious with publishing information, some might for instance make it easier to mount DDoS attacks.

Bill Woodcock (PCH) said that because of differences in performance tuning requirements for TCP and UDP, he had been experimenting with splitting TCP and UDP traffic to server processes running under different kernels. He will write up his findings. Bill wondered if others are considering doing similar things.

Joao Damas commented that DNS goes over TCP and UDP equally. Joao said that he saw increased delay when DNSSEC was turned on for two signed zones and TCP queries increased to about 10 % of the total query load. Either of these zones gets more queries per second than the root zone overall, none had problems. Other zones have seen a decrease in query rate, we don't know why. Joao thought worries are hypothetical. The worst day is the first day and that has not been a problem for these 2 zones. Olaf Kolkman asked to see the data and analysis on the changes in TCP traffic that Joao described.

Rob Blokzijl was not completely sure the right decisions will be taken by ICANN based on this report. He said as a community we can do two things: (a) make it be known we fully support the findings of this report; and (b) express our concerns about ICANN making the right decision based on it.

Shane Kerr asked the audience if anybody liked the idea of a vastly expanded root zone, but there was no time left to go into this discussion.

Lyman Chapin clarified that the report is going to go to a steering group, which will consider this report, and a number of other inputs. The actual recommendation to the Board will come from the steering group.

About 25 to 30 people in the room indicated they had read the whole report.

Jim Reid said the report pointed out the need for an early warning system. Jim asked who would have the ability to activate that system and who would be listening. Daniel Karrenberg answered that some root name server operators have concluded exchanges of letters with ICANN about operational cooperation. Speaking for the K root server, the NCC would let ICANN know in no uncertain terms if server operations were under strain.

Johan Ihren (Autonomica) commented that by pointing out the need for an early warning mechanism, it could be set up in haste and then act as a brake or catalyst on changes to the root because it wasn't fully scoped and debugged. The situation was fuzzy and could be operating in a very dynamic environment. This needed careful consideration.

Glenn Kowack pointed out that the term early warning system is a bit problematic. In this case it doesn't mean immediate problems. There needs to be a new order of coordination between everybody involved, and over time scales of months to years.

Daniel Karrenberg advised the WG that as the operator of the K root server, the NCC would tell ICANN about its long term plans, and expect ICANN to do likewise. Both parties would commit to those plans and published their intention to do so.

Peter summarised the discussion and thanked the audience.

AOB

Jim Reid proposed a statement to thank ICANN and support the idea of getting the root signed. He wanted endorsement from the WG so that the statement could be presented at the closing plenary with the view to having it endorsed as a statement of the RIPE community. The statement was agreed unanimously by the people attending the WG session.