 Ich hoffe, ihr konntet irgendwie genug schlafen. Ich weiß nicht, wie es euch geht, aber durch die fehlende Mainstage erleben wir dieses Jahr viel stärker die farbenfrohe und fantastische Vielfalt des Chaos und der Chaos-Begeisterten. Vielen Dank an alle, die das vor und vor allem auch hinter der Bühne möglich machen. Ansonsten noch ein Aufruf bei unseren Lightning-Talk-Sessions sind noch solch frei. Dort kann jeder fünf Minuten über seine Leidenschaft berichten. Diese Vorstellen, also meldet euch, tragt euch ein. Vielen Dank und unser nächster Vortragender wird uns ein Update über DNS geben und auf die Wichtigkeit von freiem DNS plädieren. Jörg Bacchus. Anfang der 90er wurde er an der Uni der Verwaltung mit einer Domain und den zugehörigen IP-Adressen beauftragt. Seitdem hat ihm das Thema DNS nicht mehr losgelassen. Er verfolgt es seit Jahren und ist bei der IETF brennend auf deren Umsetzung interessiert. Im Anschluss an den 30-minütigen Vortrag wird es eine Q&A-Session geben. Fragen also wie immer, bitte über Twitter, Mastodon oder IRC mit den üblichen Hashtags, Hashtag R3S oder Hashtag R3, RC3, R3S. Thank you. Und jetzt an dich, Jörg. Ja, guten Morgen zusammen. Mein Name ist Jörg Bacchus und ich bin in der IET eigentlich in zwei Themenbereichen unterwegs. Das eine sind Themen rund um ja, Storage-Datenablage. Das ist sowas wie Blog-Storage, wie NAS oder auch Object-Storage. Und das andere Thema, für den ich sich brennend, das sind halt Netzwerktämen und zwar Netzwerkservices. Und das sind besonders zwei Dienste, die mich besonders faszinieren. Und das schon seit längerer Zeit. Das ist einmal das Thema E-Mail und einmal das Thema DNS. Und ich habe deswegen auch heute Morgen das Thema Namensauflösung als Thema meiner Präsentation gemacht. Und ja, der DNS, die Namensauflösung, rückt immer mehr in den Vordergrund und viele Firmen entdecken darum, ein neues Geschäftsmodell, Internet und DNS-Services zu professionieren. Wir starten zunächst in einer kleinen Einführung am DNS, welche Elemente gibt es? Wir gucken so ein bisschen die Entwicklung an und gucken mal, wer in diesen ganzen Erwielungsstritten ja mit bei wohnt und wer dort seine Geschäfte abbildet. Ja, Domain-Name System, was ist das überhaupt? Das ist eine hierarchische und dezentrale Datenbank. Die Datenbank ist verteilt. Die ist also nicht auf einem Server, sondern auf verschiedenen Servern verteilt. Und in dieser Datenbank sind dann sogenannte Resource-Records abgelegt. Die gucken wir uns gleich auch nochmal an. Und das Wichtigste ist, dieses Domain-Name-System ist auf Verfügbarkeit und Ausfallsicherheit ausgelegt. Das konnten wir erst vor kurzem beobachten, wo die DNS-Server von Facebook nicht erreichbar waren. Das bedeutete auch gleichzeitig, dass die Dienste im DNS nicht verfügbar waren und damit auch die Services dieser Kampagnen nicht zur Verfügung standen. Aber welche Daten sind überhaupt in dieser verteilten Datenbank vorhanden? Und da habe ich mal kurz eine Zusammenstellung aufgebaut, die wichtigsten Informationen, die dort abgelegt werden. Man unterscheidet zwischen zwei Verfahren. Es gibt einmal den sogenannten Forward-Lookup und einmal den Reverse-Lookup. Forward-Lookup ist die Auflösung von Namen nach IP-Adressen. Ich habe das mal hier bei Spielhaft an drei Resource-Records durchgeführt. Das kann natürlich im IPv4 als auch im IPv6-Bereich stattfinden. Die Resource-Records haben unterschiedliche Namen. Das A steht halt für IPv4-Adressen, dass die abgewellet werden, das Quad A halt für IPv6-Adressen. Wenn man Namen auf IP-Adressen abbilden kann, dann kann man es auch andersrum machen. Und genau das findet im sogenannten Reverse-Lookup statt. Dort werden halt IP-Adressen über einen Pointer-Rekord wieder auf Host-Namen abgebildet, wie man hier auch sieht. Es gibt aber noch weitere Resource-Records, die im DNS sehr wichtig sind, damit Services im Internet funktionieren. Einer der ganz wichtigsten ist der sogenannte MX-Rekord. MX-Rekord steht für Mail-Exchanger, damit man weiß, wenn man eine bestimmte Domain hat, an wen die E-Mails ausgeliefert werden müssen. Welcher Server fühlt sich verantwortlich für die Auslieferung von E-Mails? Also eine ganz wichtige Sache. Wenn kein DNS vorhanden ist, dann wird es schwierig, E-Mails überhaupt auszuliefern, vielleicht sogar auch unmöglich werden. Und dann gibt es einen weiteren Resource-Rekord, also genannten Text-Rekord, der wird für allerlei Informationen heutzutage gebraucht. Als erstens verschiedene Identitätsüberprüfungen werden halt verwendet. Wenn man sich irgendwo registriert, einen Dienst nutzen will, dann muss man im DNS einen Text-Rekord setzen und danach wird halt validiert, ob man Eigentümer der Domain ist oder nicht. Aber ich habe hier auch ein paar andere Rekords aufgeführt, die regelmäßig in diesem Text Sachen verwendet werden. Das sind halt Sachen aus dem E-Mail-Bereich, Decim-Signature, SPF und so weiter. Und wie man schon sieht, die Daten sind ungemein wichtig, dass mit überhaupt ein Service im Internet funktioniert. Wenn man also eine Webseite aufruft, www.meinefirma.de, dann wird sofort im Hintergrund ein Namensauflösung im DNS gestartet, damit man nachher den Seite aufrufen kann. Im DNS-Dienst gibt es ein Server und eine Kleinseite, beziehungsweise es gibt zwei Server-Varianten und eine Kleinseite. Es gibt diese genannten Authorities, DNS-Server. Die Authorities sind dafür verantwortlich, Informationen für eine bestimmte Zone zu liefern. Eine Zone kann zum Beispiel sein, eine Top-Level-Domain, zum Beispiel die Top-Level-Domain-Net oder für den kompletten Domain-Namen Backschuss.net, zum Beispiel hier in dem Beispiel. Und diese Authorities DNS-Server sind die eigentlichen Verwalter der Daten, die halten die Daten. Und die Zonen sind normalerweise über verschiedene DNS-Server verteilt, so dass man auch eine gewisse Redundanz hat. Als zweites Server-Komponente gibt es so genannte Recursive-DNS-Server oder Resolving-DNS-Server, auch non-authoritative genannt oder auch zum Teil caching-DNS-Server genannt. Was machen die? Wenn man an diese Reservice-DNS-Server eine Anfrage stellt, dann lösen sie über die verschiedenen DNS-Server die einzelnen Zonen aus und liefern praktisch das Gesamtkonstrukt basierend auf Top-Level-Domain, Sub-Domains und Host-Name auf, so dass man dann den kompletten Adresse halt sehen kann. Und der Ganze, der das auslöst, der das Anfracht, der den Recursive-DNS-Server anfracht, das ist auf dem Client. Und dieser Client kann ein beliebiges Endgerät sein. Es kann Handysign, es kann ein PC sein, unterschiedliche Betriebssysteme. Und da ist so ein kleiner Stubb, nennt sich das. Und dieser kleine Stubb, das ist ein fester Eintrag, der weist halt auf einen Recursive-DNS-Server. Und wenn eine Name aufgelöst werden muss, dann geht er an diesen Recursive-DNS-Server und versucht die ganze Sache aufzulösen. Wir konzentrieren sich dem Vortrag eigentlich auf den Recursive-DNS-Server und den Client-Sub-Resolver. Und das Verhältnis von diesen beiden Elementen. Wir haben gerade schon von gesprochen, es gibt die Clients, also Mobil-Device, PC-Server, wie auch immer. Und die sind hier oben in der Grafik als Client-Stubb dargestellt. Und wie bekommen die Gezehre-Informationen, welcher DNS-Server Informationen auflösen kann. Die häufigste Methode, die auch heute noch zum größten Teil zum Einsatz kommt, ist der Client kommt ins Netz, bekommt eine IP-Adresse, bekommt eine Netzwerkmaske und Gateway zugeteilt und dann wird ihn normalerweise per DHCP auch noch der DNS-Provided. Und daraus gibt es verschiedene Möglichkeiten. Es kann ein lokaler DNS-Resolver benutzt werden. Also viele Firmen haben einen eigenen kleinen DNS-Server und lösen dann die ganzen Domains auf. Es gibt aber auch der Internet-Provider, also hier bei uns Telekom, Vodafone oder die Telefonika. Oder es gibt auch, und das sind eigentlich ein bisschen die neuen Spieler dabei, das sind die Cloud-DNS-Resolver. Es steht ganz vorne in der Google, Cloud-Fair oder auch eine Quad-9, die sich dort etabliert haben. Meine Erfahrungen nach sind mehr als 90 Prozent der Clients holen sich ihre DNS-Server über das DHCP-Protokoll und nehmen das einfach entgegen, ohne diese Auswahl zu bewerten oder ohne das um zu ändern. Es gibt aber noch weitere Schritte, wie man ein DNS-Server halt konfigurieren kann in den Client-Systemen. Das funktioniert mittlerweile auch über IPv6 natürlich, aber man kann natürlich auch in einem Client-Start statisch die Informationen eines DNS-Systems hinterlegen. Das sind alles Level, die auf Betriebssystem-Level stattfinden. Das Betriebssystem bekommt die Information, welcher DNS-Resolver genutzt werden kann und die Applikationen greift dann auf diesen DNS-Server, der Betriebssystem hinterlegt ist zurück. Es entwickelt sich aber letzter Zeit ein Trend, dass man weggeht vom Betriebssystem-Level, sondern auf Applikations-Level geht. Auf Applikations-Level stehen die neuen Morausa-Version im Vordergrund. Dort kann man separat einen DNS-Server einfragen und dann lösen die Browser nicht mehr über die Vorgabe des Betriebssystems eine Domain auf, sondern mittlerweile dann über den Browser direkt. Also verschiebt sich das Ganze vom Betriebssystem-Level auf den Applikations-Level. Was passiert bei vielen Firmen auch noch? Viele Firmen haben einen lokalen Rekursiven DNS-Resolver, sieht man ganz links im Bild und sie lösen die Informationen aber nicht bis ganz zum Schluss auf, sondern sie leiten das einfach an einen ISP wieder weiter. Sehr unsinnig. Wenn ich schon einen eigenen DNS-Resolver habe, warum löst da nicht die komplette Domain halt auf, also den Full-Qualified-Name? Warum übergebe ich das dann wieder an einen ISP? Das macht eigentlich keinen Sinn, wird aber bei vielen Firmen halt gemacht. Ja, hier sind die einzelnen Konfigurationsoptionen nochmal so ein bisschen zusammengefasst. Bemerkenswert ist halt, über DHCP und über das Router-Advertisement, den DNS-Information zu bekommen, ist eigentlich ganz einfach zu modifizieren. Weder DHCP noch das Router-Advertisement, worüber man auch den DNS-Information bekommen kann, ist besonders abgesichert. Das heißt, wenn irgendeinem Netz ein jemand einen weiteren DHCP-Server deployt, dann kann er ihm einfach einen falschen DNS-Server auch unterjubeln. Und das hat vielleicht zur Folge, dass gewisse Sachen haus ausgefiltert werden, manipuliert werden oder einfach nicht mehr aufgelöst werden können. Und es gibt noch ein weiteres Idee von Microsoft halt. Wie kann man halt den DNS-Server an die Clients provisionieren? Die haben ein neues Protokoll implementiert. Das ist jetzt auch mit den neuen Windows-Server-Versionen, Windows 11 eingebaut worden, ist aber noch nicht standardisiert in diesem Fall. Ja, und wenn wir unten nochmal gucken, da habe ich ein paar Logos eingebaut. Wer sind die Treiber, die auf Applikationsebene halt gerne DNS-Informationen aussuchen möchten? Das sind hier die Mozilla-Gruppe und einfach Google mit seinem Chrome. Ja, die Übersicht zeigt einfach noch mal, was kann man automatisiert machen und wo muss man halt händisch eingreifen? Also, die Standard-DNS-Verfahren, die werden wir auch nachher noch mal ein bisschen kennenlernen, die können mittlerweile komplett automatisiert provisioniert werden, also DNS oder DNS-Sec. Für alle anderen gibt es diese automatische Konfiguration nur eingeschränkt bzw. manuell. Also, da ist man noch nicht so weit und da sucht noch in den Standardisierungsgeremien nach Möglichkeiten, wie man diese DNS-Konfiguration auf dem Kleinteil setzen kann. Ja, gucken wir uns mal an, wie die Namensauflösung funktioniert. Wenn man zu Hause ist, wenn man bei einem Internet-Provider ist, dann wird einem da ein Router hingestellt. Der Router bekommt eine DNS zugewiesen und der gibt den dann per DHCP an seine lokalen Clients einfach weiter. Ich habe hier einfach mal ein paar Beispiele aufgeführt. Die meisten sind noch bei DNS-Server, die nur IPv4 sprechen, aber es gibt mittlerweile auch mal mehr DNS-Server, die von den Internet-Service-Providern dargestellt werden, die mittlerweile IPv6 können. Aber was ist mit der Vertrauenswürdigkeit dieses DNS-Resolvers? Manipuliert der Daten, werden Daten gesperrt. Und wie sieht das mit der Privatsphäre eigentlich aus? Und die Frage sollte man sich eigentlich stellen und nicht einfach den DNS-Resolver nutzen, den der ISP so einem einfach zur Verfügung stellt. Ja, wir können auch noch mal gucken, wie sieht es in dem Rouser Chrome aus? Ja, auch da hat man die Möglichkeit, man kann einem Custom-DNS-Server dort eintragen und muss nicht den vorgegebenen geben, den Microsoft normalerweise hier provisioniert, also seine Quad-Aid, sondern man kann ja auch eine eigene DNS-Server eintragen. Aber man muss es halt händisch machen und wer trägt schon gerne etwas händisch ein, ja? Abgesehen davon kann der Kunde nicht überprüfen in Chrome, ob eine Domain, da kommen wir nachher nochmal abgesichert ist durch DNS-Sec. Ja, im Firefox haben wir ja ein ausgiebiges Add-on-Modell, wo man sich verschiedene Add-ons installieren kann und dort hat man eigentlich eine vollkommene Transparenz und man kann sehen, ja, welchen DNS nutzt man, wie nutzt man DNS, ist der per DNS-Sec abgesichert und natürlich kann man auch frei sein DNS-Server-Halt hier einstellen. Ja, ich habe gerade schon von gesprochen, wie vertrauenswürdig ist ein DNS-Resolver, aber ich möchte erst mal darauf eingehen, warum macht man das überhaupt DNS-Manipulation, was ist überhaupt die Idee dahinter? Die erste Idee ist eigentlich, was in der DNS-Szene als Split-View dargestellt wird, das heißt, man hat eine Webseite www.meinefirma.de und die hat eine offizielle IP-Adresse. Jetzt möchte aber man von seinem internen Firmnetz auch auf diesen Webseite zugreifen, aber möchte nicht von außen darauf zugreifen, auf diesem Grund, aus diesem Grund wird die IP4-Adresse dann halt modifiziert mit einer interne IP-Adresse. Das ist einfach, damit man halt sein Intranet nicht verlassen muss, sondern nur intern seinem eigenen Netz bleibt und nicht auf die offiziellen IP-Adressen zugreifen muss. Und natürlich, in Firmen natürlich, wenn man interne Dienste anbietet, möchte man die nicht über IP-Adresse aufrufen, sondern über Hostnamen, dann hat man im Intranet einen eigenen DNS. Aber der höreaufwistigste Fall, warum DNS-Daten manipuliert worden ist eigentlich die Blockierung von Online-Inhalten und die vier Punkte, die ich dort aufgeführt habe, die zeigen eigentlich so, wie ich die Blockierung von Inhalten erfahren habe, wie ich sie kennengelernt habe. Das erste war, ich hatte vor zehn Jahren eine Spielekonsole bei mir zu Hause und die hat halt immer Online-Firmware-Updates gemacht, jedes Mal, wenn sie gestartet ist. Das wollte ich nicht, weil die neuen Firmenversionen nicht so funktionierten. Man konnte das aber nicht unterdrücken und abschalten. Was habe ich gemacht in diesem Fall? Ich habe den DNS manipuliert und die Seite Update-Meine-Spiele-Konsole.de halt einfach ins Leere laufen lassen. Das war gewollt, eine erste Blockierung von Inhalten durch die Manipulation eines DNSs. Die nächste Stufe ist, dass verschiedene Streaming-Devices, die wir heute haben, einen fest eingetragenen DNS haben und normalerweise immer den DNS eingetragen haben, wer der Hersteller dieser Streaming-Devices halt ist. Auch das möchte ich nicht. Ich möchte sehen, auf welche Seiten greift mein Streaming-Device zu. Das war auch mal sehr schwierig, weil man in diesem Streaming-Device keine Änderung des DNS vornehmen konnte. Auch nicht per DHCP. Aus diesem Grund habe ich damals DNS-Information, den Port 53 TCP UDP, halt einfach umgelenkt auf meinen eigenen DNS. Schon war ich ihm wieder im Bild. Im dritten Punkt, dass Filtern von Werbung und nicht jugendfreien Inhalten, das ist immer mehr Commodity geworden. Es gibt ein sehr interessantes Projekt, was auf dem Raspberry Pi läuft, das sogenannte Pi-Hole. Und das ermöglicht halt Werbung auszublenden und auch gewisse Inhaltskategorien, also hier zum Beispiel jugendfreie Inhalte, nicht jugendfreie Inhalte auszublenden. Und das ist halt auch ein legitimes Mittel, was genutzt wird. Das wird nicht nur von einer Installation, die ich zu Hause habe, ein Pi-Hole abgebildet, sondern auch durch professionelle Dienste, die einen Filter für Werbung und jugendfreien Inhalten darstellen. Und nichtsdestotus schlutz gibt es zum Schluss natürlich noch die Blockierung von Inhalten aufgrund von Copyright-Verletzungen. Das kriegt man ja auch immer wieder mit in der Presse. Es ist irgendwo eine böse Seite, die hat einen Domain-Namen und man möchte verhindern, dass dieser Domain-Name aufgelöst wird. Also wird sie normalerweise bei den ISPs in ihrem DNS-Resolver einfach unterdrückt und somit kann man die Seite normalerweise nicht mehr aufrufen. Ja, wenn man vom DNS-Resolver spricht, dann kann man Daten natürlich mitprotokollieren. Jeden Dienst, den ich im Internet nutze, versucht einen Namen aufzulösen, ob ich eine Webseite aufrufe oder meine E-Mail abrufen will. Immer ist hinter einem Service normalerweise ein Hostname abgelegt und dieser Hostname will ausgewertet werden oder gesehen werden. Und deswegen hat die Internet-Engineering-Task-Forge schon relativ früh gesagt, dass sie es nicht viel gut hält, wenn Daten gemonitort werden. Denn daraus kann man ein Profilbild abbilden, man kann Leute aushorchen und so weiter und sofort. Das Ziel ist eigentlich, dass man nur ein minimalistisches Monitoring durchführt. Minimalistisches Monitoring heißt nur zu technischen Zwecken und nicht für Werbung, Marketing oder Ähnliches halt. Ja, auf dieser Basis halt, wie kann man die Privatsferse im DNS halt gewährleisten, sind verschiedene Verfahren ins Spiel gekommen. Und wenn man so guckt, das hat sich regelmäßig immer im Abstand von ein bis zwei Jahren wirklich entwickelt, dass man gesagt hat, wir möchten mehr Privatsphäre im DNS und man hat verschiedene Formen eingeführt, wie man diese Privatsphäre halt auch erhalten kann. Wir gucken uns gleich diese Verfahren an, wie sie funktionieren. Das Erste ist die Namensauflösung. Wie funktioniert die Namensauflösung? Ich hatte schon erwähnt, sie funktioniert rekursiv und das ist hier in diesen Schritten von eins bis acht dargestellt. Es wird versucht erst mal hinten die Top-Level-Domain aufzulösen. Das heißt, ich gehe an den DNS-Server, der die Com-Domain hier auflösen kann. Dann versuche ich die Example aufzulösen und ganz zum Schluss versuche, den Hostname noch aufzulösen. Man sieht hier sehr schön, wie ich hier eine rekursive Auflösung durchführe. Und wie man sieht, wird die Anfrage aber hier immer als Full-Qualified-Domain-Name weitergegeben. Also jeder, der Resolver, der hier mit dem Boot ist, sieht den kompletten host.example.com. Und das ist ja eigentlich nicht schön. Und aus diesem Grund wurde im ersten Schritt ein Verfahren aufgebaut. Das heißt, es wird nur die Information an den aufzulösenen DNS-Server gegeben, die wirklich nötig ist. Also der Top-Level-Domain sieht nur kommen, dann kommt der Domain und dann kommt eben die Hostname. Das heißt, wir sind hier sparsamer mit unseren Daten unterwegs. Ja, die Betreiber eines DNS-Resolvers, wer ist das? Ja, das sind normalerweise unsere Internet-Service-Provider. Wir hatten oben in der Folie schon gesehen, dass unser Router halt normalerweise vom Internet-Service-Provider DNS-Resolver vorgegeben wird und zum größten Teil weit mehr als 90 Prozent nutzen den halt auch. Und der Internet-Service-Provider kann natürlich diese Daten protokollieren. Er weiß, welche Seiten, welche Dienste der Nutzer aufgerufen hat. Und kann diese Information auch schön an Werbetreibende weitergeben, um einfach das Verhalten der Nutzer auszuwerten. Also sollte man sich bewusst sein, jeden Dienst den man nutzt, nutzt ein DNS und damit ist das Verhalten ja protokollierbar und auswertbar. Es gibt einen weiteren Schritt, um die Privatsphäre im DNS halt noch ein bisschen sterfer zu führen. Hat aber auch ein Vorteil, dass wir eine schnellere Antwortzeit haben. Wir holen die sogenannte Route Zone, die transferieren wir uns auf unseren lokalen Resolver. Wir haben also eine lokale Kopie der Route Zone vorhanden, sodass wir uns nachher beim Auflösen der eigentlichen Top-Level-Domain einen Schritt sparen und eine Antwortzeit, die nah von 0 Millisekunden halt ist. Also aus unseren acht Schritten einen Hausnamen aufzulösen, werden nur noch sechs. Ja, wir werden Namen aufgelöst. Wir sehen hier die verschiedenen Phasen, wie sich das über die Jahre entwickelt hat. Und man sollte bitte achten auf die Jahreszahlen. Wir sind 1983, 1987 mit dem Standard DNS. Der wird DNS over 53 genannt. Das ist halt für Port UDP TCP 53 benannt. Da sind wir eigentlich mal mitgestartet. Und es hat über 15 Jahre gedauert, bis man den nächsten Evolutionsschritt im DNS gemacht hat, nämlich durch die Einführung Dundun DNS Sec in 1999. Und dann sieht man aber, dass regelmäßig 2016, 2018, 2020 das Thema DNS immer mehr an Fahrt aufgenommen hat und es wurden immer mehr Verfahren entwickelt, wie man halt Namen im Internet auflösen kann. Wir gucken uns diese einzelnen Verfahren mal im Detail an und versuchen für uns auch mal zu bewerten, welche Vornachteile haben diese Verfahren und wie kann man seine Privacy, wie kann man ja sicher sein, dass der DNS-Information, die man auch bekommt, wirklich valide sind. Der erste Schritt, das Standard DNS, DNS über den Port 53 TCP UDP, normalerweise wird ein UDP-Paket versendet und man fragt halt an seinen DNS-Server, fragt man halt ab, bitte lösen mir bitte mal den Namen auf. Und wie wir sehen, das ist eine UDP-Information, da ist keine Verschlüsselung, nichts. Die Pakete werden auch nicht mit Checksumfer versehen. Jeder kann hier jeder Zeit die Information fälschen, verändern, blockieren oder auch im schlimmsten Fall redirekten auf einen schlechten DNS-Server, der dann falsche Informationen gibt. Und dann landet man zum Beispiel nicht auf der wirklichen Seite www.meinefirma.de, sondern von einem Etecker auf der Webseite. Also sind wir hier eigentlich, ja das ist zwar ein Modell, womit man sehr schnell Namensauslösung machen kann, aber es ist komplett ungesichert. Und wenn wir das einfach mal sehen, der Standard DNS ist einfach zu blockieren, der ist einfach umzuleiten, der kennt keine Verschlüsselung und jeder der in der Kette drin ist, kann das mitprotokollieren und kann es manipulieren. Da, gegen allerdings, hat man sehr, sehr schnelle Abfragen, verlüssen normalerweise in den Regelfall ein UDP-Protokoll ist und dadurch sehr, sehr schnelle Abfragen möglich sind. Ja, dieser einfache DNS kann ja modifiziert werden und das wird ja auch. Es gibt hier bei uns in Deutschland eine Klierenstelle Urheberrecht im Internet und die verfügt halt auf Antrag, dass Einträge von Webseiten im DNS halt ja modifiziert werden oder ausgeblendet werden, sodass man diese Webseiten nicht mehr aufrufen kann. Das ist also ein erster Schritt in die Richtung, wo man eine Art Manipulation durchführt. Mich wundert das, dass eine Privatorganisation solche Aktionen durchführen kann, die Art Zensur durchführt. Das ist das, was ich eigentlich nicht sehe. Ich fordere eigentlich, dass ein DNS frei ist, dass jeder den gleichwertig nutzen kann und dass es hier nicht einfach zu einer Manipulation kommt. Schade ist, dass diese Klierenstelle leider auch von allen großen ISPs und den verschiedenen Rechteinhabern unterstützt wird, sodass man schon ein ganz großes Potential hat, dort überhaupt gehört zu werden. Wir sehen aber auch, im Wikipedia ist mittlerweile ein Eintracht, wie viele Sperren durch DNS halt durchgeführt worden. Da kennt man die verschiedenen Streaming-Portale oder illegalen Streaming-Portale, die halt durch einswillige verfügungen im DNS halt ausgeblendet werden sollten. Und das geht halt beim DNS Overport 53 relativ einfach, weil hier DNS-Einträge nicht verifiziert werden. Ja, im nächsten Schritt hat man gesagt, ich möchte, dass DNS-Einträge nicht mehr, ja oder ich möchte wissen, ob ein DNS-Eintrag valide ist oder nicht valide ist. Deswegen hat man mit DNS-Sec eine Schlüssel-Situation eingeführt. Das heißt, jeder Information wird signiert und man kann feststellen, ob ein Eintracht manipuliert wurde oder nicht manipuliert wurde. Ist ein Verfahren, was sehr stabil läuft, allerdings von vielen immer noch abgelehnt wird, weil die Verwaltung im DNS-Sec von Zonen oder Kiewechseln noch sehr aufwendig sein sollte. Ja, das war am Anfang wirklich einfach so, weil die Software halt noch nicht dementsprechend war, aber mittlerweile funktioniert das Signieren von DNS-Sec Zonen eigentlich automatisiert und sehr zuverlässig. Und wenn man DNS-Informationen halt ja signiert hat, dann kann man auch davon ausgehen, dass sie nicht manipuliert werden können und man kann dann auch verschiedene weitere Sicherheitsdienste darauf aufbauen. In Dane ist zum Beispiel eine dieser Implementierungen, die dann möglich sind. Das heißt, Zertifikate werden durch eine Check-Soman noch mal im DNS abgelegt und man kann halt überprüfen, ob Zertifikate auch noch mal gültig sind. Ja, dann ist man noch mal ein Schritt weitergegangen und hat gesagt, ich möchte nicht nur, dass die Einträge halt durch eine Signatur abgesichert werden sind, sondern ich möchte den Transportweg dahin verschlüsseln. Das ist natürlich gut, dann kann keiner mehr dort reingucken, ist keiner das Ganze mehr monitoren, eigentlich eine gute Idee. Aber als erstes, was ist passiert, man hat den Port 853 ausgewählt, also einen anderen TCPIP-Port ausgewendet, der wird einfach von den Providern gesperrt und schon muss man wieder auf den normalen DNS-Dienst zurückgreifen, dem wir wissen, dem Transportweg nicht verschlüsselt ist. Und außerdem hat man ein weiteres Thema in dem Bereich, dass die Verschlüsselung nur opportunistisch ist. Das heißt, ja, es ist schön, wenn man Verschlüsselung hat, es muss aber nicht sein. Und wenn ein Ertecker dazwischen ist, der kann natürlich ganz klar sagen, ich möchte keine Verschlüsselung haben und schon ist man wieder unverschlüsselt unterwegs. Viele haben auch gesagt, ja, die Auflösung von DNS-Informationen über eine verschlüsselter Verbindung ist vielleicht langsamer. Ich habe eine röhre Roundtrip sein, ich habe vielleicht auch mehr CPUs, die ich brauche. Das sind so diese negativen Sachen, die dort im Raum standen. Und dann ist man auf die geniale Idee gekommen und hat gesagt, Mensch, bei DNS over TLS haben wir das Problem, dass wir einen separaten Port benutzen können. Warum das? Machen wir doch einfach, wir nutzen einfach den Standardport, den wir für HTTPS benutzen. Und dann hat man halt DNS over HTTPS implementiert. Das heißt, der komplette DNS-Traffic wird HTTPS verschlüsselt übertragen. Er wird mit dem normalen HTTPS-Traffic ja vermischt, sodass man DNS-Abfragen und HTTPS-Abfragen gar nicht mehr voneinander unterscheiden kann. Und den Port 4v3, den kann man auch nicht ohne weiteres mal eben abklemmen, weil sonst würde man keine Webseiten mehr aufrufen können. Also eigentlich eine sehr, sehr gute Ausgangssituation dafür. Das Ganze wird natürlich auch noch mit TLS-1.3 verschlüsselt. TLS-1.3 hat auch den Vorteil, dass man nur sehr, sehr schwerlich mitten in den Mittelattacken durchführen kann, weil TLS ist nicht ermöglicht, normalerweise einen verschlüsselten Tunnel wieder aufzubrechen. Und längere Zeit galt auch die Sache, hat man auch gesagt, DNS aber HTTPS, dieser Traffic, der HTTPS-Traffic und DNS-Traffic könnte nicht identifiziert werden. Es gab allerdings im November diesen Jahres, gab es eine Studie und dort hat man, indem man die Pakete analysiert hatte, die in diesem gemixten und vermischtem Streamhalt waren, hat man analysiert mit Machine Learning und daraus konnte man halt feststellen, dass in normalen HTTPS-Paketen auch DNS-Daten halt vorhanden sind. Ja, auch hier gilt natürlich die Sache, ich füge eine weitere Verschlüsselung ein, ich füge hier die Z-Ficcate ein, ist das nicht alles langsamer, brauche ich nicht mehr CPUs und wie sieht das überhaupt aus. Aber eine ganz wichtige Sache ist halt vielleicht noch, wenn ich einen Split-Fluid haben möchte, wir haben das oben gelernt, wir haben eine interne Sicht von Hostnamen und eine externe Sicht. Wie kann ich das damit abbilden oder kann ich das überhaupt abbilden? Ja, man hat das Protokoll noch mal verfeinert, statt über das normale HTTPS-Protokoll zu gehen, greift man noch mal auf das Quick-Protokoll zu, Quick-Protokoll gleiche Art und Weise wie es funktioniert, wie HTTPS, nur ist der ganze Handshake, der durchgeführt werden muss, bei den Verbindungen halt erheblich verkürzt. Quick ist ein Protokoll, was von Google initiiert wurde, aber mittlerweile auch standardisiert ist und man sieht hier halt der Grafik, die die Kollegen von Cloudware zu verführen gestellt haben, dass der Handshake wirklich viel viel schneller ist und dadurch man, ich sage mal, durch die ganze Verschlüsselung nicht so viele Millisegund an Anforderungszeiten hinzubekommen. Nächste Stufe ist, indem man verschiedene DNS Proxies implementiert. Das nennt sich Oblisches, DNS over HTTPS, ein riesenlanger Name, aber was passiert denn da? Wir haben auf der linken Seite haben wir wieder unseren Client, also unser Endgerät, das macht über den Port 443 eine DNS-Abfrage und diese DNS-Abfrage wird nicht sofort an den Resolver weitergeleitet, sondern sie kommen erst mal in einen Proxy und in diesem Proxy werden alle Anfragen von allen Endgeräten, die es so gibt, vermischt und aus diesem Proxy, da sind die an Benutzer praktisch anonymisiert, werden die eigentlichen Anfragen an die DNS-Server im Hintergrund gestellt. Das heißt, man hat eine Mehrschichtigkeit, sodass hinten man nicht feststellen kann, welcher Kunde hat welche Seite aufgerufen. Und die beiden Bilder mit der Kampine da oben drüber zeigen auch, dass die zwei unterschiedliche Organisationen sind, die für diesen Proxy und einmal den Target Resolver verantwortlich sind, sodass man auch, ja, sie sich nicht gegenseitig austauschen können und da braucht eine Rückverfolgbarkeit des Benutzers und dessen Verhalten dargestellt werden kann. Ja, wie gesagt, mehrstufiges Protokoll, Proxy und ein Target dazwischen und der Erster, der diesen Gedanken aufgenommen hat, diese Idee aufgenommen hat und darauf ein Service gebaut hat, ist Apple. Man kann ein Feature dort buchen bei Apple mittlerweile, das nennt sich Private Relay und mit diesem Private Relay bekommt man halt ein obwisches DNS over HTTPS. Also meine Aufrufe im DNS können nicht rückverfolgt werden und man kann auch nicht sehen, was ich gemacht habe. Man hat aber jetzt festgestellt, nachdem Apple dieses Feature freigeschaltet hat auf seinen Geräten, dass verschiedene Punkte halt noch offen sind. Es gibt kein Quality of Service mehr, weil ganz viele DNS-Abfragen ja von ganz vielen Usern vermischt werden. Das sogenannte Zero Rating, das was bei der Telekom als Stream On oder Vodaporn passt gilt, dass man halt gewisse Dienste ohne Anrechnung auf seinen Datenvolumen nutzen kann, funktioniert nicht mehr und es ist auch nicht mehr möglich eine Filterung von Werbung und jugendfreien Inhalten zu machen, weil man nicht mehr auf den DNS-Resolver des ISPs oder einer anderen Institution zurückgreift. Also letzte Evolutionsstufe und die wir gleichzeitig als bei Apple als Servicegedanke aufgenommen. Ja, das was ich gerade gesagt habe, ist hier noch mal einer Tabelle aufgeführt. Wir sehen in dem oberen Bereich die klassischen DNS-Protokolle. Da sind viele Punkte mit Rot dargestellt. Das heißt, sie sind nicht so komfortabel, was Privatsphäre angeht. Sie können auch ja verändert werden und die neueren Protokolle kommen halt immer mehr dazu hin, bessere Verschlüsselung, bessere Anonymität und bessere Privatsphäre halt. Ja, schlagen wir noch mal das Thema Geschäftsmodell-Namensauflösung. Wo findet das eigentliche Geschäft der Namensauflösung statt? Natürlich in der Protokollierung und Auswertung durch den ISP oder Werbetreibende, aber auch wenn wir bei DNS over HTTPS reden, Konzentration auf wenige und auch diese wenigen großen Cloud-DNS-Provider können protokollieren und auswerten. Und natürlich versucht man diese großen Cloud-DNS-Provider zu beeinflussen. Wir haben hier die Geschichte von der Quad9, wo hier in Deutschland Sony Music erfolgreich gegen Quad9 geklagt hat und Quad9 halt den DNS manipulieren musste. Und das Geschäftsmodell funktioniert auch weiterhin um kostenpflichtigen Dienst anzubieten, wie Apple das macht und Insiderkreise sprechen mittlerweile nicht mehr von dem Browser-Krieg, welcher Browser ist der beste, sondern über den DNS-Krieg. Und deswegen möchte ich meinen Vortrag schließen, wenn nicht ein DNS-Resolver man nutzt, man sollte sehr umsichtig sein und wissen, welche Technologien er unterstützt. Vielen Dank. Vielen Dank, Jörg. C3 News einblenden, der heute Morgen um 11 Uhr rauskam und danach geht es dann mit der Q&A-Session weiter. Okay, Entschuldigung, wir machen erst das Q&A und danach kommt der C3 News. My apologies. Okay, genau, wir haben ziemlich viele Fragen bekommen. Genau, ich gese einfach der Reihe nach durch. Ein lokaler DNS bietet die Möglichkeit, ungewünschte Anfragen zu blockieren und Namen für lokale Dienste aufzulösen. Ist dies kein sinnvoller Einsatz für lokales DNS? Also, einen jokalen DNS aufzusetzen ist immer sinnhaft. Das finde ich sinnvoll, das auf jeden Fall zu machen. Das würde ich immer wieder bevorzugen. Ich, als jene, der einen privaten DNS-Resolver aufsetzt, hatte immer den Vorteil, ich habe das unter Kontrolle. Ich weiß, was mitprotokolliert wird. Ich weiß, ob die Einträge valide sind. Deswegen befürworte ich, dass auf jeden Fall einen privaten DNS selber aufzusetzen. Das ist, glaube ich, auch eine Möglichkeit, dann den Port 53, wie du sagst, umzuleiten und dann auf seinen lokalen DNS. So ein Piehole, der auf dem Raspberry läuft, ist auch für Endanwender halt relativ einfach zu konfigurieren und hat viele Möglichkeiten. Der unterstützt auch die neuen DNS-Protokolle. Also kann ich nur ermootingen, sowas einfach zu nutzen. Dazu gab es auch eine Frage. Heißt das, dass ich meinen Piehole in Zukunft als hyper-local-root betreiben soll? Ja, das ist möglich. Man kann den Piehole so umkonfigurieren, dass er sich die Route-Zone regelmäßig holt und dann praktisch mal einen hyper-local betreibt bei sich zu Hause. Gibt es weitere Fragen? Gibt es Informationen, was die Provider mit den Logs von DNS-Anfragen der Kunden machen? Können diese Informationen von denen weiter genutzt, weiter verkauft werden? Also mir liegen direkt keine offiziellen Statements der Provider dazu. Allerdings weiß ich natürlich aus guten Quellen, dass das halt passiert und dass das ein Geschäftsmodell halt ist. Gibt es neben Mozilla und Chrome weitere Anzeichen, ob DNS-Abfragen auf Applikationsebene zur Umgehung von Werbeblockern zum Beispiel Piehole bereits genutzt werden? Also man sieht immer mehr Applikationen, die auf einen eigenen Resolver zugreifen wollen, aber es ist halt noch nicht so standardisiert, dass jetzt viele Applikationen darauf aufspringen. Also ich glaube, das ist noch eine Entwicklung, aber es wird massiv zunehmen meines Sachens nach. Und da hatte ich auch eine Frage zu, wie kann ich das sehen, wenn ich jetzt beim Brausen bin und ob die Webseite dann letztlich ihren eigenen DNS da benutzt oder nicht? Ja, beim Chrome ist es schwierig, da ist es nicht transparent. Beim Firefox gibt es Add-ons und die Add-ons zeigen halt, wie die DNS-Auflösung funktioniert hat. Hat sie über DNSsec mit HTTPS funktioniert, da kann man das halt sehen und sich anzeigen lassen. Aber bei allen anderen Brausern wird das ein wenig verschleiert, weil die Brauserhersteller natürlich auch ein Art Geschäftsmodell dahinter sehen. Ja, danke. Gibt es deine Folien zur Präsentation zum Unterladen? Natürlich. Der Talk fragt nach DNS als neues Geschäftsmodell. Nur gab es hier, wie du auch angesprochen hattest, das Urteil des LGH gegen Quad 9 und der eben DNS als Geschäftsmodell hat. Dieser soll damit verpflichtet werden, bestimmte Media-Serververteilung von der DRM-geschützten Inhalten von Dritten nicht mehr aufzulösen zu blockieren. Was denkst du über dieses Urteil? Ich finde, es dürfen Daten nicht manipuliert werden oder zensiert werden. Deswegen finde ich, das ist das der falsche Weg. Und es gibt ja auch eine Spendenaktion für Quad 9, damit rechtlich dagegen vorgegeben kann und damit diese Sperren wieder aufgehoben werden kann. Einfach mal im Internet gucken und einfach mal Quad 9 unterstützen. Quad 9 ist einer der DNS-Provider, die ein offenes Modell fahren, die transparent sind, die auch extra deswegen von die USA in die Schweiz gegangen sind, damit sie das halt auch fahren dürfen. Und ich finde es wichtig, dass wir das unterstützen. Gibt es Empfehlungen für DNS-Filter im Organisationsumfeld bei Firmen? Womit man zum Beispiel bekannte Mailware-Domains auf DNS-Ebene blockieren kann? Ja, gibt es verschiedene Seiten im Internet, wo man sich Listen runterladen kann und in seinen DNS integrieren kann. Es ist natürlich immer schwierig, solche Listen zu bewerten, wie gut oder schlecht sind die, aber die gibt es ja. Welche ist die beste Methode, die lokale DNS Entries von meinem ISP zu bekommen, damit ich rausfinden kann, welche Domains zensiert sind? Schwierig festzustellen, was zensiert ist oder nicht zensiert ist. Wenn eine Domain mit DNS-Sex signiert ist, dann kann man das feststellen, dass sie modifiziert wurde, aber sonst wird es sehr, sehr schwierig zum Teil, das rauszufinden. Was ist Danke? Was ist die Motivation der ISPs, den Port zu blocken? Und wie verbreitet ist das in Deutschland? Das ist genauso, als wie man vor nicht allzu langer Zeit den Port 25 für ausgehende E-Mails blockiert hat und genauso ist das auch im DNS-Bereich. Das findet das. Und letzte Frage, welcher öffentliche DNS-Server ist das geringste Übel? Lautflair? Nein, ich würde sagen, es gibt von Freifunk München eine DNS-Resolver-Infrastruktur, die man nutzen könnte und die man nachher mal ausprobieren sollte. Ja, da ist man, das kommt aus dem Bereich der Freifunker, das ist alles offiziell dokumentiert, man kann sehen, was sie machen, es wird nichts protokolliert. Das wäre eine wirkliche Alternative. Vielen, vielen Dank, ihr Jörg Baxus.