 Welcome again everybody. This is Petter, you've seen him before today. Today he's going to not have you pick between security and performance. Thank you. So, we have quite short time so I will keep it short. Usually when somebody says security... Okay. Security, it means that the performance will go down, right? That's the usual notion. So, first we will look when we care about the DNS performance, then we look what's the so-called random subdomain attack, what's the DNS attack, aggressive cache and how it plays together. So, performance under stress basically means that your infrastructure is under attack and if you mean it seriously with DNS, there is no other way than over provision heavily, which in practical terms means that the normal traffic is not interesting at all because it's way lower, it's like one order of magnitude for example lower than the traffic you have to handle to withstand some modest denial of service attack, right? It practically means that when you add some security sugar on top of it, you will not notice performance wise because you still need to over provision for the denial of service attacks anyway. So, normal traffic is not interesting from performance perspective. When somebody is attacking you, you need to handle a lot of traffic, so any means how to reduce the amount of traffic you have to handle is a good way and you need it badly. And please keep in mind that when we talk about the denial of service attacks there is nothing like guarantee that the system will survive. We can only make it a little bit more resilient but nothing is going to guarantee that your domain will be up if the attacker can push 100 gigabits per second and your line have only 10 then well there is nothing to do about it. So, we just want to increase the cost for the attacker and decrease the cost for us as a defenders. So, when you add DNSSEC of course the data in the zone file will be bigger and the packets will be bigger but under normal circumstances which means not under attack it's practically not interesting because the over provisioning for attacks is so big that you just don't care under normal circumstances. So, now attacker wants to flood us with bunch of queries and what are the options? Of course he can spoof IP address and so on but that's kind of easier, well there are ways how to deal with it. But there is one particular nasty attack which from the attacker doesn't require basically anything special. It might be just a page with little piece of JavaScript and if you get or if the attacker gets the JavaScript for example into advertisement platform it will get distributed to thousands and tens of thousands and potentially millions of computers and the only thing with the JavaScript needs to do to render attack is to load or attempt to load a picture or some other web object from randomly generated name which is just some garbage dot and the domain under attack. So, in this example the domain under attack is www.example.com. This JavaScript or this attempt to load objects from web will trigger DNS query using the very standard DNS API so there is nothing suspicious per se so the operating system have no way to detect this at the first try and it goes through the layers of the operating system API then to the recursive resolver of your ISP or home router or something and then the recursive resolver goes and attempts to contact the authoritative server. Of course at this point the authoritative server is getting millions of queries from all over the place because the query rate from every single client might be like 100 or 10 queries per second but if you have million clients then you are doomed. So, for the attacker it's super easy, super cheap and that's a problem. We want to make this more costly for the attacker and cheaper for us as defenders. So, now there is a new fancy technology which is finally implemented and released into resolvers which is called DNSSEC aggressive caching. Basically the idea is very simple. In DNSSEC if you ask for a name which doesn't exist you get back something which is called proof of nonexistence and the proof says basically in the zone we query for name example right and on the public internet there is nothing like top level name example. So the proof of nonexistence says there is a name which is Everbank, then nothing and the next name which exists is Exchange. This is a real example and this data plus the cryptographic signature which is not on slide because it's this big garbage proves that there is nothing like that and the resolver will reply to the client, annex domain, no such name and so on. And the trick we are talking about here, the aggressive caching is basically storing this proof in their cache and reusing it again for new queries which we haven't seen before but if you imagine that first we query it for the example, it doesn't exist. We get a proof, the proof gets stored to the cache and then we get new query which is example 2 or example EE or something like that. It's still lexically between the Everbank and the Exchange. So when the resolver finds in its cache this proof it doesn't need to go and contact the authoritative server because there is no point in doing that. There is TTL time to live, one hour, so for one hour we don't need to contact the authoritative server again which might be a huge help under attack. So in practice if the DNSseq domain is signed using NSEQ at the moment but that's technically tail it will just work. Over the time the resolver will fill its cache with the proofs of non-existence for various pieces of the namespace so over time it will quite quickly build basically coverage of the all namespace so the random queries will be hitting just the data in cache and will not get forwarded to the authoritative server. So the authoritative server will see short peak because the caches on the recursive resolvers are still not filled but the peak will very quickly go down and stay down for the TTL so after one hour there will be peak again because the records expired and then it will fall down and hopefully stay flat. So for the attacker this complicates situation a lot because well now it's not enough to push little pieces of JavaScript around and he needs to do something more clever and for the defender and for the guy who operates the resolver it's super easy because it basically means install sufficiently new version of recursive resolver and that's it because it doesn't require any configurations the protocol right so of course it helps only with signed domain so if your domain is not signed too bad there is no way to detect this automatically and all the resolvers or operators of resolvers have to rely on some heuristics which is nightmare to set properly of course if it's 3 in the morning on Saturday and phone rings you are not up to tweaking the little knobs in the configuration of resolver and finding the right values for the heuristics so to sum it up please sign your domain it will help you and others and if you are operating a recursive resolver please validate usually it just you know is flipping once which somewhere and it's mostly done so install sufficiently new versions bind 9.12 can do aggressive caching not resolver 2.0 can as well do aggressive caching so pick one of these hopefully the others as unbound and power DNS will join us and if your domain is not signed because ma it's hard to configure and so on have a look at the not DNS authoritative server it's super easy it's basically one switch it has reasonable defaults it will sign the domain and all you need to do is to push the public key to the parent domain and that's it and for some tlds like .cz you don't need to do even that because the tld will find the key automatically and you're using some magic process it will upload it so we had a talk on that but I couldn't fit it in sorry okay so we have couple minutes for questions right does it also work with insect 3 and with insect 3 with opt out of course if there is opt out in your zone it will not work because it doesn't prove anything right but if you are owner of dns sec dns zone and you are not calm don't use opt out that's it I mean opt out is insecure by definition so it's for special cases for huge zones like .com which has 100 million names in it if you are not signed which are not signed yes if you are not calm domain don't use insect 3 opt out that's it but will it be so for example .at uses insect 3 with opt out so yes will it cause problems if the resolver starts the agressification no the resolver will detect it and will not do anything interesting too bad but how many domains do you have I'm curious I mean it's sorry but I wouldn't use opt out it's like you know decreasing security for everyone for little benefits I mean one million domains is like peanuts sorry it's next question yeah that's correct but I mean peanuts over 16 million .e domains we are using insect 3 with opt out because there is a very huge imbalance between what sign and what it is not so we are doing opt out and I can I can just say it's memory issue yeah maybe I should add that the opt out makes sense for TLE right because the TLE is so have so heavy over provisioning that well the aggressive caching for you as TLE operators is not that interesting it's way more interesting for the guys down there because their over provisioning is not that big so if you have like domain example.com don't use opt out it's like pointless for you to use it it just decreases security so thank you for well it depends of course if the attack is small enough you can handle it on your server if it's big enough it will just fill the link and too bad and there is no way for you how to stop the attack if the link is full so this the trick of the aggressive caching is that it doesn't even get to your server so then there is nothing you need to do okay I think time is up so thank you for your attention