 So thank you. My presentation is here to introduce you to the next panel, which is on DNS or HTTPS, which is a hot issue in the DNS community. So I'm sure there will be a lot of questions and participation. So I thought it would be audio. Okay. So I thought to basically run through the issues, which are mostly non-technical issues. I first will give a brief introduction on how this works. Of course, all of this is personal. I'm sure there will be people that don't agree with my assessments. So that will be the subject for the discussion and for the questions at the end. So before we get to the points, I just want to briefly introduce some terminologies so that we all agree on what we are talking about. So of course, when you connect to the Internet, you just connect straight to the IP address. If you're not using a name and then you go through an ISP. So you start from your homeland, which might be yours, so you might be the owner of the land. It might be your company, it might be someone else's like an internet cafe or whatever. You go through an internet access provider, and then you get to the rest of the Internet. That's how it works for, at least for consumer access to the Internet then of course. If you want to use names, of course you need to resolve those names. So what happens is that on your device you have a stack, and in theory it could just work this way. So you could have a full DNS resolver in your operating system so that the applications call it, and all the queries to the authoritative servers are done by your own device. But this is not how it works. This is not how it has been working basically for the last 20-25 years. So how it works now is that you have a stub resolver. So there's a in your operating system, in your TCP IP stack or in your software, there's a piece of software that does the resolution for you, but it's not capable to do the full resolution. So what it does is that it uses a resolver, it's what the other users normally know as the name server. So at least initially the name server was provided by your ISP and this is still the most common case today. Even automatically, so now we have the HCP that can give you the address of your local name server, and then your ISP resolver will connect to the authority, will do all the queries to you, will do caching, will do a lot of stuff, and then we'll give you back the reply. So this is the local DNS resolution model, and why local? Because the ISP's network is anyway the first network you go through. So it's the topological in ears to you, but it's not just a matter of network topology. It's also usually at least in your same country, they speak your own language, you know them, you have a contract with them, maybe you don't like them, but still at least they are local in more than one dimension. Then what happened is that since local resolution often sucked, so there were ISPs that were not providing a good name service, or for other reasons. So for policy reasons, for example, people didn't like the policies that were applied to the local resolver, then remote resolvers started to happen. A remote resolver is somewhere over the internet. So you go across your ISP network because you still have to cross your ISP's network, you get somewhere to the internet, to the resolver, and then the resolver will do the queries, will send you back the reply. So this is the remote DNS resolution model. So this is the terminology I will be using in the rest of the presentation, and why it's remote? Because it's generally somewhere else, it could be very far from you. Mostly these services are provided by US companies, so they are on the other side of Atlantic, even if maybe the servers are in fact near to you. But still they are on someone else's network, they are under another jurisdiction, and they can be free, so there are the so-called public solvers like what they ate by Google and the other ones, code nine, code one, or it could even be page services. So there are people actually selling you a better DNS service or a different DNS service and getting money for that. So what's happening with DOH? Well, first of all, what is DOH? I guess everyone more or less knows, but well, it's a new RC, so it's a new standard by the ITF, RC84-84. It's been mostly promoted by web people and people that also mean some of these companies also operate or are starting to operate the public solvers. The big feature is that your DNS queries are now traveling over HTTPS, so they are not any more traveling with the traditional bytecode or whatever. They are encapsulated in an HTTPS request, and then you get back the replies in the HTTPS reply. So of course, this makes the connection encrypted, and even authenticated if you have a certificate on the other side, you can check who the server actually is. The other thing that is changing is that, I mean, this can be easily spoken by any application that is capable of speaking HTTPS. So browsers, first of all, but almost any application. So at the application level, it becomes really easy to start doing queries on its own. Without having to go through the operating system and through the resolver of the system. So the applications that use DOH are, at least potentially, but that's what they are doing that the first ones, they are completely bypassing the operating system and the settings that the user made in the operating system. So they can use a different server, they can do other stuff. On the serving side, of course, you have to upgrade your DNS server, so you cannot serve this with your normal application unless it's upgraded to support DOH as a transport protocol. So in the end, if you try to define the three main changes that this brings into the way average users, everyone using the Internet, resolve the names. These are the three main changes that you can detect. So the first one is that you encrypting the device to resolve a connection. You're not just encrypting it, you're actually hiding it inside web traffic. So the protocol was designed so that it's impossible from the outside to distinguish whether some HGPS traffic contains DNS queries or contains normal web page requests. So it is basically impossible to filter, unless you want to block all HGPS traffic, or I mean, especially if the server, as an example, it is often made during the explanation of why this protocol is good. So if the server is put on the same IP address for www.youtube.com, I mean, you cannot block that IP address because otherwise you would block YouTube, and I mean, no one wants to block YouTube. So it's basically impossible to block the OH for the people that run the networks or your ISP and anyone sitting in the middle. The second change is that each application can use a different resolver. So since you are not using that the operating system anymore, each application can just have a different server configured and send the queries to somewhere else. So this moves DNS from the network layer to the application layer. So this becomes an application. An over-the-top application that uses the transport and the network to connect to its own server, and this is, I mean, we will see the consequences that it will in the rest of the presentation. And the third change, which is also the most important one, is that each application can come with its own resolver hardwired. So since it's not using the operating system settings, then it can just start and start connecting to their own server. At least as a default. So of course, if the application wants, they can let you change the server, maybe you can put back the one you are already configuring into the operating system. But at least in the default, this is switching the model from the local resolution model, which was the default, that has been the default until now, to the remote resolution model as a default. So this is really a big change. So we'll go through these three changes and see whether they are good or better. I mean, what do they do? So the first one is encrypting the connection and hiding it into the web traffic. So this is the scenario that it's trying to address. So you have someone that is trying to spy you somewhere over the Internet on the path to your remote resolver. Of course, today DNS is not encrypted, the transport is not encrypted, so they can just see all your queries, they can track you, they can make a list of everything you see over the Internet because everything starts with the DNS resolution. So it is really a privacy and security problem. Of course, this is less important if you are using a local server, because unless the attacker or the sniffer is on your local ISP network, so really on the last mile of your connection, they will not be able to sniff this. But for people that are using a remote resolver and there are many people that actually want to use one, I mean, this really changes the security of the connection. And of course, this is also the other scenario which DOH is trying to prevent. So now there are many ISPs using transparent DNS proxies. So they are actually, I mean, you think you configure a remote resolver, you put a remote resolver in your operating system, but they still intercept your queries since they are unclear and they can just take note and track you or they can even change them, apply some policies, maybe some low mandated filtering, some stuff. So this is also a scenario which is prevented by using DOH. So is this good or bad? I mean, there are a number of cases. So if you use a remote resolver, this is really good because in the end, it gives you more privacy and security into your connection. And also if you don't trust your ISP, this is good because it prevents your ISP from messing up with your DNS queries. If you are using local resolution, possibly this doesn't change a lot. I mean, unless someone has hacked your ISP, but maybe you should switch ISP. But it's also bad in some situations. So if your ISP is doing stuff for you, many ISPs use the transparent proxy for example filtering out botnets and malware, or they give you voluntary services like parental control, productivity control, so that your children cannot see in the appropriate content in certain times of the day. And this is all based on DNS mostly, by most ISPs. And this stops working. So if you actually, if you are a user that wants these services, I mean, then this is bad for you. So in the end, is it good or bad? I think it depends. But in the end, it's mostly good. So in the end, possibly transparent DNS proxy is the wrong answer to our correct question. So maybe we should find a different way of doing that. But in the end, there's a trend towards encrypting everything and providing transport privacy and protection. I think it's fine. So I don't have an issue with encrypting the connection. Then the second change, each application using a different resolver. This is good or bad? Well, it depends. I mean, if you think that the application is smarter than you, I mean, this is the argument that I've heard from Mozilla, for example, that is promoting this. So the user would like to get privacy and security, but they are not technical enough to change DNS, so we're changing it for them. And this is actually true if the user is not smart enough but trusts the application provider and the application provider is honest. So he's actually doing this on behalf of the user and thinking of them. And also if you don't trust your operating system, of course, it would be indifferent if there were an agreement so that the OH applications used the user settings, but this is not happening at least now. But it's also bad in a number of situations. For example, it's bad if the application maker is smarter, but it's also dishonest. So if you're a malware author or botnet author, today most of malware filtering is done at the DNS level by filtering out connections to websites, website phishing websites, command and control centers, and so on. And so if they can just connect to their own DNS server in a way that cannot be blocked or intercepted, this is bad. You get no way of stopping them anymore. And also if you're a user that likes to have a choice, then this is bad because it's much harder for you to configure your DNS even if they leave you in 50 different applications, one by one. And so it's bad if the application doesn't give you control of the OH server. It's bad if the remote server fails because then maybe, I mean, your wide area network connection doesn't work and then it cannot connect to your DNS anymore and the application stops working. Or in case of disasters, there's a number of situations in which having a local server makes it work. And in the end, there's even worse scenarios. So like every application starting to use their own name server or their own policies or giving you different IPs, then this becomes a total mess. So in the end, in my opinion, this is bad. This is really crossing the stream. So moving something that should be at the network layer at the application level, this is really a bad idea. And then there's the third thing. The third thing is that, well, each application maker can just hardwired a remote resolver. And in general, there's a push towards, I mean, changing the DNS into a remote service that you get from application providers, application makers, and not from your ISP. So this is actually happening. So of course, this is, I guess, most people that are interested in the question already, this is a blog post by Mozilla from last May, in which they said, we like your age, it's great, it provides you privacy and security. And so we'd like to turn this on as the default for everyone. So they said they will actually do it. At a certain point in time, so they didn't do it yet. In the end, I mean, there's been some pushback because there are many people concerned about this. So now they said that maybe we'll start with the US, we will still thinking of it, we haven't decided the date in which we will turn it on. So I think that they're thinking of it. They realize that maybe not everything is working fine. But this is still the last announcement we have, which is that at a certain point in time, they will do. And if they will do, it may possibly, I guess, other browser makers will do. So of course, we are concerned with the scenario in which all browsers start giving you their own remote resolvers by default, which is really the troubling scenario. And so this would be the real change, in which I mean, currently as a default, when you connect something to a network, you get the local resolver. Then if you want, you can change it, but you get the local one. In the future, you install the application, you get the remote resolver of the application by default. And then if you want, you can go change the settings into every application. And so it's also a matter of user choice because in the end, I mean, currently, you set it once for all in your operating system. In the future, you will have to take care of all the applications throughout every application. So is this a good or bad thing? And so this is the longest part of the presentation. So now we will go through a detailed analysis of what this is changing in terms of different things. So what would happen if, I mean, if this happens, if the browsers and maybe all the other applications starts using their own services defaults? Well, first of all, the thing that would happen is concentration. And this is really the problem in my opinion. So currently, the DNS traffic is spread across hundreds of thousands of servers around the world. Now, I mean, if the browser starts doing this on their own, over 90% of the world is using four browsers, by at least browsers by four companies, so Apple, Microsoft, Mozilla, and Google, and they are all in the same country. And also, I mean, currently, you can still pick pretty easily. So you have a choice with some problems, but you have it. And in the future, it's unclear how much choice you will actually have if you don't like this. So is this bringing privacy? Well, to a certain extent, it is. I mean, so of course, your connection will be encrypted and your queries will not be able to be sniffed anymore. But at the same point in time, especially for people that are not in the US, this is changing a lot. Because in the end, if this happens, all your data will go basically to the US, or at least to services that are controlled by US companies. And also, this changes the type of company that is providing your service. Because today, ISPs are not in the main business. I mean, the main business is not selling your data and tracking you down and doing target advertising. And at least in Europe, they are regulated to prevent them from tracking you and doing this. Well, I understand this is a problem in the US, so this is a real problem for the people that have thought this, but in Europe, it's different. And in the future, you will give these two companies that are already basically get most of the revenues from data monetization. They are really web companies. They are already using all the tracking systems because then if you send this data over HTTPS, then you can get cookies, even if the standard tells that you shouldn't, but yeah. And you can use device fingerprinting and all the techniques that already existed to track users across HTTPS connections. So I think really this is not giving you more privacy. Sensorship is another argument. And it's true, again, if you're the proverbial Turkish dissident that, I mean, of course, the picture of, I mean, Qolay to return on a wall in Istanbul during the, it's everywhere. And it's true. I mean, maybe if you don't know how to configure but you want to bypass the content filters that are set up by your counter and your ISP, then this can help you. But it's not like censorship disappears because the new servers will still be in a country and in single one, apparently. So you will stop getting censorship from your own government but you will start getting the censorship from the US government. And even if the US has a protective argument, I guess that if national security comes into play and presidential order comes and says, from tomorrow and the one can connect to Huawei websites anymore, then Huawei disappears from the entire planet or from the web. So, and that's not enough because still, I'm pretty sure knowing some of the governments in Europe that they will not just say, okay, this is going away. We will stop blocking Nazi propaganda and racist speech and whatever. They will just do it at a much more invasive level. So you wouldn't get IP level blocking in Europe and DNS blocking if necessary in the US. Network neutrality, I think this is just moving the point of control. So of course, the ISP can break network neutrality, can use the transparent proxying of DNS stuff to meddle with your connections but the same can do whoever is then running your DNS. So you're just changing the people that are able to break competition, network neutrality and whatever. Performance, performance I think it's, I mean, there's a lot of measurement going on. So I'm not the expert, I will leave this to the experts. In the end, of course, the application doesn't have to wait for the operating system, so they can do some prefetching, some stuff so it could be easier to browse the web but at the same time, the resolver is far away. So it depends on the connection, depends on how distributed it is, whether they actually put servers near to you and so on. So that's an issue with CDNs because nowadays, your local resolver is basically on your same part of the internet. So CDNs can give it the most, the nearest servers for content delivery without really knowing your IP address because they give it for the resolver and that's fine. While if you're using a global remote resolver, they really need to tell the CDNs where you are to give you the correct, or I mean, so either they do this and they sort of, I mean, you lose some privacy or they don't do it and you lose some performance. Security, security again is an issue. Yeah, of course, it's a security from interception, it's better with your age, but ISPs are responsible for the security of the network including your connection and they are using the DNS to monitor the networks to see botnet infections and malware and even to stop them by filtering out the DNS queries. And this is all going away, so your ISPs going to become blind on what is happening on the network or I mean, if you're a network administrator or a corporate network administrator, you will have the same problem. There's a lot of setups that work with local configurations like speed horizon, local names and this kind of stuff. Again, this is going away if people use remote resolvers. So I'm sure we will see many corporate network administrators trying to block this and prevent this from happening. And another issue is that the DOH can be used for data exfiltration. There are already, I mean, prototypes around the network for this so that the application can just use the DOH and clip it connection to push data under the form of a DNS query. So, and then user empowerment. Again, today at least you can pick a server more easily and you can get this kind of DNS based services from whoever you want because you just set your DNS server to the provider you choose and if they give you parental control, if they give you better DNS or whatever, then you get it and you know where your queries are going. In the future, if you have to change the server in each and every app, it will be a problem and it does not even have any agreement where all apps will let you choose the server and any other DNS based service will stop working at least for the applications that are using their own resolver. And also one problem is that it's true that users are technical and don't know how to, not technical and they don't know how to change the DNS but some do and you can easily write a guide and I mean, people have, more or less people have sort of learned to change the DNS if they want. Well, this is really changing the model so you have to teach the people again a completely different way of controlling where the DNS queries will go and it's much more complex since you have to do it in a bigger number of places. So in the end, there are two points I wanted to make first of all. First of all is that privacy in transport which is provided by DOH is not privacy in the overall. So that's the real difference and so when DOH proponents tell you this is giving you more privacy, yes to a certain extent but in the overall I think it's really giving you less privacy in the end. At least for the use cases that I mean, myself as an individual and I think everyone here is in mind. And the other thing is that if you combine the concentration and the reduction in user control then you really get a potential surveillance machine. So I'm sure that the intentions of the people that thought this were not to build the surveillance machine but in the end if everything, I mean if most of the DNS of the world goes more or less into the same place in a reduced number of systems and companies and then it's pretty easy for the security agencies of the country where these companies are located to show up at the door and say please let us see the DNS traffic from the entire world. And even if they wanted to resist in the end they will have to seize and give the data because in the end they are subject to the laws of the country. So this is really potentially a problem for surveillance. So in the end is this good or bad? Well I think there are still a number of cases in which it's good. If you're the proverbial Turkish dissident or from any authoritarian country even if in that case I mean I guess you'd better learn how to change your DNS anyway. And so if you think that you trust the big OTTs more than your ISP and this is really true in the US. So in the US there are many people that trust the big Google and more than the ISPs. Then this is good of course. This is empowering these companies and this is empowering the ISPs. But of course if it's the opposite. So if you trust your ISP because it's at least you know them it's a company in your country if you trust your own regulation. So you think your private regulation in Europe is better than private regulation in the US. I mean then this is bad. And so I think it's really up to you. I think it's mostly bad but I think it's mostly a matter of policies. So especially these last changes really depend on the way that the resolvers are chosen and to which degree there's a user control and there are simple ways for the user to control what's happening and maybe tell all the applications on the system to use the same server or this kind of stuff. So I think that the main issues that there has not been a proper policy discussion yet and we need to sit around the table and think of how to make this work well. So I will leave you with the DH dilemma. It's actually two because in the end I couldn't stop it. So I had two of them. So of course the first one is who should choose your resolver. So should it be the user or should it be the ISP that pushes it to you through your DSP? Should it be the browser maker? Or someone on behalf of the user because then if more or less everyone agrees that yes the user has to be in control but then some people add yeah but the user is not smart enough they don't know what they're doing so we have to do it for them. And so this is I think the real policy issue and if we could agree on the answer to this question then it would be clear which kind of policies and which kind of protocols we still need to make this work. And the second one is who should be entitled to apply policies to your DNS? Because the DNS over time has become a very complex environment in which people put stuff onto it. There's content control policies of every kind, good, bad, and I think it really depends on which content you are trying to stop. So it's not always good or always bad. And there are local security monitoring I mean there's all I mean even opting products there's everything. So the point is should your government have the right to enforce some kind of DNS policy to you even if you don't want it? Or maybe you should the resolver do this or maybe the network administrator which is I mean has to do something to protect the network. So should this happen? And so these are the two questions that I will feed into the panel. Thank you. Question? Yeah. Okay, quick question. So some DNS over HTTPS is bad. So how do you feel about DNS over TLS? I think it's, the question is since I have problems at least with DNS over HTTPS, how do I feel on DNS over TLS? I think it's less of a problem. It's actually good. I think ISP should have deployed TLS a long ago because it gives you the encryption but it's not changing the resolution model. So it doesn't change the way you get your DNS. It can even work. I mean there's already some kind of an official discovery mechanism probing port 853. So I think that should be the next step for everyone in the DNS community. So at least turn on DNS over TLS. And I think it would be better than DNS over HTTPS. Thank you for the push. I mean, okay, what do I think on several push I mean the result of the question before they are asked to basically, this could be an interesting optimization but I'm not gonna give up my privacy if just to get this optimization. So I mean, if we can make it work, why not? But first of all, I want to be sure that we get them. There's also the question then whether there is malicious content. Yeah, I can push that. Yeah. Like dirtying the cache with push some. There's lots of security issues also with that. So of course we have to evaluate everything and be sure. In the additional section. Yeah. It still needs to take it back on an active request. And people like Warren. That's true. Warren has written many works on it. Oh God. Okay. Hi, Warren. Warren? There's just more of a sort of comment rant. Yeah. All right. It is. What is very, very common in that people are viewing code and resolving this DNS as the same thing. Doe is actually just the carrying of DNS stuff in the HTTPS protocol. And it makes it very easy to do the resolvallist DNS stuff as well. But they're not actually the same. They're not actually the same thing and people keep conflating them together. I should point out that the browsers could already do fairly much all of the stuff without using Doe. If they have, they're a browser, they could use any other funky protocol to do the same sort of thing. Just this potentially makes it easier because they know HTTPS a bit more than others maybe. But I think it is important to try and keep the two bit separate and refer to them separately because Doe as itself is almost always good. It's the resolvallist DNS stuff which opens up the can of worms and all the scaringness. Doe as itself simply provides you a more secure channel than DNS over TLS. In order to carry this because it's indistinguishable from the DNS in TLS stuff. I think that that's full disclosure. I was one of the chairs of the DNS over TLS working group and wrote some of the initial drafts. It has the serious failure mode that it's clear that it is still DNS traffic and so it can be blocked. Carrying it as HTTPS traffic makes it much harder to block. And Stefan's gonna go off on a rant now about that. I'm gonna do that in a panel. Yeah. Thank you. Thank you. Thank you.