Friday, 24th October 2025.
RIPE 91.
Main room.
9.30am:
VALERIE AURORA: Good morning everyone. I am Valerie Aurora, one of your two session chairs this morning, just a reminder to don't forget to rate the talks. There's an email with a link to do that in your IP box. Right, our first talk I am happy to introduce Andrew Losty, PhD student at University College London, department of electronic and electrical engineering to tell you about Towards Operational and Security Best Practices for DNS in the internet of things.
Andrew, thank you.
ANDREW LOSTY: Good morning everybody. Thank you very much, I'd like to thank RIPE for the opportunity to present and I'd like to thank the RIPE community for making such a warm and welcoming inclusive environment. So what I'd like to do is describe some research we have been doing and actions and a lot of this is going to be driven by there's a wish for, there's a wish for engagement, you will see as to where that comes on a little bit later. It's not a passive action that I am trying to accomplish today in terms of saying this is what I have done, end of story, that we are moving on, it's very much an ongoing activity which I am hoping some of you in the room would work with us to participate in.
What I have got to do is give say that this is a joint action so we can see the four names there, myself, Anna, Abbey, Matthew and importantly, Infoblox, Jim Moseley, who has been working with us, it's very hard to have the business side as well as the academic side and we are working together and that's been extremely positive.
So just a little bit of an overview. We want to give a little bit of a view as to why we are doing this because it's meaningless if it's just an action. We want to give a review of the current regulations, standards and guidelines. That's not to go overall this again but it's just to show you as to what we have done and what's driving us in this direction. Then we are going to deal with the lab experimentation that we have been doing and the results and the final is where we think this should be going.
So we did a paper and the paper sort of, you have seen the title and we did that in collaboration with INRIA and it was very accepted at the IETF so we were very happy about that and it's to basically carry out empirical research, measurements, observations, experiments and we did this on 35 current IoT devices to see what is the state of device operations, what are they currently doing, have they changed, are they much better, it could have been the case that, the gated, the need for us to pursue this further but we'll see as to what we found and as I mentioned, the investigation of the regulatory frameworks.
So the first thing is this is brief but it's only just to give you a little bit of a view as to the motivations, why are we doing this, what might have changed. IoT sort of has changed I think and is changing so first of all there's the growth, so it's clearly set to double by 2034. So high rates of growth. Now that doesn't change much in itself but it's that growth in other areas in medical IoT which is seeing a far higher rate of adoption than traditional IoT we are used to so that really is expanding a great deal and we are looking at the critical infrastructure, so the movement to industrial and utilities growth is extremely high so therefore the security assumptions we have made which is not really changed a great deal for home use but is certainly changing a great deal for these applications.
We are looking now any of us in the room could have looked how we all know that the rate of attack, the rate of attacks is going up and it just depends as to who your measurements by, just this week the national cyber security centre in the UK reported a 50% rise in serious attacks, the Z scaler which is take to IoT malware so is probably more focused on this reported a 45% year on year and then HIPAA, where we are looking at the medical records showed a 13.7% increase, so we are seeing more serious and larger scale attacks. The cost of the breaches is serious and so that's going up, that's 4.4 million and clearly what it says is that the highest loss area is health care. Again another factor which is driving the work.
There's many concerns with IoT devices, so we know that to some extent trying to pin down the actual weakness is very difficult but the IEEE vulnerability analysis report gives two million vulnerable end of life device and then the quote is that it's 50% threat end by high vulnerabilities. That's backed up by pal low Alto and pal low Alto give that at 57% of devices being vulnerable in some ways. So these are the serious bodies who are analysing the devices and I think it's just as, oh and clearly the pal low Alto 83% reports unsupported OSes. The bottom one I think is just as serious because that is really saying what the users feel about these devices and if 62% are reporting concerns and I think a lot of us would share those concerns, then it's really hampering the market so it's not just a passive concern.
So we are looking to approach this in the research in three different spheres, the security, so the protocols, the support of secure DNS, their operation, we are looking at the behaviour, a lot in that area in terms efficiencies and how they handle normal traffic, we are looking at TTL protocol implementation and then we are looking at the controls, so the standards and regulations and guidelines. So what's in place to actually keep these things operating in some sort of correct way.
So we are not going to go through the regulations, that would be sort of just to say this is what we have done as a starting point. So we went through the standards, there's lots of standards, IoT reference architecture, IoT device cyber security guidelines, cyber security for consumer IoT base guidelines, that really gives the impression that everything is done and that our concerns should be finished because these are published, either standards or guidelines. What we are doing is only addressing the DNS IoT sector. And we don't find any particular reference in how the devices behave in DNS and what they should do in DNS.
So this is a little summary and I am certainly not going to go through this. But I will say so the column, the DNS and IoT is where we are looking for specific operational or control guidelines and we have been through all the major, what we think are the major publishers of standards, we don't identify any guidelines specifically for DNS IoT.
So that's the first page. That's the second page. So we do see sort of there are recommendations internationally and there are some which refer to DNS but there's nothing for this platform with all its limitations of constrained hardware, limited CPU, limited storage. This is the area we are looking at and this is where we are trying to improve IoT security, particularly on DNS.
So our test bed. We got simple environment in our lab, so 35 consumer IoTs, giving quite a wide range of devices in their complexity, sophistication but try to represent a cross‑section of typical used devices. We have got DNS unbound server which can configure to either do secure DNS or standard DNS. We can use it to manipulate packets and so the two things we are doing here, we are doing passive collection, just to see how did the devices behave. What are they doing in their normal operation, they boot up, we use them, what do we see in the DNS there and then we are doing the active.manipulation so we are modifying the packets of the DNS responses, we are changing the TTL values, we are changing the resource records, we are changing the number of resource sort of records to try and see as how these devices behave but the we can they are fully automated, we can reboot the devices, we can start experiments, it gives us a good cross‑section as to what's going on.
The first question is, this is going to be no surprise to anybody in the room but you have to do the test, do the devices support encrypted DNS, of the 35 devices, none of them do but that's fine so as long as we know that, we know as to what we are working with and where we are. None of the devices support DNSSEC, which again is not really surprising. One thing which was a little bit surprising is that the DNS extension EDNS zero, to support larger pay loads above 3512 bytes, there was only one device supported that, it's a very limited, a very limited implementation really as to what we are seeing.
Then we looked at an old matter to see if it still present DNS source port randomisation so clearly the security concerns were well known, an RFC was produced, measures for making DNS more resilient against forged answers and that gave us the answer but it hasn't been implemented, all these years later. So we see that one device whereas we should clearly have a completely randomised answers, one device gives from 1,066 requests, it gives 452 on one port, 134 on another port, that's not random at all, two other devices give all the responses on one port or another. So therefore there is no randomisation, they are open to spoofing, they are open to malicious responses. I have to thank Ulrich Weisser who worked with us at the DNS Hackathon, the RIPE event in Stockholm, who did programming for us with a weekend on this work, so tremendous work by him. (Ulrich) transaction ID, the means of avoiding spoofing is clearly combine the transaction ID with the source port and we see again serious problems that the devices did not perform this security, so we should have a range of 65,000 on the first device we see a range of eight, so far from as to what we want, next device is a range of two, everything is going out with either a zero or one, the next one looked a little bit better at first with zero to 4 F, OK, that's good, we see some randomisation but it's only 0.12% of the entire range so not great and the last one we see that the device increments it's transaction idea with each request made. The implementation is all just wrong. So we looked, one of the concerns we saw that was the devices use of hard coded DNS so the devices have got DHCP servers giving an IP address that should be extremely positive in the fact that they should behave in the way which we expect. However quite a number of the devices, well five devices in this case are by passing the DHCP provided DNS and are using their hard coded. And clearly the problem with that is if you have got a company which is implementing a control over DNS requests, it's doing DNS inspection to make sure the devices are not compromised, they are not going to malicious sites and in this case, because they are going out to non‑assigned addresses, it could well be by passing that, by passing security controls and leaking data to a third party.
So your requests are going, are really going elsewhere.
We identified those devices. We looked at the re‑try rate. So this is just to say how the devices behave when you lose the DNS server so OK, in a normal network, wide bandwidth network we are used to, it doesn't matter a great deal but in this case, some of the devices are using very low bandwidth connections, they could be using Zigbee or Thread, you might only have 50k throughput, depending on the number of hops and so if you are making frequent requests and in this case we are seeing between ten and twenty fold increase, then you are really hammering that very, very low bandwidth network because you are frequently making these DNS requests and you are reducing the battery storage. So if you have your thermostatic valves, the room switches that are batly powered, that's certainly taking a big impact when these devices are not behaving in a controlled way so we'd expect them to do some, to perform an Expo mention back off mechanism so that they really trail back the number of requests which they are making, we expect them to put in some form of jitter or delay so we are not all transmitting at the same time and we are not seeing that.
So another concern.
Device identification is a little bit open because these devices are clearly using unencrypted DNS, you can see in the pay load what the domain that is being requested but it was also seeing that the devices are highly identifiable in the frequency, the timing, the length of the responses so a lot of factors that say it's not just going to this domain but it looks like it is this particular device and that might identify cameras or sensitive devices.
So perhaps and I am not saying the point but perhaps there should be some padding or some mechanism and the other point is that lots of devices do a precursor action before they do any DNS or just after so they might do an ICMP request, they might do some other action but two the things combined help identify what the particular device is.
TTL clearly the response, the device makes its request for its domain, it gets its IP address back and it gets a TTL and we would want the advice to device to cache that and then use it for the period of the caching. That's not seen to be happening in the IoT devices, irrespective of what the TTL value is. The devices have a fixed constant DNS query rate. What we did is we changed the TTL from either point one or one second just to give us an easy means of analysis, we then put it down to zero and then we put it up to 11,000 days, which just seemed to be the biggest value we could get in. And so because of the lack of respect for the TTL value which it gets back, then what we see is that there's an increased DNS load because the making more queries, running the battery down, if it's a battery device, increased latency because they are not holding the value for the amount of time it has to go out, resolve, come back, then perform its action. So very poor behaviour in terms of the mechanism, which should be there to actually provide the most efficient operation.
IPv6 support is extremely limited so we got a number of devices, I think by actually performance the DNS queries with IPv6, we compared that to some published research which is just done recently and that came out at about the same as the figure which we have seen and that's about 20% and that's not even 20% of the the devices performing a full DNS function, so what we clearly observe is a general lack of support for IPv6.
Then two last methods. DNS is susceptible to RR injection, so we modified the responses just to see whether they would accept them and even though they are non‑routable specific for test purposes we'll say the devices accept them, we are not surprised at that because these are basic devices and it really should be done at the application layer but it was just to see whether they accept anything and they certainly do.
This one is a little bit different though because this one we expected a little bit more and we send responses with 100 duplicated resource records and what we see in that is that the devices fall over, they crash. They cannot handle the large and what it means is we saw at the start there was only one device supported EDNS zero which would handle the larger pay load, if they don't do that, they should switch to a TCP, we don't see that and if they don't do that, they should fragment the impact and what seems to happen is that they do fragment the impact but they have a lot of problems. And so seven of the 35 devices were rendered inoperable when we sent back large pay loads with a hundred responses.
Now. And that's what I have just covered on the duplication.
OK, the findings we give a summary. I am not going to go through this because it is just the results but in a tabular form that actual we said so and if anybody wants to look through this, after, that would be great.
And again just finish off the results. So the conclusions I am going to skip through very quickly, just go through because they are all the points, this is just highlighting all the points we have said as to what they support, what they don't support and the fact that they only give partial implementation of the RFCs. So clearly the two RFCs for the transaction and ports and the back off mechanism. And I am going to skip, just because these are all the matters we have seen. So. The means of addressing this. We identified that the existing standards and regulations do not address these points and there's the reasons and so what we want to do is propose an IETF security and privacy for DNS IoT devices, so this is a best practice, we are not adding regulation, we are not adding standards, we are not trying to create any new mechanism because there's enough, we are just trying to put a best practice standard and what we would do with that, this is the best practice guideline which we have just launched in July. It's now version 1.1 and this is where we are looking for engagement for people to contribute to say is this good, are the ideas within the guidelines good, can they contribute an add or question, I think it's fine to say. This is a lot of the work is Jim Moseley and Infoblox here, we have to give a great deal of praise for him and what it does, I am not going to go through these because they are really addressing the points we have seen and you will just be of the mindset that you have seen what the problem is, here's the answer and clearly we cannot specify that devices must adhere to secure protocols, because many of them won't, they don't have the hardware implementation to do so but we do make the points of saying what they should do, some cases as to what they must do, some of this is so the EDNS, there's a paper which is just coming through to fruition which has got to be addressed in our guidelines which is DNS over CoAP, we will be looking at that, there's really lots of matters there what we are going to that we see will solve matters and will make devices more secure and more efficient in their operation, more controlled and our aim is to have the regulation bodies, the standards and guidelines refer to this. That is the goal, that is our aim. And that's what we are hoping for.
So there's our test lab. There's a little link there, we have got two hundred plus IoT devices, we have been doing, and these are the people who have been working hard on that really on this work in terms of bringing it together so I'm clearly only the spokesperson here today for this.
So in conclusion, I'd like to just say that I would be very pleased if any of you can look at the paper and make a contribution and thank you very much for your attention today.
(APPLAUSE.)
VALERIE AURORA: Thank you. A very good talk, don't forget to state your name and affiliation. Wolfgang Tremmel speaking for myself, did you include OpenSource based IoT devices in your tests and what were the results?
ANDREW LOSTY: We didn't. There is a good deal of scope for this, what we started because I think at the start we didn't know as to what our findings would be. And so we only went for consumer grade products that reflect the commercial market. I think that there's a very strong point for saying how did these compare as you say with OpenSource and how did they compare with medical and sort of infrastructure. So we take it on board but it wasn't done in this initial 35 device, yeah.
SPEAKER: First, I significant if you haven't already that you also bring this to the attention of the DNS operations working group in the IETF. And make a briefer and more succinct presentation there for time reasons. Because there's a lot of operational experience in that group that may not exist in the IoT groups so just an idea. Second a question, do you ‑‑ have you seen any commonalities between the behaviours that has led you to think that the manufacturers are using a common library, DNS library of sorts, that might be interesting to try to influence in order to improve things?
ANDREW LOSTY: I take that on board and I can absolutely follow the logic because the behaviour should be to say if these devices and we saw some devices are using a single port and then the logical question is are they using the same libraries for their DNS operation. We haven't taken that and I think we have, we are looking to interact with some manufacturers to begin delving down deeper into that now but it is clearly recognised and it would move us forward. I think we are going to see how far we get with the best practice guide and that will help us to decide but I take it on board completely. .
VALERIE AURORA: We are going to stop any new people joining the line and then this microphone.
JEN LINKOVA: As someone once who tried to make IoT devices work over IPv6, first of all sorry if I missed it, your document which is definitely very userful because there are so many different standards and expect that hosts must implement all must and should implement all should and unrealisitc. Is it DNS specific or are you making kind of IETF host requirement document which I think might be useful for the same way V6 ops produce a CPE requirement document, right, we do know how to expect for CPE router for example, a huge set of standards.
ANDREW LOSTY: We are aiming, we have got to be focused in this and I think the IoT breadth of security areas is so wide that we have decided to just go with DNS on IoT. I think once that comes through, if we can get that through to a best practice, then it leaves the next question whether there should be a best practice for the whole of the IoT, at the moment we are being very focused on DNS IoT.
SPEAKER: Tom Hill from BT, I am hoping I might put you in touch with one of my colleagues, we'll have a chat after this, the main question is similar to Jen Jen but more we have thought about best practices for IPv6 and IPv4, Happy Eyeballs behaviour, there have been noticeable instances of devices very common ones in the home doing very strange things when presented with IPv6 DNS resolvers.
ANDREW LOSTY: Yeah, clearly one of the recommendations will be the support of IPv6 and matter is going, IPv6, there's a lot going, what I think though is the case now I will just be brief then, you gave an opinion there and your knowledge within that area of IPv6 may be, your experience may be far greater than ours and that's where we are looking to have contributions so the IETF means of putting this forward is to try and encourage people to get on to the mailing list and put in a view so rather than me clearly saying now that I think that you are right or that we disagree or something, what we are looking to do is harness the skills and the knowledge for people who contribute and if that is a push towards IPv6 or against IPv6 in some ways, then that's good.
TOM HILL: Sure, we'll be at the IETF in a week or so, we'll be able to have a look.
VALERIE AURORA: Any on lines questions? I'd like to throw out one, Valerie Aurora, you can get paid to work on the Cyber Resilience Act IoT a standard, check it out. Thank you very much for this very important talk. I appreciate it.
(APPLAUSE.)
OK, our next talk is IPv4 versus IPv6 for AuthDNS by Shane Kerr from IBM. Thanks Shane.
SHANE KERR: Thank you, good morning everyone, it feels good on a Friday morning to be nestled between two other DNS talks so.
This is lightning talk, a very short thing, I wanted to mention a little measurement that I did, basically I work at IBM NS1 connect and one of our customers was asking our business people how good is our IPv6 network and so they were like oh we are just going to they will them it's great, no, no, maybe we should check. And so that was what I wanted to do. And so the way I decided to do this, I set up a DNS zone that all of the name servers only resolved to AAAA meaning it was only accessible via IPv4 and then I did the same thing for IPv6. And I ran it through a little zone checker, there were no warnings about only having IPv4 addresses but there were warnings about only having IPv6s, that's the first thing we could do to improve the universe.
Yeah, and you see for each of these zones, I picked just 1,000 RIPE Atlas, it's great, please check it out, it's great for doing ad hoc measurements, especially in the DNS space, I picked 1,000 random probes and I did a query of TXT record in the zone and I did it again, the reason I did it again was so increase the chance of all of the rest of the stuff being cached so when you do a DNS resolution, it's got to chase down from the parent all the way to the zone itself. And all these things need to be cached so it's not a perfect solution if you are using for example the big public solver or an ISP with a lot of resolvers, they will probably run a cluster and might end up with different server but I wanted to increase the chance of that. What I wanted to have is the actual measurement is the probe queries its local recursive resolver, that recursive resolver queries the authoritative server so basically two look‑ups and that would be the whole test. Anyway, I made a with the response times, I cut it off at five hundred milliseconds there, the time out by default I think on RIPE Atlas is five seconds, that makes the graph very hard to read because there's a bunch of white space. You can see and the orange here is IPv6 and the blue is IPv4 and so you see in this case, IPv6 is a little bit faster, great, everything is good and yeah, that's basically it. If you look at the top it's a little hard to read because the font is a bit small, we see average per probe, the issue is when a RIPE Atlas probe tries to figure out what resolvers are on the networks, it gets whatever DHCP tells it, there's two or three IP addresses that come back, what we can't know is like when your laptop gets that, it may have a different sort of heuristic for deciding which of these resolvers to query in which chord, it could probe them once to see which is fastest, it might pick the first on the list or until that gives a surf fail and move on, we don't know, in this case I just picked the average and that's what we see here.
Now, yeah, there's a summary about that, we see about 3% difference, when you look at the mean, which is fine, it's basically the same.
And like I said though, we have multiple offers so my, the hypothesis is that people setting up their networks are probably going to put the fastest resolvers first and the others are back up in case something goes wrong, if we pull out the fastest result, the graph looks slightly different and the sort of improvement of IPv6 over IPv4 becomes less but it's still basically the same. I think the first thing to take away is that well just to go over this a little bit more, I don't know which of these graphs is closest to what people see but they both tell the same basic story which is that our edge, for this last part of the query look up, IPv4 and IPv6 are basically the same.
But that's, I don't really want to talk about any of that, what I want to talk about was something I noticed at the end of this thing which is of these, you ask for 1,000 measurements and you get some number, not quite, because RIPE Atlas has some peered non‑deterministic methods of figuring this stuff out, it's fine.
But for IPv4 97% of the measurements that got submitted ended up with a correct answer. IPv6 was 96%. Does that mean we don't mean to use IPv4 for AuthDNS any more? We can certainly say all of the cautious requirements that we have had in the past for saying make sure you have two IPv4 addresses and if you want, add IPv6, that was strengthened more recently saying you should add IPv6, maybe we can say you just have to be IP and if IPv6 is cheaper, it's probably good enough, I don't really know, that's it. That was all I wanted to say.
(APPLAUSE.)
JEN LINKOVA: A question: So you got 1,000 random probes. How do you distribute it with the resolvers because maybe most of them were using like or few very well known resolvers but also getting a few thous probes with random resolvers.
SHANE KERR: I did not limit the probes at all, I said give me 1,000 probes globally and I did repeat the test with basically identical results and the queries with the probe over covers were done with IPv4.
JEN LINKOVA: You did not try to distribute them between different ASes.
SHANE KERR: No, and if you are run running a resolver on your laptop in a crappy hotel network, then you can't get to an IPv6 only network.
SPEAKER: Mark Van del Wal at AFNIC, also a developer of the little zone checker tool you mentioned in the slides. Feel free to open the Github issue few feel we should change the warnings.
SHANE KERR: I will do that, great, thank you.
PETER HESSLER: Peter Hessler, thank you very much for doing this research, it's great to see it quantified and documented, I have also done a number of other IPv6 only experiments of not just DNS but other services and my concern is for the audience if you want to run IPv6 only services is be aware of who your users and customers are. And like the vast majority of people would have access, but the ones you want to serve, if they don't, then you are doing a disservice to yourself unfortunately so just be aware of who is trying.
SHANE KERR: I agree with that but I also think we are at the stage of the internet now where that's also true on IPv4, like why are we so worried about IPv6 when we just assume everything is fine on IPv4 and I think we are past that now.
PETER HESSLER: Absolutely, yes, dual stack at minimum.
SHANE KERR: Thank you.
AMADEO BECK PECCOZ: Thank you so much. Do we have any online questions? No?
VALERIE AURORA: We have one. Shane, you got time for one more question? It just came in. From Simon from Switch: "Might the population of Atlas probes be biased to overestimate IPv6 support, i.e. people who run atlas probes are also likely to have working IPv6?"
SHANE KERR: This is very much scientism, this is not science, this is just one measurement, well a few measurement results picked at random. If people want to do more rigorous research in this area, I am happy to collaborate but I don't really have any more plans right now so.
AMADEO BECK PECCOZ: OK, while we thank Shane with a big applause.
(APPLAUSE.)
If you think that his presentation was good, please rate it, you have the URL in your email, please use it, while the rest of us try to fix things, there is someone who tries to break them, I am going to introduce you to mark Van del Wal who is going to talk about the intentionally broken DNS service. The stage is yours.
MARC VAN DEL WAL: Well hello everybody, I am mark Van del Wal, R&D engineer at Afnic of registry of .fr domains. Today I will give you an update on one of my project called IBDNS, I have had a chance to use it for something interesting and I thought you would like the story. So first of all, why do we even need or want a server that intentionally miss behaves, so think of as a testing tool and a testing tool to make sure in this context for example zone master gives us the right diagnostics in the right situations.
And also because I think it can be useful for other situations, making sure that your IoT devices don't catch fire for example. So I thought I proceeded with this project which I started three years ago and this is me at DNS Org 39, talking about the intentionally broken DNS server for the first time, back then I couldn't do much, since then I added many more features like well mostly centred around RFC 1034 and 1035. It's released as open as well on their GPLV 3 and I have added a lot of documentation. This is me three years later at the DNS Hackathon in Stockholm and among the project that were submitted, there was a proposal to implement a draft that would give us in addition to the BGP clock we saw, a DNS clock. So how it workses like NCI D, a client asks for the time in the server returns the time in an EDNS option and so Lars and I teamed up together and started implementing this feature. Lars had some patches for BIND and DIG and while I started implementing it in IBDNS.
This is an excerpt of the configuration file I had running on a public instance of IBDNS which was useful for Lars to test his version of dig and also for other people to play around. And this gives you an idea of what I came up with. Do everything right by default or according to the query name, it would exhibit different behaviour and/or like returning random bytes instead of the correct time or skewing the time by a fixed amount to simulate a server that was way out of sink.
And so off we went. So this is how it looks like when things are operating normally so with the patch version of dig, you add the plus UTC option an you get the time and the UTC stamp EDNS option. And so then I said to Lars OK, all's fine, try this domain instead, this happened. Well. That was the first iteration so clearly it wasn't ready for production yet. Second iteration, he made, he added some checks for return values of C library functions like you should and this is how it should operate. And I had a more, I added a few more edge cases that resulted in him writing a little test suite in the form of a shell scrips and the shell script would just query a lot of names and compare and we'd compare manually with the expected behaviour so I guess that was nice.
So what did we take home from that Hackathon. Two server implementations that UTC stamp extension in BIND and in IBDNS so two independent implementations. Also it works in dig and dig will not crash. If even if we throw the worst of the garbage possible, so this is ready for production and also IBDNS did not support EDNS at all until now. So it was a good opportunity to have it implemented, Twente a road map but I just didn't get to do it until now.
And also last but not least, let me introduce you to a new DNS animal. So some of you know of the DNS camel but Jonas Anderson made this DNS cat and he very kindly let me use it as the visual mass cot for IBDNS so thank you very much Jonas. OK. It goes to show that good contribution for open do not have to be code, it can be ideas and also mascots. Anyway. So if you are interested in the source code, here's the link to the GitLab repository and the GitLab QR code as well and with that I am happy to take any questions. Thank you.
(APPLAUSE.)
SPEAKER: Lars Liman from NetNode. Thank you. This was absolutely top fun, we had so much fun doing this and this shows two things, one is how a Hackathon works and the immediate and very cheerful and good interaction you can have during a Hackathon. This brings things forward very rapidly and efficiently so please go to Hackathons, it's great fun. The second one is that before this, I had my slight doubts about the usability of IBDNS but as we sat there and my code just crashed, I realised how important this tool is as a testing tool, IBDNS is really, really useful. For those of you who develop code and implement code, please make use of IBDNS, it's actually very, very useful to test your code. I am quite sure there are new ways to make my dig crash but it's probably not going to be the UTC stamp. Thanks.
MARC VAN DEL WAL: Thank you very much for that comment and yes, I second that, it was really great team work.
MARCO SANZ: Speaking for myself, serious question: How do you come up with those test cases? What kind of legal or illegal substances you consume to come up with those ideas!
MARC VAN DEL WAL: Well first of awful, I'd say my general methodology is to first read the RFCs and kind of anticipate what could go wrong in for example naive implementation, a good example of that is the handling of empty NOG terminals which is something that's in RFC 1035 and yet modern day implementation still gets it wrong, and IBDNS can replicate it.
AUDIENCE SPEAKER: Thank you.
NIALL O'REILLY: Just another member of the community. I want to echo what Lehman said about hack tons, I was at another one in March and it wasn't the project I was working on but there was another tool similar in some senses to this one called Canned DNS which gave you the possibility to configure deterministically broken responses which were repeatable. Another clever tool. I am sorry I forget whose initiative it was, I wasn't in that group.
MARC VAN DEL WAL: It must be Matt Stufburg's initialive, actually the idea for that tool also came forward from the discussions I had with him about IBDNS so, and it's also, yeah, synthesising responses like Canned DNS does is something I'd like to do as well and would be a very useful feature in IBDNS and would let us finally test zone master really systematically with IBDNS for everything.
VALERIE AURORA: Just one question about me, was the artist of the logo at the Hackathon or was any more details on that?
MARC VAN DEL WAL: Yes, he was.
VALERIE AURORA: Cool, thank you. Big round of applause. That was amazing.
(APPLAUSE.)
VALERIE AURORA: Dual purpose, all right, don't forget to to rate the talks and next up we have Dave Phelan from APNIC, filter your things or no, I don't want to use your NTP server.
DAVE PHELAN: Good morning everybody. This slide deck has gone through a few working titles. It started out at no, I don't want your customer details; no, I don't want to use your NTP server, but eventually I settled on filter your services. Whom I. I am a network and infrastructure engineering for a long time. I am now policy manager and I like the odd cat meme from time to time, knowing what I am what's standing between you and coffee, I am going to try blast through this. I am going to talk about numbers I collect a lot in my region and Tom Strickx talk got me thinking how much bad SNMP is there, I thought I would have a look. How many servers are insecured and bad news, it's lots. So we look at DDoS by layers, obviously the area I am going to focus on is up here in layer five, six and seven. Which is reflection and after cation, etc. So for those that are uninitiated (Amplification) attacker wants to go and break some stuff so they contact DDoS about the rental service and I go that's fine, I will go and deploy a botnet, here you and go and we ask the botnet to get all of its bots to query A specific A record so the open recursive resolvers guest the text record in my domain, it goes to all of these open resolvers, we pull back the actual record for my evil.com domain and it will then respond with this 4k record and then go and attack my victim and eventually my victim will hope plea canon fire and we on with life to our next target.
So why reflection and amplification, well you UDP is a really great reflection target. We can spoof it easily, it's connection /HR‑LSless we don't have a three way handshake and amplification, anything that gives us a good result in terms of small query, big response. So DNS is great for that because we can get some variable size responses but there are much better protocols. Or better servers. SNMP can be random, DNS is fairly consistent, my two favourites are M TP and M cache D. Who is doing what, I had a quick look around the RIPE service region, I had to modify my scripts to to pull out the RIPE service region and this is what we found. So when I look at NTP servers, these are all open, one, two, three, anywhere between a stratum 2 and stratum 12 time server I see around the traps, no surprises on Russia being at the top but Italy, 230 K. I had a bit more of a look into some of these devices, I have got some more scripts that do random sampling on the results and it's mostly consumer CPEs, with open port 1, 2, 3, I don't want to query your time servers so my question is to the operators, why are you not filtering these services towards your customer's residential blocks. Your residential customers pay you the least and you are giving them everything.
Should we be doing this, I don't know. I hear arguments for, I am a carriage service provider but we should be securing our networks, don't put it in the realm of the security teams, this is a job for all of us.
Romania wasn't on the list, I had a quick look, they are sitting at 7th in about 90 K, when I look at the global numbers, typically I see my corner of the world feature fairly prominently, usually it's US, India and ton of other APAC countries so the fact that we don't tend to see the European countries or the RIPE service region up there is not surprising. We have a quarter of the world's population just two countries, so it's going to happen. SNMP V2, this scarce me more than it should. This is only things that have responded with read only community of public. So these are things that are in default mode. Italy: I found 3,000ish Cambium wireless devices, they clearly belong to a wireless ISP somewhere. Anybody know what the default configuration of a Cambium AP is, guess who the read write community is, private! Guess how many of them have now had a new system description? I don't, I didn't do that but yes. A lot of them were set for still default private.
So they have gone thrown an IP address on them an put them out into the wild so Italy, Russia, Poland, Spain, Sweden. DNS recursives, this is only DNS resolvers that will actually have recursion enabled and I again run up sample queries to make sure most of these are functional so Russia, Spain, Ukraine, Italy, Poland.
Romania is sitting down there in 16th so good work.
This one we shouldn't be talking about in 2025. Memcached has the highest bandwidth amplification factor, that was a problem in 2016 which we thought we'd solved.
Filter port 11211 memcached problems go away. Clearly that's not the case. This is an area where the European side of the world out strips the APAC side, we don't have this problem to this degree on my side of the planet.
So if your country is on this list, please go and have a look at your networks. So prevent your services from attacking others, do things like rate limiting, please do BCP 38, some much you have been around to a couple of years, it's gaining adoption but we are getting there, securely configure your DNS and NTP and SNMP servers, we don't need your public SNMP data available to everybody. One other note, one of those SNMP servers was also from an ate al Jan ISP downstream of telecom Italia that had one of their BNGs wide open, two that you have thousand customers sit sitting on that B N G, no open resolvers, if you are running resolvers, please lock them down to your customer's IP address ranges, these are common things we are not doing. If you don't know what you don't know. Check your own stuff with Shodan or subscribe to the shadow server reports, it's not hard, they are all free things. Sources from data, cyber green, Shodan an cats of the internet everywhere. Any questions.
(APPLAUSE.)
SPEAKER: Great work, the problem of course is that the people who should be fixed this are not here, so please name and shame so that when we go back home, we can mock these people. Thanks. (APPLAUSE.)
DAVE PHELAN: In my own service region I do that but I don't do it when I'm travelling, I like to come back to other countries from time to time.
PETER HESSLER: In the past Reddit was also a large source of this red disadd add change in their distribution to local host, I was curious to listen only on local host, so I am curious if you checked red difficulties and if there was a significant difference you saw.
DAVE PHELAN: I didn't, I literally threw this together at 5am on Tuesday morning.
PETER HESSLER: Valid.
SPEAKER: One small question. Is your reach increase looks like amount... it looks like from the amount of device but could you check all amount of the device in the country because the country is completely different size so it could be different.
DAVE PHELAN: I have a much longer version of this presentation where I dig into per Capita type rates and that sort of stuff as well. Obviously for a lightning talk I just want to hit the headline numbers and let everybody else work the other bits out so yeah.
AMADEO BECK PECCOZ: OK, well we thank you so much for your presentation, a big applause please.
(APPLAUSE.)
We are just in time for a well deserved coffee break. Before we run out, please do not forget to rate presentation, this is really valuable information we need from you. Just not in the case that we make it right but also in those cases how you think things can be improved. Thank you so much. (APPLAUSE.).
RESUMPTION OF THE GM ‑ VOTING RESULTS
ONDREJ FILIP: The voting results will start in a few seconds, if not, feel free to go for refreshment outside of the room. If I can get a little bit of attention. Here are the voting results from the general meeting. You remember that this general meeting was in, there was just one resolution and there's no surprise in that, the super majority of the members voted in favour of the resolution number one so in case there will be a nexus contribution, this will be redistributed and if there will be a deficit, it will be covered by RIPE NCC reserves, no surprises, almost 90, more than 92% voted in favour, 7% against and just 9 votes abstained. So really no surprises here. And last announcement: I have to thank Joao Damas for being here, independent observer, please help me to thank him.
And with that I am closing the general meeting so the general meeting is closed, enjoy the last session of the RIPE meeting and see you all in Edinburgh. Thank you very much.
(Coffee break)