[dns-wg] RIPE65 minutes

Here are the minutes of the last WG meeting. Please speak up if there are any corrections.

RIPE 65
DNS Working Group - Session I
26 September 2012, 11:00-12:30
WG co-Chairs: Jim Reid, Jaap Akkerhuis, Peter Koch
Scribe: Daniel Quinn


A. Administrivia

Jaap Akkerhuis, DNS WG co-chair, opened the session and welcomed
attendees. He announced that the minutes for RIPE 64 were online and
no comments were received so he assumed it was safe to publish them as
final. He reminded attendees to state their name clearly before asking
a question. Jaap said that there would be some changes to the agenda
and that the OpenDNSSEC and benchmarking effort presentations would
swap.


B. Software Reports

DNS Benchmarking Effort - Shane Kerr, ISC

https://ripe65.ripe.net/presentations/168-ripe65-dns-benchmarking.pdf

Jim Reid, WG co-chair, asked if they had a mailing list or website
where the public can see what was going on. He would like to see
benchmarks and other forms of information. Shane said there wasn't and
that although BIND is not developed in a committee-fashion, ISC is
still interested in requests from the community.

Daniel Karrenberg, RIPE NCC, asked which direction they were going and
whether it was just local benchmarking or a more natural network
setting with remote clients. He also asked if they were looking for
realistic test loads that come from actual server operators.

Shane replied that real world query traffic is important, but it is
also important for people to be able to reproduce these benchmarks in
their own environment. Also, privacy is a concern. Emilio Madaio, RIPE
NCC, pointed out that there was in fact a mailing list:
dns-benchmarking at lists.dns-oarc.net

OpenDNSSEC Update - Sara Dickinson, Sinodun Internet Technologies

https://ripe65.ripe.net/presentations/189-ripe65-opendnssec.pdf

John Bond, RIPE NCC, asked if they were planning on continuing auditor
development. Sara explained that it is no longer part of the product
and would require a lot of work to maintain. It is unlikely to
continue.


C. RIPE NCC DNS Update - Romeo Zwart, RIPE NCC

https://ripe65.ripe.net/presentations/179-RIPE65_RomeoZwart_NCC_DNS_update_.pdf

Antoin Verschuren, SIDN, asked if it was possible to mandate that
networks that have a local K-root node have to do validation. Romeo
agreed that that was a good idea.

Wilfried Woeber, Univie, pointed out that the RIPE NCC's current model
of thinking will exclude networks that are built around ASes like
his. Romeo acknowledged this and said that he'd like to make sure that
the RIPE NCC approaches these settings on a case-by-case basis.


D. DNSSEC Measurement-A slightly closer look - Geoff Huston, APNIC

https://ripe65.ripe.net/presentations/177-2012-09-26-dnssec.pdf

Lorenzo Colitti, Google, commented that the numbers of 8 and 15% are
different for their various tests and experiments but that they always
vary with the same range between them. He added that '3' is the number
you can trust, which is 8-5.

Jim Reid wanted to know if they were doing fingerprinting for software
identification. Geoff replied that they were.

Heather Schiller, ARIN, asked what record the IP addressess in Geoff's
final slide were querying, remarking that if they belonged to her, she
would have them fixed. Geoff said that they were querying the A record
all the way down in that domain.

Paul Vixie, ARIN Board of Trustees, commented that the version of BIND
(8) that exhibited this behaviour is known to be susceptible to two
stack smashing attacks. He suggested that publication of this
information would encourage the managers of those machines to upgrade.


E. Panel: Overcoming the “First Mover Loses” Paradigm for IPv6 DNSSEC Deployment

https://ripe65.ripe.net/presentations/161-worldfitbday.pdf

Panel: Patrick Falstrom (Netnod) Andrei Robachevsky (ISOC), Roland Van
Rijswijk (Surfnet), Antoin Verschuren (SIDN)

Jim Reid commented that validation may not be as painful as many may
think. He suggested that better explanation might help with adoption.

Patrik pointed out that what he's heard from others was that the
process was so painless, they don't really have any comment on it.

Roland said that it cost his organisation nothing, and made no money
aside from offers to pay him for talking about it at conferences. He
added that training costs should be small because all that's needed is
a one or two-day course.

Andrew Sullivan, Dyn, Inc., stated that he's more interested in making
sure that endpoints are using IPv6 and DNSSEC. He's less interested in
ISPs doing the work. He wants OSs and browsers to look into supporting
this, rather than ISPs.

Peter Koch, WG co-chair, said that this was a topic for another panel.

Patrik said that it was good to focus on the "low hanging fruit": the
ISPs, and work from there.

Lorenzo Colitti, Google, said that the panel was ignoring the problems
beyond the initial setup and training costs such as CPU load and the
lack of information available regarding the results in different
environments.

Roland said that the process used for IPv6 migration was one worth
repeating, and advocated for some pioneering ISPs and/or big providers
like Google, Facebook, and Yahoo to setup DNSSEC for other networks to
test against.

Patrik said that there was not enough information yet to prove that
CPU consumption was significantly increased as a result of DNSSEC, and
suggested looking at Sweden’s results, comparing average growth of DNS
records and CPU load vs. growth of DNSSEC records and CPU load.

Andrei said that the low-hanging fruit isn't very meaningful because
there isn't much to validate.


DNS - Session II
26 September 2012 - 14:00-15:30


F. Interop & New Protocols

Knot DNS - Marek Vavrusa, CZ.NIC

https://ripe65.ripe.net/presentations/183-knotdns-ripe65.pdf

Sara Dickinson, Sinodun, asked whether the remote control utility they
built was using a proprietary protocol. Marek answered that it was and
that there are not yet any plans to publish it.

Dane: Killer App for DNSSEC - Warren Kumari, Google

https://ripe65.ripe.net/presentations/180-Kumari&Sury-DANE-RIPE65_1.pdf

There were no questions.

RESTful WHOIS – the IETF WEIRDS WG - Olaf Kolkman, NLnet Labs

https://ripe65.ripe.net/presentations/213-RIPE65-WEIRDS-WG-DNS.pdf

Stanislav Petr, HOSTING90, asked know why they needed this new
protocol. Olaf replied that this was an entirely different dataset and
requirements.


G. DNSMON Future - Romeo Zwart, RIPE NCC

https://ripe65.ripe.net/presentations/202-RIPE65_RomeoZwart_NCC_DNSMON_future.pdf

Joao Damas, ISC, wanted to know if these features would be open to all
members and wanted more specifics. Romeo said that they would be open
to monitor domains for members that want their domains to be
monitored.


H. Operational Considerations and Recommendations for DNS Response
Packet Sizes - Roland Van Rijswijk, SURFnet BV

https://ripe65.ripe.net/presentations/167-20120926_-_RIPE65_-_Amsterdam_-_DNSSEC_reco_draft.pdf

Rick van Rein, OpenFortress, asked if the problems he'd experienced
were related to IPv4 or v6. Roland confirmed that the problem exists
for both, but that it's much worse with IPv6.

Joao commented that BIND was going to have a lot of work done on it
soon and asked for Roland's opinion on best practice for DNS. He asked
whether you compromise efficiency and performance for the sake of
compatibility with poorly configured firewalls or do you leave people
with broken networks with slower speeds. He asked if there was a
middle ground. Roland referred to the differences between BIND and
Unbound and how Unbound's method was more effective at getting a
response faster for the user. He added that that, coupled with Geoff
Huston's revelations from earlier that day that users are extremely
impatient, meant that users are less likely to blame the zone operator
for poor speeds, but rather they might blame the network operator who
can't fix the problem.

Joao asked if Roland, as a zone operator, was happy with the increase
in TCP requests for DNS. Roland replied that that metric wasn't in the
stats, but that they did monitor for an increase in TCP and there was
no statistically significant increase for TCP fallback.

Paul Vixie asked if the total number of UDP queries go up when he
dropped the buffer size. Roland explained this was not monitored
specifically, but that there were no spikes indicating an increase in
extra queries. He added that they could look at it specifically. Paul
said that he wrote RFC2671, and as the author he would like to
apologise for mistakes he made in its initial writing.

Lars-Johan Liman, Netnod, asked how the recommendations would be
conveyed to the community. Roland replied that a draft RIPE Working
Group recommendation is open to suggestions from this point. An
audience speaker commented that DNS operators generally don't like
being told how to run their servers. Jim Reid said that what was
important was that there was something documented that could serve as
an example. The speaker agreed and asked that this be considered in
the decision process.

Eric Osterweil, Verisign Labs, objected to the hard limits on either
side of the equation and noted that establishing standards like this
are a slippery slope leading to telling people how to write their
code. Roland agreed, stating that a lot of people have limited
understanding regarding how to configure their own resolver.


I. Panel: DNS Amplification Attacks: BCP38, mitigation, reputation or what?

Panelists: Olaf Kolkman (NLnetLabs), Paul Vixie (ISC), Andrew Sullivan
(Dyn), Xander Jansen (Surfnet)

Joao asked if the solution was something that couldn't come from the
people in this room and whether it be meetspace law? Olaf said the
problem was enforcement, the overhead in tracking as well as
international treaties, as well as the "arms race" and RFC 3514.

Paul said that it comes down to enforcement and that as a victim, you
are either being used as an amplifier and reflector or you are being
attacked by others. He encouraged anyone in the audience that may be a
target of such attacks to contact him privately, as they have access
to data that they can share about the attack. They would be
contributing to a global effort to track down people conducting these
sorts of attacks.

Jim Reid noted that by the time the attacking packets have reached
him, the perpetrator is already gone, and suggested that BCP38 may be
the solution to this. He suggested that core internet exchanges might
offer discounts or fatter pipes to ISPs implementing BCP38. Andrew
Sullivan said he agreed because it reversed the equation of who has
terrible bandwidth: people who act poorly suffer on lower network
speeds, as opposed to people who are being attacked. He admits that
this is not an ideal solution, but he wasn't sure of a better
alternative.


J. AOB

Anand Buddhdev, RIPE NCC, announced that the RIPE NCC wanted to make
the name server attribute mandatory in the RIPE Database, as well make
some minor changes to the syntax. He encouraged everyone to look into
the archives of the DNS Working Group mailing list and to comment
there.