Wednesday, 14th May 2025. Side room. 9am.
DORIS HAUSER: Good morning everyone. It's nice to to see that a lot of you came to join the session today. I am really happy to welcome you to the DNS working group session and especially very happy that I am doubly represented today, thanks to Willem.
Yes, so the first thing I would like to announce is that tomorrow, so Thursday, we have a BoF at the end of the sessions, which is about DNS authoritative servers and whether we should ‑‑ we would need best current practices document and how that should work, that is a panel with four people and I would like to invite you to join this discussion and help us find some conclusion about that. Next up a short announcement about DNS org best current practices, is he in the room already? Ah. Perfect.
SPEAKER: Right, hi, Phil, incoming president at DNS Org. And just that you mentioned, operational BCPs is great timing, we have had some of you might know at Org 44 at Atlanta, we had a BCP discussion, a panel and it seemed there was general consensus, it was a good idea to have the Org community take a look at DNS operational best practices and we are looking forward to this panel tomorrow and for those of who are interested, please come and talk to me, we are kind of moving forward on this and having a discussion channel on an the people on the panel back then are being invite to contribute and see how does this evident take shape and what should be Org's voice and involvement in this, so again coming ‑‑ come and talk to me in the breaks an also tomorrow during the BoF, the panel session will be very he will relevant for that so thank you.
DORIS HAUSER: One more topic before we start with the presentations, an as a lot of you will probably know from the mailing list, I am stepping down as a DNS co‑Chair for personal reasons and we have found a person to join the team which is... and we will join her. Hello. We cannot hear you so far.
(APPLAUSE.) Thank you. I am very happy to becoming a co‑Chair at the next RIPE meeting, thank you.
SPEAKER: So Doris, this also means that you will be leaving us, we are very sorry about that, you have been a really great co‑Chair, as a token of our appreciation, we have a small present for you.
DORIS HAUSER: Oh thank you! Thank you.
(APPLAUSE.) Yes, for whoever still has doubts, I am not leaving because of the team! You are amazing. All right.
Now off to our first speaker, Ondrej, he is going to tell you about post quantam DNS SEC.
ONDREJ SURY: Hi, I am Ondrej, I hope you had a good party and you took your partner for a spin. It was a quantum joke.
So, there was some previous studies use in DNS SEC, I finally wrote my final draft for my thesis, and then I found some issues with it, so I am still working on that. I included more than just the Falcon that has been already approved by NIST but there's additional signature scheme round two, running right now and there are some interesting algorithms that might be useable for DNS SEC, so am I looked at all of them and didn't just pick some that might be suitable and then tested them so there's these are extra one, there's Hawk, yes, there's joke on Falcon, also it is based so I'm not a cryptographer, I am a Crypto plumber, I don't understand any of the maith, there's SQI sign which is really nice, it's really small but it has problems, you will see, Mayo, it's oil and vinegar scheme and ANTRAG which is not in the NIST but it's, it looks like the others but thinking about making Falcon smaller.
So these are the sizes, as you can see, SQI sign has the smallest public key and smallest signature, then comes the Hawk 256, but this is a challenge label, they have this in the paper like, this is NIST level 1 and we give you a slightly less, slightly smaller parameters and we challenge you to break it so this is a challenge level so I don't know how much secure it will be in the end but it might be suitable for the DNS SEC because our needs aren't the same as like 20 years of storage of the secure data and the US government.
And then Mayo has a small signature, this is the third one and Antrag is small public key, but it doesn't seem to be so important. Implementation status, I also implemented Falcon as well, there's quite good implementations, Hawk is like, like thank you to the authors, this is a neat little code meant for embedding, it was very easy to embed, the SQI sign and Mayo, the teams are mostly focused on the NIST challenge, so they are not suitable for any external uses like benchmark, I had to mash it, the CMAKE project into building shared libraries and yeah, it's horrible. The current state of the code, and I think the cryptographers should not write code and sorry Antrag, again, a shared library and it's a work in progress, there are some bugs in that.
I have some machine that I disabled for turbo boost, from 22 core, just six but for the stability of the results, there's a neat tool called hyper fine, the comments you give it in several repetitions and do the, you know, the mean and the Sigma and I am using only the reference implementation, not the optimised ones.
There are several branches, each for the algorithm and then I had to like I bumped some ED N buffer sizes to be bigger so I am also using for the classical cryptographic.
Times for key generation, not so much important but as you can see it is the slowest one is RSA and the standard is feared but I have been told this is normal for RSA.
So signing. Signing is not that much important for normal but there are some cases like online signing or huge zones like dot com, dot Org or something where it matters.
As you can see the Hawk is really nice and the SQI sign is really nice on the size but it's very, very slow.
The message sizes, so the orange one doesn't fit into the increased buffer size, the yellow one doesn't fit into the EDNS flag day sizes, it's 1232. And so is it a problem? Well, on the verification sometimes, the SQI sign is very slow and Hawk is even faster than the existing algorithms.
So for the resolver testing, we have at ICS, we have this test bed of where we combine the Git labs CI and DNS shotgun and I set it up custom root server for hosting route zone signeds with these algorithms, and the results.
So ECDSA, I included all the classical ones as well. This is quite small, the blue one is always the baseline, this is the like normal route zone and the orange one is the algorithm I have been testing. So the top two pictures are the reverse... pictures, I hope you have seen them before, but basically you want everything to the left and to the down.
So but as you can see, these differences are mostly like noise, same for ED 25519.
Now, Falcon, as you can see, there's ‑‑ because and this is what I am looking at, the difference is because the signatures are larger and there's a fallback to the CP for some of them and this is just a route zone signed with the Falcon, not anything up in the hierarchy, so this is quite a large effect because if you look at the ‑‑ at your top left picture.
Can I use it as a laser pointer? No.
So the bottom line means that everything has been answered under one millisecond and the difference is between 15% hasn't been answered under one millisecond and it goes up to 30. So the difference is between 85% has been answered under one one millisecond to something like 70 or 75% only.
So this is quite, quite a difference. Also this memory spikes are weird but that could be also a noise.
Hawk again, it looks like no difference, the top right might be some noise there, but you know, this is like, it's been tested on the real internet. OK. This might be just a noise because it's real internet, you know. So, Hawk 212, again it looks like it might work, you know. It's slightly lower slower but nothing, this could be also a noise SQIsign, that could be a problem but maybe we need to have a choice does it have to be like that fast or secure so security speed, maybe we'll have to make some compromises and one thing that I need to say about this testing, this is real world data but it's not like et I caners data, there's more research coming that I plan to do like look at, I will speak about this. This isn't normal data graciously given by one of the ISPs that might be even here.
So the SQIsign is small but the crypt difference, you can see the CPU which is bottom left at the beginning, there's the CPU goes up and there's a difference. So Mayo, Mayo has a nice property, it has a larger public key, but the signatures are small, smallìsh enough for DNS SEC and it looks nice. Again, Antrag, again, it might be a choice.
But yeah, more research needed. So for Antrag, yes, authors talk to me, that doesn't happen that often, but the multi‑threading is broken, if I am signing anything, I need to just use one thread because it's just ‑‑ otherwise it's so slow, it's slower than anything on earth because there's some contention happening. The signing API is, you know, confusing and I reported this to the authors. And it uses own random by generation which needs to be initialised, I generated the keys and it had some key tags and then I just purged it and generated it again and, whoa, they are the same, so...
They were not initialising the random state internally.
For SQIsign, I finally I managed to download dot Org zone and I am signing it for my thesis and after eight hours it ended up with floating point exception. So there's some still some work to do.
So for the future work, I need to test it at different levels of DNS hierarchy. I do have access for the centralised zone data stored, the CCDDS from ICANN, maybe use more algorithms, there's still DNS composition ongoing, looking at the pseudo‑random sub‑domain patterns, how does a look when an attacker will try to attack signed domain with these algorithms.
Then try something like forced rekeying, so small TTLs for the DNS SEC keys. Implementing N SEC 3 aggressive caching, maybe drop out because of this because we can you know deploy the cacheing, we also use the system D trace probing already in BIND code and I have probes around the Crypto operations to see how it affects the and maybe use the optimised implementations but there's.for example SQIsign, you can't make them shared libaries,, we need more implementations from people who are engineers and can owed an ISC code. So thank you. Do you have any questions?
(APPLAUSE.)
AUDIENCE SPEAKER: Geoff Heuston, APNIC, thank you for that presentation. I kind of am mystified as to why though. Youi said earlier, and I understand this from NIST as well, that the evolution of computing says at this point somewhere around 10 to 20 years from now we might see deployment of these kinds of machines that basically breaks existing Crypto, agree. And if you want a secret to last for 20 years in today's world, then this kind of stuff is now timely and in some areas necessary, what puts the DNS in that mode, what part of the DNS needs to be a secret or DNS SEC has an innate requirement to be a secret 20 years from today. Does anyone use 20 year expiry times in their caches, what's going on?
ONDREJ SURY: I absolutely agree, and I wanted to say that, thank you for bringing this up. My conclusion from this is we should wait this out. So because there's still like a lot of research ongoing and we should talk to NIST though and this was actually suggested by the NIST guy who was at the site meeting in Bangkok, we should talk to them about our requirements for the post quantum cryptography because their focus is elsewhere and we should bring their focus to our needs as well. I absolutely agree, we should wait this out because there's no urgent need to have this.
AUDIENCE SPEAKER: And one further comment, it was unclear in your presentation if you were querying your signed route zone for names that existed or names that didn't exist, because the insec answers as we know, massively big; the positive answers, by comparison, are tiny.
ONDREJ SURY: I can send you my thesis. I do have this in the future research, you know! It already has a hundred pages so... I didn't bring it in. But I absolutely agree it's one of the things that, there was the thing I was talking about, I should try several random sub sub‑domain NSEC on the sign zones, which would include the NSECs, absolutely, it already is a hundred pages.
AUDIENCE SPEAKER: Hi, well, I agree that we shouldn't deploy it today but I say but Crypto ability is a thing and DNS doesn't have the best track record of that so we cannot wait 19 years and then deploy it because you know, then we will be a little bit late. So I think we need to look into this and then at some point start rolling it out because it will take a lot of time, many years and so I think this is really good work and.
ONDREJ SURY: I feel these are two different questions, we don't, I think that what Geoff was asking was why we need to deploy this now, we don't. But we need to research this. And I am trying to do that. And getting my masters as well.
DORIS HAUSER: OK, do we have any more questions? No? OK, then I would conclude this, thank you very much, Ondrej.
(APPLAUSE.) And our next speaker is Marc Van del Wal and he is going to be talking about SPF DKIM at dot FR. The floor is yours.
MARC VAN DEL WAL: Hello everyone, I am Marc Van del Wal from AfriNIC, I am an engineer and today I am going to talk about my research I have been doing for over two years now about the adoption of SPF DKIM and DMARC within FR domains.
First of all, what is it about? Well you know probably that email has been not easy to forge, because there are no real checks on the email headers and sender addresses especially which leaves the gate open to all sorts of abuse and shenannigans, like phishing and extortion emails, you have probably had in your in box.
So in order to make it more difficult, three mechanisms have been devised, SPF, DKIM and DMARC, you list the emailers allowed accepted on your behalf, with DKIM we introduce signing, digital signing of email headers and body and finally with DMARC, DMARC uses the results of SPF and DKIM to decide on the fate of an email, also as a sending domain, you can specify the action to be taken when an email fails the SPF and DKIM simultaneously.
So, how is it, how are things currently going with dot FR and I see Powerpoint has been messing with my statistics a little bit.
Well, we have the quite a bit of an increase in the adoption of SPF, we were about 56% I think from 2023 if I remember correctly but DKIM and DMARC have been increasingly growing so that's nice but we are still a long way from widespread adoption.
So as I said, with DMARC, in your DMARC policy record in the DNS you can specify the action to be taken when email fails SPF and DKIM simultaneously, these are the proportions of the three policies. None means do nothing special, and so I distinguished between those that had no email address for receiving the automated feedback reports that you can also have with DMARC nd those who do.
And in the latter case, it's called monitoring mode. And so we have quarantine, which means in this case, in the case of an email that the fails SPF and DKIM can send it to the junk folder and reject means reject at the SMTP level, so we see some big shifts in proportions, especially the P plus quarantine, now how can we explain it. This is the job of the next figure.
So, the advice usually here is when you are deploying DMARC is start with P equals none, but do look at the reports you get and once you are confident enough that all your email passes authentication, then switch to P equals quarantine or reject. Now as we can see, the big increase in the enforcing mode policies actually comes from.brand new deployments of DMARC and not so much from deployments that started with P equals none and then switched to something more strict.
And this happens two years in a row so I thought it was quite interesting to show that the evolution in time of DMARC deployments like this.
Anyway, looking at over four million domains, there's some interesting configuration mistakes that you sometimes see. The first example are overly permissive SPF policies, so you can shoot yourself in the foot by accidentally allowing everybody to send email on your behalf, and there are three ways of doing it: One is by ending your SPF policy with plus all instead of minus all. The second way is by fat fingering a /24 and turning it into a /2. And the third one, well I have no idea what happened but this guy seemed to really like IPv6.
Also the downside of asking, the downside of well asking people to put things in their DNS is that they sometimes don't understand what it's supposed to be. So when you have one SPF, when you have an SPF policy, you should have exactly one, and so when you are outsourcing your email to a different company, like for mass emailings and that company tells you to put this TXT record in your DNS and you go to a different company for a different emailing campaign, they tell you to do the same, you end up with several SPF policies, if you don't understand what it's all about.
Now, still with SPF, SPF policies live at the apex of the domain, they have to contend with other TXT records, especially those Google site verification TXT records and well here I was trying to look for the SPF policy of this domain, can you see it? Oh. No, I am sorry, I should have zoomed out a bit. There it is!
So yes, this DNS response has 80 TXT records, it's about three kilobytes in size, there's no way it's going to fit in UDP and well, SPF were to be specified today would probably be at under score SPF dot domain dot example, we can probably fix the domain verification challenges, there's a nice IETF draft and we can probably all try to put these domain verification challenges in the attribute leaf instead of the apex.
As for DMARC, I think it's something that's dot FR specific where key words use French terms.
Now, I was wondering why. Well, the answer is easy, web tutorials that were machine translated but not proofread.
So obviously the code examples shouldn't have been translated.
(APPLAUSE.)
OK. So this screenshot actually comes from a presentation I did two years ago and someone from the audience searched for the exact text and reached out to the website and it was fixed one day later. Fortunately, these tutorials do get fixed. However, I tried reaching out to a different website and I had to be much more patient and wait six months until they finally fixed the typo.
Now finally, I'd like to finish this presentation with the subject of parked domains, they are domains that you purchase for some reason but you don't do anything with it. Probably, maybe it's a defensive registration or you have some project. But you tend to forget about them and what sometimes happens is, well, these parked domains, they don't have an SPF policy, they don't have DMARC policy or they have some incomplete configuration and the domain gets used as a sending email address in phishing campaigns. So in one case I had, I saw a domain that was used in a phishing campaign, unbeknownst to the domain owner and they had an SPF record but not DMARC equals reject, so it wasn't rejected. Sometimes when you park your domain, you park it with a company that asks you to change the name servers of your domain and so you lose control over the zone file contents, if they don't have the appropriate configuration, your domain is at risk of getting spoofed if you have a parked domain, be sure to check the configuration and make sure that that nobody can use it for nefarious purposes.
All right, that's all I could cram into ten minutes, thank you very much. If you have any questions, let me know.
(APPLAUSE.)
AUDIENCE SPEAKER: Hi, this is Andre. I worked for dot CZ before. Do you have any classification about dot FR domains, like these have some content and these are just parked and this is cross‑ matched with this with the policies?
MARC VAN DEL WAL: Yeah, so I have done previous studies in 2023 and 2024 where I did try to pick out domains that had content or in versus domains that were parked, but it turns out our classifier wasn't that reliable. So for 2025 I left it out sadly but, it's a big subject by itself, it could be worth of a lightning talk.
AUDIENCE SPEAKER: Greg. In a previous life, I had to try and sort of sort this stuff out for the company I worked for and I think it's notoriously difficult when there's not a great deal of good information on what is good practice to do, like you showed people just stuff things in because they don't know what they are doing, I think there might be a case for better information dissemination to people who have to do this kind of stuff, you know, so that they can have the right kind of guidance to say this is the kind of thing you should do, rather than just blindly, you know, person A says put it in DNS, person B puts it in DNS and they tick a box and go aawanted think it's all sorted. By the way, I hate 'include.
MARC VAN DEL WAL: Thank you. I agree, it's notoriously hard to find good practices in SPF especially so I am trying to compile my own.
NIALL O'REILLY: As much of what Greg said, I don't have a strong position on include however, but part of the thing that needs to be put into the best practice from the point of view of an artisan who runs his own artisan mail server is an indication of what can go, what can break if you haven't understood things properly, because part of the obstacle, at least from this Postmaster is if I do this, will my wife's mail break? And that's not acceptable.
MARC VAN DEL WAL: Someone who runs his own mail server also for his personal email and my spouse's, I wholeheartedly agree.
DORIS HAUSER: Are there any more questions? Online maybe? No? OK. Then thank you very much, Marc.
(APPLAUSE.)
And our next speaker is Asbjorn, he will talk about best current practices for DNS filtering. The floor is yours.
ASBORN SLOTH TONNESEN: Hi. So why we do DNS filtering. Both for legal reasons ‑‑ in the EU, for instance, there are some sanctions against Russian media and other sites. And then we also have parrot sites like the parrot bay and other sites that get blocked in some jurisdictions. And then we also have some product safety things. And we have some gambling legislation. And in some providers networks, there's also some security filtering like malware or phishing domains that can get filtered out, in some cases, this is mandatory and other cases it's an opt in thing that people can opt out of.
Oh. So how does this is often done is using response policy zones, and then you could respond with an NX domain to a filter domain, right. However, in some jurisdictions, we also need to show a block page explaining why this is happening, where is ‑ if it's NX domain, people just get could not connect to a server in the browser.
This thing with the block page might have worked great 20 years ago when everything was HTTP and you could spoof everything all over the place but today there are issues with that and therefore these pages are not really even in place where they are mandated, they are not really seen by anyone because if you follow a link from HTTPS then it will just give you a connection refused message in the best case. And in the case that blocks server is listening on HTTPS, you will get a certificate error, but normally you would use a simple IP for this where you reject HTTPS connections.
So maybe we need something a little bit more modern than this. And also this specific HTTP status code is not really implemented except for a few test cases.
So one of the things that we could solve this with is that there's an RFC called extended error codes that defines four different error codes. So one of them is Forged Answer which means that you replied a C name or error code and it doesn't specify which recent it's blocked for. And there are some only that can only go together with an X domain that are block, censured, and filtered. So blocked is, if it's a mandatory policy in ISP setting, it's not that common. In... setting, it would just be covered policy forbids you to visit the site. So that it's a decision taken on the entity that is doing the blocking.
Whereas in Sen state, it's legal mandate that you have an external requirement that you need to block this, for instance in the EU we need to block... dot come. And in the filtered case, it's these kind of opt‑in security malware phishing filters where it's the client doing the DNS requests that have requested that the blocking is done.
And supposedly sometimes it's enabled by default and you have to opt out, other cases, it's an opt in thing but the basic thing is if it's the filtered error code, you should be able to opt out of it.
It could also be a parental control or similar stuff to that.
And of course error messages are propagated through the resolver so that if you have a CPU device that requests from the upstream solver, it will propagate this error all I way to the client, right? No, it's an implementation detail but it may propagate, so it's very weak. And in practice it doesn't happen.
So we probably need to work a bit more on that before we can really replace the HTTP block pages.
So an example of a request with an EDE code could look like this, where ‑‑ this is a test bed we made during the DNS Hack‑a‑thon in Rotterdam, that has recently been upgraded to have some more different resource types and is now based as an authoritative server running with a camp DNS which you will hear more about in the next presentation.
But basically you have the error code and you have extra text field, so the extra text field can contain whatever you like, it's a free text field that supposedly should be able to be shown in the browser saying this page is blocked due to these EU sanctions or whatever.
I have found some cases in the wild where it just says blocked due to E U sanctions, but there's only few cases of this. So EDE codes are currently not possible to set with IBC in unbound or BIND and DNS just can set them but not set the extra text but DNS just cannot do IBCs. The DNS mask would need to propagate this for it to work in reality and stub resolvers would need to propagate it to the browsers and the browser would need to implement error pages for this, we are still a long way off having viable alternative to the block pages in order to inform users what is going on.
So there is a structured DNS errors draft in the IETF, that has just been... and that basically tries to change extra text field to be an I JSON field with some specific parameters and it also tries to define some of the initial keys for that registry and some of those keys are also free from text, that will not be localized whereas many of these block pages are dual language, especially for the ones in Denmark, we have them in Danish and English, we don't make any assumptions that people understand Danish.
I have seen some other examples, for instance, in Austria where it's only available in German.
So this draft also specifies that the extra text field must be discarded if the whole chain is not secure. I don't think we are going to see CP devices propagating the upstream DNS resolver or doing less encryptive certificates in order to be able to do a secure chain. So I have my doubts about whether or not this is going to work but it's the current development on this.
So to summarise, we have NX domains, we have C name or QUAD A that links to these stop block pages and we have some cases where it's a record or QUAD A records or just pointing to local host in respective address family and then we also have empty replies in some cases, and then in some cases EDE errors are sent.
So yeah, we need something else in this HTTP block pages because it's a thing of the past.
So I have tested this across RIPE Atlas with all of the probes in the greater EU area and the majority of them don't use public resolver but it's pretty close but then also the majority of those that don't use public resolver don't do any centering and I think this has to do with that RIPE Atlas probes are deployed in more technical networks than usual so there might be a higher degree of people having their own resolver or not using ISP resolver in any way, I have counted the ones forwarding to public resolver as using public resolver as well but yeah, I am not sure that this represents the average internet use in Europe.
But there's quite a lot that is not blocked and then there's some are, it's done in a variety of different ways so it's not reasonable consistent how this is done across Europe. Even though this RT filter affects it all.
Yes, what should you do from here, should we make some consensus on how to do this or do we do it in one way and one way only or what should we do. With that, I will give it up to the long queue.
(APPLAUSE.)
AUDIENCE SPEAKER: Speaking as a responsibility for the DNS infrastructure architecture error draft, you said it's last call, it's still the last call, it's not over, right, and it's clear there's no consensus.
ASBORN SLOTH TONNESEN: I said it like that because I am not completely familiar with IETF procedures and also the last call that I have had passed so I would leave it up to you.
AUDIENCE SPEAKER: That's no problem, it was simply to clarify the situation. Thank you.
AUDIENCE SPEAKER: You mentioned the BIND doesn't have RPCD but of 920 they actually do so.
ASBORN SLOTH TONNESEN: Also with extra text.
AUDIENCE SPEAKER: No extra text.
ASBORN SLOTH TONNESEN: So it's the same as unbound or DNS just.
AUDIENCE SPEAKER: Yes.
AUDIENCE SPEAKER: More of a comment than a question, the whole block pages is a really, really bad idea.
ASBORN SLOTH TONNESEN: I agree.
AUDIENCE SPEAKER: We are trying really hard to convince government people to not do that because all it does is trains people to click through the SSL warning, so like whenever somebody says please redirect to somewhere, we are like no, bad idea. Also I think ICANN.asack is going to be publishing a DNS blocking document soon which largely says similar things like try not to do this unless you have to.
ASBORN SLOTH TONNESEN: In Denmark we often get PDF file with the need to use this exact sign on the block page, it doesn't include HTML, just the PDF sign thing.
AUDIENCE SPEAKER: I have got two quick questions, first of all, great presentation, thanks for all the stuff and the hard work you have done there. I wonder if you think there's any value 234 trying to capture the details of the implementations not propagating these errors codes, not so much naming and shaping but it would be good to have a director as it were saying person X and Y does this and doesn't do that and gather that information, I think that would be very helpful.
The second point is that I want to make is about your question of trying to get consensus around a standard way of handling this in an operational practice. I think that's a great idea in theory, but I think it's going to be rather impractical because DNS is so diffuse and the explain page and others use the DNS, it's going to be hard to see how anyone can converge around a consensus how to do this. By all means, give it a try but I would be doubtful if you could actually succeed.
ASBORN SLOTH TONNESEN: Thank you. Yeah, it's a time to do all of the different working tests and stuff like that. But I am considering doing RIPE Labs write up of some of the details I found.
AUDIENCE SPEAKER: First command on the Atlas data, as we understand the sanctions, they have to apply to... customers to public, they have not to be applied to enterprise environments or employments etc, so, it's common to have an Atlas probe in a non‑broadcast or non‑private host area and that might influence the results.
ASBORN SLOTH TONNESEN: Sure.
AUDIENCE SPEAKER: Second point, as you mentioned, it would be fine if you have a clear indication what's the reason for blocking or or not resolving correctly but we find we have text like that. But if you are going to... customers, there will be no security for the first resolver. So if the thing for mentioning, please change it in the IETF, it will not work.
But it will work for the intended audience.
Next point, I am really happy to hear that some country in Europe which has a definite list of domain names which should be blocked.
ASBORN SLOTH TONNESEN: In Denmark we have the telecommunication union that publishes all of the domains that should be blocked and I noticed on the block page in Austria, they also included all of the domains they were blocking on the block page. But yeah... is also running a draft in IETF trying to make a public resolver or ISP resolver registry to make some reputation based thing on whether or not the browsers would trust an error message and yeah. That's already an extension to the draft in question.
AUDIENCE SPEAKER: Just to a comment on the censorship or the Russia today situation. We did a study on that, measuring the blocking of Russia in websites in Europe and ISPs and we saw that every country has definitely another definition of blocked domains that should be blocked, some countries block also the mirror pages, others do not. Even with countries, there's a difference between ISPs, it's a very messy situation because the EU basically says you have these organisation names and every country has to figure out which domain names belong to that.
ASBORN SLOTH TONNESEN: Yes, thank you. We also had recently an article on the Danish broadcaster's web page, where they had found some RT domains that were not blocked and they blamed the providers and then others blamed it back, the list we had got from Danish government didn't contain them.
DORIS HAUSER: OK. I see no more questions. Then thank you Asbjorn.
ASBORN SLOTH TONNESEN: Thank you.
(APPLAUSE.)
DORIS HAUSER: Next up is Denesh and he will tell us about the DNS Hack‑a‑thon update.
DENESH BHABUTA: Thank you, Doris. Well, I am Denesh, and yes, so some of you will know me from my previous role at DNS Org for the past 12 years. But while I am here, yes, that QR code, I am making use of this opportunity looking for roles, that QR code goes to my website, which then links to my LinkedIn, so if you are interested in hiring me, please have a look at that.
(APPLAUSE.)
Thank you!
So it's really nice being back here in Lisbon. My first time in Lisbon was actually 16 years ago at the last RIPE meeting in Lisbon, that was what, 31 meetings ago? And since then, I have been coming back regularly and also some of you will know that I am also the co‑founder of PT Nog and we are going to have a kick start meeting tomorrow if anyone is interested in supporting PT Nog going forward. So I will just give a brief update about the Hack‑a‑thon which took place in Stockholm on the 15th and 16th March a couple of months ago, kindly hosted by NetNode in their offices.
So who knows what a Hack‑a‑thon is, anyone in the room? OK, actually I am surprised not many do. Who doesn't know what a Hack‑a‑thon is? OK, Geoff I am surprised...
OK. How many people have been to a Hack‑a‑thon? Oh wow, half it half. It's generally, for the benefit who don't know what it is, it's generally a hacking marathon but it's all about collaboration and it's all about community, it's all about sharing and the actually non‑competitive. It's basically working on things to together even you may be working in competing organisations but it's working together to make the internet better and in this case the DNS Hack‑a‑thon was to evolve the DNS to make it better as we know forward through time.
So I'd like to ‑‑ well, I have already started anyway, I'd like to start with gratitude because it's always nice to thank those who have made this happen. So there were three hosts for this meeting, it was RIPE NCC and the representative was Vesna, and NetNote was Johanna and in my previous role as DNS Org, I was the helper there. Things happen over time and while the thing was ‑‑ while the Hack‑a‑thon was initially discussed way back last year sometime, unfortunately Vesna doesn't make it, so instead we had Gerry from DNS Org who was Vesna's replacement basically but with less hair.
And then there was Matthias from Netnod who was helping around and other people from within Netnod helping with the catering and everything.
But the Programme Committee of course, Arife and Lehman, and Samaneh, the only PC member was of a reef because there was all this pre‑work that went in which made the Hack‑a‑thon possible and made it run smoothly.
But of course the Hack‑a‑thon wouldn't be anything without the whole group, there are about 34 people there, a collaborative, it's all about collaborative work and I just like to point out that the first photo, that one over there was taken by Hannah, she's also part of the group, we wanted her in the photo, we thought let's all look at the cam that's pointing to the group and then you will Johanne in a with the camera there take I can the photograph. It's all about collaboration, and I will quickly explain how Hackathons work over the next few slides.
It's basically there are three to four stages to a Hack‑a‑thon and the first stage is the idea stage. This is where people come along, some people have ideas of what they want to do in the Hack‑a‑thon, others think I am not really sure, I will just listen to what the ideas are and I may or may not join a group and so these are just ideas being written down. There's a lot of brainstorming going on, those who have ideas are writing things on white boards and over here on the bottom, I think that's Willem's hand who is writing his ideas down for one of the project I will come to later on.
That's the first stage.
The second stage is to persuade people to join your group and it's basically selling your ideas, come and join my group, and a typical group size would be maybe three people, minimum, eight maximum because that's a decent enough size to get work done within the two days that we are there.
So next one is getting the groups together and working together. People get together, they will start coding or they will write an RFC or draft an RFC or anything else.
So I just thought I would make it full of pictures and you can see the whole group here.
So those who were at the Hack‑a‑thon in Stockholm, if you are comfortable enough, could you stand up please?
Yes, so thank you everyone, thank you for this. Those in the room who would like to know more about the Hackathons and the work going on, I will put the link up later on at the end of the presentation with the link to the Hackathon page but do make use of this time and this week to talk to the people in this room who are at the Hackathon and if you were interested in joining their projects, then please do so because the thing is, the Hackathon may have ended but the project do not end, the project continue. So if you are interested in contributing, please join the groups, contact the authors and join them.
So just very quickly then, I will go through what the projects were, there were seven projects across 34 people.
The first ‑‑ well I am doing in this in alphabetical order, there's no hierarchy or anything. Basically the baby was delivered. It was working on NSD authoritative server to integrate it with Stork and the future is to integrate .DNS and DNSC.
The next one was Canned DNS, creating a name server with Canned DNS responses and this was the most completed project and as mentioned in the talk before mine, there's a nice link to the previous talk that Canned DNS would be mentioned, interesting thing, it is being used as an authoritative server by Asbjorn himself already, so thank you.
And then there's DoHot or Donion, the interesting thing and the thing that I remember about this was as I was going around between the different groups to see how things were happening and whether anyone needed any help with anything is that they didn't actually realise that Tore is within the actual name, DoHot Tore Donion. But I had to point that out, me being a non‑techy but anyway, I just found that surprising.
And the next one, this is pronounced idiot. Because am IoT devices are idiots and there was various insight and recommendations on the Hackathon page about what they found, so please have a look at those.
And there was LHB, look up host name best practice and it was one of the things was making info better or user work around but Niall is here from that group, so is Asbjorn, even though Asbjorn was on a different group, he still did the Canned DNS authoritative himself as well.
And then there was poisonlicious. I mean these are really good names, aren't they? Proof of concept for an efficient DNS resolver in unbound and this group started drafting an IETF document. And if you download the slides, you can just click on that link, it's a safe link by the way. So it should be OK.
And then the final one was resviz, what a resolver does when it's looking up a domain name.
Actually I'd like to go back to something, I have just remembered something, the Look Up Hosting Best Name Practice, had the thing that was clear from this and what a lot of people do not know is that DNS is more than just domain names, it's more than just, well this group knows of course with you it was something that was reiterated during the Hackathon. It's more than just domain names, it's more than address resolution.
So coming on to that, so that's all of them. So again like I said, I will put up a link on my final slide which links to the Hackathon website, it's a Github page and if you are interested in contributing, continuing to contribute to any of those or you wish to find out more about those, please go and have a look at those.
But like I said at the beginning, it's non‑competitive, none of the Hackathon stuff is competing against it's each other, it's all about collaboration, sharing and making the DNS world better or making any technical thing better, depending on the Hackathon.
So the commendations, the most completed project was Canned DNS, the funniest project name obviously had to be idIOT and there was a project with a self‑appointed trouble maker and that was babies and this particular person was always coming up with, actually, yes, we have done this now, but you know NSD also does this, maybe we need to change something and look at this, and it just complicated matters a bit but they went through it and I have this person's authorisation let's say who mention who it is, it's the next speaker from RIPE NCC, Anand bud deaf, after my talk, I will welcome him on stage but anyway, again, co‑operation, collaboration, working together and that's what it's about. That is a safe link, the QR code, that is a safe QR code, if you don't believe in QR codes, there's the link.
But again, like I said, I am actively seeking opportunities, do keep me in mind. Any questions?
(APPLAUSE.)
AUDIENCE SPEAKER: I have a question from a remote participant: How can we participate remotely?
DENESH BHABUTA: So the thing with this Hackathon, we decided not to have remote participation this time because one of the ‑‑ one was that there wasn't enough time to do it because there was something, there was a request that came in too late and for the organising committee, it was too late to implement something like that.
The nice thing about Hackathons is that you are working together in the same room and yes, there are ways of doing this, so I guess in the future if there is a DNS Hackathon, then that, whatever the organising committee, they can keep that in mind. But that will be made clearer at the time.
DORIS HAUSER: Do we have any more questions? No? OK. Thank you Denesh.
DENESH BHABUTA: Thank you. Self appointed trouble maker.
DORIS HAUSER: Yes, last but not least I will welcome Anand, he will give us an update from the NCC about the DNS.
ANAND BUDDHDEV: Good morning, I am Anand Buddhdev from the RIPE NCC, and I am part of the team that runs the RIPE NCC's DNS infrastructure and this morning I am here to give you a short update on some of the stuff that we have been doing.
So I'd like to start by telling you about our authoritative DNS, this is an Anycast DNS cloud that we operate in addition to one of the route name servers, Kroot, this authoritative DNS cloud carries various zones including RIPE.net, the reverse DNS zones of RIPE NCC's address space as well as the reverse DNS zones of the other RIRs and a number of CCTLDs country code top level domains.
This is an Anycast cloud and we have been actively adding new locations and since RIPE 89, we have added four new locations to this cloud in Caracas, Venezuela, in Paris, France, in Maracay in Venezuela and in Taipei in Taiwan, this is also an opportunity to invite community members to host an instance of this AuthDNS because having such an instance in your network or nearby helps to speed up resolution of the reverse DNS particularly. As a host you need to provide a server or virtual server and if you are able and willing to do that, please look at the URL which is on this slide where you can find more information about the requirements.
This is a map showing the various places that we have authoritative DNS instances, not unsurprisingly we have many instances in the European region, but absent from this is the north American region. So if there are folks here who would like to host instances of AuthDNS in Canada, North America, Latin America, Africa, that would be great.
The next thing I'd like to talk about is this service that we had which we internally called ns.ripe.net. This was actually the very first name server that the RIPE NCC ever operated and initially it was just a single name server that carried all the zones and everything we ever had. And back then this server also offered secondary DNS for LIRs for our members. And the provisioning process was a little bit complicated, which means that for a long time we had to keep this name around even though many of our other services were moved off to other names.
We eventually decided to stop providing this service and we had a proposal last year, we wrote a RIPE Labs article and you can find the link to that article on this page. There was discussion and the community supported our decision to withdraw the service and we started the implementation in June last year and on the 15th January this year, we completed this project and stopped providing this service.
The provisioning for the LIRs was done through the RIPE database and you could request secondary DNS so this work involved updating domain objects. And at the start of this project, we had just over 3,500 such domain objects in the RIPE database and we communicated with all the users by sending them individual emails in addition to public announcements and so users began to take action and on this graph you can see the red line which is the theoretical linear rate of deletion or update of domain objects, the blue line shows what actually happened, though initially when there was a push, lots of updates happened and we were doing better than we had hoped or expected. But then toward the end of the year, around October November‑ìsh, things slowed down a little bit and then at the previous RIPE meeting somebody suggested that maybe we should contact not just zone contacts but also the contacts of the IP address space referring to the reverse DNS. So we updated our scripts and sent more emails and more actions and more domains were updated.
On the 15th January, we still had a few stragglers; there were a number of domain objects that had not been updated despite several emails and attempts to contact them by phone. But this was the deadline and so we updated the domain objects ourselves and completed this work.
The next thing we are doing is IPv6 renumbering of our authoritative DNS cloud, this is the authoritative DNS cluster I mentioned just previously, and there's a reason for it. We currently have just a /48 prefix for this authoritative DNS service and on the internet these days, people tend to filter at /48 and anything more specific is likely to get dropped. This means that we have no room for covering prefix or even a test prefix.
And so, last year at the RIPE NCC was allocated a /29 prefix in IPv6 for various bits of our infrastructure and we have set aside a small amount of this address space for our authoritative DNS cloud, we have a /44 now and we are using one /48 from this for production and we have another /48 as a test prefix and it allows us a /47 prefix as a covering prefix. The idea of a covering prefix is probably familiar to those operating networks and running BGP and it allows for scenarios where if the more specific is unavailable for some reason, for example when a customer has only one upstream and cannot reach the /48 then they can still reach this prefix through the /47 announcement.
The prefixes are already configured and announced and the DNS server we operate are also answering but we now need to update the names, we have to update the AAAA records of the names and we will be doing that in the coming months. And since we provide secondary DNS server for some ccTLDs, they will also have to make changes to their AAAA glue into the route zone and so this will solve some co‑ordination with them.
Statistics and graphing.
For server metrics, we have recently switched to Prometheus I will not go into the details for that but for DNS specific specifically, we were using DSC, which is a software originally developed by Dwayne Wessels and is now a DNS Org project. And we currently process XML files from D SC and we display graphs using a very old pearl based grapher but now we are start to go process the XML files into Prometheus files and we get Prometheus to collect the statistics and store them and we use graph fan in a to display the graphs and later we'll switch to Graphana.
Next I'd like to talk about our DNS SEC signers, we have a pair of DNS SEC signers, Dell servers, which we purchased in 2018. The warranty is going to expire this year and can no the can extended and we intend to continue with the same model that we have for DNS SEC signing, so we are going to acquire two new hardware servers, there will be no change to the operating system, the signers software or the procedures because that's been working rather well for us. And we continue to add and improve monitoring to our DNS SEC signing infrastructure.
And with that, I come to the end of my presentation, thank you for listening and if you have any questions or comments, please let me know.
(APPLAUSE.)
DORIS HAUSER: So do we have any questions? ? Anyone? No. Then I would like to thank you Anand, or is there someone coming? No. Thank you very much.
ANAND BUDDHDEV: Thank you Doris.
(APPLAUSE.)
DORIS HAUSER: That concludes our DNS session today, thank you all very much for coming. Please remember to go to the BoF panel tomorrow and at the end of the sessions.
And now I would like Willem to... yeah. So with that I think everything is set and you can go to the break now. Enjoy.
Coffee break.
