DoH or Don't
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 102 | |
| Author | ||
| License | CC Attribution 4.0 International: 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. | |
| Identifiers | 10.5446/43234 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
TelecommunicationChaos (cosmogony)Limit (category theory)Computer virusDirect numerical simulationGodBitInformation privacyJSONXMLComputer animationLecture/ConferenceMeeting/Interview
00:57
Direct numerical simulationInformation privacyPrisoner's dilemmaPrisoner's dilemmaInternetworkingDirect numerical simulationInformation privacyDifferent (Kate Ryan album)Physical lawFamilyLattice (order)GoogolMultiplication signWeb browserComputer animation
01:46
Communications protocolInformation privacyEncryptionDirect numerical simulationTransport Layer SecurityMetadataClient (computing)Observational studyServer (computing)Computer networkQuery languageUDP <Protokoll>Dot productGoogolPoint cloudImage resolutionService (economics)File formatInternetworkingAuthenticationPublic-key infrastructureInternet service providerAsynchronous Transfer ModeError messageOperator (mathematics)QuadrilateralDigital signalUniform resource locatorShooting methodPhysical systemInternetworkingCommunications protocolDirect numerical simulationInformation privacyDomain nameInformationSelf-organizationSoftwareTelecommunicationValidity (statistics)Arithmetic meanMoment (mathematics)Dot productLocal ringScaling (geometry)EmailQuery languageGoodness of fitReal numberFamilySimilarity (geometry)Server (computing)Normal (geometry)Asynchronous Transfer ModeIP addressResolvent formalismAuthenticationEncryptionObservational studyInternet service providerData streamLattice (order)Client (computing)In-System-ProgrammierungIdentical particlesNeuroinformatikPublic key certificateCache (computing)Service (economics)Web 2.0MathematicsPrice indexResultantOperator (mathematics)Point (geometry)GoogolSound effectPoint cloudMotion captureDifferent (Kate Ryan album)Right angleLecture/ConferenceComputer animation
09:30
Direct numerical simulationQuery languageLocal GroupComputer networkDigital filterIntrusion detection systemData integrityTransport Layer SecurityIntegrated development environmentSystem programmingFunction (mathematics)BlogQuantumDefault (computer science)Operator (mathematics)Information privacyService (economics)Information securityGraphical user interfaceConfiguration spaceRevision controlGoogolBlock (periodic table)Normal (geometry)Software developerComputer programmingLibrary (computing)Image resolutionCodeSoftwareIncidence algebraIntegrated development environmentArithmetic meanForcing (mathematics)Line (geometry)Group actionMereologyPhysical systemLocal ringEmailLink (knot theory)System callQuery languageConfiguration spaceRevision controlGoodness of fitServer (computing)PlanningData integrityInternetworkingOperator (mathematics)Process (computing)Normal (geometry)System administratorRootInformation securityGraphical user interfacePoint (geometry)Set (mathematics)Resolvent formalismInternet service providerWeb browserElectronic mailing listDirect numerical simulationClient (computing)Selectivity (electronic)Different (Kate Ryan album)Proxy serverMultiplication signWikiService (economics)Web 2.0Intercept theoremDefault (computer science)Enterprise architectureOrder (biology)Speech synthesisDreizehnQuantumFamilyPressurePeer-to-peerLattice (order)GoogolInformation privacyPoint cloudView (database)Block (periodic table)TouchscreenArmSpacetimeFigurate number
16:51
Block (periodic table)Normal (geometry)Direct numerical simulationSoftware developerFunction (mathematics)Computer programmingLibrary (computing)Image resolutionExecution unitData structureComputer programmingLevel (video gaming)Programmer (hardware)Goodness of fitInternetworkingNormal (geometry)Communications protocolCartesian coordinate systemHierarchyDirect numerical simulationInformation privacyIn-System-ProgrammierungDifferent (Kate Ryan album)Image resolutionNetwork socketWeb 2.0Software developerQuicksortComputer animation
18:28
InternetworkingDirect numerical simulationOperator (mathematics)Information privacyDefault (computer science)Similarity (geometry)Server (computing)GoogolWeb browserQuery languagePrisoner's dilemmaExecution unitPrisoner's dilemmaGoodness of fitInternetworkingInsertion lossInformation privacyArmSoftwarePhysical lawDefault (computer science)Computer configurationConfiguration spaceComputer animation
19:40
InternetworkingDirect numerical simulationOperator (mathematics)Information privacyDefault (computer science)Similarity (geometry)Server (computing)GoogolWeb browserQuery languagePrisoner's dilemmaCommunications protocolPresentation of a groupSoftwarePairwise comparisonComputer programmingStandard deviationDot productSource codeProduct (business)BlogWeb pageArchaeological field surveyVideo gameFormal languageImplementationSoftwareComputer programmingProduct (business)Prisoner's dilemmaIdeal (ethics)Projective planeCentralizer and normalizerGoodness of fitFamilyInternetworkingProcess (computing)Point (geometry)Hash functionWeb browserRepetitionElectronic mailing listSelectivity (electronic)AuthorizationPublic key certificateSpacetimeDot productInternet service providerDirect numerical simulationComputer animation
21:40
Execution unitCommunications protocolImplementationFunction (mathematics)Dot productWeb browserGraphical user interfacePhysical systemModule (mathematics)Server (computing)KnotAuthenticationPublic key certificateQuery languageInternet service providerSoftwareInformation securityDependent and independent variablesDirect numerical simulationUDP <Protokoll>GoogolSimilarity (geometry)Transport Layer SecurityType theorySlide ruleDisk read-and-write headMessage passingEncryptionSource codeTelecommunicationClient (computing)Vector potentialKolmogorov complexityInformation privacyProgramming languageSoftwareProjective planeDot productDirect numerical simulationComputer programmingPiImplementationMathematicsTelecommunicationCategory of beingState of matterArithmetic meanFunctional (mathematics)Maxima and minimaPairwise comparisonPhysical systemNumberCentralizer and normalizerLink (knot theory)Query languageServer (computing)Matching (graph theory)Covering spaceInternetworkingOperator (mathematics)Software bugRoutingInformation securityGraphical user interfaceVector potentialCuboidVotingResolvent formalismAuthenticationData storage deviceCommunications protocolWeb pageCartesian coordinate systemFirewall (computing)Module (mathematics)Web browserInformation privacyClient (computing)WebsiteDifferent (Kate Ryan album)Intrusion detection systemProxy serverContext awarenessMultiplication signGraphics tabletPublic key certificateSpacetimeOperating systemAndroid (robot)YouTubeDefault (computer science)Mobile WebCodeOrder (biology)Self-organizationProof theoryPower (physics)MultiplicationResultantQuicksortFamilyBacktrackingWater vaporMetropolitan area networkOpen setRoundness (object)EncryptionShape (magazine)Internet service providerGoogolSource codeEndliche Modelltheorie40 (number)ArmParticle systemService (economics)Personal area network1 (number)Computer animation
31:31
SoftwareFunction (mathematics)Hacker (term)Dot productInformation securitySystem programmingSource codeSoftwareServer (computing)Functional (mathematics)Information securitySound effectImplementationAxiom of choicePhysical systemReceiver operating characteristicInternetworkingOperator (mathematics)Process (computing)Remote procedure calloutputAuthenticationJava appletDirect numerical simulationElement (mathematics)Public key certificateState of matterPurchasingOpen setData storage deviceCommunications protocolLattice (order)Multiplication signOperating systemLecture/ConferenceComputer animation
34:00
Projective planeLocal ringCentralizer and normalizerServer (computing)PlanningLattice (order)Information privacyMultilaterationDirect numerical simulationLecture/Conference
34:55
Projective planePlanningDirect numerical simulationBounded variationQuicksortServer (computing)Information securityCommunications protocolSurfaceAuthorizationRecursionProof theoryGroup actionExtension (kinesiology)Thomas BayesResolvent formalismInformation privacyIn-System-ProgrammierungImage resolutionCopyright infringementImplementationSoftwareResultantNumbering schemeArithmetic progressionLecture/Conference
36:02
ImplementationSoftwareTelecommunicationResolvent formalismClient (computing)Server (computing)Direct numerical simulationCryptographyAsynchronous Transfer ModeLecture/ConferenceMeeting/Interview
36:48
SoftwareAsynchronous Transfer ModeCartesian coordinate systemDirect numerical simulationTransport Layer SecurityPower (physics)MassLecture/Conference
37:24
SoftwareQuicksortPlanningFinite differencePhysical systemNumberSimilarity (geometry)Matching (graph theory)InternetworkingProcess (computing)Modul <Datentyp>Cartesian coordinate systemDirect numerical simulationClient (computing)WebsiteOptical disc driveSpacetimeOperating systemGame controllerSoftware developerResolvent formalismDifferent (Kate Ryan album)Mobile appMeeting/InterviewLecture/Conference
39:05
SoftwareAngleServer (computing)Matching (graph theory)InternetworkingPoint (geometry)IP addressDirect numerical simulationDifferent (Kate Ryan album)AuthorizationPublic key certificateBootstrap aggregatingCellular automatonAsynchronous Transfer ModeState observerNumbering schemeArmSpacetimeLecture/Conference
40:31
Server (computing)Different (Kate Ryan album)SpacetimePrice indexInformation privacyPhysical systemQuery languagePlanningComputer virusHeegaard splittingNamespaceGraphical user interfaceResolvent formalismEncryptionWeb browserDirect numerical simulationView (database)Operating systemDefault (computer science)FamilyHash functionLatent heatGoogolLecture/Conference
42:33
VideoconferencingComputer virusWeightLecture/ConferenceJSONComputer animation
Transcript: English(auto-generated)
00:21
Okay, everybody, welcome here for the next lecture. Our speaker here is Carson Strutman, and he is really infected by a DNS virus already since 30 years. He can't get rid of it, it seems. So, I don't know, can you give it to me as well?
00:41
You think? After the talk, you might have it. Oh, my God. So, rescue us, please. Thank you, hello, hello, hello. So, the question is do or don't? I want to talk about the difficult suspect
01:02
of DNS privacy and discussion around that. So, we talk about DNS privacy, what that is, why that is needed, the different new technologies like DOH, DOT, DOQ, I will cover that in details,
01:20
and then the dilemma with these privacy-enhancing technologies and DNS enhancements and a summary at the end. So, I'm a self-employed internet nerd doing DNS and DNSSEC and sometimes IPv6. If time permits, go to RIPE and ITF meetings,
01:41
but I'm not at all employed with any of the big browser vendors. So I'm not from Mozilla, I'm not from Google. I just talk here about stuff that I have heard either officially or inofficially in some talks there, but please, please, I'm just the messenger. Please shoot me.
02:01
Please don't shoot me about what you're ... So, over the last few years, the ITF, which is the body of the people who design internet protocols, they expanded the DNS to enhance the privacy of the domain name system.
02:21
The system that we use to, or our computers use, to get IP addresses from domain names and other important data they need. And even though there is more than just the transport protocols, in this talk, I will only talk about the transport protocols being DNS over TLS, DNS over HTTPS, and DNS over QUIC.
02:44
So why do we need more DNS privacy? A recent study presented at the ITF meeting in Montreal in July last month showed that on a total scale on the whole internet, 8.5% of networks
03:02
intercept DNS traffic. So they capture the queries, and they don't let the packet go out to the real intended DNS server. Instead, they redirect the packet and answer that DNS question locally.
03:20
And in China, it's more than 27% of all DNS traffic being intercepted. Now, couriers, it's today, it's the fact that the most couriers are just answered as if the query was not intercepted. So the users still get the correct answer.
03:41
It's just coming from a different server. But that can change, of course. And maybe today it's mostly surveillance, looking what people are querying in the internet. But that infrastructure can also be used to change data and change answers.
04:01
And that is the reason why we need encryption in the DNS. So there are new abbreviations, new terminology for all the new technologies. We have DOE 53, which is the traditional DNS, which is DNS over port 53 UDP and TCP.
04:22
That's the old stuff that has been around since 1983. Then we have DOT, which is DNS over TLS. I will cover that in a moment. Then DOH, which is DNS over HTTPS, port 443. We have DOQ, which is DNS over QUIC,
04:41
which is something that we will see in the future. And I cover that in a moment. And then we have DOC, which is DNS over cloud, which means DNS not resolving locally, but through some internet service. Cloudflare, Google, Quad9, or similar stuff.
05:02
So first, DOT. It's DNS over TLS. It has an RFC, it's a few years old, and it encapsulates the normal DNS just over TCP and TLS, which is the same transport encryption that we use for the web, but on a different port. It's port 853, and it gives us encryption
05:23
and authentication, and either we authenticate the other endpoint through a certificate, like we do that in the web, or we can use DANE, which is a way to validate certificates over DNS and DNSSEC, both as possible. But most people today use the internet PKI.
05:44
This is how normal DNS works. Sorry, there's some German still in the slides. The client on the right side sends a query to some local resolver, which is either in your own network or in your ISP's network. That one looks in a cache.
06:01
If the answer's not in the cache, it goes out and asks a couple of authoritative servers. They collect the answers, and the answer's being sent back to the client. And all that goes completely unencrypted and not authenticated, meaning the client will not get any information if that data's
06:21
being intercepted or played with or just exchanged. The client just doesn't know, it gets an answer, and it takes that answer for the truth, which might not be the truth. So with DNS over TLS, this is the situation we have today. It could be that DNS over TLS would go to a local resolver,
06:43
but I haven't seen that anywhere so far. So what we see is that the client is being reconfigured to do DNS over TLS to some service in the internet, which is not local to the network. That can either be Google or Cloudflare, these big vendors that have DOT services,
07:03
or it can be privacy organisations like Digitalkurage here in Germany or others that operate DOT servers. It's also possible, but I seldom see that, to do forwarding. So if you have a local DNS resolver in your network, and the communication between your clients
07:20
and that local DNS resolver does not need to be secured because it's your network and you have control over it, but you want to do forwarding, like not resolve yourself into the internet, then you can secure the forwarding path to the ISP resolver or to any other DOT service in the internet.
07:42
DNS over TLS can be operated in two different modes. One is the opportunistic mode, meaning we check whether we can authenticate the end point on the other side, and if that works out, all good. But if it does not work out, we will still use it. So this is very similar to how TLS is being used in the mail world,
08:02
where all the certificates on the other side are not really checked and verified. It's just used for encryption. Or you can configure your DOT client in the strict mode, and then authentication must happen, and if there is a failure in authentication,
08:22
no data will be sent, meaning the internet is kaput if authentication doesn't work. There are a couple of operators, big and smaller ones. Here are a few that you can choose from. There are many, many, many more.
08:42
Then we have the other, the big brother of DOT. It's DOH, it's DNS over HTTPS, and that is RFC 8484 from November last year, and it encapsulates a DNS, as we know in the past, encapsulates that over TCP and HTTPS.
09:00
It sends it over port 443, and the idea here is that an outsider looking at the data stream could not distinguish normal web traffic from DNS traffic that is DOH. And it gives us encryption and authentication, which is the same as with DOT, but it also gives us cloaking, and cloaking here means that we hide
09:22
the DNS data in web traffic. And the idea here, it's much harder to censor, to stop the DNS traffic if it is intermingled into the normal web traffic going over port 443. This is how it could look like.
09:40
The client will send a query, actually, to a web server on port 443. That web server will detect that this is a DOH DNS query, will decapsulate that into normal DNS, and will send that query to a DNS caching resolver, and that talks then to the authoritative servers, and that is then normal DNS.
10:01
Just the pink transport line here is encrypted and authenticated. I'm now observing the ITF for more than 20 years, and the process of getting DOH into an RFC was one of the fastest I've ever seen. Normally, it takes five or six years
10:22
from the first idea to having an internet RC, because the ITF is built on rough consensus, so you need to first discuss a lot of stuff with the people until you have consensus and you have running code. With DOH, the first idea, start of the working group, was in November 2017.
10:43
In March 2018, the draft was ready. The RC text was complete, and they started the working group last call. And working group last call is basically like in a church when there's a wedding, asking is there anyone objecting against this, and if nobody calls out
11:02
either in the meeting or on the mailing list, it becomes an RFC, and that happened in October 2018. That was under one year from first idea and inception of the working group to getting an RFC out. So that was remarkable, and that shows the forces that are behind this idea, behind DOH,
11:22
mainly from the big browser vendors, because they want to have that happen. And so we were seeing why this is. There's an interesting quote in that RFC saying that filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment
11:41
due to the confidentiality and integrity protection provided by TLS, meaning that all the devices that look for security incidents in the network by looking at the DNS, by looking at unencrypted DNS will not work any more, and that scares a lot of administrators in networks that have of course
12:02
good intentions because they want to keep their network secure, but their devices which were quite expensive when they bought it, they won't work any more, and so some people fight DOH because of this, other fight DOH
12:21
because of other means, but keep that in mind. So DOH first appeared in Firefox as a browser in Firefox 61. That was in May of 2018, and initially there was just a manual switch in about colon config,
12:40
so you had to be a nerd to find this out. But in the newer Firefox Quantum, this is a screenshot from Firefox 68, which is the current one I think. You just go into the proxy settings and you scroll all to the end, and then you can check mark enable DNS over HTTPS, and then you can either select today Cloudflare
13:03
as one provider being in there, or you can select your own value and put the server name in there, and this DOH default roots DE is just my server. So what happened here, or what are Mozilla's plans? Mozilla gave a talk at ITF 105 last month,
13:24
and they plan to enable DOH in Firefox by default at some point of time in the future, but there's no date set. Reason for that is that they still figure out how they can enable that without breaking a lot of configurations in enterprise environments, because the problem with enterprise environments
13:42
is that they often have their local DNS space, DNS names that are not registered anywhere in the internet, which are just locally to the resolver there. And if the Firefox browser would switch to DOH and use any DOH service in the internet, of course that would not know about the names used in that company environment.
14:04
So the users will not be able to find the local JIRA wiki or something like that. And that is bad, of course, bad user experience, and Mozilla tries to avoid that, so they have to figure out a solution for that. But once they have figured that out,
14:20
their plan is to switch DOH on for everyone. It will not be Cloudflare everywhere, so some people fear that Mozilla will just switch on DOH in Firefox, and everything will go to Cloudflare. That is not the plan. Instead, Mozilla is working with local providers
14:40
of DOH services, and they certify local provider, and they will provide a list of operators of DOH service in Firefox, and they will select for every region one of them to be the default. So it might be then that for Germany as a region or for the German-speaking region
15:00
that there will be some provider, hopefully one that we mostly can trust, that will be then the default in Firefox, but in there. Mozilla has published the requirements of being certified, and the link is in here, you can read that. Also, if you want to operate your own DOH server
15:20
and you want to be listed in Mozilla or Firefox, you have to check these requirements, and then you can request your service to be listed in there. Chrome, there is DOH in Chrome currently, but it can only be enabled with a command-line switch,
15:41
and there's a link how to do that. The Google team has announced that they plan to have a GUI configuration part in Chrome 78, which is one or two versions in the future. But they don't have any plans to switch on DOH by default, so it will always be for Chrome an optional setting to do.
16:04
Here's a list of DOH operators. So what is the difference between DOT and DOH? DOT can be easily blocked because it's running on a dedicated port, and especially in certain markets where DNS interception is very often done,
16:24
like in Asian markets, like in Indonesia, the people there, the users, they only have actually two ports that they can use for DNS name resolution. It's port 53 UDP, and only that, and only to the local ISP, and that one is filtering,
16:42
and it's maybe intercepting traffic, and it's maybe even changing traffic, and it's port 443. Nothing else is open there. And of course, the operators will not change that. They will not open port 853 for privacy because they don't want privacy, and also the governments might not want privacy there.
17:01
DOH is made to look like normal HTTPS traffic, so the idea is that selective blocking of only DOH is very difficult, and blocking all port 443, all web traffic, is impossible for an ISP. That's the idea behind DOH.
17:22
So it's of course a mess, it's a protocol mess to have DNS over port 443 in HTTPS, it's true, and it's a nightmare for every engineer, but it seems to be that if we want to have a privacy-enabled internet, we can't rely on a good structured internet hierarchy anymore. We have to look for loopholes
17:42
where we can sneak the privacy in. Also, DOH is very easy to implement because it's based on HTTPS, and most programmers nowadays know how to do that, more those than doing BSD socket programming. And DOH also enables developers
18:01
to do name resolution on the application level. Of course, that scares a lot of people, having DNS resolution on the application level, because that would mean that every application can have its own DNS resolution pass, and different applications can get different answers for the same question. And that is a nightmare to troubleshoot,
18:24
but it's getting even better. So, there's a dilemma with DOH. To reach the internet users that are really in need of privacy, and this is not we in the Western world, it's not we in Europe,
18:40
we have quite good privacy laws in Europe, but in the US, in Asia, there are a lot of networks where getting privacy access to the internet is very, very hard. And for these people, we need to have a solution.
19:02
And how Mozilla looks like is they say, we have to find a default, we have to turn it on by default, because if we make it an optional configuration somewhere, it's only the nerds that will switch it on. It's only the people here at camp that know how to switch it on,
19:21
and these people don't need it because they know how to protect themselves, they know about privacy. We need to have a solution that works for 99% of the rest of the internet population. And for them, you can't explain the problem, you have to get some default in there. And Mozilla says this is very similar
19:43
to the certificate authority selection in the browsers. So the people we trust with the certificates, they are also provided by the browser, so also lets us put in a vetted list of DOH providers in the browser.
20:03
That still might lead to some centralization of DNS queries, and that is of course bad because centralization creates a point where data can be collected and being analyzed. That's bad. So there's a dilemma. We can't have one without the other,
20:22
so we can't have a 100% good solution. We have to fight and we have to discuss a middle ground. And the discussion is not over, and we can still participate in this discussion. So then I looked at DOH, and whether that is only in the browser space,
20:41
because sometimes people who fight DOH tell me that, okay, this is something the browser vendors want to push on the internet people, and nobody wants that really. It's just the browser people that wants it. So I looked at the landscape of software that is on GitLab and GitHub to see,
21:01
is it only the browsers, or are there other projects that use DOT or DOH? And I did that in May and July this year, and I looked only at genuine software products, not of composing products, not something that just wraps with a Docker container some existing software, but new software that implements
21:22
either DOH or DOT. And you can find the list of implementations there, currently 55 implementations I list there. Interesting is the implementation languages of all the stuff that's being newly implemented. Go, the Go programming language, has superseded C and C++,
21:42
which is still second, but the most new stuff is done in Go. I would say most new projects are done in Go, and the C projects are existing DNS software that had now DOH bolted on. Some is in JavaScript, some is in Python, Rust and Java,
22:01
and then we have a longer tail of the usual suspects of other programming languages. There's much more DOH than DOT. We have 41 projects of 55 that implement DOH, and we have 23 that implement DOT. Some implement both.
22:21
The project start, that's interesting. So in 2015 is the year when DOT was first announced, and there were just a very few project there, and it really spiked last year, the year when the DOH RC was published. We had 29 new projects last year,
22:41
and we have 13 projects this year, and I think that we will reach a very similar 20-something number at the end of the year, because every month I look for new stuff, and five or six or seven new projects appear there.
23:01
Then I looked at the freshness, whether these are just one-shot projects that are published on GitHub and left there to die, or are there active projects? Are there issues in the bug tracker that being worked on? Is there a new commit on the code? And most projects of 44 or 55 are active,
23:24
and 11 are dormant, are dead, and nothing happens there. Here are some applications that have DOH or DOT. It's Firefox and Chrome. A curl on the command line has that. Tent browser and bromide are two browsers in the mobile space and on Android
23:41
that have that implemented. On the operating system side, system D resolve D on Linux has it, but not by default. You have to enable it on default for DOT. Unwind is a new system resolver for OpenBSD that shipped first time with OpenBSD 6.5 in April this year
24:01
and that has DOT built in. And there's a resolver module for libc that is a proof-of-concept state, but it could be expanded on, and that would give DOT or DOH to all applications. Now, there's a lot of client proxies.
24:21
I won't cover them, all of them, but you find the links on the implementation page. And server proxies as well. And there are DNS servers that now implement DOH and DOT directly, like Unbound, Not, and also the SDNS software. So what I found missing in the DOH,
24:42
DOT software is certificate authentication via Dane. They usually authenticate via the certificate store of the operating systems, but having authentication via Dane would be even stronger having that. A witness function would be nice, meaning that a query received from a client
25:01
would be sent to multiple operators, multiple servers in the internet, and then we wait for two or three answers coming back, and then we compare the answers. And if they don't match up, we take a majority vote. So if just one operator plays foul and changes the DNS data,
25:22
such a software will detect that, and then will go with the answer the most DNS servers provide. Of course, it will slow down DNS, so there should be a switch somewhere for the user to decide whether the user wants to have a secure and private or a fast internet. And of course, all the new software, there's almost, I haven't seen any security audits,
25:43
so it's all new stuff there. There's probably tons of security bugs in there still, and there would be a need of doing some software security audit for these new softwares. So what's in the future? We have DNS over QUIC. Now QUIC is a new protocol
26:01
that has been developed inside Google and is now at the ITF for standardisation. It is to be replacing TCP. It's based on UDP, but it has TCP functionality built in. It's already in Chrome, and it's already on the Google server side. So if you have used Chrome with the Google search page or YouTube
26:21
in the last three years, you have used QUIC, because if you have Chrome and you contact some of the Google services, and especially YouTube, the browser will automatically detect that this website is QUIC-enabled, and it will switch over and not use TCP. It will use QUIC. The reason why Google developed QUIC is because TCP is ossified,
26:42
meaning it's impossible to change TCP because there are so many middle boxes, firewalls, intrusion detection systems, that make certain assumptions how TCP works. And if you change TCP as a protocol, these middle boxes will break. And it's impossible to change all the middle boxes
27:02
or just even get the vendors and the users aware of this problem. So we are in a state that TCP cannot be changed anymore. It cannot be made better, even though there are ideas to make TCP better. So the route that Google goes
27:21
is to create a new protocol that works on UDP, because UDP is not a problem. You can make any changes to UDP or on top of UDP, and it usually just goes transparent to the firewalls. And, of course, with this new protocol, there's an idea to have also DNS over this new QUIC protocol.
27:44
Yeah, QUIC has TLS 1.3 built in. It has zero round-trip time, encryption, resumption, and all this. All that we have in TLS 1.3 is also in QUIC, and there's currently discussion on the ITF how to standardise DNS over QUIC.
28:03
And it would look the same as DOH or DOT, just with a different transport protocol, but I'm not sure if I have that here. Yeah, QUIC is ... The idea of QUIC is that QUIC is not built
28:21
into operating systems like the TCP IP stack, but it's built in the applications, like it is in Chrome today. So it is a new network stack that is in the applications. So if you are feared of having DOH and having all applications doing different DNS name resolution,
28:40
with QUIC, all applications will have a different TCP IP stack, basically, and talk differently to the outside world. And that will be a troubleshooting nightmare, but we will see how that ends. So here's a comparison of DNS over TLS
29:01
and QUIC and traditional TCP by the person by Christian Hoytema, who wrote the draft to the QUIC implementation for DNS. And of course, QUIC comes out the best on the right side. It has all the nice properties that one wants.
29:23
So I'm always coming to the end of this talk. We see that the DNS is evolving fast these days. There's many, many changes to the DNS protocol, not only the new transport protocol, but much more like E-DNS padding and Q name minimization.
29:41
And for some people, it's too fast. Bert Hubbard from PowerDNS wrote this article, The DNS Camel, and he basically says that the DNS is like a camel, and if we put too much stuff on it, it will break and not work anymore, which is true. So the internet, especially the DNS community, are currently working on also deprecating
30:02
some old behaviours of DNS to be able to rip out unused stuff out of the DNS software. But I'm very certain that the future of DNS communication will be encrypted. It will either be DOT, it will DOH, or it will DOQ.
30:24
If I had to make a guess, I would say it's DOH, and it will be DOH, and there's nothing we can much do about it. We can only maybe shape the way how it is implemented, but we can't avoid that, we can't stop that anymore.
30:41
I see that DOH or DOQ have both the potential of centralisation or decentralisation. It really depends on the software, or and how much operators are there of these DOH and DOQ servers. If nobody but the big vendors are implementing this,
31:03
of course there will be centralisation. If a lot of ISPs, if a lot of privacy organisations, if a lot of private people implement DOH and DOC servers and make them public and operate them in a responsible way, we can have even a better internet
31:21
and a decentralised internet by having that. The software is there, the protocols are there, the protocols are neutral. The protocols don't demand how it's implemented. Of course, if DOH is implemented and all data is being sent to one operator, that's bad. But if we have a lot of DOH servers out there and users can choose, and maybe the software
31:42
is even intelligent to choose for the user, then it could have a decentralisation effect, and that would be good. What can we do? We can start operating a DOH and DOT server. It's not rocket science, quite easy. Software is there, software is mature. We can use that.
32:01
We can hack on the DOH and DOT server, maybe do security audits, maybe implement a witness function that is currently not there. Maybe implement Dane authentication of certificates. We can work on, if we work on operating systems like Linux or the PSDs or Haiku or any,
32:24
alumnus or something like that, we can try to bring these new technologies into these operating systems. We can't avoid them. Don't try to say, oh, I want my old DNS and I won't do this new stuff. It's already decided, I guess.
32:41
It's nothing we can do about it. But if we implement that in the operating systems, we can give the users a choice, and maybe a sane choice there. Please engage with the ITF. Don't just criticise the ITF of the ROCs they make. The ITF and the ROC process is open.
33:04
Everyone can participate. There's no membership fee. If you can't travel to the meetings, there's remote participation. You just need your time. Sit there, listen to the talks, and you can use Java chat to ask questions or bring in your input there.
33:20
That is much appreciated. The ITF needs more people from the base, from the ground, to bring input there. Because if we don't do that, it's the big people from the big corporations that steer the internet protocols, and that is maybe not in the best interest of the people using the internet.
33:42
And independent from this talk, deploy DNSSEC, because DNSSEC makes DNS more secure. So I thank you for listening, and I hope we have a few, thank you.
34:06
We might have a few minutes for question and answer, and if you want to have more discussion on the topic, the nice people at Digitalcouraja who operate a DOT server, they allowed us to go there at six o'clock
34:21
and have a little meeting there and discussion. So if you are interested in the topic of DOH, DOT, and DNS privacy, you can meet me and other people over at Digitalcouraja around six o'clock, or a little bit later. Six-ish. Six-ish, yes. Okay, thank you, Carsten. Other questions here in our audience, please.
34:43
Yes, there. Can someone with the mic go down? Oops, be careful. Phones and some bottles. You mentioned the possibility between centralisation or decentralisation that this project could bring.
35:00
So one question I had here is, are there any plans for making sure that authoritative DNS servers, name servers, run one variation of those secured resolution protocols? Because if we want a real decentralised service, what we want is for me at home
35:21
to be able to run my own recursive DNS over HTTP resolution scheme, even though I am behind an ISP that blocks the pirate bay and that sort of thing, which means to be able to do that locally, I need to be able to reach all the authoritative name servers over HTTPS to make that work.
35:44
Are there any plans for this that you know of? Yes, the DNS privacy working group in the IETF is currently exactly working on that. They are looking into a protocol extension for DOT and DOH between the resolver and the authoritative servers. Still work in progress, it's not there.
36:02
There are some proof of concept implementation software already, but this is the second step. Securing the path between client and resolver was the first step, and this is what we have today. That is mature, we have the RCs, and the second step, securing resolver to authoritative communication
36:20
that's currently being worked on. Excellent, thanks. I see a question here in front. What is any of this new security rough and has no protection from downgrade attacks? It always falls back, and there's no way to know if there's supposed to be an encrypted channel to this DNS server.
36:42
What is truly gained in the face of an active attacker? Most of these software have two modes. One is the opportunistic and one is the strict mode. The opportunistic mode has a downgrade possibility. It falls back. Either it falls back to unauthenticated TLS or even it falls back to classic DNS,
37:03
but most software you can configure in strict mode, and then it will not be downgradeable. It will just fail if the encrypted and authenticated transport is not available. Okay, some more questions here. Sir?
37:21
Yeah, thank you for the talk. Just a quick question about the DNS inside application. What are your thoughts on why corporations are doing this? Is it just because it's simpler, because they own the software that implements it right now,
37:40
or do you think they have maybe nefarious thoughts or plans? I mean, I can't look into people's heads. I trust Mozilla, and so far I've talked with certain people from Mozilla, and they were frustrated with DOT and the process of DOT being implemented in the world.
38:05
The DOT RFC is now three or four years old, and it has not seen wide adoption. And that was one of the reasons why Mozilla worked on DOH, because then they have control over the client side,
38:22
and they don't have to wait for the operating system vendors, because DOT is usually something that you have in your operating system. Of course, others might have other plans, and I see, especially on the mobile space, which is the majority of internet users today, I fear that we have different apps in the mobile space
38:44
that all have different DNS name resolution, and that different operators give the application developers money to put in their DNS resolver there, because then they can analyze the traffic and get stuff out of that, for whatever reason.
39:04
And that is not what we want. Okay, someone. What about the initial host name of the DOH or DOT server? How is that getting resolved to an IP address? And isn't that a point where censorship
39:22
could already start to not letting people know where they can get DNS over HTTPS or TLS? Yes, so first, how is this resolved? How is the first step? The name of the DOT or DOH server is resolved.
39:41
Depends on the software. Some have some hard-coded bootstrap server, others use just traditional DNS for that. About the way how to, if that would be an angle to intercept and subvert the whole scheme, no, because of course someone could intercept this first query and give a different IP address
40:01
for the name, but then the certificate wouldn't match. So if you have a strict mode, where you really check the certificate of the other endpoint, unless the attacker has the ability to fake a TLS certificate, it wouldn't work.
40:20
Great. Of course, there's problem. That's why I say we should have software that relies on Dane and not on the public infrastructure of the internet with the certification authorities because that is a completely different problem space and yes, it's not perfect. Okay, this gentleman.
40:40
Hello, thanks for the talk. I'm wondering, as long as we don't have encrypted server name indication, a lot of the privacy benefits are lost again in the next, in the follow-up request after the DNS lookup. Yes, that's true. But the encrypted SNI is being worked on. Are you familiar with the plans of the browser vendors
41:04
regarding encrypted server name indication? Not so deeply as other people. I'm more DNS person, but I've just talked to someone today who's more in that space and he told me that this is currently actively worked on. I can't give a date when that will be there, but all the big vendors, Apple, Google with Chrome
41:24
and Mozilla are pushing that forward. I suggest we have one more, one last question here since we have to close. And are there already possible solutions for this split view DNS problem you mentioned?
41:42
I understand the question correct. Are there possible solutions for the split DNS problem? Yes. Probably yes. I haven't really looked into that. But what you can do is you can send certain queries to the system resolver that your operating system has
42:03
to figure out whether there is some specific namespace. But I'm not in the details of that. And this is still an open question and still something to be researched. It's the reason why Mozilla hasn't turned on DOH by default because they haven't figured out a good way to do this.
42:22
Still researching on that. But this is a problem that needs to be solved. Great, Carson. You, well, I got the virus as well now. I think some of the people here got this DNS virus. Thank you, Carson. Thank you.