[dns-wg] Draft minutes from RIPE72

Colleagues,

Here are the draft minutes of the RIPE72 meeting of the DNS working group, please send any corrections to the working group chairs.

Kind regards,
dave




DNS Working Group - RIPE 72
Thursday, 26 May
WG Co-Chairs: Jaap Akkerhuis, Dave Knight, Jim Reid
Scribes: Michael Frearson and Fergal Cunningham
Session I - 14:00 - 15:30

A. Administrivia [5 min]

•    Agenda Bashing
•    Review of Action Items
•    Approval of Previous Minutes

Dave Knight opened the session. Dave mentioned that during the 
follow-up section, if people wanted to bring up extra items they are 
welcome to.

Dave then announced an addition to the second session agenda: a 
brief proposal about the Yeti DNS project.

Dave announced there were no outstanding actions from previous 
sessions and no other changes to the agenda.

There were two sets of minutes to approve: minutes from RIPE 70 and 
RIPE 71. Dave asked for comments – there were none – and declared 
the minutes approved.

B. RIPE NCC Report [30 min] Anand Buddhdev, RIPE NCC

The presentation is available at: 
https://ripe72.ripe.net/wp-content/uploads/presentations/121-RIPE72_AnandBuddhdev_DNS_Update_v2.key

In response to Anand’s slide about strange K-root peering behaviour 
in Belgium, Jaap Akkerhuis, NLnet Labs, said the situation exists 
not only in Belgium, and that he has seen similar behaviour in 
Amsterdam.

Offering feedback on ns.ripe.net, Shane Kerr, BII, suggested that as 
it’s only reverse, and people need forward DNS anyway, people are 
likely to have some other DNS provider, so he doesn’t see any loss 
of value in turning down the service.

Shane then commented that he looked at ripe-663, the ccTLD 
guidelines, which don’t mention anything about IPv6, so he was 
considering trying to get that (IPv6) added as a reason a ccTLD 
could get service from NCC. There are a few dozen TLDs that still 
don’t have IPv6 service and Shane thinks that they should.

Jim Reid, DNS Working Group co-Chair, then asked whether the extra 
domains that were in the RIPE NCC’s DNS infrastructure – domains 
such as www.ripe.int and www.ripen.cc – were removed.

Anand replied in the affirmative and said the RIPE NCC sent an email 
to the DNS Working Group mailing list about it last year.

Gaurab Upadhyay, Limelight Networks, agreed with Shane’s point about 
ripe-663 and said a lot of smaller ccTLDs might have more than three 
servers in the same network right next to each other, and that three 
servers is a high limit, therefore the criteria might want to be 
written more subjectively.

Blake Willis, L33 Networks, asked Anand to talk with him after the 
session regarding K-root peering in Belgium.

Dave Knight, Dyn, asked Anand if there is a timeline upon which the 
RIPE NCC is seeking guidance from the working group regarding the 
ns.ripe.net issue.

Anand replied that there is no rush, that the issue has been going 
on for a while, and that the RIPE NCC can keep tolerating the 
failures and refresh issues. Anand went on to explain that the aim 
is to improve the service for everyone in general and that the RIPE 
NCC would like to start doing something about ns.ripe.net later this 
year (2016) and into early next year (2017).

C. Root Zone ZSK Size Increase - Duane Wessels

The presentation is available at: 
https://ripe72.ripe.net/wp-content/uploads/presentations/168-verisign-zsk-change.pdf

Paul Hoffman also briefly presented on the upcoming KSK rollover – 
questions came after.

Shane Kerr said the Yeti root server testbed is testing a roll to 
2048 bits with their own ZSK, which they will report on in a few 
weeks. Shane went on to ask about the bandwidth increase, which he 
said seemed high, and asked why the increase was so large.

Duane said he thought the increase was due to so many queries coming 
in with the DO bit set, but it would take another study to determine 
whether or not all of those DO bit queries are junk.

Shane then asked which feedback channels Duane would be open to. 
Duane listed Twitter, an email address that will be available, and 
mailing lists.

Dave Knight then mentioned that the root-dnssec.org website didn’t 
look like it had been updated since the signing. Dave asked if the 
website would be updated.

Duane said he thought the website would become more of an historical 
reference and would not be updated for these activities, but things 
could change in the future.

Jim Reid thanked Paul and Duane for communicating the information in 
their presentations. He then asked Duane to explain more about the 
rationale behind moving from a 1024-bit to a 2048-bit key for the 
zone-signing key.

Duane said the rationale was comprised of a couple of things: there 
is a NIST recommendation on key lengths, which plays a part, and 
there was also a big mailing list discussion and this decision is in 
response to that community input saying the key should be bigger.

Peter Koch, DENIC, asked if this helps all the people who get their 
domains signed immediately from the root.

Duane and Paul answered in the affirmative.

Peter then said he hadn’t seen a general recommendation to move to 
2048 bit or some intermediate size for any of the intermediate 
levels in the DNS tree, and that the considerations and measurements 
done during the experiment Duane described may or may not apply to 
other levels in the DNS tree. He went on to say the idea that 
everyone should run to 2048 bit for the ZSK may be a bit premature.

Duane said he would agree with that statement, and asked Peter where 
he would see such a recommendation coming from and who would do it.

Peter said he would not refer to the NIST recommendations for a 
variety of reasons.

Paul said people should not want to hear himself or organisations on 
stage recommending it – many national bodies have been recommending 
going past 1024 bit, but he has not heard of any national or 
regional organisations recommending to stay at 1024 bit.

Philip Homburg said that when Logjam announced breaking 1024 bits 
the same also published details on how to break 1024 RSA, and that 
this suggests someone with EUR 100 million spare cash can build a 
machine to instantly factor it, so it was dangerous to assume that 
this is safe for any purpose at this moment.

Paul explained that this was not a correct interpretation of the 
paper: the 1024 bit key that was broken was a special 1024 bit key 
with an equivalent strength of 750 bit. Philip argued that nobody 
has used this amount of cash to actually do it but the speculation 
is theoretical.

Paul said that this point was about how someone might build such a 
device, and that the work was purely theoretical at this point. He 
went on to explain that the theory is not impossible and it is 
widely assumed there are designs on it, but no one has demonstrated 
the hardware configuration that could possibly achieve it.

Ólafur Guðmundsson, CloudFlare, said that DNSSEC is a chain, so the 
weakest link decides whether the answer will be trusted or not. 
Ólafur reasoned that if the web browsers say “we will not trust 
anything that is less than ‘x’”, that means if anybody on the way 
there is less than ‘x’ the chain will not be trusted, and it doesn’t 
matter what the lower level does. Ólafur went on to say that this 
would enable everybody who is using larger keys below to be trusted, 
and that there were in excess of 85 domains that only use 2048 bit 
RSA or larger keys, so instantly the browsers will say those are 
good, so the next step is to get the rest of the TLDs to start 
moving up or switch to a better algorithm. Ólafur added that the 
community would then have smaller keys.

Paul agreed that keys would be smaller, and said they would return 
in five years to talk about that.

Kaveh Ranjbar, RIPE NCC, said there are hard links between this 
community and the IETF and this community and ICANN, and he hears a 
lot of things that are inspired or designed by W3C and subsidiaries; 
this community doesn’t have many links to that SDO. Kaveh said that 
maybe the RIPE working groups need more communication with that line 
of standardisation.

Paul responded that once they had the 2048 bit ZSK, he thought more 
groups would be willing to initiate conversations, certainly the 
browser vendors.

D. QNAME Minimization in Unbound - Ralph Dolmans, NLnet Labs

The presentation is available at: 
https://ripe72.ripe.net/wp-content/uploads/presentations/120-unbound_qnamemin_ripe72.pdf

There were no questions for Ralph.

E. Follow up from plenary topics

What’s So Hard About DNSSEC? - Paul Ebersman

There were no questions.

Session 2 – 16:00-17:30

F. BIND 9.11 Release Update – Vicky Risk, ISC

The presentation is available at: 
https://ripe72.ripe.net/presentations/177-RIPE_BIND_May_26_2016.pdf

Shane Kerr, Beijing Internet Institute, asked if Dyn DB supported 
incremental zone transfers and dynamic DNS, and Vicky said they had 
not tried that yet but that it should. Shane asked if it was 
possible to have multiple catalogue zones and Vicky said this was 
possible.

Anand Buddhdev, RIPE NCC, noted that there was an effort underway to 
update the document for RSSAC02 statistics so this might change in 
the future and it would be good to make sure BIND is compliant with 
the new version.

Sara Dickinson, Sinodun, asked if the implementation of the EDNS 
client subnet supports, or recognises, the option that a client can 
set a 0 in the request so that its subset isn't exposed upstream.

Vicky said that was not done yet as what she is talking about is 
just the authoritative side implementation. She added that she 
didn't know that any clients did set a 0, it would be great if they 
did and she would support putting that in. She said the resolver 
side implementation could be ready for BIND 9.12 and her colleague 
Stephen Morris confirmed this was the case.

G. DNS Privacy Public Resolver Proposal – Sara Dickinson, Sinodun

The presentation is available at: 
https://ripe72.ripe.net/presentations/119-RIPE72_DNS-WG_DNS_Privacy.pdf

Sara concluded her presentation by asking if there were any RIPE NCC 
members who would be interested in offering a DNS-over-TLS 
privacy-enhanced public recursive. She also asked for discussion on 
whether the RIPE NCC would consider running such a service if there 
was demand for it.

Lars-Johan Liman, Netnod, said he would be happy to see the RIPE NCC 
participating in any experiments for this but he didn’t see running 
this as an ongoing service as part of the RIPE NCC's remit. He also 
asked that it be implemented first over IPv6 and then backported to 
IPv4 if necessary as this is the mindset we should have now.

Thomas Steen Rasmussen, BornFiber, who runs a DNS service called 
UncensoredDNS said he would love to be the open resolver to test 
this out. He said there were some issues with amplification problems 
but provided that can be fixed, it would be ideal because the 
service is centred around privacy and censorship.

Sara agreed there were a few implementation details to be sorted out 
and at the moment the implementation coverage in the various name 
servers is a bit patchy. She said she would like to see this as a 
driver for getting features implemented across the name servers and 
using a variety of name servers to run some of these different 
trials.

Ondřej Surý, CZ. NIC, asked about making this a collaborative effort 
and getting the address space for IPv4 and IPv6 and each trusted 
organisation would run its own DNS-over-TLS resolver at its own 
premises and export those prefixes. He said in that way we wouldn't 
burden the RIPE NCC with running another service and, for example, 
CZ.NIC would be happy to run such a service in shared PI space.

Kaveh Ranjbar, RIPE NCC, said the RIPE NCC would fully support the 
implementation if the community wanted that, but at the end of 
running such an experiment there should be documentation on how to 
operate such a service so anyone else could do so as well. He said 
the second requirement would be to make sure the whole privacy thing 
at the end of the experiment would be covered, maybe only with TLS 
but maybe also with minimisation and other things as well, and 
end-to-end because for example we could also study the effects of 
this on the root.

Sara said there are a lot of elements to this and there should be a 
phased approach where we look at the different aspects, learn some 
lessons and move on and expand the project as we go along.

Kaveh noted the suggestion from CZ.NIC and said it is possible with 
different participants as all the policies for experimental address 
ranges are there so everything is in place.

Geoff Huston, APNIC, asked about the distinction between DNS over 
TLS heading towards recursive servers that then query in the open. 
He said they were working in the GetDNS project where you are 
dragging this back towards the users and eliminating the recursive 
from the entire picture. He wondered aloud whether in the long or 
medium term future of the DNS and privacy whether public recursives 
are a part of the picture or whether they’re actually kind of in the 
way. He said from a privacy argument it's sort of “who am I sharing 
my faith with and my secrets with”. He said he could use 
DNS.google.com and it's a secret between him and Google. He asked 
Sara to comment on that kind of tension between the intermediary 
versus using exactly the same technology and piloting it and 
bringing it back to the host.

Sara said one of the things to be explored with this was how it 
changes the role and the requirements on the operators of recursives 
and there are potentially lots of legal implications there and these 
are potentially different per country. She said with GetDNS, that 
will work in both stub and recursive mode and one of the target use 
cases for recursive mode is really DNSSEC roadblock avoidance, so if 
there are services that will let you use TLS from the stub to the 
resolver and you trust your resolver you can do that. She said this 
is a long road and we are just discovering which steps along that 
road we want to take.

Geoff asked, considering that the DNS is the most wildly abused 
system for surveillance, censorship and almost every other thing 
that folks see as being cheap and as a way to implement such 
policies, whether baby steps is enough. Shane Kerr, BII, said there 
are privacy advantages to resolvers as well because the queries 
don't go to the authority servers so there is a tension there. He 
said that for maximum privacy you need to look at the balance and 
the unanswered research question as to what the right balance is 
between having one or a set of resolvers and it probably sits 
somewhere in between where we are today where you have no privacy 
and Tor. Paul Hoffman, ICANN, said this was discussed in the IETF 
dprive Working Group and there were two main drivers away from 
recursive to authoritative or even stub straight to authoritative. 
He said in order to do effective crypto, the authoritative servers 
would have to be promiscuously allowing easy CPU denial of service 
attacks, which is why there has to be baby steps. He said the other 
driver is that people have a relationship somewhat with a recursive 
and why break that by jumping immediately away when those are the 
ones that could actually handle CPU denial of service attacks 
because they already have ACLs, which the authoritatives don't. He 
suggested looking in the dprive archives and that discussion was cut 
off at stub 2 resolver.

Tim Wicinski, IETF dprive WG co-chair, said to do recursive not just 
involves technology but ICANN. He said the root server operators 
basically have to get involved which means an involved non-technical 
process. He said they were trying to prove that TCP can be scaled 
for DNS at very high rates and that is why this is a great idea.

Duane Wessels, Verisign, asked if getdns had implemented the strict 
authentication yet and Sara said that it had.

Kaveh Ranjbar, RIPE NCC, took an action on the RIPE NCC to create a 
lightweight plan on the DNS Privacy Public Resolver initiative, not 
mentioning who will operate it, and if people agree with that plan 
we can move forward from there.

H. Shane Kerr, Beijing Internet Institute, Yeti DNS Project

Shane said that he sent an email to the working group mailing list 
asking the RIPE NCC to operate a Yeti root server and possibly 
resolver if that makes sense. He said Kaveh Ranjbar from the RIPE 
NCC was very supportive. He said he didn’t think it involved very 
many resource requirements it would be very helpful.

Jim Reid, DNS Working Group co-Chair, asked if a definitive end date 
for the project could be published as many of these projects seemed 
to start and go on without a fixed end date.

Shane said this is a three-year project and it is currently on year 
two.

Kaveh said this was an interesting research project and that he had 
one concern that Yeti was a parallel root and because the RIPE NCC 
is a root operator and there needs to be a technical safeguard there 
in case Yeti wants to go a separate way from the IANA root zone 
file. Kaveh said he also had a lot of personal trust in Shane and 
other involved parties, which made him feel good about this 
particular project.

Shane noted that the coordinators of the WIDE project in Japan who 
also run such a root server probably have the same concern.

I. Panel on DNSSEC Algorithm Flexibility Ondřej Surý, CZ.NIC, 
chaired a panel discussion on DNSSEC algorithm flexibility. The 
participants were:

• Ondřej Surý, CZ.NIC • Lars-Johan Liman, Netnod • Marco D’Itri, 
Seeweb • Dave Knight, Dyn • Phil Regnauld, Network Startup Resource 
Center

The participants introduced themselves, talked about their 
backgrounds with DNS and also explained what their DNS set-up was.


Ondřej asked, if the ed25519 draft is approved this year, how long 
would it take to deploy and possibly start signing the new 
algorithm.

Lars-Johan said it depends on where the requirement comes from in 
the DNS community and also goes what is going on with software 
development.

Marco said he saw no major roadblocks to upgrading if some important 
feature would be useful. He said the only problem would probably be 
the PowerDNS held-up-based platform because that backend is not 
currently maintained.

Dave said his organization was not doing a lot of signing but they 
do serve a lot of signed zones on behalf of customers so it's quite 
easy to be reactive, particularly on the TLD platform. He said 
demand was customer-driven and they used off-the-shelf, open-source 
software so it’s quite easy to react to a customer who wants 
something new.

Ondřej asked if it was safe for DNS cookies when the customer asks 
you if will be able to deploy it and Dave said it very much was.

Phil said his case was similar to Marco’s but he would see how it 
goes on the operational side before recommending others to do the 
same.

Ondřej asked if there is anything that can be done to made these 
issues more known within the community of people running DNS 
servers.

Peter van Dyke, PowerDNS, said the PowerDNS panel has been reverted 
into maintenance but they are looking for competent users.

Lars-Johan said it's very important to get the package maintainers 
of the operating systems on board because that is how things are 
distributed. He also disliked automated updates but said they were 
useful and actually enhanced things in general.

Marco said that outreach from protocol developers at the events like 
RIPE Meetings is helpful but for the vast majority of users probably 
new features should be pushed and advertised by the software 
vendors.

Dave noted that with DANE it's browser vendors who drive a lot of 
what the user requirements are.

Phil said if there was a place where users could click and check if 
zones are signed then there could be more demand from the customer 
side.

Lars-Johan said one of the problems is that the DNS is not viewed as 
an application; it is an application but it's the glue between the 
operating system and the network and the application that you 
actually want to run. He said no one runs DNS because they want to 
run DNS; they do so because they want to reach other services. He 
said we need to work together so it is seen as a service on its own.

Ondřej reiterated what Phil said and thought there is or was a 
DNSSEC name-and-shame webpage somewhere that gave A+ ratings.

Lars-Johan agreed it should come with the web services, that it 
should check the DNS as well because what you are checking is the 
web service or the SIP service but this is not in their minds.

Ondřej said this was quite a clever idea, if you could get the SSL 
labs to include the DNSSEC test even without counting the score.

Benno Overeinder, NLnet Labs, said there was something like this on 
the website internet.nl and it's a cooperation of organisations and 
they work together to check if ISPs and service providers provide an 
up-to-date Internet. He suggested this is an idea that could be 
exported.

Ondřej said the experience from the Czech Republic was that although 
they tested banks and other websites, they didn’t see it as a 
problem.

Paul Hoffman, ICANN, said the last couple of comments were maybe 
aimed at the wrong people who would be helping here. He said people 
who are running a DNS server intentionally probably update it. He 
said there are two classes of software: ones that don’t get updated 
until the whole distro gets updated and ones that do in between. He 
thought that simply getting the authoritative and recursive servers 
upgraded to the software that gets updated in between would greatly 
increase the amount of people doing DNSSEC. Marco said this would 
probably not be possible because there are categories of software 
that are updated in stable distribution and those containing 
sensitive things such as important software or browsers.

Dave said the DNS community is obviously very enthusiastic about 
DNSSEC and want to see it innovated at pace but to everyone else 
this is somewhere lower in their concerns and is something they want 
to be conservative about, which is understandable for operating 
standard maintainers.

Peter Hessler, Hostserver, said for this exact reason they had a 
policy of making a release every six months because when you have a 
five-year release cycle then it can take ten years before something 
shows up in the wild.

Peter Koch, DENIC, noted that some people running critical 
infrastructure wanted fewer features, not more. He asked the panel 
how many features are desirable and are we receiving good guidance 
from those producing the standards.

Lars-Johan said, from a root server operator's perspective, agreed 
with Peter that stability is absolutely paramount and more features 
and more diverse code always brings more bugs, which can have an 
influence on stability. He said this is why root server operators 
want to see what the general trends are before implementing new 
features.

Shane Kerr, Beijing Internet Institute, asked the panel if they ran 
RRL.

Lars-Johan said I-root does other forms of limiting but not RRL, 
although it is on their roadmap.

Shane said it is a feature that at least some of the root operators 
do implement, and root operators are like everyone else in that they 
want good features rather than bad or unnecessary features.

Lars-Johan agreed and said the root operators were not driven by 
customers in but by the general community and what they see as 
useful options.

Marco said customers do not push for new features so they themselves 
have to do some pushing of useful features.

Phil said if the software is not visible enough then it doesn't have 
enough user attention. He said it’s not a solution per se, but if 
you want the software to have more visibility and dynamics then you 
should move it closer to the user.

Niall O’Reilly said the motivation driving all of this has to come 
from the business cases of end customers like banks and insurance 
companies. He said the DNS community needed to sell the advantages 
and he wasn’t sure how that could be done.

Ondřej said the goal of this panel was to address this issue.

Lars-Johan asked Niall if the last time he updated his browser it 
was because he needed a new feature, and Niall said it wasn’t. 
Lars-Johan said the same goes for the DNS users but the browser 
vendor saw that it would be good to update because it would make new 
features available to other people in communication with you. He 
said the benefits of updating may come to the overall system rather 
than to the individual user.

Niall said it was not about incremental upgrades to this or that 
component but rather it was about promoting and selling the 
ecosystem.

Lars-Johan responded that you couldn’t motivate people unless they 
have the software with useful features that they could try out, and 
Niall said this was a fair point.

Vicky Risk, ISC, suggested that people care quite a lot about Google 
rankings, so if you could have the ranking applied there then that 
would make people take notice. She also suggested that the idea of 
cyber insurance would be worth looking at because if you don't have 
your zones signed and people can phish your customers pretending 
they are sending email from you, that potentially is in the big 
money category for cyber insurance.

Ólafur Guðmundsson, CloudFlare, said the panel is very useful to 
look at the one small part of the equation: the DNS ecosystem 
consists of producers of DNS answers, the consumers of them and the 
verifiers and there is something in the middle that enables the 
distribution of DS records. He said when a new version is going to 
be available to distribute through the EU registries, registrars and 
hosting providers that is going to take a long time. He suggested 
concentrating on the middle section and making it more automated. He 
concluded that DNS was not sexy and we need to decide what we want 
to break, and if we do break something it should be RSA.

Florian Streibelt, speaking for himself, said when Google started to 
rank pages based on things like HTTPS it added pressure, which was a 
good thing. He added that the DNS community is doing a very good job 
in not breaking things, unlike with browsers that won’t show Youtube 
if you don’t upgrade, so maybe DNS is a victim of its own success.

John Dickinson, Sinodun, suggested that if some things were 
classified as security enhancements rather than features then that 
might be productive.

Alfred Jenson asked, given how far behind DNS is when it comes to 
modern cryptography, how do you see transitions in the DNS system to 
a world where we have quantum computers?. Marco said it was still to 
early to answer this but it would be a good topic for someone to do 
research on.

J: AOB

There was no other business at the working group session. Jim 
thanked everyone for their participation and said he looked forward 
to seeing everyone in Madrid for RIPE 73.