You're viewing an archived page. It is no longer being updated.
Date: 28 October 11:00 - 12:00
WG co-Chairs: Joao Damas; Shane Kerr; David Knight
Scribe: Marco Schmidt
Status: Final
David Knight started the Working group (WG) session with administrative matters. There were no requests to change the agenda. Also, no minutes of the previous meeting needed to be approved as the WG didn’t meet during RIPE 80.
David continued with the selection of a co-chair. The term of João Damas as Chair is ending. João was also the only candidate for the next term and hence that there was consensus that he would continue in his role as WG co-chair. David added that fresh blood is needed and next year there would be another chance when his term ends.
Anand Buddhdev , RIPE NCC
Presentation available at:
https://ripe81.ripe.net/wp-content/uploads/presentations/37-RIPE81_DNS_Update.pdf
Shane Kerr informed that there are three questions that people have asked in the Meetecho.
Ave Ozkal, Lasagna Ltd., asked about if Anand had looked into why there was a substantial rise in query volumes in April and whether it was related to lockdowns.
Anand responded that they did try to look into this and that they couldn't quite figure out why the query rate suddenly increased. The focuses were somewhere in Asia mostly, but there was no clear correlation with COVID-19. An interesting aspect was that the query rate went up at Neustar servers but not at the other name servers.
Shane commented that if this was in Asia it could possibly be linked to how anycast is set up.
Anand replied that while that couldn’t be ruled out he didn’t have a clear explanation at this point either.
John Bond, Wikimedia, asked if they saw a corresponding increase in queries to the other servers once they stopped using Neustar?
Anand confirmed there was an increase in the query rate at the cluster, but it was not substantial. The query rate went up from roughly 800 queries per second to something like 1,000 queries per second. An increase of 200 queries per second is not much for their cluster.
Geoff Huston
Presentation available at:
https://ripe81.ripe.net/wp-content/uploads/presentations/10-2020-10-27-ripe81-qname-minimisation.pdf
Kris Shrishak, TU Darmstadt, asked which vantage points were used for the experiments.
Geoff responded that they used an online ad that enrols users from anywhere so long as they see the ads. They aim for the recursive to authoritative, and they run three authoritative systems, one in each major area of the globe. The latencies aren't that bad, they are not brilliant, but in some ways because they are testing people and the resolvers they use, the vantage points on the authoritative side don’t really matter.
Lars-Johan Liman, Netnod, asked Geoff if he has looked at all into technical consequences of doing query minimisation? Do things happen to the DNS system in general in the large scale such as shifts in query patterns?
Geoff replied that the only place where there was some degree of controversy was in the behaviour of some content data network providers who were doing quite complex CNAME mapping when they got a target name, and they were moving it to an alias where the domain name was sitting inside the CDN itself. CNAME mapping really had some issues with partial names. He suspected that trimming down to only three labels actually avoided the problem of CNAME mapping inside CDNs.
He added that the other issue is the empty non-terminals and what happens when you ask an abbreviated query where the string inside the zone actually is. A.B.C.D, it's a non-delegated stream. If you only ask for the A part, it's an empty non-terminal. It's not an NXDOMAIN. The answer should really be to keep going, to expand the name form. He was unsure if compounding names inside DNS zones was actually a problem in QNAME minimisation. It shouldn’t be, as long as the authoritative name servers actually understand what’s going on and give the correct answer to a partial query.
Lars-Johan followed up and asked whether the hidden non-terminals were the reason for not using query minimisation with more than three labels.
Geoff answered that this wasn’t a good reason for not doing it because for most recursive resolvers and most authoritative servers, the authoritative servers give the right answer. The issue is that it is less efficient in those situations because the full query name amounts to massive privacy leak, but you aren’t trying to find where the zone cut happened. If there wasn’t a zone cut, it just worked, which is the trade-off here. On the other hand, a lot of people, who are not root server operators, are privy to your query and make a business out of this. This will stop authoritatives who are high in the tree from knowing what’s going on lower in the tree. Recursive resolvers always have all the information and QNAME minimisation doesn’t change that.
Andrew Campling
Presentation available at:
https://ripe81.ripe.net/wp-content/uploads/presentations/34-Ripe-DNS-WG-Developments-in-encrypted-DNS-20-10-28-.pdf
Seyed Ali Mirheidari, SINET Co., asked if there is any report or study about DNS encryption load on CPUs?
Andrew said that there have been conflicting reports on that, but Comcast didn’t have concerns in terms of it being a significant load. BT and Akamai did some work on that. Recent reports from those actually seemed to be suggesting it's not as bad as the modelling had originally suggested.
Thomas Schäfer, LMU, asked whether there were any studies about conflicts involving DoH and DNS64. He added that he was aware that there are some providers, but it has to be set manually.
Andrew replied that while he didn’t have a definite answer to that, he was not aware of any conflicts.
Benno Overeinder, NLnet Labs, commented that DNS Open Source software developers have those supported in their most recent resolver or proxy resolver. ISPs have different options to implement DoH support in their own network.
Andrew agreed and added that he knows a number that are using PowerDNS in particular, like Quad9, DT and BT and maybe Comcast. Other vendors are also available. He added that tools are starting to be developed now to detect the DoH streams, some tools out there claim a 95% rate.
There was no other business, David thanked the WG and reminded the attendees that there are remote DNS Working Group sessions, roughly every three weeks, with the next one on November 18.
The end of the session.