Encrypted DNS? D'oh! - The Good, Bad and Ugly of DNS-over-HTTPS (DoH)
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 254 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/53042 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
00:00
Ext-FunktorVerschiebungsoperatorDirekte numerische SimulationSchreib-Lese-KopfSprachsyntheseMereologieMailing-ListeAutorisierungComputeranimationJSON
01:02
Vollständiger VerbandSprachsyntheseMereologieTaskForcingInternetworkingProtokoll <Datenverarbeitungssystem>Direkte numerische SimulationSoftwareentwicklerWeg <Topologie>BitGruppenoperationRechenschieberJSON
02:00
Wort <Informatik>ResolventeRauschenBitTwitter <Softwareplattform>VollständigkeitCachingStellenringResultanteWort <Informatik>
02:41
ARPANetDirekte numerische SimulationNetzadresseNumerische StrömungssimulationVirtuelle MaschineNP-hartes ProblemElektronische PublikationInternetworkingNetzbetriebssystemMicrosoft dot netOrdnung <Mathematik>VierzigJSON
03:28
Ordnung <Mathematik>Numerische StrömungssimulationMapping <Computergraphik>ARPANetDomain-NameSynchronisierungDifferenteNetzadresseDirekte numerische SimulationClientQuick-SortKlasse <Mathematik>Auflösung <Mathematik>
04:10
Auflösung <Mathematik>Direkte numerische SimulationDomain-NameTaskServerAdressraumDNS <Internet>StandardabweichungServerDomain <Netzwerk>Direkte numerische SimulationClientNetzadresseAuflösung <Mathematik>Güte der AnpassungPhysikalisches SystemBitFormale SpracheOrdnung <Mathematik>Domain-NameMultiplikationsoperatorHierarchische StrukturService providerStandardabweichungJSON
05:09
Direkte numerische SimulationLokalkonvexer RaumPhysikalisches SystemProtokoll <Datenverarbeitungssystem>DifferenteMAPDomain <Netzwerk>TopologieServerDirekte numerische SimulationHierarchische StrukturComputeranimationDiagramm
05:57
Direkte numerische SimulationDomain <Netzwerk>EreignishorizontNetzadresseWurzel <Mathematik>TopologieHierarchische StrukturServerExogene VariableTropfenNumerische StrömungssimulationService providerRoutingCASE <Informatik>ZeitzoneKartesische AbgeschlossenheitJSON
06:47
Auflösung <Mathematik>Prozess <Informatik>TopologieServerPunktHierarchische StrukturService providerDirekte numerische SimulationWurzel <Mathematik>NetzadresseProzess <Informatik>RechenschieberVorlesung/KonferenzJSONComputeranimation
07:39
NetzadresseProzess <Informatik>Twitter <Softwareplattform>ResolventeTopologieRechenschieberReelle ZahlServerService providerWort <Informatik>ResultanteVorlesung/Konferenz
08:28
ClientTaskZeitzoneElektronische PublikationDirekte numerische SimulationServerClientPhysikalisches SystemDeskriptive StatistikStandardabweichungNetzbetriebssystemUmwandlungsenthalpieNetzadresseBitDirekte numerische SimulationMAPDomain <Netzwerk>Wurzel <Mathematik>MereologieJSON
09:19
ZeitzoneServerInformationResolventeDifferenteElektronische PublikationE-MailInternetworkingDirekte numerische SimulationRechenschieberDomain <Netzwerk>DatensatzDatenbankUmwandlungsenthalpieCodeBitMAPMereologieWurzel <Mathematik>TopologieKreisflächeKartesische AbgeschlossenheitSelbstrepräsentationVerzweigendes ProgrammMessage-PassingBenutzerbeteiligungProjektive EbeneBinärcodeMathematikAuthentifikationHierarchische StrukturResultanteGeradeDomain-NameAdressraumComputeranimation
12:13
InternetworkingServerNetzadresseRichtungDifferenteMetropolitan area networkLesen <Datenverarbeitung>Domain <Netzwerk>Direkte numerische SimulationJSONComputeranimation
13:35
Service providerSystemverwaltungMAPSpywarep-BlockDirekte numerische SimulationComputerspielTermKonditionszahlJSON
14:16
Humanoider RoboterEinfach zusammenhängender RaumWeb-SeiteService providerGruppenoperationDirekte numerische SimulationKonditionszahlServerPunktProtokoll <Datenverarbeitungssystem>URLLoginWort <Informatik>GoogolRuhmasseWeb SiteTotal <Mathematik>SystemaufrufSpannweite <Stochastik>SondierungComputerspielQuick-SortVorlesung/Konferenz
15:37
DNS <Internet>MaßerweiterungZeitzoneServerMaßerweiterungWurzel <Mathematik>StandardabweichungDomain-NameTopologieDatensatzMereologieEinsHierarchische StrukturComputersicherheitPhysikalisches SystemElektronische UnterschriftDirekte numerische SimulationEinfache GenauigkeitBeweistheorieSchlüsselverwaltungJSONComputeranimation
16:33
NP-hartes ProblemServerRoutingFreewareSchätzfunktionMultiplikationsoperatorNetzadresseWurzel <Mathematik>Direkte numerische SimulationResultanteAdressraumService providerVorlesung/KonferenzJSON
17:41
NetzbetriebssystemServerResolventePhysikalisches SystemElektronische UnterschriftResultanteBenutzeroberflächeDomain-NameHierarchische StrukturDatensatzDomain <Netzwerk>RouterCASE <Informatik>ClientProgrammierumgebungValiditätDirekte numerische SimulationQuaderFitnessfunktionStützpunkt <Mathematik>Computeranimation
19:12
StandardabweichungComputersicherheitImplementierungStandardabweichungOffene MengeWeg <Topologie>Service providerDatensatzDirekte numerische SimulationSoftwareSkriptspracheNotebook-ComputerAggregatzustandSystemaufrufServerJSONVorlesung/Konferenz
20:35
Direkte numerische SimulationAggregatzustandUbiquitous ComputingDirekte numerische SimulationStandardabweichungProtokoll <Datenverarbeitungssystem>GruppenoperationMultiplikationsoperatorNetzbetriebssystemImplementierungChiffrierungJSONVorlesung/Konferenz
21:30
SkalarproduktDirekte numerische SimulationTLSDirekte numerische SimulationChiffrierungImplementierungServerNetzbetriebssystemStandardabweichungp-BlockClientSkalarproduktJSONVorlesung/Konferenz
23:24
Direkte numerische SimulationMixed Realityp-BlockNP-hartes ProblemWeg <Topologie>Direkte numerische SimulationProgrammierumgebungProtokoll <Datenverarbeitungssystem>Lesen <Datenverarbeitung>Weg <Topologie>p-BlockOktaederWurm <Informatik>DatensatzJSONVorlesung/Konferenz
24:13
ClientGraphische BenutzeroberflächeDirekte numerische SimulationProgrammbibliothekWurm <Informatik>DatensatzGeradeTemplateMultiplikationsoperatorClientGraphische BenutzeroberflächeAppletChiffrierungImplementierungJSONVorlesung/Konferenz
25:49
ClientServerGoogolService providerSoftwaretestServerDirekte numerische SimulationGraphische BenutzeroberflächeDatensatzProjektive EbeneCodierung <Programmierung>GraphiktablettClientMessage-PassingCodeMailing-ListeTemplateService providerAbfrageWeb SiteSichtenkonzeptCodierungJSONUML
27:19
WikiTemplateIn-System-ProgrammierungDirekte numerische SimulationServerSkalarproduktDomain <Netzwerk>Service providerTelekommunikationNatürliche SpracheVorlesung/Konferenz
28:08
ServerWeb SiteURLProxy ServerProxy ServerResolventeWeb SiteClientServerResultanteNatürliche SpracheEINKAUF <Programm>Message-PassingDirekte numerische SimulationComputersicherheitJSON
28:48
ServerCodierung <Programmierung>Direkte numerische SimulationExogene VariableNeue MedienCASE <Informatik>Message-PassingDickeResultanteLeistung <Physik>Lokales MinimumService providerDirekte numerische SimulationNetzadresseResolventeDateiformatSechseckServerCodierung <Programmierung>StandardabweichungImplementierungDigitales ZertifikatMAPProtokoll <Datenverarbeitungssystem>Physikalisches SystemPunktKugelSichtenkonzeptBenutzeroberflächeBenutzerbeteiligungProgramm/QuellcodeJSON
30:08
SchnelltasteServerSkalarproduktClientChiffrierungDigitales ZertifikatDirekte numerische SimulationSoftwareentwicklerPunktMultiplikationsoperatorUnrundheitNetzbetriebssystemJSON
31:24
RFIDIn-System-ProgrammierungSchnelltasteAggregatzustandStrömungsrichtungDirekte numerische SimulationBenutzeroberflächeGraphische BenutzeroberflächeServerImplementierungClientGoogol
32:08
AggregatzustandGraphische BenutzeroberflächeServerDirekte numerische SimulationGoogolService providerGraphische BenutzeroberflächeServerDirekte numerische SimulationBenutzeroberflächeDifferenteFamilie <Mathematik>DefaultNormalvektorURLPunktwolkeJSONVorlesung/Konferenz
34:07
Exogene VariableServerDirekte numerische SimulationLastTDMAMultiplikationsoperatorDirekte numerische SimulationDichte <Physik>ZentralisatorDifferenteCDN-NetzwerkLastUmwandlungsenthalpieServerJSON
35:11
SoftwareClientDirekte numerische SimulationUnternehmensarchitekturOrdnung <Mathematik>Reelle ZahlWort <Informatik>Domain <Netzwerk>ServerVorlesung/Konferenz
35:53
Direkte numerische SimulationServerComputersicherheitInternetworkingService providerSystemaufrufDirekte numerische SimulationService providerDomain <Netzwerk>MereologieImplementierungComputersicherheitOrdnung <Mathematik>ServerInternetworkingBitJSON
36:42
ComputersicherheitSystemaufrufService providerInternetworkingService providerIn-System-ProgrammierungMatrizenringOrdnung <Mathematik>Direkte numerische SimulationMinkowski-MetrikGraphische BenutzeroberflächeServerGoogolVorlesung/KonferenzJSON
37:33
Service providerDatenmodellBrowserInternetworkingDigitalisierungService providerDirekte numerische SimulationProzess <Informatik>TelekommunikationBitSoftwaretestAggregatzustandServerBrowserProdukt <Mathematik>In-System-ProgrammierungInternetworkingJSON
38:40
GoogolBrowserQuick-SortSyntaktische AnalyseProtokoll <Datenverarbeitungssystem>Minkowski-MetrikStandardabweichungDirekte numerische SimulationWeb logKontextbezogenes SystemSoftwareInhalt <Mathematik>UmwandlungsenthalpieCASE <Informatik>Einfach zusammenhängender RaumDomain-NameComputervirusJSON
39:35
ResolventeServerHypermediaIn-System-ProgrammierungSchnelltasteMicrosoft dot netGamecontrollerMalwareProtokoll <Datenverarbeitungssystem>ParametersystemMereologieAggregatzustandDirekte numerische SimulationDomain-NameEinfach zusammenhängender RaumCASE <Informatik>RoutingMailing-ListeUmwandlungsenthalpieDatensatzWeg <Topologie>InternetworkingResultanteSoundverarbeitungPunktwolkeVorlesung/Konferenz
41:48
ParametersystemWeg <Topologie>Direkte numerische SimulationInternetworkingDatensatzOrdnung <Mathematik>AuswahlaxiomDomain-NameWeb logService providerMetropolitan area networkUmwandlungsenthalpieTorusTermMathematikStörungstheorieJSON
43:34
Direkte numerische SimulationDatenmissbrauchKonfigurationsraumClientMAPDirekte numerische SimulationMAPUmwandlungsenthalpieClientNetzbetriebssystemChiffrierungInternetworkingDatenmissbrauchMetropolitan area networkKonfigurationsraumPhysikalischer EffektAuswahlaxiomProtokoll <Datenverarbeitungssystem>Leistung <Physik>PunktSichtenkonzeptJSON
44:24
Direkte numerische SimulationSichtenkonzeptBrowserClientPunktPhysikalisches SystemDefaultSkriptspracheVorlesung/Konferenz
45:04
SkriptspracheDesign by ContractElektronische PublikationParametersystemDirekte numerische SimulationPunktwolkeLastAggregatzustandWeb SiteJSON
45:51
ResolventeServerProgrammierungPunktClientSichtenkonzeptAggregatzustandDifferenteRekursive FunktionEnergiedichteResultanteDirekte numerische SimulationRoutingVorlesung/Konferenz
46:46
Service providerGraphische BenutzeroberflächeDirekte numerische SimulationService providerIn-System-ProgrammierungRekursive FunktionMereologieResolventeProgrammierungWurzel <Mathematik>Physikalischer EffektTelekommunikationBenutzeroberflächeGraphische BenutzeroberflächeSoftwaretestDefaultJSONVorlesung/Konferenz
47:47
Direkte numerische SimulationDirekte numerische SimulationHorizontaleGruppenoperationServerHeegaard-ZerlegungProtokoll <Datenverarbeitungssystem>Zusammengesetzte VerteilungChiffrierungTwitter <Softwareplattform>SchwebungJSONVorlesung/Konferenz
48:45
MultiplikationsoperatorTwitter <Softwareplattform>ChiffrierungDirekte numerische SimulationVorlesung/KonferenzComputeranimation
49:30
ResolventeServerSkalarproduktClientDirekte numerische SimulationTelekommunikationMereologieUbiquitous ComputingChiffrierungMetropolitan area networkInternetworkingMultiplikationsoperatorFlächeninhaltAutomatische HandlungsplanungService provider
50:21
InternetworkingMultiplikationsoperatorComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:21
Okay, now, for the first talk in the night shift, basically, it's encrypted DNS, the good, bad, and ugly of DNS over HTTPS, and Sebastian is going to talk about that and all aspects of it. Please give him a warm welcome.
00:47
Hi, I'm Sebastian, just a small heads up, the subtitle is actually Burrowed by Daniel Steinberg. Daniel is the author of cURL. Thanks Daniel for your title.
01:02
I work for a German speaking online IT news magazine, name doesn't matter. Part of my work was going to the IETF meeting. So for those people who don't know, the IETF is the Internet Engineering Task Force. Those are the people who actually work on the protocols that make up the internet. So whenever there's an IETF standard, that is what the internet actually is.
01:27
At the IETF 99 in Prague, there was a so-called dispatch, so some developer comes up with a new idea and asks the IETF if they want to work on their idea or not.
01:41
They wanted to work on it, that protocol was called DNS over HTTPS and it was dispatched in its own working group. So there were people that worked just on that protocol. And I'm going to tell you why they worked on DNS over HTTPS. So I have to actually read this for you because it's maybe a bit too small for a slide.
02:05
So in the middle you can see Eric Rescora, he's the CTO of Firefox for Mozilla. So he's doing all the technical bits for Firefox. And he was explaining DOH to some people in an audience, just like I do now. On Twitter somebody then said the right answer is that everyone should be running a feature
02:26
complete caching and forwarding resolver on localhost. All the rest of these discussions are noise from companies that want eyeballs. So for those of you who may not know actually any of those words, you're the actual target
02:42
audience of DOH. For all the others, well you may learn something about DNS as well. That's what I'm here for. So in the beginning there was no DNS. As we all know computers talk to each other via IP. The thing is how do you map an IP address to an actual machine?
03:05
Well it's kind of hard. You all may know that there's an etc slash hosts file on your device. Basically any operating system out there has this file. With DNS that file is actually not necessary but we still use it.
03:21
And the first host file is like 40 years old and this was used before the internet actually existed in the ARPANET. They had a few problems with that. At each node of the ARPANET they had to manually maintain the hosts file.
03:41
And in order to sync them they had to phone them, they had to actually send letters to each other in order to sync the names for other IP addresses and computers. That didn't work out quite well so they ended up with a lot of different names for the same computers which is basically a clusterfuck and you don't really want this. So after 15 years and with the growing ARPANET they came up with an idea which we now know as DNS.
04:09
Basic idea is to automate the mapping of an IP to domain names or vice versa. So if a client asks for an IP of a domain some server answers and gives you the IP address.
04:24
That's still how DNS resolution now works. Nothing changed in this idea for the last 30 years. So before they actually started on the technical bits they started working on the idea of
04:43
how should our system work. Basic idea is you've got a worldwide global hierarchy where you put all your domain names into it. Then you've got decentralized servers, thousands of servers that take care of that hierarchy. In order to do this you need standards so any single server in that system needs
05:06
to speak the same language in order for this system to work. It took them like five or six years to actually standardize that kind of system. This was in November 1987 and we still use this system today.
05:22
Like this is one of the oldest protocols you still use daily, heavily daily. This is what the hierarchy in the original standard looks like. So you may see there's a top node on it and then you've got a tree. That tree goes into different top-level domains M-I-L dot edu dot ARPA. Like more than 30 years ago there were not that many TLDs and then it gets split down
05:47
and each branching node may be what you now know as a name server or it may not be. But that's the important thing. We've got still this like tree hierarchy in DNS today.
06:02
So how does this work? So let's take a look at events.ccc.de for this event. If you want to know the IP address of that domain, you ask root servers, that top node in the tree hierarchy. Okay, which server is responsible for the dot de TLD?
06:24
Then you get an answer. With this you go a step a little further. In case of the dot de TLD, the people responsible for this is the Dennick, you may know them. And you ask their servers, okay, who in your zone dot de is responsible for ccc dot de?
06:45
You get an answer. And then you do this as well with the name servers from the Kars Computer Club and you get an answer. Just to give you a picture how this works, that top node in the hierarchy, the root servers,
07:02
there are more than a thousand physical servers out there to work with the daily DNS. Without those servers, nothing at all would work. So as I explained, you go, you traverse the tree top down.
07:25
But that's not actually how it works. You make it recursive. And at each point in the tree where it's branching, you can actually cache previously seen IP addresses. This is what we call a cached resolving process.
07:43
If you remember the slide with the tweet in the beginning. This may be important for the actual DOH deployment. Then there are sub-resolvers. So these asking several different servers and traversing this tree doesn't actually happen on your device.
08:04
What's happening on your device is called a stop resolver because it actually is not doing anything for real. It still works that way that you ask your sub-resolver for an IP address and you get that.
08:20
But the sub-resolver just forwards your request to an actual recursive resolver. From that, the sub-resolver gets the actual answer for the IP address. And this is what ends up in your operating system and what the clients on your OS actually use.
08:45
So how do they talk to each other? All those thousands of servers will write. Well, as I said, they first came up with the idea of the DNS and then they worked on the technical bits. These are actually two different standards. So RFC 1034 is the idea, the description of how the DNS works.
09:04
RFC 1035 is the technical bits. How do you work on the wire with that system so they all know and understand what you're actually talking about? One of the most important things is that only a specific name servers are, well,
09:25
authoritative name servers for specific parts of the domain, like the root servers for all the top-level domains. And you can split this out. And remember the tree from the hierarchy? You can actually draw circles for each name server in those branches.
09:45
And this is a DNS zone that's going to be important in the next slides. Each of those zones has so-called resource records. They are more or less a database with a lot of info on the actual DNS in them.
10:02
So domain names, IP addresses, a lot of other different things on how the DNS actually works. Some of them are really, really important, like which mail server belongs to a specific domain. Of course, you can just run the mail server on ccc.de, for example.
10:25
But this would be a different server than the web server on ccc.de. And you can actually differentiate them on the level of DNS. And you make this with the resource records. Those resource records have an encoding representation.
10:45
So they are not text files. So whenever you ask your stub resolver or any other resolver, ask any other DNS server, they are not sending text like an HTTP. They're sending a binary encoded, not an octet encoded message.
11:06
Each resource record has specifics on how you encode those resource records into an octet. That's all in 10.35. So if you ever want to have a week-long project, if you're on holidays,
11:20
you can actually implement this. There are a lot of tutorials to do this. It's not that hard. The curl code, like the C code for curl to implement RFC 1034, it's like 700 lines or so. So it's not that hard. It's doable. And the most important thing for the rest of my talk is all those bits and pieces
11:43
that are going thrown around in the internet are done on port 53 and complete in plain text via UDP. That's why it's now called DO 53 because it's on port 53. Before, just a few years ago, that was DNS.
12:04
But DNS has changed. So we had to find a new name for the old school DNS and the new school DNS. As I said, it's completely unencrypted. Everything is in plain text. There is no authentication at all.
12:22
When they made DNS, they never thought that you would have billions of people in the internet. So whenever you ask a name server, there is no way for you to be sure that you're actually talking to the server you wanted to talk to. There is no authentication at all.
12:41
So with this, DNS over port 53 can be tracked. So any man in the middle knows or can know what domains you're asking the IP address for. It can be blocked. Just block port 53 and none of your DNS will ever work.
13:01
You can manipulate anything that runs over this. So you can just, if you're a man in the middle and there's no authentication, you can just send bogus answers and you can actually redirect requests on DNS over port 53.
13:22
So I asked the name server of the CCC, but the man in the middle points me to a rogue name server and gives me a different IP address, which works quite easily because there is no authentication at all. It gets uglier. So these kind of well-known features are actually used now by people as features.
13:45
So for the last 30 years, a lot of admins got used to be able to do this. So they are now using the unauthenticated bullshit of DNS over port 53 to make what most people call supervision.
14:02
So they filter out your requests on a block level. Hijacking is actually what I find really funny is hijacking, like redirecting you to a different page, is used as a feature worldwide in a captive portal. Whenever you enter a public Wi-Fi, you have to accept some terms and conditions.
14:28
You may have recognized that those kind of portal pages don't come up if you use an HTTPS connection because if you use HTTPS, the server you want to talk to is actually authenticated.
14:41
But if the provider of the access point with the name server that you want to talk to tries to redirect you on the captive portal page, there's a mismatch. So you can't access the login page for the public Wi-Fi. That's because they fuck up DNS. Side note, there's actually an ITF working group that works on fixing this.
15:03
So they're working on a protocol to make this work. Google kind of slipped around this. They have just a probing URL in Android. Whenever you access a public Wi-Fi, Android probes this public URL and then you get redirected.
15:24
You can also do this with neverssl.com. Highly recommend. So as I said, DNS is kind of strange and it's used in, well, not that good a ways.
15:41
So in the end of the 1990s, a lot of people saw that the unauthenticated part of DNS is going to be a problem. So they came up with what we now know as DNSSEC. DNSSEC stands for Domain Name System Security Extensions.
16:01
The name extensions is because they just add new resource records to the old ones. So it should be compatible to the old standard. The idea is that you assign zones with a key. So each root server zone is signed with a key. And then you can, with this, you can traverse the tree and the hierarchy
16:25
and add signatures to those new zones for any single name server zone. With this, you can actually authenticate the name server you're talking to. So the answer you get from those name server you can trust is tamper-proof.
16:44
Problem is, it's still unencrypted. So whenever you use DNSSEC, people on the wire can still see what you are requesting. They are not able to manipulate your root.
17:01
They are not able to manipulate the answer. You still get the correct IP address. But do you really want your employer to know that you're serving Pornhub in your free time? Hmm, maybe not. There are other problems with DNSSEC. So it's really, really hard to deploy, it turns out.
17:20
It's hard to tell how many servers actually use DNSSEC. But the current estimate is just between 15 and 20 percent of all the name servers out there actually use DNSSEC. And they had 20 years of time. So that may not be a viable solution to actually make DNSSEC tamper-proof, DNS tamper-proof.
17:43
And, as I said, you've got sub-resolvers that don't actually use any resolving. But they just refer you to another name server on your operating system. And they would need to validate the signatures.
18:00
But there are not any actually deployed sub-resolvers that do this. So the Microsoft sub-resolver in Windows is able to understand that they get DNSSEC signed resource records. But it's just not validated if the signature is actually valid.
18:22
And this is the case with Linux and BSCs as well. If you're running those operating systems, you can of course validate your DNSSEC signature. But in Germany you would then have the problem that, for example, the Fritz Boxes by R4M, a typical home router in Germany, use the domain FritzPunkBox.
18:43
If you use DNSSEC in your home environment on the client devices, you wouldn't be able to resolve FritzPunkBox. Because it's just a bogus domain name. It's out of the actual hierarchy. So there is no signature for it. If you validate signatures, you won't get an answer. And you can't access your router anymore.
19:01
So DNSSEC has problems. Then ten years later, people actually thought, okay, what about encrypting the actual DNS? Like, make it all secure and encrypt what we put on the wire. This grew out of the OpenBSC folks.
19:22
But you may know folks from OpenBSC or have heard how they work. They're not really standards guys. They just implement stuff and see, think it's secure and say, yeah, well, we've got a solution. Use our solution. That worked with OpenSSH. But this only worked because some people at IETF actually thought, okay, well, we use your implementation for our standard because it's the best.
19:46
With DNSSEC, it never got any track record. So DNSSEC, DNSCrypt is no IETF standard. Nobody uses this out there. You can go to the DNSCrypt website, download a client, make it work and have encrypted DNS.
20:06
But if you use this, you can only talk to a really, really few name servers because the name server has to support this as well. So if you're running OpenBSC on your own server somewhere in the network, you can then run DNSCrypt capable name server.
20:22
Yeah, that's not going to work on your laptop. Think about your grandma. Is she going to do this? No. So the IETF got a wake-up call by the Snowden revelations in 2013. And they actually made a standard that says that pervasive monitoring by state actors should be taken like an attack.
20:50
So anybody working on IETF protocols should implement upcoming protocols in a way that you can't do that kind of pervasive monitoring that the Snowden revelations revealed.
21:06
And one of the first things the IETF thought about was DNS because DNS was one of the last protocols that at that time was still completely unencrypted. So they really quickly started a working group to solve that.
21:24
That was the DNS private exchange, DPRIVE. DPRIVE came up with DNS over TLS. So we've got this really, really nice encryption protocol, TLS. We've got a lot of really good or really weird implementation for TLS.
21:41
But any operating system out there supports this. So why not just encapsulate the DNS traffic in TLS and put it on the wire? Then it's encrypted and nobody can complain. And this kind of works. So if you're using DOT, it is actually encrypted.
22:01
Nobody in the middle can see what you're asking a name server. But the thing is the traffic can still be monitored because the actual standard says that you must use port 853. Just like you must use port 80 for HTTP. There's no way around it. You can still see traffic on there.
22:23
And with this, whenever you see traffic, you may be able to analyze or block it. So the easiest way to block DOT would be just to block the port and nobody would be able to ask for encrypted DNS answers.
22:41
Which is kind of lame. So then there was DNS over HTTPS, DOH. This was worked on after DOT. And this was basically based on the idea that DOT can be blocked.
23:03
And the idea was how are we able to work around the blocking feature of DOT. The basic idea is that you just mix DNS within any other HTTPS traffic. If you would block HTTPS traffic, none of your clients would work anymore for anything.
23:24
So even in a work environment, nobody would be able to work. So the idea is if you use that protocol, you can't block DNS requests and answers. You can't track it because it's encrypted.
23:41
You can't really modify any of it because you can't see anything. And you just see HTTPS traffic but you don't know what it is. And when I was at IETF 99, this was kind of like a revelation for me because it was a really, really nice and easy idea to just encrypt and make DNS safe.
24:01
I really, really liked that idea from the beginning. It got standardized like a year ago. So how does this work? So as I said, we've got these resource records that are pushed into octets that make up their packages on UDP on port 53.
24:24
We use this kind of encoding just as an HTTPS payload. You can use get and post requests, get an answer for it. If you import a lot of libraries that do all this, this is just a few lines of Python.
24:41
So you have to import a DNS lib that makes your DNS request and then you have to import the HTTPS library. And then you basically tell your client, okay, please make a request and then you get the answer. Literally, it's like 10 or 15 lines of Python. It's really, really nice, really easy, really usable.
25:01
If you've got a few hours of time, try it out. It's really, really good. You can use it in Firefox and Chrome as of now. They published it, both of them published the implementation like months and years ago. And off top of that, there are standalone clients out there if you just want to play around with DOH.
25:22
CURL supports it. Like for one and a half years, you can use DOH in CURL. And then OK HTTP, one of the most used Java libraries, supports DOH. So if you build a client that really needs encrypted DNS, look at those libraries.
25:45
This is taken from the standard RFC 8484. So how does this work? We've got a URL template like DNS query on example.com. We make a GET request on HTTPS to that server.
26:04
As you can see, the DNS query, it's just a bunch of encoded stuff. In the standard, they use base64 URL encoding without padding to make the resource records just smaller.
26:20
You could use all of the actual octets, but that would be, well, it would be just too long and too much. So we use base64 and we call this a DNS message on HTTPS. Really, really easy to understand if you know anything about HTTPS.
26:41
Just look into the RFC. How does this work on the server side? So the code project by Dennis Sandberg actually provides a list of public DOH servers. So if you just want to use Firefox or Chrome or any other client and try DNS over HTTPS,
27:01
you can use several different servers. A lot of big commercial DNS providers support DNS over HTTPS. Google, Cloudflare, Quad9 from IBM. Digitale Gesellschaft 2 runs their own DNS server. The DNS server from them supports DoT and DOH.
27:25
Please don't spend their DNS server. The Freifung München runs their DOH server on the congress on a specific domain. So if you want to play around with DOH after this talk, take a look in the wiki.
27:41
They have a lot of explanation how to use their Freifung DOH server at congress. And finally, British Telecom is the first big commercial ISP in the world that is now testing the deployment of DNS over HTTPS. You can use DOH on your own servers, of course.
28:04
As I showed you, you just need a URL template and pass whatever request you get for this. There is a tutorial for Nginx on how you do this. It's really straightforward. The idea is that you use Nginx just as a proxy for an actual resolver.
28:22
So you take the request, forward this to the resolver, the resolver gives you back the resource and then Nginx pushes this back to the client. So if you're running a website, you can put this website into a DOH server. So if you really care about your security, please do this.
28:44
How does this look on the server side? As I said, we've got this DNS message which is standardized in 8484. And this is, as I said, the actual DNS format on the wire. That's what's standing in the standard.
29:04
So the server answers with an OK message. You get the content lengths, you get the maximum age of that request. So you can actually cache that request. And then you've got a hex encoding of the actual DNS answer
29:20
which your server resolver actually can use, pass, and give you the IP address or whatever you're asking for. Problem is, on the deployment side, outside of the web HTTP sphere, you can't really use DOH with currently available methods.
29:44
Microsoft announced that they're going to support DOH in Windows 10 just a few months ago. There is no implementation, no readme, nothing on what they want to do, on how they want to work. They just announced they're going to support the protocol. So, from my point of view, it's really good
30:01
because no other OS-level resolver has this on their agenda. None. The systemd folks implemented DoT but they don't validate the TLS certificate so you can just, yeah, it just doesn't work. Why use TLS if you don't validate the certificate?
30:25
So, in the point of the operating system, you basically can't use DOH as of now. If you're running a kind of commercial name server yourself, you may know DNS dist. This actually supports DOH.
30:44
This actually supports DOH without TLS so you can play around with all the encryption without validating a certificate if you just want to look at what is actually happening. And then there's Bind. Bind is the most widely used DNS server in the world.
31:03
Bind was co-developed with the actual DNS standard. They pride themselves for actually supporting anything that is happening within DNS but they just waited and waited and waited and waited and didn't do anything on DOH because none of their clients would pay for the development.
31:24
Finally, just a few months ago, the ISC announced that Mozilla is going to pay for the DOH support in Bind. So, after that, even your ISP that runs Bind may be able to support DOH without any trouble. They just need to upgrade their Bind.
31:44
So, current state of the available client situation on DOH. With Chrome and the maybe upcoming Windows 10 implementation you can use DOH and it's used automatically
32:01
if your predefined DNS server also uses DOH. So, let's say you've got Google 8888 as your DNS server. If you do this, they kind of guess that you want to use DOH if you're using Chrome
32:21
and then they just transparently upgrade you to DOH and you're going to use this. This works with a bunch of other servers like eight or nine different providers in Chrome. We don't know what Microsoft is going to do with Windows 10 but they said they want to do this as well.
32:43
Firefox defaults to using DNS over HTTPS in the US. Unfortunately, this got a lot of heated discussion because they use a predefined server in Firefox with a knocked out.
33:00
So, whenever you're going to install a new Firefox with the US English location, you're going to use Cloudflare as your DOH server provider. And as of a few weeks ago, Firefox also supports NextDNS which is also a new upcoming commercial DNS provider in the US.
33:25
But as I said, this only happens if you're running the US international location of Firefox. Okay, so just a short recap why should we use DOH? As I said, it's encrypted and standard compliant encrypted
33:42
not like DNS script. Typically, DOH servers are faster than normal name servers. That's because we use HTTP. For the last 25 years, HTTP was optimized in pushing content fast. That never happened with DNS because, well, just wait for a UDP packet
34:02
and if it not arrives, just send a new one. HTTP never worked that way and thousands of engineers worked on making HTTP faster. That's why DOH is most of the time faster than DNS. You can reuse load balances, you can reuse caching infrastructure, you can reuse a CDN.
34:23
On top of that, we typically use HTTP2 for DOH and then you get multiplexing and a server push. So, you actually get your answers faster by design. The bad thing is there are not that many DNS servers out there so there may be a centralization
34:40
which runs against the actual goal of making DNS decentralized which may be a problem. The standard actually says that you can use HTTPS for a lot of different monitoring and as Snowden revelations showed us this is also used. So you can infer
35:02
a lot of specifics on the HTTPS traffic, even if it's encrypted which is stuff that you may not want to do. Then there are deployment problems. You may have internal and external networks. If you deploy a DNS
35:20
in your company you may have specific domains that are just known inside your company and are just resolved inside your company. Typically, you would just announce your own name server via DHCP and this own name server would resolve your own made up domain. With DOH it won't work
35:40
because it's encrypted on a different channel on a different port and the clients of your users will never get this name server. Which is a deployment problem especially in enterprises and then there's a problem on how do I actually get to a DOH server because I mean I need a domain for my DNS
36:02
in order to resolve domains. Isn't that a bit weird? The active parts of DOH OpenBSD community that prides themselves with working for security and invented DNS script, they deactivated
36:21
DOH in their Firefox implementation because they just don't like Mozilla or I don't know, they maybe don't like security features. I don't know, they just didn't want DOH which is kind of stupid in my opinion. The ISPs in the UK actually called Mozilla an internet villain because they are deploying DOH.
36:42
Like, who is gonna fuck up the internet? Of course, it's gonna be Mozilla. Are you kidding me? The same, kind of same that happened in the US. A lot of ISPs and their lobbying companies actually wrote letters to Congress that the
37:00
deployment of DOH is gonna be an anti-competitive behavior. But how is your ISP in competition with your browser? Okay, so this works in that way that they think that if Google and Chrome ever uses their Google DNS servers
37:21
yeah, the ISPs will never be able to send you advertisements over DNS or hijack your DNS in order to set your advertisements so they are then now competing with Google on ad space and that would be anti-competitive. I've asked, as my
37:40
day job as journalist asked ISPs in Germany how they're gonna solve this. I really didn't get any answer. They just don't care, they just wait cause, well, we're in Germany and digitalization just needs time. The most liked answer for me was from Deutsche Telekom. They said DOH is bad for data ownership
38:01
but if I encrypt my DNS and I choose my own name server, how is that bad for data ownership? Ah, it may be bad for the data ownership of Deutsche Telekom that sells those data. They said also that browser makers flip over the production model of the internet. According to
38:21
that, the production model is selling user data. That's your ISP, that's the most used ISP in Germany. You're not paying them to actually get internet, you're paying them to sell your data. That's kind of weird. And they also said if you use DOH in a browser then the browser makers will see
38:43
well the traffic of the browser. Isn't that the kind of thing the browser does? Sending traffic back and forth? I really didn't get what they want to tell me. Then there's a lot of stuff on DOH that is just plain out nonsense out there.
39:02
A famous German blogger that has said that DOH uses JSON and he published this without any knowledge on the protocol. As I said, it was standardized. You just have to look into the standard
39:21
and it says we're using HTTP in the specific context that I explained. There is no JSON. You don't need JSON parsers. Your DNS request will not fail just because you have a space more or less. Then there was a case where a malware resolved their
39:40
domain name for the command and control server via an HTTPS connection. They didn't use the standard for this, but a lot of media said that malware uses DOH and that's why DOH is bad. But how many malware examples out there are using AES encryption?
40:02
Is AES bad because malware uses this? It's a completely nonsense argument. Then there was a talk this year by Paul Wixey who actually wrote a lot of stuff in BIND and who really really knows DNS. He compared Google to the East India company because they're using
40:20
DOH. I don't know if you know the East India company, but for 250 years there were state actors inside the British government taking part in slave trade, opium wars, horrible stuff and war crimes and they're comparing Google to this. I don't know if that's actually a good
40:40
argument. And then there's one by Bert Hubert who actually is working for PowerDNS who produce DNS list and he says that DOH violates net neutrality. So if you as a user choose your own name server with a specific
41:00
protocol that violates net neutrality. I still don't understand the argument. He says that the name server in the old school DNS is with the request able to get you faster routes on their backend. So if you're if the old school
41:20
name server of your ISP runs in the Akamai CDN and you're now using Cloudflare as your resolver Akamai can't give you a faster route anymore and that's why it's against net neutrality. I think that guy has not really a good understanding of what net neutrality actually
41:40
is and how that should work. And then there's a lot of shaming of Mozilla. I mean as I said before of course Mozilla is going to fuck up the internet because we all know that company has no track record at all. Sorry that was sarcastic. The same goes for Cloudflare. Of course Cloudflare is not an honest or good company.
42:03
But Mozilla thought about this. I'm going to come to this. And there are a lot of arguments that if you centralize DNS on Cloudflare the intelligence agency will be getting all your data. According to
42:22
the Snowden revelations the intelligence agency went to the internet exchanges and deployed man in the middle attacks, the pervasive monitoring because it was easier than coming up with court orders for each single individual company that runs a specific internet service.
42:40
So even if they come up with a court order and go to your ISP and want to get your data, it's still way way harder than the pervasive monitoring at the internet exchange because there is no man in the middle attack possible with DOH. And then there's arguments that opt out as bad because
43:01
why would you ever trust a company with choices you don't know about? And the target audience for DOH is not you in the audience. If you made it here you know how DNS works. Target audience for DOH is your grandma that doesn't know anything about domain names.
43:21
And then again there was this quote by a famous German blogger Mozilla is waging a war against their users because you can't trust a company like Mozilla. What fucking stupidity. So just remember the goal of DOH. We want encrypted DNS. We want this for all. And not just for a few people who are able to actually encrypt
43:42
their data and make specific configurations on their operating system. We want to make pervasive monitoring harder on a protocol level so that any user out there that is using the internet can rely on encrypted data. Cause we all want better privacy.
44:02
So how is DOH doing this? You can make an informed choice at the client level. So you as a user can choose to choose the path of encrypted DNS and privacy. It's really really easy to configure and as I said there is no man in the middle attacks
44:21
possible anymore. So from my point of view the only way to actually deploy this in the wild to the billions of users is to make that opt out the only way. So if you don't like DNS
44:40
over HTTPS you can just disable it. But browser vendors, operating system vendors, anybody out there that's working on clients that use DNS need in my opinion need to deploy DOH as default. Otherwise we will never get encrypted
45:01
DNS out there. Cause as we've seen with DNS script nobody cares at all if they have to do it themselves. So companies have to do this for their users. Mozilla as I said gets a lot of bad shit crazy arguments that they
45:21
are cooperating with Cloudflare. They thought about this. There is a public policy on the contract with Cloudflare. What is Cloudflare allowed to do with your DNS data? They are not allowed to personalize any of this data.
45:40
They are not allowed to sell this data. They are not allowed to make a shitload of stuff and they have to delete those log files after 24 hours. So even if a state actor like an intelligence agency runs into Cloudflare name servers, their cannery will die. We will all know about this
46:01
and then you can just switch to different name server. And they will end up with nothing. So from my point of view Mozilla is making a really good example on how a company that is working on a client is able to deploy encrypted traffic for their users.
46:21
They call this Trusted Recursive Resolver program because it is a recursive resolver built into the client that Mozilla trusts. They started doing this for the US as I said. They are going to deploy this worldwide.
46:41
That is what they said they want to do. From what I have got, there are not that many ISPs that want to cooperate with Mozilla on that and there is a lot of ISPs that say they specifically don't want DoH. From my point of view, whenever an ISP says that they don't want DoH
47:01
it is because they use DNS hijacking as a feature. So they are working against you as a user. So please ask your ISP if they want to deploy DoH and if they want to take part in the Trusted Recursive Resolver program of Firefox.
47:21
Apart from that, there are ISPs that use DoH or at least test or deploy DoH now as British Telecom. So this is going to be way more in the distant future. We are going to have Chrome and Windows on DoH as default I guess. And finally
47:41
your OS will be able to resolve a name via DoH. And then we end up with encrypted DNS for all. Yay! For all the technical problems, there are working groups now at IETF. So we are going to solve the split horizon problem. We are going to solve the discovery problem. There are drafts to make
48:01
an announcement of a DoH server via DHCP. So the engineers are working on it and then there is still QUIC and HTTP coming up. So even if you don't want to use HTTP or HTTPS for DNS the thing that the IETF is standardizing after
48:23
HTTP3 which runs over QUIC is going to be DNS over QUIC. QUIC is a new transport protocol. It's completely encrypted and well kind of is used as a mixture in between TCP and UDP but better, faster
48:41
and encrypted. Yeah I wanted to think about an outcome for next year. Somebody beat me on Twitter to it. So next year will be the year of DoH. Now it's time for questions.
49:04
If you have any. Well actually we'd have to make that singular except you are fast. You are very fast
49:20
on the microphone over there. There is another microphone there. So go ahead. Thank you. You said encrypt all DNS spot DNS over HTTPS encrypts only traffic from resolver to the stop resolver because from Cloudflare to the DNS
49:40
server everything is unencrypted like before. Well yeah so that's what we care about in the IETF pervasive monitoring. So we know the client traffic is actually monitored at the basics for example and we want to stop this and we want to stop man in the middle attacks. If you're running your own name server and you want to run a resolver on
50:00
your own name server just use DoT they're not going to block this. This is going to be DoH can't be blocked in a client kind of sense. The name server communication in between name servers is not part of the idea of DoH.
50:21
Well unfortunately that's it. We are out of time even though the internet and the signal angels still have questions and there are a lot more questions in the room. I'm going to be around if you still have questions. Maybe you can take your discussion someplace. Thank you and
50:41
applause.