[dns-wg] RIPE67 minutes

Apologies for the delay in circulating these.

Please let me know if you have any comments or corrections. Thanks.

#
#       $Id: minutes,v 1.2 2014/04/02 15:03:52 jim Exp $
#
DNS Working Group
Date: 16 October 2013, 11:00-12:30 and 14:00-15:30
Co-Chairs: Jim Reid, Peter Koch
Scribes: Chris Buckridge and Denis Walker

Session I

A. Administrative Matters

Jim Reid opened the session, welcomed participants and reminded them
that all proceedings were being webcast. He noted that the draft
minutes from the RIPE 66 session had recently been posted. There were
no objections to the draft and the minutes were adopted.

B. ENUM WG Announcement
Carsten Schiefner, DENIC eG

The presentation is available at:
https://ripe67.ripe.net/presentations/239-RIPE-67-ENUM-Status.pdf 

There was no discussion. 

Jim noted that the remaining four presentations looked at related
issues and would be considered as part of a wider-ranging discussion
in the DNS Working Group.

C. PMTU for better IPv6 Performance
Willem Toorop, NLnet Labs

The presentation is available at:
https://ripe67.ripe.net/presentations/230-pmtud4dns.pdf 

There were no questions.

D. DNS over TCP analysis
Geoff Huston, APNIC

The presentation is available at:
https://ripe67.ripe.net/presentations/112-2013-10-16-dns-protocol.pdf 

Shane Kerr, Internet Systems Consortium (ISC), asked for some
clarification regarding Geoff's graph on "time to resolve a name",
specifically regarding the zero seconds resolution. Geoff noted that
he is looking at the time between the first query for a name and the
last query for that name, and a single query is zero seconds.

Jim asked whether it was clear, when talking about TCP failover, if it
was broken firewalls or issues with the DNS software causing problems.
Geoff noted that he had looked at what percentage had "naked SYNs",
and it looks like the TCP-blocking rate is remarkably small (<1%). He
added that there’s no sign of systematic blocking by resolvers that
query authoritative name servers.

Jared Mauch of NTT Communications noted that he has considered, as
part of the open resolver project, doing a TCP 53 scan, and wondered
whether people would consider this useful. Geoff was not sure that
such a study would provide information worth the trouble of conducting
the study, however Bill Manning, ISI, speaking from the audience, said
he believed it would be valuable. Bill noted that he had looked at
this issue in 2009 and at that time they looked at the impact of query
on one address family (IPv6) and response on a different address
family (IPv4). Geoff noted that his experiment was deliberately
conducted all in IPv4. Bill noted that, running an authoritative name
server, the response, when given in a different address family, would
not necessarily match the request, and encouraged looking at this in a
future experiment.

E. Defeating DNS Amplification Attacks
Ralf Weber, Nominum

The presentation is available at:
https://ripe67.ripe.net/presentations/133-RW-DNS-Amplification-RIPE67.pdf 

Kostas Zorbadelos (OTE SA) noted that his organisation had been hit by
this attack and they were able to mitigate the effects by filtering
and rate-limiting. He also asked if Ralf had a solution for defeating
these attacks. Ralf noted that his company does sell a software
solution that can be used in this way.

Shane Kerr noted that having the servers limit the reply rate based on
size is a good idea, but that people don't have reply rate limiting
(RRL) turned on by default because it can be quite confusing for an
administrator, as it can cause your server to act in ways you're not
expecting. He suggested that if the community sees these attacks as
being very widespread, it's possible to switch RRL on by default. Ralf
suggested that this decision should remain in the operator’s hands,
especially as it may result in dropping legitimate traffic.

There were no further questions.

F. UDP Fragmentation/PMTU attack mitigation
Tomáš Hlaváček, CZ.NIC

The presentation is available at:
https://ripe67.ripe.net/presentations/240-ipfragattack.pdf 

There were no questions for Tomáš. He was then joined on stage by the
previous two speakers for a panel discussion.

G. Open discussion of C, D, E & F

Jim Reid noted that Shane Kerr discussed potentially using some sort
of rate-limiting solutions. Shane responded that the goal was actually
to control the amplification factor, the idea being to target this
problem. He said the way to do this is to penalise larger responses.
Shane added that this is a sophisticated algorithm that might be confusing
for network operators, but it shouldn’t have any effect except in an
attack scenario. He noted that the basic philosophy is having a name
server act in a degraded mode when under attack, which is unfortunate,
but perhaps the least worst option.

Geoff Huston noted that rate limiting might not be the best option,
and noted that Jared’s work seems to suggest there is a mechanism that
gets around this. He said response size seems to be the problem, and
it seems that BCP38 is unlikely to gain traction. He added that EDNS0
seems the a good option, but the usual default 4096 size seems to have
been overly optimistic, and opened up vulnerabilities - 512 would be
better.

Ralf Weber said it still might be effective to look at rate limiting.
Geoff argued that this strategy would mean you were rate limiting
everyone.

Bill Manning, ISI, suggested that authoritative servers are doomed if
everyone supports a 64k response size. Jim suggested there would be
fragmentation issues long before reaching that point. Bill noted that
pushing the response size to 64k changes the idea of what a threat
is. Shane suggested that few people were likely to be considering 64k
as a major issue.

An unidentified attendee noted that rate limiting will work for a
while, but it requires increasingly complex algorithms. He suggested
that it's not just DNS, with enough other public UDP services in the
network, SNMP. Jim noted however that TCP is also a very good vector for
attack. The attendee agreed that this had been an issue for Yandex
in Russia. Geoff disagreed, noting that other protocols (UDP or SNMP)
are not reliable attack vectors, but agreed that RRL is not effective
and can only buy a small amount of time.

Michael Daly of Nominet, noted that Nominet infrastructure had been
used for amplification attacks and that RRL had helped, but they found
that looking at signatures and rapidly responding helped more.

Shane suggested that it looked grim, though there have been some
suggestions put forward. He suggested TCP might be a good option,
though not complete, and that it’s weird that UDP is being made more
like TCP (through approaches like UDP-based cookies). He noted that
there is so much old stuff on the Internet that it may not be
worthwhile pursuing a new technology response if it won't be taken up
for another 15 years. Geoff noted that he hadn't looked at all of the
respondents in his study, but suggested it's probably not so grim -
the tail end of old stuff only serves a small population of clients
(perhaps the 2.6% that he found in his study).

An unidentified attendee noted that there have been discussions of all
these various kinds of attacks and DNSSEC could solve them all. He
noted that his organisation had made the considered decision to use
RRL (with the associated dropping of some queries). Now with proposals
on doing DNS over TCP, he noted that the only time RRL had not worked
was in cases of attacks played out over open recursive resolvers. He
noted that there is more data required on whether it’s viable to do
DNS over TCP. Ralph noted that the designers of DNS software expected
the use of TCP to be a rare occurrence, and it's a problem that large
volumes of TCP can't be consumed, but it's solvable. Geoff noted that
he had done some work in this area using virtual TCP drivers, but
that, with a standard TCP driver, you'll run into trouble.

Edward Lewis (Neustar) argued a need to recognise where we want to go
to and begin to move toward that long-term goal, evolving the DNS into
the protocol we want it to be rather than simply patching what we
currently have.

AFNIC's Mohsen Souissi agreed, noting that although DNS developers and
engineers are hitting obstacles one at a time, there is a larger issue
that might be better addressed at the IETF level.

Jim closed the first session of the DNS Working Group.

Session II

Peter Koch opened the second DNS session and welcomed everyone back. He
announced a small adjustment to the agenda: Jeff Osborn will follow
Dave Knight.

H. RIPE NCC DNS Report 
Anand Buddhev, RIPE NCC

The presentation is available at:
https://ripe67.ripe.net/presentations/248-RIPE67_AnandBuddhdev_DNS_update.pdf

There were no questions. Peter asked for volunteers to look into the
issue of secondary DNS provided by the RIPE NCC in order to consider
criteria, guidelines, service levels, and possibly even a policy if it
is thought necessary. He asked anyone interested to contact the DNS
Working Group Chairs after the meeting.

I. Which habitat fits your name server’s nature best?
Willem Toorop, NLnet Labs

The presentation is available at:
https://ripe67.ripe.net/presentations/250-habitat.pdf

Ondřej Surý, CZ.NIC, remarked that dropped zone compilations has been
removedfrom the newest version of Knot. This had sped up performance
and Willem's measurements did not take that into account. Willem
replied the benchmarks were performed in June and so the presentation
shows the results using the software that was available then. He said
he will repeat the tests with the newer version of the software.

Liam Hynes (Dyn) asked what type of queries Willem was sending to the
name servers for his performance tests. Willem responded that there
were all different type of queries – A records or AAAA and NS – and
they all existed. Liam asked if he tried different combinations like
all A records, all AAAA, 50/50 A/AAAA, maybe with CNAME or TXT
records. Willem said yes, but that they don't have the results.

Ralf Weber of Nominum asked if the queries were EDNS or just plain
DNS, and Willem confirmed it was just plain DNS. Ralf commented that
all queried records exist in the zone, and Willem agreed it would be
better to include some non-existent records.

J. Introducing Hedgehog 
Dave Knight, ICANN

The presentation is available at:
https://ripe67.ripe.net/presentations/245-dknight-ripe67-hedgehog.pdf

There were no questions.

K. ISC News 
Jeff Osborn, ISC/DNSco

This presentation is not available online. Jeff gave an overview of
recent changes in the the ISC organisation

There were no questions or comments.

L. Client-IP EDNS Option Concerns 
Florian Streibelt, TU Berlin

The presentation is available at:
https://ripe67.ripe.net/presentations/206-L-dnswg-Streibelt-ClientIP.pdf

There were no questions.

M. OTE’s resolver infrastructure/design/rollout 
Kostas Zorbadelos, Otenet


The presentation is available at:
https://ripe67.ripe.net/presentations/208-OTE-Anycast-DNS.pdf

Antoin Venschuren, SIDN, noticed they do DNSSEC validation for their
infrastructure name servers, but not yet for their customers, and
asked about the considerations for that. Kostas replied that the major
consideration is the performance impact.

Antoin asked about plans for this, and Kostas said he could not give an
estimate, but it's definitely on the agenda and they will try to
accommodate that. He added that having DNSSEC validation in the
infrastructure resolvers is one step towards introducing it gradually
to end users.

Dave Knight noted an issue in choosing an IGP to use with IPv6. He
asked whether Kostas had considered using BGP, noting that L-root
switched from OSPF to BGP and it works fine. Kostas asked whether Dave
meant between the anycast nodes and the network and Dave confirmed
that was the case. Kostas said they have thought about the issue. Dave
said he used to use OSPF and switched to BGP because everything was
much easier to debug. Kostas agreed it was easier, but said a major
concern could be the failover times. Dave said he doesn't have any
numbers on this, but the BGP approach works for L-root. Kostas said he
hoped Hedgehog would be helpful for monitoring this.

Jim Reid said the Working Group Chairs would like to get a bunch of
operators together to share information such as this, and experiences
when switching on DNSSEC in their networks, and hopes this can be done
for RIPE 68 in Warsaw. He added that there is some anecdotal evidence
that resolvers have switched this on and say they haven't noticed,
which is surprising, so would like to get some real data.

Kostas replied he is happy to share whatever they can. He said after
OTE has migrated to the new platform they intend to enable DNSSEC
validation in selective nodes, not the entire infrastructure. That way
the introduction of DNSSEC validation could be controlled much more
than would have been possible with the previous setup.

Ondřej Surý said they are already working on ISIS for BIRD routing
Daemons, and Kostas replied that they are really interested in this.

An unidentified attendee from Forthnet confirmed that they saw no
impact when they turned on DNSSEC for their customer resolvers in
December 2012.

Kostas said that in principle OTE have DNSSEC-enabled infrastructure.

The attendee confirmed that is the case for their customers.

An unidentified attendee from GRNET said they enabled DNSSEC
validation for their customers and it had no impact at all, adding
that currently 98% of their customers are doing DNSSEC validation and
it's going fine.

There were no further questions.

N. DITL Data Analysis for ICANN gTLD Collision Study
Jim Reid, RTFM LLP

The WG ran out of time for this presentation. It is available at:
https://ripe67.ripe.net/presentations/214-JR-RIPE-161013.pdf

Z. AOB

Peter Koch asked for feedback about the arrangement of the Working
Group sessions as well as the content. He encouraged attendees to
approach the Working Group Chairs with their feedback in person or
send them an email.

Jim Reid asked those who had switched on DNSSEC validation to please
come and see him because he would really like them to come and talk
about their experiences at the RIPE 68 Meeting in Warsaw.

Peter thanked the RIPE NCC staff for scribing, chat monitoring and
webcasting, along with the AV staff and the stenographer, and thanked
everyone for attending.