[dns-wg] RIPE70 minutes

Colleagues, here are the minutes from our meeting in Amsterdam last year. My apologies for the unacceptable delay in getting these circulated.

Please let us know if there are any errors or omissions.


DNS WG - Session 1
RIPE 70
13 May 2015
WG co-Chairs: Peter Koch, Jim Reid, Jaap Akkerhuis
Scribe: Emile Aben

A. Administrivia

Peter Koch opened the session and the minutes of the previous
meeting were approved.

B. RIPE NCC Report - Anand Buddhdev and Romeo Zwart, RIPE NCC

https://ripe70.ripe.net/presentations/75-RIPE70_AnandBuddhdev_DNS_Update.pdf

Lars Liman, Netnod, noted that the old scripts won't go away even if
visualisations were removed. Romeo answered he was aware of that.

George Michaelson, APNIC, expressed interest in query rates for AS112,
He was surprised by seeing 10% of queries over IPv6. Anand said he saw
similar numbers for other authoritative servers.

Jim Reid suggested putting a 'this is going away' sign on the old
DNSMON visualisations. Romeo responded that was already done, and said
the plan is to make landing page for old DNSMON a redirect to the new
DNSMON.

C. IETF Report

Peter made the room aware of a virtual interim meeting of the IETF
dns-ops group. Minutes of this meeting are available online:

https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/minutes/minutes-interim-2015-dnsop-1

D. Knot DNS 2.0 - Status Update - A New Major Version Introducing Updated DNSSEC - Jan Vcelak, CZ.NIC

https://ripe70.ripe.net/presentations/71-ripe70-vcelak-knot.pdf

Olafur Gudmundsson, Cloudflare, asked if key management is time driven
or predicate driven. Jan said they plan to provide hooks so external
scripts can do various checks. Jan further explained that if a key
server is down, steps in key management are postponed.

Patrik Falstrom, Netnod, said he likes to have callback mechanism so
it's possible to have external software react to key management
events.


E. Test Cases for Validating a DNS Delegation - A Step Towards Best Practice - Sandoche Balakrichenan, AFNIC

https://ripe70.ripe.net/presentations/83-TRTF-RIPE2015.pdf

Sebastian Castro, NZRS, said they have code ready for a discovery
check, and wanted to clarify if only compliance checks were wanted, or
also discovery checks. Sandoche responded that if there was code and
consensus that this should be added, it would be added.

Jelte Janssen, SIDN, commented that he liked the effort and said it's
probably good if tool sets can have slightly different focus.

F. DNSSEC ECDSA Algorithm Use and Acceptance - Olafur Gudmundsson, Cloudflare

https://ripe70.ripe.net/presentations/85-Alg-13-support.pdf

Anand responded to Olafur’s presentation with the promise that for
next meeting all resolvers will have ECDSA support. Anand asked if
Cloudflare could contribute in making validating with ECDSA faster.
Olafur responded they have code for OpenSSL to speed things up.

Geoff Huston, APNIC, said he kept on hearing there is no DNSSEC out
there, but he sees 25% of users do validate. He also said that lack of
ECDSA support went from one in three last September to one in five
now, and thanked Olafur for the efforts in making that happen.

G. DLV Sunset - Jim Martin, ISC

https://ripe70.ripe.net/presentations/81-RIPE-DLV-timeline-20150513.pdf

George Michaelson suggested a shorter time line for the DLV sunset. He
also asked what the resolver side failure mode is when the server stops
responding. Jim Martin said it was SERVFAIL if you are running BIND.

Warren Kumari, Google, thought that because of Jim's presentation the
number of DLV participants would drop and would be interested in
seeing the number of participants on 14 May.

Jim Reid said he found the time line for sunset quite reasonable with
regards to software packaging, and thanked ISC for bringing about the
long overdue death of DLV. He also brought up the issue of DLV code in
BIND and suggested ISC remove it from the next appropriate BIND
release. Jim Martin responded he would take that suggestion to the
developers at ISC.


————

DNS Working Group - Session 2
RIPE 70
14 May 2015, 9:00
WG Co-Chairs: Jim Reid, Peter Koch, Jaap Akkerhuis
Scribe: Florian Obser

H. Knot Resolver – A More Thorough Introduction - Marek Vavruša, CZ.NIC

https://ripe70.ripe.net/presentations/121-knot-resolver-ripe70.pdf

Ed Lewis, ICANN, asked if the resolver can learn a new trust anchor
for the root zone. Marek answered that he didn't talk about DNSSEC
because it doesn't validate yet.

Jim Reid asked when the software will be released for general use.
Marek said that he wants to have it production ready by the end
of the year, maybe earlier and that there is a release plan on the web
site.

I. Network-Tuning for DNS Zone Transfers in (lossy) Long Fat Networks - Marco Prause, DENIC

https://ripe70.ripe.net/presentations/123-TuningZoneTranfers4LFNs.pdf

Ed Lewis asked what kind of records are in the IXFR and if they are mostly
to be removed RRSIGs. Marco confirmed that this is the case.

Matthijs Mekking, Dyn, said that he looked into improving IXFRs by not
transferring huge amounts of deleted signatures but he couldn't find
real live scenarios that suffer from this.

Lars Liman, Netnod, asked if other kernels besides Linux have
implementations for different TCP congestion control algorithms. Marco
said that the congestion control algorithm can be changed in FreeBSD
but he wasn't sure if TCP-Hybla is available.

Jim Reid asked if there was any other way to improve performance.
Marco said that he was changing the TCP window size and other kernel
parameters but real improvement were only achieved with changing the
congestion control algorithm.

J. Root Zone KSK Rollover - Ed Lewis, ICANN

https://ripe70.ripe.net/presentations/86-DNSOARCRIPE70slides-submission2.pptx.pdf

Marek Vavruša, CZ.NIC, asked if there are any plans to change the key
parameters or do a algorithm roll over or just roll the old key. Ed
responded that yes, algorithm roll over was considered and that he's
not saying no to anything at this point and is open for all
suggestions. Marek pointed out that he is concerned about increased
response sizes.

Geoff Huston, APNIC said that his presentation will address that.

Sam Weiler, Parsons, wanted to make sure that people look at CDS (RFC
7344).

Jim Reid asked how people can make further observations or comments
known to ICANN. Ed said that the formal way is the public comment
period. The design team is meeting and will produce a document. The
formal way is to respond to that. Jim then asked what if someone wants
to give comment to the design team while they are working. Ed
responded that anyone can speak to the design team and they are on the
relevant mailing lists. He continued that this is an informal way of
taking part in the discussion and consulting the community. The formal
approach will be via the public comment period.

Matthijs Mekking said that the rollover had been discussed at
DNS-OARC and that the discussion there has been archived.

Peter Koch, DENIC, observed that people in the Working Group are aware
of RFC5011 and if they are not running it they can either manually
change their trust achchor configuration or migrate to RFC 5011 aware
resolvers. He asked what the vision is for the long tail that might
be affected by the root key rollover,

Ed responded that RFC5011 is only one tool. There are other options,
for example the IETF has published a trust inchor Internet Draft. He
said that ICANN are trying to understand who is consuming root trust
anchor information. Ultimately there is stuff out there that will
break and he said that ICANN won't know how to reach the person that
will responsible for that stuff. He continued that at one point it is
hard to know how much responsibility we have to make sure that
everybody is perfectly upgraded. He said that they don't even have
tools to test. He said he can't find out if a person has the new trust
anchor without breaking that person's setup and that person then
complains. And he doesn't want that ability. He said that this is an
open question.

Peter Koch pointed out that this is as much a communication exercise
as it is an engineering exercise. Ed agreed with this. Peter also
pointed out that we need to be careful because if too much stuff
breaks this could lead to further DNSSEC push back.

Stephan Lagerholm, speaking for himself, asked if there is any work
being done to mitigate against additional risks known since
Snowden. He gave several examples of mistrust against DNSSEC in the
community and asked if there is anything that can be done during this
key roll over to help restore trust. Ed responded that the design team
was looking at different algorithms but more from the size
perspective. He thanked Stephan for bringing this up because the
design team might not have looked at mitigations for this particular
problem space.

Warren Kumari, Google, responded to what Peter said by pointing out
that there was supposed to be a public outreach since at least
2013. Ed remarked that a time machine was under construction.

K. Tyre-kicking the DNS - Geoff Huston, APNIC

https://ripe70.ripe.net/presentations/130-2015-05-14-dns-xpmts.pdf

Alain Durand, ICANN, asked what the reason for IPv6 enabled resolvers
querying over IPv4 is. Is it the same thing as with eye ball software
that tries IPv4 and IPv6 and goes with the fastest answer or is it
hard coded?

Geoff said that he doesn't see exploratory round trip probing and that
he thinks that it is hard coded. He went on to say that he couldn't
find this in the DNS resolver code but the behaviour indicates a solid
preference for A before AAAA. Alain pointed out that there are only a
few resolvers people are running and if Geoff asked the resolver
implementers what they are doing. Geoff said he hadn't done this yet
and pointed out there are resolver implementers in the room.

An unidentified attendee said they prefer IPv4 for resolution.

Jared Mauch, NTT, said that in many networks there is no traffic
engineering for IPv6 so if resolvers were doing RTT probing they would
find that the IPv6 path is slightly shorter. He went on to say that
resolvers probably have the IPv4 answer cached already and then go
with that. Geoff said that during DNS-OARC it was mentioned that
resolvers like to run red hot. So when IPv4 answers are already cached
this becomes a self fulfilling prophecy. He continued that this seems
to be a safe thing to do since everybody is scared about IPv6 path MTU
problems.

Marek asked what happens if one changes the order of glue. Geoff
responded that he only tried IPv6 only. He said that he played with
glue ordering in previous experiments and the experience was that IPv4
seems to be hard coded preferred. Marek said that some resolvers fetch
the IPv4 address first. Geoff asked what the knot resolver is doing.
Marek responded that knot fetches both and then decides on the
round trip time.

Z. Wrap Up - WG Co-Chair Appointment Process

Jim Reid said that all Working Groups have been trying to come up with
a process for appointing new working group chairs. The DNS working
group has reached a point with some kind of silent consensus for a
proposal that has been put out a week ago. He said that it would be
helpful for people to voice their support rather than relying on the
principle of silence implying consent. He continued to say that if the
working group doesn't speak up it will be adopted in time for RIPE
71. People who are interested in standing for as co-chair should speak
to the current group chairs.

Jim thanked the NCC staff, the scribe, the person taking care of the
chat room and the stenographer. With that he closed the session.