DNS and the Internet's architecture: the DoH dilemma Impacts of DNS-over-HTTPS on how the Internet works
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Bertola, Vittorio
Mozilla's announced deployment model for DNS-over-HTTPS made some properties of this protocol apparent to everyone, stirring a lot of discussion. Specifically, DoH could promote a collective switch from local resolvers to a few global public services, and make each application independent from the user's preferences in the operating system. This could provide more privacy and less censorship, or less privacy and more censorship, depending on how it is deployed and who gets to control the resolvers. What would be the advantages and disadvantages of a broad adoption of DoH by Web browsers, and its likely long-term effects? The talk will start with a general introduction to DoH, stressing its main architectural features: hiding DNS queries inside Web traffic in an unblockable way, moving DNS resolution to the application layer, and putting application makers (especially browser makers) in charge for DNS settings. It will then discuss all the things that are broken by mass-scale deployment of DoH under this paradigm, including DNS-based security mechanisms and access control services, local and national content filtering policies, and network monitoring tools. It will also discuss in which use cases DoH creates advantages for the user (i.e. more privacy and freedom of expression) and in which others it creates disadvantages (i.e. less privacy and more control). Finally, it will discuss the changes to the Internet's original principles that would derive from the centralization that DoH could induce, by providing an additional control point to a few of the usual big over-the-top companies from the GAFAM club. We also look forward to a final discussion to listen to more opinions (including those that disagree with us) and allow participants to learn more about the issue and make up their mind - or, perhaps, end up with more questions than they had in the beginning.
 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. 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 point, 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 you go through an ISP. So you start from your home land, 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. And 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. And 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 HPP that can give you the address of your local name server. And then your ISP resolver will connect to the authoritative, it will do all the queries to you, it will do caching, it 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 that's the, I mean, the ISP network is anyway the first network you go through. So it's that topological linear 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. And 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. And a remote resolver is somewhere over the internet. So you go across your ISP network because you still have to cross your ISP 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. 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 I mean, they can be free, so there are the so-called public solvers like what they ate by Google and the other ones, what nine, what one, or it could be even be a 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, RC 8484. It's been mostly promoted by web people and people that also, I mean, some of these companies also operate or are starting to operate the public solvers. And the big feature is that your DNS queries are now traveling over HTTPS, so they are not anymore traveling with the traditional bytecode, or they are encapsulated in an HTTPS request, and then you get back the replies in the HTTPS reply. And 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. And 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, I mean, on its own, without having to go through the operating system and through the resolver of the system. And 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, I mean, it can do other stuff. And 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're encrypting the device to resolve a connection. And 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 HTTPS traffic contains DNS queries or contains normal web page requests. And so it is basically impossible to filter unless you want to block all HTTPS traffic, or, I mean, especially if the server is, actually, this is an example that 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 DOH for the people that run the network, so 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 the operation system anymore, each application can just have a different server configured and send queries to somewhere else. So this moves DNS from the network layer to the application layer, so this becomes an application. And 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. And 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 default, this is switching the model from the local resolution model, which was the default. There has been the default until now to the remote resolution model as a default. And so this is really a big change. So we'll go through these three changes and see whether they are good or bad. 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. And 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. And 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 think 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're 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, 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 appropriate content in certain times of the day. And this is all based on DNS mostly, I mean, 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 a 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 the 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 use 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 a 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 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 actually makes it work. And in the end, there's even more scenarios. So every application is starting to use their own name server or their own policies or giving you different IPs. And this becomes a total mess. So in the end, in my opinion, this is bad. This is really closing the stream. So moving something that should be at the network layer at the application level, this is really a bad idea. So and then there's the third thing. The third thing is that, well, each application maker can just hardwire the remote resolver. And in general, there's a push towards 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 of this. This is a blog post by Mozilla from last May, in which they said, we like the 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, 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 think about 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, 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 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, currently, you set it once for all in your operating system. In the future, you will have to take care about 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 this happens? If the browsers and maybe all the other applications start 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, if the browser starts doing this on their own, over 90% of the world is using four browsers, by four companies, so Apple, Microsoft, Mozilla, and Google. And they are all in the same country. And also, 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, their 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 really using all the tracking systems. Because then, if you send this data over HTTPS, then you get cookies, even if the standard tells that you shouldn't. And you can use device-fungal finger printing 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. Sensorship is another argument. And it's true, again, if you're the proverbial Turkish dissident, that, I mean, of course, the picture of the QALA to be written on a wall in Istanbul during the, I mean, it's everywhere. And it's true. I mean, maybe if you don't know how to configure it, 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 the 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. And that's not enough, because still, I'm pretty sure knowing some of the governments in Europe that they will not just say, OK, 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 will get IP level blocking in Europe, and DNS blocking, if necessary, in the US. Netronutrile, I think this is just moving the point of control. So of course, the ISP can break netronutrile. They 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, netronutrile, and whatever. Performance. Performance, I think it'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. It depends on how distributed it is, whether they actually put servers near to you, and so on. But there's also an issue with CDNs. Because nowadays, your local resolver is basically on your same part of the internet. So CDNs can give 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 order. So either they do this, and they sort of, 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 their 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 ISP is going to become blind on what is happening on the network. I mean, if you're a network administrator, 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 creeper connection to push data under the form of a DNS query. And then user empowerment. Again, today, at least, you can pick a server more easily. And you can get these 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 to whether 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, are 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, 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 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, it's that privacy and transport, which is provided by DOH, is not privacy in the overall. So that's the real difference. And so when the DOH proponents tell you, this is giving you more privacy, yes, to a certain extent. But in the overall, I think it's giving you less privacy. In the end, at least for the use cases that I mean, myself as an individual, I don't think everyone here has 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 server-launch machine. So I'm sure that the intentions of the people that thought this were not to build the server-launch 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, 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, at least in the end, they will have to see this 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 are the big Google and Apple are 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, I mean, it's a company in your country, if you trust your own regulations, 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 issue is that there has not been a proper policy discussion yet. And we need to sit around the table and think about how to make this work well. So I will leave you with the DH dilemma. It's actually too, 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? Should it be the ISP that pushes it to you through your DSCP? 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 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 it should be resolved or do this. Or maybe the network administrator, which 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. 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 the TLS 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 the DNS over HTTPS. Thank you. Any more questions for Victorio? What is your opinion on server push? I mean, what do I think on server push? You mean the result of the queries before they are asked, basically. This could be an interesting optimization, but I'm not going to give up my privacy just to get this optimization. So I mean, if we can make it work, we're not. But first of all, I want to be sure that we get them. But there is also the question then, whether there is malicious content? Yeah, I can push stuff. 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. Interesting here. The DNS also already has the equivalent of server push in the additional section. Yeah. It still needs to piggyback on an active request. And people like Warren. And also, what you're making. Warren has written many words. Oh, God. OK. I want to. Warren, there's more of a comment rant. Yeah. But you need to come for me. What you've done in this talk is something that is very, very common. And that people are viewing Doe and Resolveness DNS as the same thing. Doe is actually just the carrying of DNS stuff in the HTVS protocol. And it makes it very easy to do the Resolveness DNS stuff as well. But they're not actually the same thing. And people keep conflating them together. And I should point out that the browsers could already do fairly much all of the stuff without using Doe. If 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 HTVS 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 Resolveness 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 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 HTVS traffic makes it much harder to block. And Stefan's going to go off on a rant now about that. I'm going to do that in a panel. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
 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.  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 point,  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 you go through an ISP.  So you start from your home land,  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.  And 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.  And 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 HPP that can give  you the address of your local name server.  And then your ISP resolver will connect to the authoritative,  it will do all the queries to you,  it will do caching, it 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 that's the, I mean,  the ISP network is anyway the first network you go through.  So it's that topological linear 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.  And 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.  And a remote resolver is somewhere over the internet.  So you go across your ISP network because you still  have to cross your ISP 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.  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 I mean, they can be free,  so there are the so-called public solvers like what they  ate by Google and the other ones,  what nine, what one, or it could be even be a 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, RC 8484.  It's been mostly promoted by web people and people that also,  I mean, some of these companies also operate  or are starting to operate the public solvers.  And the big feature is that your DNS queries are  now traveling over HTTPS,  so they are not anymore traveling with the traditional bytecode,  or they are encapsulated in an HTTPS request,  and then you get back the replies in the HTTPS reply.  And 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.  And 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,  I mean, on its own,  without having to go through the operating system  and through the resolver of the system.  And 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, I mean, it can do other stuff.  And 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're encrypting  the device to resolve a connection.  And 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 HTTPS traffic contains DNS queries  or contains normal web page requests.  And so it is basically impossible to filter  unless you want to block all HTTPS traffic,  or, I mean, especially if the server is,  actually, this is an example that 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 DOH  for the people that run the network,  so 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 the operation system anymore,  each application can just have a different server configured  and send queries to somewhere else.  So this moves DNS from the network layer  to the application layer, so this becomes an application.  And 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.  And 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 default, this is switching the model  from the local resolution model, which was the default.  There has been the default until now  to the remote resolution model as a default.  And so this is really a big change.  So we'll go through these three changes  and see whether they are good or bad.  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.  And 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.  And 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 think 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're 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, 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 appropriate content  in certain times of the day.  And this is all based on DNS mostly, I mean, 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 a 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 the 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 use 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 a 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 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 actually makes it work.  And in the end, there's even more scenarios.  So every application is starting to use their own name  server or their own policies or giving you different IPs.  And this becomes a total mess.  So in the end, in my opinion, this is bad.  This is really closing the stream.  So moving something that should be at the network layer  at the application level, this is really a bad idea.  So and then there's the third thing.  The third thing is that, well, each application maker  can just hardwire the remote resolver.  And in general, there's a push towards 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 of this.  This is a blog post by Mozilla from last May,  in which they said, we like the 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, 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 think about 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, 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 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, currently, you  set it once for all in your operating system.  In the future, you will have to take care  about 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 this happens?  If the browsers and maybe all the other applications  start 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, if the browser starts doing this on their own,  over 90% of the world is using four browsers,  by four companies, so Apple, Microsoft, Mozilla, and Google.  And they are all in the same country.  And also, 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, their 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 really using all the tracking systems.  Because then, if you send this data over HTTPS,  then you get cookies, even if the standard tells  that you shouldn't.  And you can use device-fungal finger printing  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.  Sensorship is another argument.  And it's true, again, if you're the proverbial Turkish  dissident, that, I mean, of course,  the picture of the QALA to be written on a wall in Istanbul  during the, I mean, it's everywhere.  And it's true.  I mean, maybe if you don't know how to configure it,  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 the 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.  And that's not enough, because still, I'm  pretty sure knowing some of the governments in Europe  that they will not just say, OK, 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 will get IP level blocking in Europe,  and DNS blocking, if necessary, in the US.  Netronutrile, I think this is just  moving the point of control.  So of course, the ISP can break netronutrile.  They 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, netronutrile,  and whatever.  Performance.  Performance, I think it'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.  It depends on how distributed it is,  whether they actually put servers near to you, and so on.  But there's also an issue with CDNs.  Because nowadays, your local resolver  is basically on your same part of the internet.  So CDNs can give 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 order.  So either they do this, and they sort of,  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 their 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 ISP is going to become blind on what  is happening on the network.  I mean, if you're a network administrator,  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 creeper connection  to push data under the form of a DNS query.  And then user empowerment.  Again, today, at least, you can pick a server more easily.  And you can get these 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  to whether 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,  are 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, 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 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, it's that privacy and transport,  which is provided by DOH, is not privacy in the overall.  So that's the real difference.  And so when the DOH proponents tell you,  this is giving you more privacy, yes, to a certain extent.  But in the overall, I think it's giving you less privacy.  In the end, at least for the use cases that I mean,  myself as an individual, I don't think everyone here  has 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 server-launch machine.  So I'm sure that the intentions of the people that thought this  were not to build the server-launch 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, 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, at least in the end,  they will have to see this 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 are the big Google and Apple are 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, I mean, it's a company in your country,  if you trust your own regulations,  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 issue is that there has not  been a proper policy discussion yet.  And we need to sit around the table  and think about how to make this work well.  So I will leave you with the DH dilemma.  It's actually too, 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?  Should it be the ISP that pushes it to you through your DSCP?  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 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 it should be resolved or do this.  Or maybe the network administrator, which  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.  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 the TLS 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 the DNS over HTTPS.  Thank you.  Any more questions for Victorio?  What is your opinion on server push?  I mean, what do I think on server push?  You mean the result of the queries  before they are asked, basically.  This could be an interesting optimization,  but I'm not going to give up my privacy just  to get this optimization.  So I mean, if we can make it work, we're not.  But first of all, I want to be sure that we get them.  But there is also the question then,  whether there is malicious content?  Yeah, I can push stuff.  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.  Interesting here.  The DNS also already has the equivalent of server push  in the additional section.  Yeah.  It still needs to piggyback on an active request.  And people like Warren.  And also, what you're making.  Warren has written many words.  Oh, God.  OK.  I want to.  Warren, there's more of a comment rant.  Yeah.  But you need to come for me.  What you've done in this talk is something  that is very, very common.  And that people are viewing Doe and Resolveness DNS  as the same thing.  Doe is actually just the carrying of DNS stuff  in the HTVS protocol.  And it makes it very easy to do the Resolveness DNS stuff  as well.  But they're not actually the same thing.  And people keep conflating them together.  And I should point out that the browsers could already  do fairly much all of the stuff without using Doe.  If 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 HTVS 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 Resolveness 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 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 HTVS traffic makes it much harder to block.  And Stefan's going to go off on a rant now about that.  I'm going to do that in a panel.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.
DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___0_155.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___156_995.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___996_1091.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___1092_1739.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___1740_1823.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___1824_3527.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___3528_4079.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___4080_4979.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___4980_5795.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___5796_5867.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___5868_8159.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___8160_11435.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___11436_11663.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___11664_13415.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___13416_14783.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___14784_15287.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___15288_15443.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___15444_17351.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___17352_18215.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___18216_18515.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___18516_20243.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___20244_21035.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___21036_21227.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___21228_21587.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___21588_22655.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___22656_24455.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___24456_26267.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___26268_26735.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___26736_28175.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___28176_29675.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___29676_31283.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___31284_33011.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___33012_34115.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___34116_34751.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___34752_34991.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___34992_36803.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___36804_39755.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___39756_39983.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___39984_40223.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___40224_40463.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___40464_40547.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___40548_40595.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___40596_42743.png DNS_and_the_Internet_s_architecture__the_DoH_dilemma_Impacts_of_DNS-over-HTTPS_on_how_the_Internet___42744_42859.png