You're viewing an archived page. It is no longer being updated.
Wednesday, 16 May, 9:00-10:30
WG Co-Chairs: Dave Knight, João Damas, Shane Kerr
Status: Final
David Knight asked for comments on the minutes for RIPE 75. There were no comments and the minutes were accepted.
The presentation is available at:
https://ripe76.ripe.net/archives/video/35
Geoff Huston, APNIC, commented that results are dependent on the way names in the zones are distributed.
Petr replied that this is true, but that real world zones were used where names are not universally distributed.
Warren Kumari, Google, commented that it would be nice to also show CPU utilisation.
Petr replied that the CPU utilisation on the recursive resolver is always 100% because it is under attack.
The presentation is available at:
https://ripe76.ripe.net/archives/video/38/
Iljitsch van Beijnum, Logius, commented that the resolver EDNS 0 size was ignored, if it supports 2k and not 3k then this will lead to issues.
Geoff replied that buffer size set by the client is a suggestion, but the server can decide what it wants to use.
Iljitsch asked why so many people have issues with fragmentation.
Geoff replied that cheap firewalls cannot deal with fragmentation and drop packages.
Iljitsch asked if ATR basically gives up on fragmentation.
Geoff replied that ATR can make things fast for big answers, if they are possible. But it won't fix everything.
Warren commented that his experience as a user is that it just works.
Geoff replied that they ran 55M experiments, but they were pushing reality: if everyone validated results would be as shown, but in reality, not everyone does.
João Damas, APNIC, replied that once caches figure out the response results are better for users.
Lars-Johan Liman, Netnod, asked if people who suffer from UDP fragmentation issues would not be likely to suffer from fragmented TCP as well. He suggested that this presentation should be given to firewall and network people.
Geoff replied that only the DNS relies on large packets in UDP - so it really a problem for the DNS community.
Jen Linkova, Google, commented that IPv6 performance here is comparable to IPv4. >Shane Kerr, Oracle/Dyn, relayed a question by Radek Zajic from the chatroom: "Is there a test query DNS server, can you run this yourself?". Geoff replied: no, there is a large amount of work spent on custom responses.
The presentation is available at:
https://ripe76.ripe.net/archives/video/41
Matthijs Mekking, Oracle Dyn, asked whether the publication and propagation delay were only taking the DS into account, and the research looked at when the DS records reached the caches and name servers.
Moritz confirmed that that was what was shown in this presentation, but the other stages were also measured.
Matthijs asked if the timings match the equations in RFC 7583.
Moritz replied that some resolvers stretch the TTLs.
Matthijs and Moritz concluded that the equation is very conservative, and a lower number can be expected.
Lars-Johan Liman, Netnod, asked how t0 was determined for measuring the delays. Moritz answered that this was determined by the first time the DS was seen in any of the RIPE Atlas probes.
Lars-Johan commented that OpenDNSSEC can automate the rollovers.
Petr Spacek, CZ.NIC, commented that no one should ever try to do an algorithm rollover manually. He asked if OpenDNSSEC can automate this and then commented that KnotDNS can automate a roll over.
Benno Overeinder, NLnet Labs, confirmed that OpenDNSSEC version 2.0 and newer can do an automated algorithm roll over.
Ulrich Wisser, ISS (the registry for .se), thanked NLNet Labs and SIDN and commented that monitoring helped to give them confidence.
Anand Buddhdev, RIPE NCC, commented that all root servers publish RSAC 002 version 3 stats with publication times, that can be used to propagation delays.
Wednesday, 16 May, 14:00-15:30
Scribe: Hisham Ibrahim
João Damas, DNS WG Co-Chair, informed the working group that the current working group chair selection process may be unfair, so the process will be modified so that there is an open period and once that is over, all candidates will be published at the same time
The presentation is available at:
https://ripe76.ripe.net/archives/video/56
Ondřej Surý, Internet Systems Consortium (ISC), stated that Qname minimisation in BIND would be ready for the next RIPE Meeting and that they are also working on DNS over TLS but it might take more time.
In a comment about sharing any issues the RIPE NCC team has faced with implementing DNS over TLS using KNOT and especially with Qname minimisation that it is best if the RIPE NCC teams talks to everyone about it as there is still “A lot of brokenness with it”.
The presentation is available at:
https://ripe76.ripe.net/archives/video/59
João asked for clarification on the process. Anand mentioned that board approval was needed on the new 100 G K-root site, adding that the 100 G equipment would come with additional costs, thus the board approval was needed.
The presentation is available at:
https://ripe76.ripe.net/archives/video/60
Benno Overeinder, NLnet Labs, asked if Vicky had a way to gauge the significance and commitment of the people that filled in the survey.
Vicky mentioned that based on her conversations with others, she did feel it was a significant issue to them. She continued that a lot of interesting information is in the comments filled with the survey but she had been asking Geoff Huston to run tests in the wild.
João stated that there might be a little bit of bias in the population. Vicky replied that this is why she ran the survey both on the BIND download page as well as social media and some of the comments implied that they were not using BIND and that they already had Qname minimisation.
Matthijs Mekking, Oracle Dyn, had a question on whether the survey showed if there was demand from the operators.
Vicky replied that more work needs to be done there and we should pay some more attention to what is going to motivate the operators to deploy it and investigate the obstacles a little bit more. As for next steps, ISC plan to make Qname minimisation the default setting.
Victor Kuarsingh, Oracle Dyn, queried about the survey’s ability to differentiate decision makers from non-decision making operational staff.
Vicky agreed that there might be need for follow up there. Vicky went on to say if she were to run the survey again she would add a question on how many users the person filling the survey is supporting, to give a better understanding of the data.
The presentation is available at:
https://ripe76.ripe.net/archives/video/63
A number of questions were asked about TCP tuning. Baptise confirmed he did it as part of his work. There were several comments congratulating Baptise on his work and comments that there needs to be a lot more work done in this area. João stated that maybe the work suggested that they need to change their mental process of how sessions are established in DNS.
The presentation is available at:
https://ripe76.ripe.net/archives/video/64
Ondřej Surý, ISC, and Phil Stanhope, Oracle Dyn, both suggested a little more follow up is needed for more insights.
The presentation is available at:
https://ripe76.ripe.net/archives/video/67
Jelte Jansen, SIDN, asked what if the address was already hijacked the moment the validation took place from the certificate authority.
Willem acknowledged his point, and Jelte went on that there was no answer for that in DNSSEC either.
Phil Stanhope, Oracle Dyn, later commented on this saying that the ACME protocol was about to adopt a multi-challenge scenario to avoid or try to manage DNS poisoning and DHCP path poisoning. He added that is wasn't live yet, but there will be multiple concurrent challenges and that had to be baked into the protocol.
Matthijs, Oracle Dyn, commented that with this they might not need DNSSEC but it was still nice to have both.
Ondřej commented that he didn't think that DNS over TLS could replace DNSSEC, as it provided the authenticity of the data while DNS over TLS provided authenticity of the channel.
Willem commented that it was a matter of who you want to trust.
Warren Kumari, Google, stated that DNSSEC allowed you to grab the whole zone and he was not sure if this could allow that or not.