RIPE 93. Side room. DNS.
YEVHENIYA NOSYK: OK. I think it's time to start. Good morning and welcome to the DNS working group session. Before I properly start I have a small announcement, the voting period for the PC election closes today at five.
So welcome, if you are here for the first time in this working group, we are interested in everything related to DNS. You will see a lot of discussions about operations, deployments, software implementation and we occasionally DNS research, here's the link to the working group description. Take a look, we also have a mailing list. For the agenda today we have four full talks, we have two talks post quantum DNS and the local route and traditional update from the RIPE NCC, what we did also here was include five minute slot for any other business, because every single meeting we receive requests can I quickly say this or show a slide, this time we have time for those.
You heard us this before but please state your name and affiliation if you are speaking at the mic, if you are joining us online today and you want to ask a question, please use hashtag question, so that we know he can read it aloud in the room and finally don't forget that the RIPE Code of Conduct applies both on site and remotely.
We do know that two‑factor authentication is very painful, but we would really appreciate if you rate the talks at the end of the session because it really helps us.
OK and with that I would like to invite our first speaker Joe Abley from CloudFlare. You have 30 minutes.
JOE ABLEY: Big green button is move ahead, isn't it.
Hello. This is not actually a cryptography presentation, I don't know anything about cryptography so ‑‑ is that better? Anyway.
So at CloudFlare we have cryptographies and we have people who care about these things of things and it turns out that lots of work has been happening not just as CloudFlare by lots of places so we have various algorithms that have now been certified and they have been attacked and they have survived and they have been published and they are ready for use.
And they are all listed here and they are all have exotic times, there's a presentation coming up later about Falcon. Post quantum cryptography is mainstream, I was quite surprised by this, I just pay attention to the DNS which is the most important thing, it turns out loads of work has happened and this is actually just normal now. Like operating systems ship with these algorithms, like Crypto libraries ship with these algorithms, if you look at Cloudfare radar, I think you can see of human visitors on the web traffic that CloudFlare sees about 72% is using post quantam algorithms with a key agreement that makes that possible. Robots are a bit more rubbish in this respect, not in all other respects obviously, I have to mention these things because in the future, robot uprising, I want to be on the side that survives.
So because of all this progress I guess, there are now various clocks, there's a NIST clock; there's a US government clock, if you want to sell to US government agencies, you better be on on this train, otherwise you are not going to make sales. And 2030 is an proximate date, 2035 you won't be able to use these services, this is quite soon. This is a lot of progress, all anticipation of a quantam computer that may or may not exist, it's still impressive.
In terms of the deployment, it's so far advanced that work has shifted to the long tail where we capture data from legacy systems and decrypt it later and these kinds of things, we are looking at the small parts of the problem space that are not mainstream, we have time to look at the long tail and we have years to do is it in. As I said I am not a cryptographer and I think the web was a mistake, we should not have done it, DNS is clearly the most important thing and it's a good job that people in this room, this is a safe space, this room, we can say these things.
DNS people are the ones that actually hold the internet together; if it wasn't for us, the whole thing would have destroyed itself years ago, we are definitely the best ones.
So let's have a look at how things are going with DNSSEC, and post quantum cryptography, because clearly this would be a good story. It turns out we have had lots of attention being paid to this.
There's been lots of presentations, people have implemented things in captive labs, people have run experiments, there have been many graphs, we have had site meetings at the IETF, the whole day of conversations here about all of this stuff and the end result of this is that we have a Root zone that is signed with algorithm 8, we still have we have TLDs that are signed with algorithm 5 and TLDs that are not signed at all. We have AP‑NIX producing regular graphs that nobody is using DNSSEC on the signing side, lots of validation but nothing to Dal date.
A number of algorithm co‑points at the time that we first started looking at this that have been assigned for post quantum cryptography is zero, it's not even a defined algorithm number you can use. None of this has been specified. So the previous slide where all this work has been done and we have done such a fantastic job that we have years spare to deal with the nutty corner cases. DNSSEC hasn't actually started.
Which is a bit terrible really. And it's not just the DNS, it turns out when I was asking some of you may have seen a question I put on the DNS OARC operations list about registries that would even accept algorithm 18, EPP and there aren't any, not a single one. It's not quite true, I had coffee with Garth miller in Amsterdam and he made a merge and infact coco does it now, that's only because I had copy with Garth ‑‑ coffee with Garth, it's not a scalable way moving forward, it's not good, this is my summary for DNSSEC and post quantum cryptography.
I think this is one example of a more general problem and the more general problem is that we are petrified of not using UDP and we are petrified of fragmentation and anything that requires large responses just invites a queue at the mic line and we don't have anybody in the community who is looking at this and saying how can we make it.happen, we mainly have people explaining patiently why it can't happen.
As it turns out is not very useful so we are not really getting anywhere. So while post quantum cryptography might seem like a slightly regulatory compliance type problem to worry about, it's maybe it's not the a real world problem, it's an example of the wider set of problems we have in the DNS and it's affected us for a long time, when we signed the root zone, we added deliberately unvalidatable signatures, specifically because we were paranoid about somebody might fetch these sets and the world might explode and we did for a long time and there was some problems, we worried about response size during key rollovers. And yes there are some problems but there are some problems every day on the internet and again the sky didn't fall. So I think to a large extent we need to get over ourselves.
And a big part of this response size concern is UDP and another consequence of not using UDP is concern, how do we provision capacity in the DNS, our authority server is going to explode catch fire because we asked them to do session management and TLS for every single query, if that is going to make them catch fire, what should we do. This is a presentation about post quantum cryptography but really about the other things, just keep that in mind, we need to talk more about this stuff.
The green button is not working.
RUDIGER VOLK: Don't touch the blue button.
JOE ABLEY: There's a button marked laser, I should do that one R there we go, July, this is just before the IETF meeting in Vienna, this is Bas Westerbaan, a cryptographer that lives in the Netherlands and he has run out of things to do because all the stuff he had been worrying with the web and CDN and stuff like that is done; he got as far as building AI tools to go through the cope base and predict where cryptography is being used because he is looking for things to fix.
So he noticed DNSSEC. It wasn't very good. So in Vienna he wrote a draft and said I am going to propose ‑‑ this is the only algorithm that makes sense, I am going to propose a draft that makes use of this in the DNS.
And a bunch of people said oh, I don't know about that response size, about what TCP, I don't think ‑‑ you are not a DNS person, you don't really understand and Bas has got this technique, he just fixes you with a hard stare until you stop talking and he submitted the draft and he got a code point and we have an algorithm number which is 18 and 18 is ML DSA 44 and according to Bas, partly because nobody wants to disagree with Bas, he knows what he is talking about, is the only practical algorithm we could imagine, they are big responses. The keys are big but not so big. Validation is slightly faster than algorithm 13. Signing is not as fast as algorithm 13 but faster than RSA with 2048 bit keys anyway, it's a reasonable idea, let's try this at least, let's try something instead of just assuming it won't work.
So that was July. We got our code point, there is Bas's draft is still in DNS op. Any DNS op co‑chairs here?
It's tempting to makes comments about DNS co‑chairs but I won't, it's slow growing because the working group is in a state of change and there's a lot of drafts held up. But you don't actually need a published document to get a code point so we have the code point.
We started in October looking at this earlier this month, what can we do with this code point
The first thing we are doing is validation.
Validation is an easy one. Because there are no algorithm 18 signatures anywhere, so the extra cost involved in validating is very much inside our control because we are the only ones signing with algorithm 18 in our test zones, nobody is doing it with the real domain name so we can do this. And this is now ‑‑ Sebastian wrote a blog post about this, the big responses that, the two kill byte responses and this is live in 1.1.1.1 and I am not wearing glasses but DNS test.dev/post‑quantum/ if you go to that in the meeting network you will notice the local resolver configured, I was using a BPN so I don't know about the local network, try it out and find out whether the local RIPE meeting network resolver is capable of validating algorithm 18 signatures and whether it supports down grade protection and some other things.
So this is done, we are finished in the resolver side of Cloudflare, that's finished, put a line under that one, that's good.
So when we implemented it in quad 1, we ran into a slight variation of purpose between approximate post quantum cryptography and how DNS is supposed to work, DNS says if I can find any chain of signatures that works, it's good, I don't care if I found broken ones along the way, I can find one clean path, then this is a valid answer but of course one clean path with algorithm 13 accompanied by broken paths in algorithm 18 is exactly what quantam attack looks like. So that's perhaps not good.
So we have to kind of, we decided if this makes any sense to do, we have to change the validation policy, if somebody signs with something like 13 and 18, and we see signatures with 18, not validating but 13 does validate, then that's bogus. We are going to require 18 to validate if it's present because we think that's the only reason to do post quantum cryptography at all, be resistant against attacks from quantam computers so we did that. I wrote a draft about that, it's not changing the spec, it's just informational.
It's a draft that basically says, it makes a big deal out of two words in the DNSSEC spec, which says all local policy ‑‑ or three words ‑‑ and explains this is the local policy we are doing here and this is why.
So there you go, if you like drafts, go with that one. Now we have some measurements, so oh it's not animated. We should have a respectful pause, when you see this, you have to pause for five seconds.
This little thing here that occasionally asks you to click the button and prove that you are human, in the background is doing a bunch of HTTP fetches, it's doing a lot of measurements and using the resulting heuristics to decide whether you are a human visitor or robotic visitor, the nice thing about this, it runs all over the place, 25% of the internet runs through CloudFlare as measured by marketing people, we get to run code on a lot of browsers around the world like YouTube and we can run experiments on this. So there is an experiment running right now. This is running for I think three weeks, there were some initial problems with the code and a couple of weeks ago there was other things that kept us busy so this is a little bit new and there isn't very much data but the challenge Java script fetches four individual unique objects over HTTP and HTTPS in parallel and each data point is four tuple and that four tuple represents one name that's signed with 13, which is C, the control, one that signed with 13 but the signature is broken, which is B, and we use this to detect things nor not validating. One that is signed with algorithm 18, which is the post quantam ML DSA 44 and one that's dual signed which 13, which is what you would expect to do in the wild, we expect there to be a time when people can validate one and not the other.
To so these fetches can succeed or fail with an error or time out and the experiment has a lot of noise because these HTTP fetches currently involve redirects which takes time if a user solves the challenge within two seconds the experiment ends early, sometimes we get results that are larger than two seconds and I don't know where that is, I am sure somebody does.
And of course it's home networks, it's browsers, all kinds of stuff. The other big one, in this initial external the DNS names as the same every time, there's no random available to make sure you are not reading from a cache, that's a big source. These results are garbage basically but they are some results and we are going to continue doing experiments, a lot of things have been fixed now and at the OARC meeting an updated set will be sent and we'll see where the observations are still holding; these slides are based on 142,000 four tuples and a sample set of challenges one in a thousand bun running for a couple of weeks.
Disclaimer, we do mention some actual AS numbers about where we see problems from, these are not real results. Think of it as an encouragement of people who know AS numbers, get in touch and we can figure out what weird things happening that we can fix together and CloudFlare is on the AS list that's got problems. We are not blaming anybody else for anything, other blaming ourselves for things or both.
All right. So in addition to not being a cryptographer, I am not a research scientist, I feel like together we can get through these scary graphs. What we have here is a set of D minus C, the difference between dual signed responses measured in milliseconds and the control which is just signed with algorithm 13, how long how much longer it it take to... compared to algorithm 13 or 13 plus 18, dual signed, they both log scales and SIM log scales I had to look up. It's telling us towards the middle of the graph here, we see first of all across most of the Grafana, we we so see a close alignment between the dotted line and the blue line, the dotted line is non‑validating, we are getting responses from the broken signature, the blue line is D minus C, difference between dual signed and control and we see this basically identical all the way through which is god good, it's what we expect to see. What we also see is a difference for D minus C on validating resolvers, so when you have a dual sign, you end up seeing extra time taken and this is the, for example ‑‑ I am not going to try use the laser, it seems dangerous ‑‑ the right hand box with an arrow pointing up, you can see a difference there, the dual signed responses are causing extra fetch times, against very early data, not many data points but it seems like it's taking longer, some of these delays are due to TCP re‑tries, either in receiving the response in the first place or maybe somebody is looking up a DNS key in order to do a validation and those are also falling back to TCP, you could imagine different reasons in the DNS why there's extra time here.
But this is the performance graph. But performance in the web sense is how long does it take to load something, not in the DNS sense or how high is my CPU based on a certain query load.
So the take away from this is that there does seem to be a performance hit but around the middle of the graph, around the median, they are quite similar and it's really only the outliers where we see a significant difference in performance.
So this the next three graphs are to do with breakage. So in this case we have net breakages as a percent on the Y axis, the right‑hand side is time and we are looking P versus C, P is a signature with algorithm 18 and C is the control with algorithm 13 and how often do we see these things break, we got an error or time out and as you can see, we see more brick age with the signatures from algorithm 18 than we do with 13.
Which I think we expected, the interesting thing is how much breakage, the reason for doing these things is try work out is this deployable, if there's too much breakage, it's not deployable, a small amount of breakage, maybe we can tolerate.
This is the second last graph, we are almost there. This one is looking at, the grey bars here represent noise, these are cases where we actually got a positive response from the post quantam signed name and we got breakage in the control. So I think this looks like a noise flaw, you can imagine the grey box as being the noise because there's a lot of noise in the experiment and the difference between the red and pink and grey represents the difference for the post‑quantum case, you see the bars get bigger towards the right and the X acquisition, these are buckets of how long it took to get a result from a particular experiment. So the left‑hand two bars are less than 500 milliseconds going up to 1500 on the right, but remember they are capped at two seconds. There's a bunch more time outs happening towards the right than the left, as we move to the right we are seeing error bar increasing because of the effect of the time out.
The difference between the red and pink is that red is a hard failure and pink is a timeout and timeouts can happen for multiple reasons, they could be all DNS failures or other things related to the nature of the experiment and the users performance in clicking a button.
So this doesn't tell us very much but it tells us that we do see breakages more in some cases significantly more than the baseline, this doesn't look too promising, the thing that does look promising, if you try group these things together by AS number this is likely far too small to read, if you want to read the actual AS numbers, you can look at the slides.
What it shows is for about 20 ASes in particular a couple at the top, there's a significant amount of breakage that we see with post‑quantum signed names, but for the vast majority of the names, there's no difference, this is encouraging, if all the breakage is isolated at 20 ASes, we debug 20 ASes, that doesn't seem to too bad, it sound like the problem we had with 1.1.1.1 that was a burnt network, now I can use it, this is a problem we can imagine solving.
Having said that, this is a very initial results and it's quite possible a lot of those time outs they are DNSSEC problems in which case it will be different, there will be more in Vancouver.
OK, signing is a much shorter story because much of our effort has been concentrated on validation. So if it looks like we can deploy this stuff without breaking things, we will implement this in the online signer on CloudFlare's AuthDNS.
Even if if there is significant breakage, we might implement it because we have customers required for compliance reason to support these algorithms and if they are required to do it and we are required to do it to sell them a service, we are going to do it. In that case it's not going to be on by default, we'll probably sign with 13 only and 18 plus 13 will be on opt, if we find a way of convincing ourselves that 18 is safe, perhaps we'll turn it on by default and that will be the pair we use, 18 and 13.
So I refer to this obliquely earlier, that you can't actually register domains and use algorithm 18, there are some registry operators in the room and there are two things I would like registry operators to think about, first of all, it's really hard to do ‑‑ find out what you do allow, you have to ask favours on mailing lists to try find out. Normal people can't do this. There's very few people who actually publish their policy. You effectively have to be a registrar and try it and most people are not registrars. So this is kind of a problem. And it's not just a problem for post‑quantum stuff, it's a problem for any new algorithm we want to deploy in DNSSEC, there's some people who only support two or three different algorithms, two of which are or one of which are not recommended anyway.
So there's a draft with a link at the bottom, this is trying to propose a policy itself, it's saying let's use the policy in the IANA registry, it's already there and maintained about what is recommended and what you shouldn't use and things like that, let's just use that as the reference point for registries, and I think this will be great. If anybody has ideas how to push this either in their ccTLD community or in the gTLD world as ICANN, I will be all ears. Ssec were excited about it. I wrote a 16 page charter they will take three years to write that doesn't address it, I feel like we are talking to registries is probably a more effective way.
So here's the conclusion. I am a little bit early.
We are not there yet. We are way behind compared to the rest of the internet, if we imagine that includes the web.
All kinds of work has been done and it's being done to the side of the DNS and we haven't been playing along and we have to catch up. These are ‑‑ this is a starting point really. We are going to continue these experiments at CloudFlare and try hard to find out whether it is deployable and if it is, we are going to deploy it at scale. And we would love to talk to other people who feel like post‑quantum cryptography is something that's worth trying. That's it.
(APPLAUSE.)
YEVHENIYA NOSYK: Thank you very much, we have five minutes for questions.
JIM REID: Jim Reid, a burn out DNS engineer for Scotland, thank you for the talk, it's very informative and useful to say where we are with post‑quantum cryptography, do you know anybody else doing a regular study of all this stuff, I am not trying to down grade the work you have done, it's very rough and ready as you have said, is there anything doing a more detailed regular analysis of that, I think we have to get more data how viable these potential solutions are going to be.
My second question ‑‑ I will throw them all at you. My second question: Do you see some value later on in either having a big bang theory we just switch off from using... over to post‑quantum cryptography or would you think a bit more prudent approach would be run these two things in parallel, doing your existing signing with bringing in a post‑quantum cryptography as well, what approach do you think is more sensible?
JOE ABLEY: CloudFlare does have a research group with people who would publish, publish something good, the code point of algorithm 18. This experiment is a couple of weeks old, the code point is four months old, as I said, nobody can register domains for this. It's very difficult to imagine being close to experimental results now in an academic sense, but I think it's fair to say we would love to talk to researchers and I bet we could help. That's the first question.
Second question about how does deployment work, I think it's way too early, it would be great to have the problem of wondering how we deploy these things, today we have got TLDs that are not signed, people are signing with algorithm 5, MD5 is still live somewhere in the DNSSEC and I think if we were in a situation to imagine how do we do a big bang, I don't know what a big bang looks like, some sort of failed fire work underneath I don't know a rusty cow, that's a bad analogy, I don't think we are close to being able to make a constructive suggestion around that stuff.
JIM REID: I think someone has to start thinking about deployment and implementation strategies to get further down this path of post‑quantum cryptography, one last point, you tried to to get registry adoption, I know you are trying to push through the IETF, but I think the way to make progress will be ccTLDs rather than gTLD, down that route you need to go through some kind of ICANN policy procedure and that will take forever, that's the nature of the beast at ICANN and you will find the gTLDs are more resistant because... we need to consult this, we need to consult this, it might be easier with ccTLDs.
JOE ABLEY: Lots of the ccTLDs are active in Reg X. The nice thing about the gTLDs, they tend to incorporate IETF standards in the language in contracts, it's possible there's a short‑cut there, we'll see.
JIM REID: I'm trying to get the ICANN policy stuff trait end out saying you must do X can take a hell of a long time.
AUDIENCE SPEAKER: Do you have any other affiliation besides Scotland?
JIM REID: No. Is Scotland not good for you?
AUDIENCE SPEAKER: We have a policy of stating affiliation on at the mic,
JIM REID: Okay, if you want more clarifty, I have a small consulting company, RTFM, which is based in Scotland!
AUDIENCE SPEAKER: Suresh, talking an as member of internet architecture, we did have a workshop recently and I would love to see this as a question paper there, since you said it's only four weeks old, I forgive you for this, I think one of the things that came up was the size of the signatures was like a big issue and one kind of solution that was like thrown about was the Merkle tree ladders, have you looked at it and I know it works for the authoritative server said, is it something you considered.
JOE ABLEY: The authoritative side is the only side we care about, downstream of the resolver you are sending a one bit, you are doing it over encrypted transport if you care about the integrity of it, on the authoritative side that is the place where something like M T.L. could have a place, the trouble is M T will is not a simple drop and replacement, it requires protocol changes and I don't know how many decades have been doing protocol changes, they are not quick. So I think the short answer is if we can make it work with the protocol as it's defined right now, that's by far the preferred approach, if we have to resort to something else with balanced Merkle trees and signed hashes and hashes of signatures on leafs, then yeah I guess it's better than nothing, at that point it sounds like DNS has failed, we want to see if we can make DNS work first.
AUDIENCE SPEAKER: The reason I brought it, you see the M TC effort happening with the...... I know you didn't care about you I was going to say you need the web to do the HTPS. I would like to chat more with you.
AUDIENCE SPEAKER: Have you done any observations on the TCP traffic and the balance between UDP and TCP that gives any hint on anything?
JOE ABLEY: We haven't yet, we have a parallel effort that I will talk about in Vancouver, which is about using secure transport for authority servers and in particular planning experiments where we can actually measure the impact of doing this in terms of different pipelining approach and different bundle management approaches and the impact on CPU and RAM and state of the authority server, I think most of the problems we find around all of this stuff go away if we top using UDP, if it becomes the legacy service that's best effort that's used for the legacy devices that nobody should be using anyway, that's fantastic, this opens the door to all kinds of stuff. To be honest, I think that's the answer to be honest towards all of this, it's another answer for the MTL stuff, we don't need MTL if we have an ability not to use UDP
AUDIENCE SPEAKER: Thanks, see you in Vancouver.
YEVHENIYA NOSYK: Thank you very much.
(APPLAUSE.)
Our next speaker is Ginevra Fabrizio and she'll talk about a format size analysis on format signatures. Thank you.
GINEVRA FABRIZIO: Hi everybody, I am Ginevra Fabrizio. I am here to talk about PQC for DNSSEC which seems to be a hot topic and we did specifically format size analysis on Falcon signatures because there are different types of Falcon signatures. OK.
So I am going to be very brief because this was done for a less technical audience. So DNSSEC introduced signatures, so this is the big point that it is actually has friction with PQC because they are very big and that's the problem. DNS responses, this is the big issue that we have, right, with DNSSEC, they should not exceed the single packet size limit of the 1500 bytes and when this happens, we have fall back to TCP which is what we heard before is not really liked. But DNSSEC responses often contain multiple signatures and quickly exceed the DNS message side and transition to post‑quantum cryptography will get this problem worse.
So, Falcon is considered the also suitable for DNSSEC primarily because it has been selected by NIST for standardisation and Falcon signatures have three different types, compressed format or unpadded, which offers the smallest signatures in average and they are efficient for transmission and storage purposes.
Then there is the padded format, that uses additional padding to ensure consistent size and it's ideal for systems where you like predictability. And then there is constant time format which allows for constant time processing but it's irrelevant to DNSSEC because the content of the DNS signature is not secret.
So we asked ourselves can this really make a difference, Falcon padded signatures have a fixed size of 666 bytes, while unpadded signature size, they are variable and they are between 610 and 670 bytes.
So does this impact DNSSEC, we want to explore in unpadded signatures can be more attractive for PQC DNSSEC. So to do this we analysed data from the n.nl DNS signed zone and we captured data over a 24 hour timeline and selected the two most common response codes, which is NX domain and no error.
And here we compared the formats: We have a CDF showing the no error responses with Falcon and we can see that the majority of them fit between the limits, but non‑negligible amount, they go over the MTU limit which is showed here.
And here we can also see the difference between padded and unpadded, it's not that, not really significant.
And while for NX domain responses with Falcon, all of them exceed the MTU limit, the line is not even showing. And here for NX domain responses, this makes all of the responses need TCP fall back.
Then we also analysed the distribution in domain length and signature sizes and we can see that the variance in domain length is the same order of the variance in the unpadded signature size, right.
And they follow more or less the same normal resolution. So what does this mean? The length of the domain name included in a query contributes similarly to the message size and is the same as the size of a single Falcon unpadded signature.
So here we have a few considerations which we came to the conclusion that the difference between padded and unpadded signature is minimal impact. So even though the unpadded format is slightly smaller than the padded one, the difference in size still doesn't prevent fall back to TCP as we would have hoped. And given the lack of significant differences, the padded format we still think might be a better choice for DNSSec implementation.
This work was done together with Dutch SIDN. And if you have any questions, I am here.
(APPLAUSE.)
YEVHENIYA NOSYK: Thank you very much. Are there any questions?
JOE ABLEY: Joe Able, CloudFlare, you know more about this than I do, by fashion I had heard that Falcon is not quite published yet and there is some question about the use of floating point arithmetic which makes implementation difficult or signing or validating more expensive. Can you say something about that?
GINEVRA FABRIZIO: Yes the thing is that what we thought, I also will be very honest, when I discovered a lot of DNSSEC operators were more into MLD I was quite surprised, post‑quantum signatures are huge and they proceeded to go with the biggest standardized signature which left me a bit OK, I do understand floating point Falcon is scary and NIST said we will standardise risk. They said this last year and did not standardise it yet, so I don't know. If they keep up like the they would say it's OK, this will be standardised because there's a FIPS, I don't know what number because I got all the numbers, there is a document for Falcon to be standardised, I hope they to they do the promise, the floating point might be a problem but in the end you have to choose between a huge TCP fall back or this floating point arithmetic implementation, so like in the end you just have to choose which is the lesser evil.
And also to reply to the question you were asked before, right now I am working with SIDN, we did not have enough time to show other stuff, we are currently working on a testbed that shows resolver side workload and authoritative side workload for a bunch of post‑quantum cryptography algorithms, specifically they are Falcon and MDLSA. Apparently people are also interested in this algorithm and MEO. And yeah, we are just trying a bunch of ‑‑ to see how it works and fallback to TCP is big, like ‑‑ I am sorry I don't have any plots because I received them like today at 6am, I did not want to ‑‑ and the topic of this talk was different. But yeah, I hope to be able to have more stuff to talk about. And also on a side note we wanted to present this very early results we had on our authoritative resolver side server at the IETF in San Francisco I will be going with other SIDN people and we pushed to have side meetings on this and they said nobody is interested and we are like OK.
Yeah, I can't really do anything about it, I just hope I will publish, and if like the CloudFlare people research like to do and maybe that will get more attention, but yeah.
JOE ABLEY: Thank you.
YEVHENIYA NOSYK: Anything on Meetecho? No. OK, thank you very much.
(APPLAUSE.)
ULRICH WISSER: Shane Kerr from IBM asks somebody may have missed detail, but I still don't understand the benefit of the padded version, is it performance or...
GINEVRA FABRIZIO: It's just predictability, like again floating point arithmetic is already kind of scary because it's hard to implement and if you have unpadded version and you get like, you might have a bunch of different bytes, like they are really not predictable, we tried to understand also why, what is the reason that some responses signature were longer but we didn't really come to let's say objective and repeatable conclusion about that. So we think that since it's ‑‑ operators would like to have predictability in their implementation, the unpadded version just adds on top of the already difficult floating interger stuff.
YEVHENIYA NOSYK: Nothing more? Thank you very much.
(APPLAUSE.)
Well done. We are done with post‑quantum cryptography.
The next talk is remote and this is a joint talk from Willem Toorop and Ilyas Rahimi.
You have 20 minutes.
ILYAS RAHIMI: Thank you very much, my name is Ilyas and today I am presenting my research project, my supervisor Willem Toorop. Moving from a conventional query driven interaction with DNS routes to model to curser resolvers...local copy of the local root. The cause of the root serving is well established, reducing dependency on external infrastructure and great resilience, it's traffic implications are less well qualified, it tended to reduce other all traffic, this is what you are going to examine in this presentation.
Next.
For our methodology, we used two perspectives to establish a baseline by the convex al model, we used R sec metrics, for the local route model we controlled a... to capture the exit traffic generated by a different resolver implementation during updated difference.
The RSSAC002... we estimated the total bytes served, dividing this number of unique IP addresses yield a resolver traffic estimate, this calculation was applied to seven days in January to 26 to establish a baseline.
Our experiment site consists of controlled virtual testbed done by Prox‑mox. We deployed... each running a resolver instance with a specific role, we observed over four days so track the serial number evolution of the production DNS root zone ensuring our measurements reflect real world metrics.
We tested three measure bound and unfound using a second unbound instance in a Knot resolver... we captured all traffic associated with updates process, including the handshake, control queries to ensure the total... on the wire was recorded.
Looking at the conventional baseline table, we see that most root server served Ben 0.67 and 1.34 megabytes, it was F office the only outlier at 11.18 scaling model, the average cost is roughly 2 meg megabytes per day.
But at that time we didn't know the reason for the F as you can see in the read me, so we shouldn't have factored it actually in that, but that makes the impact only bigger than we have already calculated.
For BIND using DNS based each update trance period upward 1.45 megabytes because the root zone updated between two and four times daily, the daily cost was around 4.35 megabytes, this was the double of the two megabyte baseline and indicating that even efficient local root servers increased traffic volumes.
Unbound using DNS followed the same logic, each update was slightly fall smaller at 1.31 leading to a daily average of 3.93 megabytes, these results confirmed using DNS transfer the application choice plays a minor role; the primary driver is how often this changes.
Here Table 4 presents.... this resulted in 48 a full downloads or day, or 1.5 megabytes per day, it served a critical warning of what happens if BIND logic is not change and it has been fixed as you can see there link is included in the presentation.
... in contrast the Knot which also used HTTPS, a more conservative strategy, performs roughly one update per day. The frequency makes it most efficient implementation as tested, just 2.65 megabytes per second.
And now to put things in perspective, if you scale these resolver for the global population of 59 million resolvers, the impact is significant. Just 10%, the Knot recover would add a 2.8 terabyte of daily traffic to the internet, a poorly optimised implementation at the same level would add 27 terabits, that illustrates the local route......
WILLEM TOOROP: Yes, so there will always be increase in the current configuration of traffic of every average traffic resolver which starts deploying local root or populating the root local to the resolver. Whether this is an issue or not, I leave up to you. But there are some measures that can be taken to reduce that increase and to actually turn it into a decrease and so in the coming slides I will show you how this can be realised.
I will present two matters and the first one is quite sensible I think and the second one is a bit mad.
Stay with me, currently the root is fully signed, approximately two and a half times a day; two times a day it's just an update of the... number and if there are changes to the root which is on average every other day, then the root is fully resigned as well.
So I have taken the baseline traffic without F, so my impact is a bit more than previously shown but this would mean in the table that for DNS transfer, for that method, a full transfer of the... costs 1.31 megabytes so times two and a half would mean 3.28 megabytes per day, which is an increase for the average resolver of, a factor of 3.4. So for HTTPS with the bug fixed, it's updated two and a half times, 2.19 megabytes which is the presentation format size, which is the site of the zone, which is an increased factor of 5.7 with a cache pre‑fill which is a different approach, that's not DNS employed, this would mean increased factor of 2.3.
So a full design of the zone also means the... this is because the signatures takes up 60% of the whole site root zone in... format, the incremental transfer even though all these resolvers are doing it, it first means all signatures need to be removed in the incremental transfer, all the old ones and the new ones need to be replace them. So the incremental... is two times the size of all the signatures which is at least 120% of the whole zone size so instead of this in incremental terms for that, the whole zone is transferred as if it were a full transfer.
So I ask myself what if the root zone would have been incrementally signed, I mean only a portion of the signatures are resigned if the zone is resigned and the portion will be the signatures that would expire the earliest, at the earliest time so only that portion is resigned twice a day and when changes happen, that information needs to be resigned as well of course, since it's new information.
So there is our tree that sets the signature lifetime must be longer than the zone expire at all times and this is this makes sense because otherwise ‑‑ I need to progress to the next slide. Yeah. It would be possible that the zone would be served with expired signatures which is not a good thing. It's better to not serve a zone than to serve bonus records, in route, the current signatures have a lifetime of 13 days, the expiry failure of the serve record is one week, seven days, so each signature needs to be refreshed every six days. So I have done this, this means since the route is resigned twice a day that doing each sign one 12th of the oldest RR SIGs need to be resigned, I have been maintaining a shadow version of the route since the 22nd December 2025. And all those versions that have been resigned in this way are available at this... and also in the case repository all the incremental transfers from one version to the next one in presentation format.
So here is a display of what is looks like. The first zone was the 2025/12/21/1. The second zone file we find is the one from 22 December and the IXFR does contain all the changes from the last zone file from the 21st to the 22nd.
Of as I said incremental transfer also in...format in the repository but as I mentioned in comment it's almost 137 kilobytes. Graph on the side of the incremental transfers to get a feeling for what it would entail, you will see here all the regular twice a day signs will cost 137 kilobytes and then only the changes take place.
And so if I put that into the table then, the average daily transfer size will be 100 X instead of, yeah, 1.31 megabytes and daily traffic will be like less than one third of the current baseline is what resolvers currently have in traffic so that's definitely an option to reduce that traffic.
Which might come in handy with first... signatures as well. So also I thought of a second method which we used even further but it's a bit mad, stay with me for this story.
So resolvers or the root zone contains resource records which is zone MD and it contains a hash of the whole content of the root zone including all of the source records and signatures and everything.
So when resolver verify the zone, then they can assume all the Srecords in the root zone are correct as well and they don't need to actually validate them with their signature, if... TLDs. So the only need for that DNS key set and the zone MD signatures to verify the validators. So there would be a special update of the transfer protocol and you would be able to ask for the full zone with other signatures except for the DNS key and zone MD. So this protocol also means additional zone MD records with the hash of the complete zone file, except for the signatures for all the DNS records, for everything basically with only the signatures for the DNS key and the zone MD.
In that case, I have also made incremental files presentation format for this protocol I call the reduced incremental transfer for... the working life of this only consists of a new server record, so old one coming out and two zone MD, the old one going out and the new one entering. The regular updates just cost 1024 bytes and any changes are larger than because they contain all this information as well, but in addition also are the changes. If I put that in the table then the average transfer size will be just 1112 bytes and the daily traffic will be reduced to less than P kilobytes which is less than one three hundredths of a, yeah, the baseline traffic. And also it's interesting to notice that with the current signature size, 89% of those transfer messages will be smaller than 1232 bytes.
So the traffic trade off between local route queries and... is doing root queries and root zone distribution... currently increased traffic... on average with a factor of 2.3 at the very least. Is this acceptable? Maybe it is.
If not then the measures that can be taken, one of them is incrementally signing of the root zone created to one third of current average traffic per resolver per day.
Or there's also this crazy new method to decreasing to negligible amounts by makes thee resolvers rely on the zone MD and that's it. You can take questions if you have.
(APPLAUSE.)
YEVHENIYA NOSYK: Thank you very much. Are there any questions?
AUDIENCE SPEAKER: Let's keep it under three minutes.
JIM REID: I am still a burnt out DNS guy from RTFM in Scotland. Yes. Thank you.
Just making a point. Thanks for the talk, guys, I think this is fascinating work. I wonder if you had considered other approaches to fetching the root zone? I realise you are trying to work with a DNS protocol there, but for example, why not just transfer the whole zone with R‑sync?
WILLEM TOOROP: We have not considered that.
JIM REID: Thanks. Another thought I had, why not just walk through the zone, if you walk through the NSEC, you would find the new information by doing that, you are not necessarily have to do his own transfer, I am concerned about some of the ideas you were putting forward to get down to that 3 kilobyte number, it's great to get the data down to that level, I am wondering if the three dots are going to be sensible, you are introducing more moving parts, more failure modes. Is that a robust way to go about this thing for the sake of shaving off a few bytes of data?
WILLEM TOOROP: Yes, agree. With respect in the NSEC chain, with respect to your last question, just incrementally signing to decrease traffic amount, with respect to Schain, I think it would be trafficwise in that average traffic the same as just transfer zone because you are doing all those follow‑up queries anyway. Maybe a bit less because you aware of the TLDs, don't fetch them when you need them, yes. Yes, very interesting.
JIM REID: It's interesting stuff but I was also pointing out we have other cases of comparable things being done on the internet today, for example, web browsers pulling down whole list of trust anchors, I am not really convinced we have a problem here in actually distributing root zone to every server on the planet.
WILLEM TOOROP: Yes, if it would have been a problem, there are methods
AUDIENCE SPEAKER: Joe Abley from not Scotland. I think I got some of the question to Jim but it's a more rudely phrased question: I wonder what the point of this is. And it's two parts of the question.
One of them is the actual data transfer per day you are talking about doesn't seem that big. Multiplying it by a .5 or 10 seems like a very manageable compared to the amount of data transfer that happens with the ebb, I don't think it's me talking with a CDN lens in front of my eyes, it's not very much data so I wonder how much effort is worth trying to optimise it.
And the second thing is I would be interested for the average resolver in what these data transfer sizes look like compared to not doing local route, and just processing a cache miss when it happens, because I think most resolvers, aside from the centralized ones, don't care about most TLDs, they have a pre‑limited set of interest and it may be that if we do care about data transfer, the answer is only do local root at all ‑‑ the answer is don't do local root at all.
WILLEM TOOROP: The base line measurement is based on R sec 2 data we could determine that, the root self measuring itself and considering unique sources are unique resolvers, that results in almost one megabyte per day on average per resolver so not doing local roots.
AUDIENCE SPEAKER: This is Ulrich from ICANN speaking for myself.
Data size not being a problem is really showing where you live in the world. If you live on a Pacific island and your only access to the world is through a very long sub sea cable, transit is really expensive and so for these people it's really a question, the data size is not negligible, so not a problem, I agree but we also have root servers everywhere around the corner, we don't need this at all, but there's people in the world who don't have the luxury that we have and maybe this is a solution for them that we could use and make make their life a little bit easier.
YEVHENIYA NOSYK: A brief question.
AUDIENCE SPEAKER: A brief comment. Joe you talked about processing when you have cache misses, they happen very often in root name servers every query about something that doesn't exist has to climb up to the root. Thanks.
YEVHENIYA NOSYK: Thank you very much, thank you for joining us remotely.
(APPLAUSE.)
Our next presentation is a traditional update from the RIPE NCC and will be presented by Leon.
LEON GRASMEIJER: Thank you. I will be presenting what we have been working on since last RIPE meeting so we are always adding hosting DNS instances, for K‑root we have added two more going from 136 to 138, and for AuthDNS we added one DNS going from 42 to 43. We added three new AuthDNS instances but we also decommissioned two since the last meeting, the number went up only by one, we would like to increase the number of AuthDNS instances and getting closer to the number of K‑root instances. If there's anyone what would like to apply, you are very welcome to.
As you can see on the map, WEP don't have any AuthDNS in Bulgaria, maybe there is someone in the room who is interested in helps us out with that, talk to me or apply on the RIPE DNS website.
Next we have added RFC 8950 support to our hosted DNS.
For those of you not familiar, this RFC allows you to advertise IPv4 prefixes with an IPv6 Next‑hop. We bring our own IPv4 fixes, you still need to get an IPv4 address from any host from peering, with this it's no longer necessary.
There is support for this. With most vendors, you can see this nice list of availability information that Euro‑IX created and example configurations for most popular vendor and if you want to learn more about this RFC, read this RIPE Labs article, it does tell a lot more about how this RFC works and how you can transition an existing IXP for peers that don't support the RFC so there can be some peers that do support it and some that don't. We are currently running on one commercial internet exchange, as you can see in the screen from the we don't have IPv4 address for peering, we have still advising IPv4 prefixes and we have updated our hosted DNS web application forms. And that way you don't have to fill in any IPv4 addresses for peering and filling in the technical details when you are applying for a node.
Next at the previous RIPE meeting we presented some improvements to our service automation, so a quick summary. We were already checking if the local DNS server was working so we have a small daemon running, just makes a query to the local DNS daemon; if that fails, we withdraw the prefix.
And then we added in the last year a check for whether there's a default route or full table; if it's not there, we also withdraw the server prefix. And yeah, in the meantime for safety we always keep advertising the covering prefixes on our core site even if something goes wrong with this automation, we don't, yeah, interrupt the service.
Since the last meeting we have expanded this even more. So we have already been monitoring the reachability of each DNS instance by sending messages to each of our Atlas anchors and we check which percentage of the anchors receive these messages and if this percentage is too low, we think there's something wrong with the return path of these DNS instances and we are draw the service prefix.
But yes, this requires manual intervention and also manually checking when this resolved reverting this change to readvertised service prefix, now this is fully automatic so we periodically collect which percentage of the anchors each of the DNS instances can reach, if it's too low, we will withdraw the service prefix automatically and then automatically advertise it again when this recovers.
And as a fail safe, when we know there's something wrong but too many instances at the same time or a percentage gets too low, in a lot of places at once, suspicious, so we keep the last result so we don't accidentally withdraw a prefix. We had a chance to test this, due to a change mistakenly in our firewall, we could no longer collect the metrics about anchor reachability, suddenly the reachability of all instances zero percent at the same time but the prefixes kept being advertised as expected.
Another change, we are publishing public DNS figures on our website and we have updated these, here's the old figure, this shows the number of queries per group of nodes, different core size and host DNS and this is what looks like now, it's using your new RIPE NCC colour scheme. And yeah, we think it looks a lot better, we hope you do too.
Another different figure type that shows the most popular TLDs and which query types are reaching, are being asked, you can, for example, see how popular the very famous TLD get cache DHCP result for current conflict result is.
And this is what it looks like now and you can see that the dot xyz.TLD has replaced aforementioned TLD unpopularity, that was taken at that time a slightly different time.
And when we created the previous version of these figures, the IPv6 query traffic volume was so slow we showed both of them in the same figures, IPv6 was not visible at all next to v4. But now we have enough IPv6 queries coming in to show both of them in the same graph, of course we would like to switch these two around.
Yes, we think this looks better but if you don't or have other feedback, let us know. And yeah, we also did this because the DNS statistics presenter start of the DSC project was deprecated and running on an old system, in an effort to make the deprecated software run a new system w created our own and we are still using the DNS of this collector to gather this data.
Yeah, that's miscellaneous things, we have completed K‑root hardware refresh of a few of our core sites, so in Amsterdam we replaced both the servers and routers and in London and Tokyo we just replaced the routers. We were also planning to replace the servers in London and Tokyo but stuff gets expensive, recently so we are planning to still do that.
You may have already heard the activity plan presentation by Hans Petter Holen, there was a bit more detail here, we are going to continue operating our services, K‑root, AuthDNS and AS 112. But yeah we are planning to finish the hardware upgrade in London and Tokyo. As well as replaced AuthDNS equipment in the London and Amsterdam and Stockholm core sites as well as the AS 112 server.
And we are also focusing on more automation and improving our monitoring. Thank you for your attention.
(APPLAUSE.)
YEVHENIYA NOSYK: Thank you very much. Do we have any questions?
Do we have anything on Meetecho? No. OK, in this case, thank you very much.
(APPLAUSE.)
We are moving on to any other business, so we did not really do a Q&A for the session, suspect you talk to the speaker directly, the first presenter is Giovane Moura. You have around five minutes.
GIOVANE MOURA: Thank you.
Yeah, so yeah good morning everybody. This is just sharing some datasets. If you are a researcher, if you have a ccTLD operator, I hope you join us to share more datasets for researchers and that's it.
The root operators have been in the room, they have been doing the statistics of other traffic, they have been doing it for 10, 15 years, I used it before and in some TLDs we publish some stats, the Czech folks as well and the Irish report but each of us have their own thing, frequency, data and it's kind of like hard to compare them. So I thought why we don't just share the same using RSSAC002 so folks can compare them easily, exactly the same, that's where this thing started and where we are doing now, we are just connecting traffic that we collect anyway and we were doing that with publishing daily now our statistics, it goes back one and a half years I think. And we are given different types of known data.
So in essence what happens is that we get other traffic and the same metrics and there's no personal information in there. And we did it because we want to give open data about your current infrastructure, we want to give it back, we have used this RSSAC002 for the roots before, there was a presentation about RSSAC002 and same format and we were losing the tool to journey the data based on the traffic in your zone, if you want to and this is, it was a tool developed by TU Delft that I supervised. So it would be nice, I see TLD operators in the room, it would be nice to publish your RSSAC002 data, we are giving for example one of the examples that shows a traffic volume, the counters here, almost like 8 billion queries a day, 34 over IPv6, 1.2 over PcP. Our code, 91% is no error, our two ENTRADA weird R Code which is minute news one, not standard, for the queries that don't get a response. So you can see later there are like traffic size distributions, this is pretty much RSSAC002 and I can see this analysis, now if you combine the servers the traffic we get, this is equivalent to D root, the volume of queries so in terms of volume, it's like D root, so what I can do that, protocol adoption, there's a bunch of stuff we can do, check out the data. That's the tool. I am going to skip it. But anyway, I'd like to just make researchers aware this data is there, there's a lot of information you can check later on and you would like to see other TLDs published as well and that's it, thank you.
(APPLAUSE.)
YEVHENIYA NOSYK: We have a short announcement from Jerry Lundstrom.
JENNY LUNDSTROM: Hi, I am Gerry, I work at DNS organise and during the summer I started a third iteration of check my DNS and I added end points and regions. If you want to help with that, please see the link. I should have put the QR code up top, I see that now. See the link about the community, about the end point programme or come talk to me or reach me. Send me an email. Thanks.
(APPLAUSE.)
YEVHENIYA NOSYK: That concludes our sessions, thank you very much for joining us. Please don't forget to rate the talks and enjoy your lunch.
(APPLAUSE.)
Lunch break