 Dit is Willem van NLNET Labs en hij gaat opnieuw praten over stupresolving of de pijn die het invoort en hoe hij het voor je zet. Dat is waar. Dus ik ben aan het werken op deze library, de Gettiness Library, die is een versetelstupresolver. De versetelstupresolving gaat over de motivatie voor de versetelstupresolver. En wat van de hudels moet het opzetten. En ook op het einde de infrastructuele positie van de stupresolver. En hoe het misschien moet veranderen of moet er anders zijn. Dus met het leven op het einde... Ik heb niet het leven op het einde van een ebbs, maar de einde van de netwerk. Met de end-user-devices, of de end-user, opnieuw de infrastructuur of de netwerk, de services die de users gebruiken. En ook de middelboxen die de users traffic hamperen. En de infrastructuur die het ebbs dropt op de users. En dit is eigenlijk een van de primaire motivatie voor de versetelstupresolver. De initiatie van de technische commuutie om de encryptie everywhere te doen. En de encryptie van de end-user tot of tot de service die het gebruikt. En zodat er niets in de tweede kan intervieren of gebruiken of doen. En dit is de DNS ecosystem. Je hebt de autoritatieve service. En ze zijn gehosted door DNS operators, TLD's. En ze zijn queries by... Oh, let me start at the edge, this part. Dat is waar de stepresolver resides in de device of the end-user. En het sends its query to the recursive resolver which then in turn iterates over the authoritative service to find the answer the user asked for. En de observation I want to make here is that the authoritative servers reside in the best networks. They have complete network transparency and they are easy to manage etc. They have, so to say, the best end-to-endness properties. And it's already getting harder with recursive resolvers. But the stepresolvers are by far in the most hostile end-to-endness environment, so to say. There is a lot of traffic engineering which interferes with what stepresolvers see as also indicated by better in the previous talk. So, to every initiative for an encrypted connection starts with the lookup of an address. And to be sure that you connect to the actual server the correct endpoint, you have to make sure that the address is correct. Dinesack can provide origin authentication. It's a method with which you can verify that the answer of your DNS query is indeed coming from the owner of the domain name. And the standard sort of when it was developed it was made for the recursive resolver. But if you want to do encryption from the very end the edge of the network, the end user to the service we have to start right there and do Dinesack validation at the stepresolver. Having that said, the web server also authenticates or not a web server, the browser authenticates the web server by verifying the name on its TLS certificate. So, if we verifying that name do we actually need to make sure we are connecting to the right address because afterwards we are authenticating again. But DNS is more than just addresses. There are also referrals in the DNS. One of the best known example is perhaps the meal exchange record which refers you to a different name and of course you have to know that this is authentic. This could be, when this answer is poefed then in the end you will connect to the wrong name and TLS might authenticate but it might authenticate for the wrong name which is not the meal server for the main name you intend to connect to. So, TLS authentication that's another thing where Dinesack can improve because regular PKIX has the too many certificate authorities problem does any certificate authority can basically vouch for any DNS name. There is one certificate authority which I really like, which is Let's and Quit. They hand out certificates for free because it doesn't matter how pricey your certificate is which you bought, how much you trust your certificate authority because all the others are able to vouch for your name as well so they can basically interfere with your TLS connection. So Dinesack has a means to deal with that. You basically publish in your domain name a hash of the public key used for your TLS encryption for the service of your TLS encryption. Another nice use case for Dinesack is the signaling of TLS support. For example, meal servers don't have interaction with the user so TLS for SMTP was before was opportunistic in that you tried if you don't get it you fall back to plain text. So interfering middle box could just let it fall back because there was no, if it was using a certificate authority which was not recognized by the other end then there was no way to get confated information to the user. So with Dinesack a meal server can check well this one does have TLS. I'm certain about it but because it verified I looked it up in the DNS and I should be able to set up a secure connection for delivering the email. So now that in contrast to regular PKIX with Dinesack you have ultimately the root zone or the Dineskey of the root zone that vouches for the delegation to the top level domain and the top level domain has its own key that vouches for the second level domain that's mostly where your service resides so instead of having at least 1500 certificate authorities you have two. So there's the root key signing key and it is the root of the DNS and it is used to sign the top level domains as I just told you. There is a problem, a hurdle, the first hurdle for a step resolver which is trust anchor management because there is a trust anchor management protocol or a wall over protocol so to say but it's written for because of resolvers. They assume a permanent running process with system privileges. It is a protocol which have look at the key do you see a new key, wait for 30 days is it still there, okay you can trust it it might be the new key that starts signing et cetera this doesn't match step resolver properties step resolvers might be in application they don't run all the time they might run only occasionally and they're running with user privileges so what I write to disk is also overwriteable by other applications. Luckily there is also RC7958 which defines a way to acquire the root key signing key and this is done by publishing a XML file on the IANA.org site and together with this XML file there is a SMIME signature which could be verified with the ICANN root certificate authority which has an expiry date by the way so I should read now a piece of the RFC it is important to note that the ICANN certificate authority is not a DNSAC trust anchor instead it is an optional mechanism for verifying the content and origin of the XML and the certificate trust anchors but it's very useful for bootstrapping the KSK so in libgetdns we've implemented zero configuration DNSAC it's basically if there is no trust anchor of the root DNS key while validating doesn't validate fetch new trust anchor from IANA verify with the ICANN root certificate authority and if it matches use that and also make sure you track the root key so you don't on every query do a new fetch of the XML file of the trust anchors second hurdle is DNSAC roadblocks so middleboxes, especially customer premise equipment they have forwarding resolvers which really break DNSAC in various ways luckily there is this RFC 1827 roadblocker for this which defines how to deal with that ultimately the step resolver has to be able to fall back to full recursion getdns can do that too another motivation for libgetdns or encryption everywhere is not just security or DNSAC verification but also privacy so libgetdns has been developed alongside the DNS over TLS standard and can this set up a TLS connection to the upstream recursive resolver there's a whole bunch of RFCs that deal with various aspects like you have to keep the connection open you have to make sure you can send multiple queries on the same connection answers might come in out of order all that sort of things we have all implemented that in getdns there is also for authenticating the DNSAC upstream resolver currently we use pin sets but this is not very scalable every time you change the key of a recursive resolver of a privacy resolver you have to have to distribute the pin sets so a better way would be or typically or very fitable for DNS such as A to do it with Dain store the TLSA record authenticating the upstream resolver in the DNS with the name for that resolver during the last hackathon at IETF 100 I've implemented authenticating the upstream through the opportunistic setup the TLS channel and then when it authenticates it upgrades so it may be used for regular DNS queries another interesting draft is the one that bundles the whole authentication or the Dain record for authenticating the upstream resolver together with a complete chain of trust DNS and trust within a TLS extension so you don't have to query for it anymore it comes together with setting up these TLS connections and this is also mentioned in the new draft which talks about securing the paths between the resolver and the alternatives another interesting IETF effort is DNS over ACPS it's on the ACPS port so probably less hamper than the port for DNS over TLS and also all the queries which take place in context of visiting a certain page then go over this channel to this specific website so I think this has a lot of potential and we should track it very closely nut64 dns64 is a hurdle from IPv6 only networks you still want to reach IPv4 only service this is done by synthesizing the IPv6 answer which can obviously not be dnsacverified so a versatile step should detect the synthesis then ask for the actual answer and do the synthesis itself so this RC was originally for dnsacverilitating steps but it also applies to dns over TLS this was I think not foreseen with this RFC yet so it is another motivation for having a versatile step close to the application and the end user is that dnsac at the recursive resolver when it fails it tells the user this by not answering so the user doesn't know anything about why it didn't work with a library the browser could say this seems like a genuine spoofed answer to me so you should probably not connect or the signatures expire as you choose do you want to continue or not same with dns privacy it could indicate what kind of privacy you have with your dns queries so this is the positioning of the infrastructural component of the step interface traditionally it was with two system or calls get other info and get name info and then if you needed something more complex like an x-record query you used a resolver library like libvsolve or libfall ldns which would then read etcvsolve.com or get the addresses otherwise query the upstream recursive resolvers directly but then legacy applications cannot benefit from versatile step capabilities like dns over tls so some of those versatile step resolvers I list a few here have a step server to make applications use the step server capabilities these step servers do that by listening on localhost and there's also systemdvsolver which does it slightly different it has its own nswitch module but also listens on localhost for applications that need to look up mx-records et cetera unfortunately the serving part of systemdvsolve does not serve dnssec so it cannot be used for that I submitted a github issue for it the application should do access the debus api of systemdvsolve direct I just wanted to end this positioning stepvizolver story or the architectural story with this picture the after part is where we are heading and maybe there should be some standardization work or other ways of discussing things amongst the stepvizolver developers because they're not that well organized so this was my talk and this was my practice we can do one quick question I agree with the principle of securing dns traffic but this is a conflict of concern so when I'm outside my home in my house in the context I want to block adverts I want my local resolver to block some addresses where it can't put adblockers on dns is the only mechanism to rewrite with this in place I use the ability to rewrite because dnssec in the client is de confliction between the need to control the traffic negative dnssec trust anchors so you can save this specific domain cannot dnssec validate there's no proof that it's insecure but I want you to assume it's insecure and accept data so that's the technical answer and there's a provisional answer which is more complicated or the provisional question so I don't know how to do that but home net is working on that at ITF oh, can I mention one so there's more slides after this slide so if you download the presentation there's a whole new presentation telling you how to install gtns code examples etc. thanks