You're viewing an archived page. It is no longer being updated.
Date: 16 October 09:00 - 10:30
WG co-Chairs: Joao Damas; Shane Kerr; David Knight
Scribe: Marita Phelan
Status: Final
Petr Špaček
Presentation available at: https://ripe79.ripe.net/archives/video/198/
Benno Overeinder (NLnet Labs) thanked the speaker and asked if the arrival rates and the arrivals were both compressed, and if so, whether the speaker had looked at the statistical characteristics of the compressed log as it would depend on if it was a poisson arrival process or not as to if they would be independent statistical events and if you could compress them or not. The speaker replied that the theory is generally based on the law of big numbers. They agreed to take the discussion offline.
Brian Tremmel (DE-CIX) asked if the speaker had a plan for how he's going to do DoT DOH encrypted things? The speaker replied that that was also a much bigger discussion and that they could discuss it in the hallway later.
Kostas Zorbadelos (Canal+ Telecom) commented that when you try to measure a server, you don't know if you've hit the limits of the server or of the tool that you're using to measure. The speaker replied that they have developed a little BPF programme, which is running inside the kernel and shoots the answers back. If you replace the DNS resolver with that, it will shoot back whatever comes in, which means the numbers will be much higher. Kostas asked if the server and the measuring tool run on the same hardware. The speaker replied that they were in a rack next to each other connected by a network cable.
Warren Kumari (Google) commented that they should keep traffic type shift in mind. The speaker agreed that fresh data should be used and not two year old PCAPs.
An audience speaker mentioned that he thought the speaker was about to use something like immersion learning to see the pattern of new clients and wondered if the speaker looked into that as if you take what's later in the PCAP and use it now, it's probably not the same traffic pattern. The speaker replied that it depends on the period.
Pieter Lexis (PowerDNS) mentioned that he uses lots of tiny scripts like this and having something a bit more complete would be nice. They have a tool available and stressed to always anonymise the data.
Neda Kianpour, Tyler Shaw
Presentation available at: https://ripe79.ripe.net/archives/video/200/
Eduardo Duarte (.pt) mentioned that when you're configuring F5 it auto-rotates the key and if the speakers were aware of that. The speaker replied that there are standard timings in the default set up and that people need to set those themselves.
Peter van Dijk (PowerDNS) asked what they can tell people who experience broken F5s. Can they get the same hot-fixes? The speaker said that a number of fixes were already in the code and had already been mentioned in the presentation and have been back-boarded to version 12. If the bugs aren't addressed in your current version, you can report the specific bug ID in a support case to F5 for a hot-fix.
Austin H. Hounsel
Presentation available at: https://ripe79.ripe.net/archives/video/201/
Jen Linkova (Google) commented that it would be really interesting to see the measurements from real devices because what you are going to see in real life when you are using normal DNS is that the response will be coming from something which sits much closer to the user and pretends to be the real resolver. Therefore the response time in UDP would be much faster than for encrypted protocols. The speaker replied that that they are trying to perform measurements from white boxes within residential ISPs at the moment.
Jelte Jansen (SIDN) commented that he would also like to see plain text DNS over TCP added as it would tell you whether DOH or DoT have something extra that could explain the differences instead of presuming it's TCP. The speaker thanked him for his suggestion.
Petr Špaček (CZ.NIC) asked if the cache hit rate was taken into account when comparing different resolvers as the long tail DOH version to the cloud resolver would out-perform the local resolver and it might be caused by the difference in cache hit rates as CloudFlare has much bigger cache hits than the local resolver. The speaker agreed and mentioned that the measurements were performed over the span of three and a half weeks and that it may be that what is appearing in the Amazon resolver might not also be within the CloudFlare resolver. They're noticing that the DOH queries are outperforming the DOH 53 in the tail within CloudFlare.
Jim Reid (RTFM llp) suggested that it might be helpful to have a clearer separation between measurements to do with DNS transport and how they are being used by browsers and other applications as opposed to page load times. He also suggested another future project assessing the impact of CloudFlare's lack of ECS support in DOH. The speaker replied that they noted that CloudFlare's page load times, which do not support ECS, were faster than when using Google's resolver which does support ECS. This is something they would like to investigate.
Dave Lawrence (Oracle) made a similar comment, that it would be interesting to compare TCP plain text, but more specifically a deep dive into that would include the difference between persistent connections whether encrypted or not, with not uncommon TCP implementations that don't keep open persistent connections.
Willem Toorop (NLnet Labs) suggested that the speaker conduct a measurement from vantage points that are a little further from the Cloud DNS providers in Frankfurt. For example, what would DNS over HTTPS mean for people in Africa. The speaker replied that he already had some colleagues working on that in a university in South Africa.
Florian Obser
Presentation available at: https://ripe79.ripe.net/archives/video/202/
Peter Koch (DENIC) thanked the speaker for the update and asked that, ignoring Berlin, 7,500 K-root instances seemed to be a non‑negligible part of the overall query nodes and if the speaker had a chance to look into where they disappeared - which other nodes got less load and was it operationally relevant in any case? The speaker replied no, not for those nodes, but that when they brought up type A, they noticed that those queries were not disappearing from K‑root at the sides and that actually they took their queries from other letters and has had no chance to look into where they are coming from.
Geoff Huston
Presentation available at: https://ripe79.ripe.net/archives/video/203/
Allison Mankin (Salesforce) asked if the speakers data shows before and after for the US with Mozilla's decision? As it would be interesting to see what kind of impact a decision about defaulting can have on the overall picture and that could help to justify your picture of the future if you see trends like that. The speaker responded that hard volume data started on June 1 but Firefox didn't turn it on until late September. Therefore you would need the browser fingerprint knowledge to map, so you can can see Mozilla users and the resolvers they use. The data hasn't been analysed yet, but it will be.
Robert Kistaleki (RIPE NCC) noticed that North Korea had a very distinct colour in many of the speakers maps and wondered if that was because there was no data or because they are different? The speaker replied that no, they're not different, that there are mobile phones there, people play games, games have ads and ads run the script. They use Google, and what was seen is Google usage.
Robert also asked if the speaker had separate data for v6 proportions or any data on that? The speaker replied no, that when you do any extension header with v6, the survival rate of that packet through the network is less than 67%. If you are running v6 in the DNS, to think very carefully about fragmentation because fragmented UDP and v6 as a combination is close to toxic which means you have to really wonder how to do a quick fallback to TCP if you are going to run v6.
An audience speaker used the Netherlands as an example that 66% of users in the Netherlands were using their in-network resolvers but only 55% were in-country. He asked if in some of those cases, was the speaker geolocating their network to outside the country? The speaker replied that you might use two or three resolvers for one question because the DNS is extravagant. If you use your ISP's resolver, that's one, if you use a different resolver that is in the same country but not your ISP, that's a different one, and if you use something that's not an open resolver in another country, that's a different country answer.
Pieter Lexis (PowerDNS) commented that the open source DNS vendors are planning to decrease the default UDP buffer size to 1232 by default, so that truncation will happen quicker and there won't be any fragmentation in the DNS packets anymore.
Allison Mankin and Willem Toorop
Presentation available at: https://ripe79.ripe.net/archives/video/205/
Matthijs Mekking (ISC) commented that he liked that the speaker was thinking of the next steps like privacy, not only to the resolver but also for EDF. Referring to slide 12 of the presentation, he commented that he thought it showed that while the change is small you can get a pretty big IXFR. Matthijs also commented that the speaker was looking at performances of this way of doing zone transfers on TLS and wondered how much of this is expert related and how much is generic. And could they apply the same logic on, for example, dynamic updates because these are for a different transport protocol. The speaker replied that they suspected that dynamic updates are from many different clients so there is no longstanding TLS connection. Matthijs commented that the generic answer is probably there is some overlap and some differences and would like to chat about it in the hallway later.
EDDI (https://www.encrypted-dns.org),
Jim Reid
Presentation available at: https://ripe79.ripe.net/archives/video/207/
There were no questions.