 Leise findet einen freien Platz, weil der Vortrag fängt jetzt an. Es geht um die Domain Name System, ein hierarchisches dezentralisiertes Namensystem, das in den letzten 30 Jahren benutzt. Das ist von Hannet Minat, der bei TLS und OTA mitarbeitet und Kaffeemark, oder ein Kaffeennert ist. Eine große Runde Applaus, bitte. Danke. Danke. Ich bin Hannes und ich möchte über den Domain Name System reden. Das ist ein Teil des Grundlagen Tracks auf diesem Hier. Wenn ihr schon viel über den S wisst, dann werdet ihr wahrscheinlich nichts Neues lernen und wenn ihr schon einiges wisst und wenn ihr noch nichts wisst, dann hoffe ich, dass ich es euch erkläre. Worum geht den S? Die Grundlage, nur das Ziel von DNS, ist Menschen lernbaren Hausnehmen, IP-Adressen zuzuordnen. Das ist das Einzige, was all DNS macht, das heißt im Endeffekt ist es ziemlich ähnlich zu einem Telefonenbuch. Vielleicht erinnert ihr euch an eine Sammlung von Papieren oder ein großes Buch, wo man Menschennamen suchen kann und dafür eine Telefonnummer zu finden für einzelne Städte. DNS ist nicht so statisch wie ein Telefonenbuch und ist dezentralisiert organisiert, das heißt wir können Updates viel schneller und häufiger einspielen. Wir haben ein dezentralisiertes und hierarchisches Abgleitungssystem, so dass Leute, die ihren Domain Name haben, ihren eigenen Eintrag ändern können und DNS wird in vielen Anwendungen benutzt überall im Internet. So, wir haben eine Kommandozahlen-Betriebssystem, das nennt sich Host, auf den meisten New Links Betriebssystemen und wenn man jetzt Hosts von, in diesem Fall Events.c.de eintippt, das ist die Hauptwebsite, dann kriegen wir eine Antwort von diesem Programm und dieses Programm benutzt DNS oder das Protokoll, worum dieser Vortrag geht und sucht einen Eintrag dafür. Natürlich können das natürlich auch schieflaufen, wenn der Name überhaupt nicht existiert, aber in diesem Fall wird Events.c.de einer IP-Adresse zugeordnet, 195, 54, 164 usw. Was macht DNS noch? DNS ist ein EETF, Internet Engineering Task Force, das ist die grundlegende Internet-Organisation in der Reihe von Anträgen spezifiziert, beginnt mit 10, 52, die die Grundlagen für das Protokoll, wie man Domain Names zu IP-Adressen umwandeln kann, gelegt hat. DNS hat sich in der Zwischenzeit weiterentwickelt, vielleicht, das könnt ihr hier sehen, und DNS ist heutzutage 20, 30, vielleicht sogar 40 unterschiedliche RFCs, also Anfragen für Kommentare. Im Endeffekt werden immer noch dieselben Grundlagen benutzt und da DNS in den letzten 30 Jahren benutzt wurde, die ganzen letzten 30 Jahre, vermute ich, dass wir es 50 weitere Jahre benutzen werden. Ich glaube, dass wir DNS nicht überleben werden. DNS wird immer noch da sein, wenn wir sterben, und das ist, weshalb DNS für mich wichtig ist. DNS ist ein dezentralisierter Daten-Key-Speicherort, der vor 30 Jahren spezifiziert wurden. Es gibt ein hierarchisches Namensystem und es benutzt Weiterleitung, Delegation, um einen dezentralisierten Aspekt zu beinhalten. Es hat integrierte Resonanz und integrierte Skashing in dem Protokoll selber. Lass uns mal anschauen, wie die Namen im DNS aussehen. Wir sehen einen Events.sdc.de und das Namensystem ist hierarchisch. Das heißt, es gibt ein Baumstruktur, wir haben eine Wurzel hier oben, alle Informatiker haben Bäume mit Wurzeln oben, und darunter haben wir die Top-Level-Domain, z.B. DE und ORG und weitere hoch-levelige Domains. Danach haben wir zweit-level-Domains, wie z.B. CCC oder viele andere, bei dem nicht schnell definierten Branch. Und darunter haben wir Events, den Events-Domain. Wir haben eine Baumartige Datenstruktur. Jeder Domainname, z.B. Events.sdc.de, hat eine Reihe von Labels oder Einträgen, die von Punkten, mit Punkten getrennt werden. Das DNS-Protokoll weiß, was ist der oberste Domainname. Dann haben wir eine zweitschichtige Domainname, z.B. CCC.de und dann haben wir die dritte Schicht Events.sdc.de. Jedes kann nur alphanomerische Buchstaben, A bis Z, 0 bis 9 und Minus beinhalten. Aber Minus darf nicht mit Minus anfangen. Die Länge darf nur zwischen 1 und 63 Charaktere lang sein. Der maximale Länge von der Gesamtlänge ist 253 Buchstaben lang. Events.sdc.de darf maximal 253 Buchstaben lang sein. Der Domainname ist nicht groß-kleinschreibungsabhängig. Das heißt, egal, wie er das schreibt, er kriegt immer die gleiche Antwort, wie man die groß-kleinschreibung setzt. Dein Klein, dein Computer, fragt einen Service und fragt da an, was ihr das haben möchtet. Da kriegt ihr einen Namen, den wir sehen, ein Typ und eine Klasse. Der Antwort beinhaltet dieselbe Information, den Namen, den Typ und die Klasse. Aber außerdem wird auch noch die Lebensdauer, die Länge und das Datenfeld übermittelt. Das Datenfeld wird unterschiedlich interpretiert, je nachdem, welcher Typ das Ganze hat. Der Zeit-Time-to-Lift ist die Anzahl von Sekunden, wie lang dieses Wert gecached werden darf. Das heißt, wir haben in die inkludiertes Caching und wie lange Caches gültig sind. Wir sind schon die unterschiedlichen Typen. Wir haben einen A-Adress, den haben wir gesehen. Das ist ein A-Record. Dann haben wir aber auch noch andere Typen, wie z.B. den Namesaver, der NS benannt wird und den Start of Authority, SOA. Die Klassen, die wir hier oben gesehen haben, ein Triple, wo wir den Namen und den Typ jetzt schon definiert haben, die das ist in der Regel Internet. Das Einzige, was wirklich benutzt wird in den heutigen Netzwerken. Aber es gibt noch andere. Dns, wo damals definiert wird, es gibt irgendwie so einen Chaos-Net, aber das wird einfach nicht mehr benutzt. Wie sieht ein DNS-Paket aus? Wir haben eine Anfrage, ein Request, das ist dieses Tripplet, Tripplet und die Antwort ist eine Liste von diesen Tripplet und die anderen Daten. Den DNS-Paket hat einen Helder, der 12 Beiz groß ist. Das ersten zwei Beiz ist eine Transaktions-Idee-Nummer, es sendet ja kleint einfach an den Server. Dann haben wir 16-Bits, die Flags, Operationscode und Rückgabewerte beinhaltet und dann haben wir vier, zwei Belt, vier Ilder, die die unterschiedlichen Anzahl von Fragen und Antworten beinhaltet und die Fragen von Zusatzinformationen. Danach haben wir beliebig lange Felder mit diesen Dingern, also eine beliebige Anzahl von Fragen, also dieselbe Anzahl, wie oben definiert, die Antworten, die Autoritäten und dann zusätzliche Informationen. Jedes dieser Fragen ist dieses Tripplet und alle anderen Felder ist diese ganze Struktur. So, wie sieht jetzt, wir haben ein Host-Befil gesehen. Jetzt haben wir einen anderen Befehl, der nennt wir DIC, der wird benutzt, um die Backinformation oder um sich den S-Paket näher anzuschauen. Wenn ich jetzt in mein Laptop DIC von A, der Anfragetyp A, das heißt ich möchte herausfinden, welcher IP-Adresse hinter events.cc.de steht. Das ist ein A-Record, das heißt ich möchte den Adress Informationen bekommen und ich frage jetzt mich meinen normalen Domain-Server, sondern diesen spezifischen, das ist dieser ns.cccv.de, das ist ein autorativer Nameserver für diese Domain. Dann kriege ich diese Antwort zurück. Also das ist eine Texterklärung, die ich benutze aus dem S-Protokoll im Hintergrund und hier sehe ich die Antwort zurück. Zuerst kriege ich noch mal eine Kopie der Anfrage, events.cc.de, ich frage nach Internetadressen und ich benutze den Typ A, das heißt ich möchte ein Adress-Record haben. Außerdem kriege ich eine Antwort, events.cc.de, um 600 Sekunden Dauergültigkeit, der Klasse ist in, der Typ ist A und dann kommt der wirklich hier Inhalt, und das ist dieser IP-Adresse, die wir früher schon gesehen haben. Dann kriege ich zusätzliche Informationen, autoritative Sektionen, kriege ich welche Nameservices verantwortlich sind, das heißt für events.cc.de kriege ich auch eine Überlebensdauer und dann ein Nameserver-Antrieb, das ist eines ns.cccv.de und der andere ist ns.cc.de. Dann kriege ich noch zusätzliche Informationen, hauptsächlich das ns.cccv.de, auch eine IP-Adresse hier unten. Okay, also wie funktioniert diese Delegation? Wie funktioniert dieses System? Okay, also zuerst müssen wir den Nameservice aufsetzen für eine spezifische Domain, das heißt man muss in diesen Nameserver einen bestimmten Eintrag einfügen und ein Start of Authority Record, also ein Eintrag für die Subdomain, die man eintragen will, die muss man in die Domain zuerst dazu gehört eintragen. Das bedeutet, man muss da eintragen, dass jetzt mein Nameserver für diese Unterdomains zuständig ist. Jetzt schauen wir uns diesen SOA Record Type genau an. Also Start of Authority beginnt der Autorität im Antwortteil, da kommt events.cc.de, dann die Gültigkeit, Typ und Start of Authority. Da drin ist das erstes, der Nameserver, wo die Informationen herkommt, dann die E-Mail Adresse, wo das erste Add, da ist stattdessen ein Punkt drin, das ist die E-Mail Adresse, die dafür verantwortlich ist für diese Zone und der Start of Authority hier ist sehr hoch und darunter dann die Zeiten, zu denen diese Information neu geladen werden soll. Wenn man dann fragt, was sind die Nameservers von events.cc.de, wir haben das vorher schon in der Autoritäts-Section gesehen. Also in der Antwort kriegt man dann zwei Nameservers zurück und in den zusätzlichen Informationen steht die IP Adresse. Also wir haben jetzt Servers, Servers haben Delegation, also Delegations und da gibt es eine Wurzel dazu und die gehören zu IANA und die wissen, was die Wurzel Nameservers sind. Wie funktioniert diese Auflösungs-Service, beschwore es jetzt den iterativen an. Also das Kommando dazu oder die API dazu heißt gethostbyname und wenn wir da fragen nach events.cc.de, dann sendet da eine Anfrage an diesen Auflösungs-Service und wir fragen nach dem Typ A und nach der Domäne events.cc.de. Was tut dieser Auflöser jetzt? Wenn jetzt dieser Auflöser gar nichts weiß außer wo die Wurzel Nameservers sind und dann fragt er den Wurzel Nameserver, wer ist verantwortlich für die DE Wurzel Nameservers, der sendet zurück ein paar Nameservers, dann fragt der Auflöser einen dieser Nameservers, wer ist verantwortlich für zc.de, dann kriegt der andere Nameservers zurück und dann fragt der einen von denen, wo ist der A-Eintrag von events.cc.de, dann kriegt der Auflöser die IP-Adresse zurück und schickt sie zurück an den Client. So funktioniert die iterative Auflösung von domains. Euch wird aufgefallen sein, dass es da eine ganze Menge Pakete von dem Auflöser zu verschiedenen Hosts ging und diese Hosts haben nur Namen und keine IP-Adressen hier, also woher weiß der Auflöser das, wie man die erreichen kann. Und die Lösung ist, das sind Glue, also, falls die Nameservers ist innerhalb der, der Nameserver für cc.v.de ist auch verantwortlich für names.cc.de, dann muss er auch dazu sagen, wo, was die IP-Adresse von diesen Nameservers ist. Und dadurch ist es möglich, dass der Auflöser weiß, wie man ihn fragen muss. Die iterative Auflösung, die ich jetzt da gerade gezeigt habe, hat Query Name Minimization, also Abfrage, Fahrtminimierung verwendet und das ist ein Privatsparen-Feature. Und zwar haben wir nicht an den Rootserver die gesamte Adresse geschickt, sondern nur die Top-Level-Domain, also.de, nach der wir gesucht haben. Einige Auflöser haben dieses Feature. Das ist ein Privatsparen-Feature, weil, wenn wir das nicht haben, dann würden wir den, dann wüsste der Rootserver genau, wo wir, welche Adresse wir versuchen aufzulösen. So, wie sieht caching aus? Also, jeder Auflöser bekommt diese Gültigkeitsdaten und kann dadurch diese Daten caching und kann die dann verwenden in späteren Anfragen. Also, der Setup sieht normalerweise so aus. Ich habe hier mein Laptop, dann habe ich meinen Rootserver. Da ist ein weiter leitender Auflöser und der schickt einfach alle Anfragen direkt weiter, zum Beispiel zu dem ISP gehört, also dem Internet-Service-Anbieter. Und der fragt dann die Nameservices, die Autorität haben. Das ist ein ganz typischer Setup hier. Die Alternative ist, dass eben mein Brouter nicht den ISP nachfragt, sondern einfach direkt die iterativen Anfragen stellt. Also, es gibt mehr als nur die drei Rekord-Die-Eintragstypen, die ich gerade gezeigt habe. Also, ein paar Praktische, die wir häufig verwenden. Zum Beispiel gibt es eine Art, wie man aliases, also, zweitnahmen sozusagen einführen kann. Also, zum Beispiel kann man eine Weiteleitung anrichten von fu.example.com mit dem CNAME-Typ. Und jetzt, unabhängig von dem Resource-Rekord-Type, nach dem wir gefragt haben, mit diesem CNAME-Entry wird diese Weiteleitung eingerichtet. Also, von fu.example.com kriegen wir dann bar.example.com. Mx ist ein anderer Typ für E-Mail. Und dann gibt es noch die Vierfach-A-Einträge, die sind für IPv6, also für so ein 6.IP-Protokoll Adressen. Also, einfach für IPv4 und vierfach für IPv6. TXT ist für Textdaten, das für eine ganze Bandbreite von Protokollen wird verwendet. EDNS ist ein Erweiterungsmechanismus. Das bedeutet, innerhalb von dem Protokoll gibt es ein Erweiterungsmechanismus, was sehr interessant ist und ziemlich schön. Weil diese Protokolle, die werden über Zeit verwendet. Und was immer ganz wichtig ist, dass man rückwärtskompatibel ist, weil es einfach wahnsinnig viele Auflöser da draußen gibt. Und deswegen, was man auf jeden Fall vermeiden will, ist eben, dass es zu incompatibel ist, die Pelt kommt. Und DNS wurde vor langer Zeit entwickelt. Und ab nächsten Jahr soll EDNS flächendeckend akzeptiert werden. Okay, also Transport. Also DNS wird über UDP verschickt. Man kann das auch über TCP verwenden. Das ist normalerweise für, wenn die Antwort zu groß ist für UDP. Wenn es zu groß ist, dann wird es eben abgeschnitten nach, sagen wir, 512 bytes. Und in dem EDNS-Header würde dann stehen, oh, diese Antwort ist abgestellten. Und dann muss der, der die Nachfrage gestellt hat, eben nochmal nachfragen. Für TCP muss man eben eine ganze TCP-Sitzung aufbauen. Für TCP ist es ganz ähnliches, ganz ähnliches Format, nur dass da ganz am Anfang die Gesamtlänge des Pakets besteht. EDNS kann auch die maximale Größe des UDP-Pakets mit schicken. Okay, noch etwas mehr zu EDNS. Also, wenn man eine zweite Leveldomain einrichten möchte, dann muss man mindestens zwei Nameservers haben, die die Autorität haben, die in unterschiedlichen IP-Netzwerken laufen, damit man Redundanz hat. Das liegt daran, dass eben einer von den zwei immer ausfallen könnte. Und dann muss es eben einander geben, damit Clients immer diese Adresse auflösen können. Und wenn wir jetzt mehr Instanzen dieser Daten haben, dann, also, es gibt einen Zontransfer in dem Protokoll selbst. Dieses Zontransfer verwendet Seriennummern, um herauszufinden, ob ein Zontraffer überhaupt nötig ist. Und verwendet dafür auch ein Teil der Timer in dem Start of Authority. Auf die Seite können wir eben Synchronisierung und auch Redundanz haben. Also, wir können auch dynamische Updates machen, damit wir nicht jedes Mal unsere Server neu starten müssen, wenn wir sie neu konfigurieren. Also, zum Beispiel kann man dann sagen, bitte füge diese Domainnummer mit dieser IP-Adresse hinzu oder entfernen sie. Also, für die Synchronisierung haben wir diese Timer und es gibt auch einen Benachrichtigungsmechanismus. Also, der primäre Server macht die dynamischen Updates und benachrichtigt den zweitrangigen Nameserver. Übrigens, die Seriennummer meines Eintracks hat sich erhöht. Bitte update deinen Eintrack auch. Und wenn man eben diese Updates machen kann, dann soll das nicht jeder können. Dafür gibt es eben Authentifizierungsmechanismus. Da ist T-Sync und verwenden normalerweise einen H-Mark Geheimnis. Und das muss eben im Vorhinein geteilt sein mit dem Server. Oder man kann Diffy-Hermann-Schüssel-Austausch verwenden. Man kann DNS verwenden, um es für Low-Band singen. Wenn man mehrere Adressen für den gleichen Namen einträgt, dann wird der Nameserver die zurückgeben, aber in einer zufälligen Reihenfolge. Und der Klein kann dann sich raussuchen, welcher davon nimmt. Das kann der erste nehmen oder viele an zufälligen. Und das heißt, wenn man zwei Einträge hat für den gleichen Domainnamen, dann ist die Wahrscheinlichkeit, dass etwa die Hälfte der Clients die eine Adresse fenden und die andere Hälfte, die andere Adresse, ist ziemlich hoch. Das nennt man auch DNS Round Robin. Weitere DNS Features. Wir haben noch ein paar DNS Features, die noch nicht notwendig sind. Wir haben dieses DNS-Sech, dass auch nur die Informationen zwischen dem autoritiven Resolver und dem autoritiven Nameserver absichert. DNS wird auch in Multicast-Situationen für Service Discovery benutzt, wie zum Beispiel Rondeau oder Seroconf. Das ist auch DNS-basierend. DNS kann auch Internationalisierung verwenden. Man kann internationalisierte Top-Level Domains benutzen. Für den benutzen wir ein Punicode in Kodierung. Was sind Angriffe auf DNS? Das sind Herausforderungen. Das eine ist Zensierung. Jeder, der ein DNS-Taball laufen lässt, kann nach Domainnames filtern. Oder wenn der DNS-Resolver das Kunden, wie zum Beispiel der von Google oder der von AT&T oder von CloudCloud, die können im zentralen Punkt herausfiltern, welche Domainnames nicht weitergegeben werden, welche sie nicht weitergeben wollen. Sie können zum Beispiel keine Antwort für Domainnames geben, die sie nicht mögen. Zum Beispiel LibGen.org, LibraryGenesis ist einer von diesen problematischen Seiten. In manchen Ländern gibt es auch Menschen oder manche Regierungen, die wollen gewisse Webseiten filtern und sie machen das dadurch, dass sie die Internet-Service-Provider zu zwingen, gewisse Sachen zu filtern oder diese Domainnames zu filtern. Da DNS standardmäßig ist es möglich, dass ein Angriff im lokalen Netzwerk einfach eine Antwort mit vielen, also einfach viele Antworten senden und vielleicht ist er dann auch mal schneller als anderer. Das heißt, diese kleine Ringe-Entropie, wir haben nur 16 bits im Header als Transaktions-ID und außerhalb kann man wenn ein bisschen Entropie herausdurchkriegen, dass wir die Groß-Kleinschreibung des Domainnames verändern, aber das ist es. Man kann auch ein bisschen mit dem Quellport spielen, um noch mehr Entropie zu bekommen, aber das machten wenige Menschen. Ein weiteres Problem ist, dass Benutzer nach Verfolgung verfolgt werden können. Wenn man einen centralen Resolver hat, dann sieht man viele Informationen von vielen Menschen. Man kann die Menschen nachverfolgen, das heißt man weiß welche Domainnames da sind, welche nachgefragt werden usw. Ein weiteres Problem ist, dass das gefunden wurde in den S ist das Verstärkungsangriffe, sogenannte Verstärkungsanfrage. Die Idee ist, dass man den S-Anfrage in der Regel relativ klein ist, einen kleinen Header, der nur den Domainname und den Typ und die Klasse beinhaltet. Aber die Antwort kann unter Umständen sehr groß sein, insbesondere wenn man den S-Sack verwendet, ein kryptografisches Signatur dabei verwendet. Die verbinden der Unterschied zwischen den Antworten, die gesendet werden und die, die zurückkommen, da ist es sehr groß. Man kann die IP-Adresse fälschen, man kann einen Resolver mit einer falschen IP-Adresse mit sehr vielen kleinen Paketen anfragen und der den S-Saver wird dann antworten auf diese fälschte IP-Adresse mit sehr vielen großen Paketen, das heißt man kann seinen Angreifen verstärken. Das heißt anstelle, dass man Pakete direkt an die Ziel sendet, kann man sie bei einem den S-Resolver weiterleiten und der wird sie verstärken und es wird das alles zum Opfer hinschicken. Den S über TLS ist noch eine Privatsphäre Verbesserung, es ist eine spezifiziert in diesem RFC 7858 und das ist eine Verbindung mit dem Caching Resolver und dem Alternativen Resolver. Man muss den Zertifikat von dem Caching Resolver überprüfen und man muss ihm vertrauen, keinen Mann in der Mittel zu haben und es führt dazu, dass es nicht so einfach modifiziert werden kann. Das heißt, wenn man in einem Land ist, wo den S zensiert wird, kann man zu einem anderen den S-Saver sich verbinden, das über TLS machen und dort ist er eventuell den S nicht mehr gefiltert. Das heißt, vielleicht kennen wir Leute, die iterative den S-Saver laufen lassen und die man besser vertrauen kann, die in Ländern sind, wo man dem besser vertrauen kann. Jetzt kommen wir zum Ende, ich werde jetzt nochmal kurz über MirageOS, einem Betriebssystem reden, der es einen sehr kleinen Angriffsziel hat und weniger Angriffsektor als ein normales Unix-System und es ist in einer funktionalen System-Sprache definiert. Und die Frage, wie passt das zusammen mit den S? Ich habe in den letzten Jahren den S-Saver und Antworten inklusive dynamischer Updates, Authentifikationen mit Edge-Mech-Sicherheiten auch über Let's Encrypt von anderen Leuten das implementiert und das habe ich integriert und wir haben Präsisten, Speicher in einem Git Storage und wir können das Let's Encrypt-Zertifikate ausrollen durch den S-Challenge. Das heißt, man kann ein DNS-Zertifikat von Let's Encrypt bekommen. Wie funktioniert das? Die Idee ist, wir beginnen mit einer virtuellen Maschine oder ein MirageOS Unicornle mit einem statischen Seed mit einem privaten Schlüssel und dem Edge-Mech-Geheimnis und der generiert den privaten Schlüssel von diesem statischen Seed und generiert ein Certificate-Signing-Request. Dann fragt es den, das Zertifikat von einem DNS-Saver an, das benutzt einen anderen Typ, TLSA, das beim Dein Projekt spezifiziert ist und wenn es den, das findet und der private Schlüssel passt und das Zertifikat immer noch gültig ist, dann fangen wir, machen wir weiter und können zum Beispiel ein Meld-Server machen und wenn es nicht gefunden wird, dann wird das Zertifikationssignal Irons-Request zum DNS-Server hochgeladen und der DNS-Server wird dann regelmäßig gefragt, ob er ein Zertifikat ausstellen kann und zwischendurch macht ein anderer den Unicornle, der den DNS-Server macht, der wird informiert und er fragt mit Let's Encrypt und versucht, dieses Zertifikat zu bekommen. Das ist wie ich meine Ausrollen von DNS und selbst signierten Zertifikaten, net's Encrypt-signierten Zertifikaten durch sich führe. Ich bin jetzt am Ende des Vortrages und nochmal kurz zusammenzufassen, DNS ist vielweilseitig eingesetzt und ich glaube, dass es noch mindestens weitere 50 Jahre benutzt wird. Es ist retondantes federiertes Daten während Speicherprotokoll und es hat in Caching und Authentifikationen. Es ist also ein sehr komplexes, aber auch sehr vollständiges Protokoll. Soweit es jetzt von mir, wenn ihr jetzt noch irgendwelche Fragen habt, dann könnt ihr die entweder den Mikrofon stellen oder auf Deutsch im IRC senden. Das war Hackandt und dort das den Kanal ersteckt 35 C3 Minus Zoll Minus C. Ich habe eine Frage über Mirajuas. Was sind eure Pläne für 2019? Da gibt es wohl ein neues Release von Herman. Was sind eure Pläne? Bisschen neben der aktuellen Frage, aber wir werden uns nicht das her sammeln. Wir sind noch mal treffen und wir haben ein paar Ideen, wie man das mit DNS integriert und automatische Encrypt-Sachen und ich möchte so ein paar DHCP Sachen da integrieren. Was wären die Vor- oder Nachteile von DNS für Load Balancing im Vergleich mit anderen Load Balancing, zum Beispiel H-Proxy? Bei einem Proxy hat man am Ende einen einzelnen Punkt, der die ganze Last handeln muss. Das ist alle Verbindungen laufen darüber. Bei DNS-basierten Load Balancer kann man einfach eine Reihe von Servern anbieten, die alle einen Teil der Last bekommen. Aber bei einem Load Balancer mit einem Proxy der vor hat man den Vorteil, dass man einen einzelnen Punkt hat, vor alle Verbindungen durchgehen und wir haben eine zentrale Instanz. Einige, in einigen Situationen ist den S-Round-Droppen nicht wirklich sinnvoll, aber in anderen ist es das. Das heißt, wenn man einen gemeinsamen, geteilten Status haben muss, dann sollte man vielleicht bisher ein Proxy benutzen und damit hat man einen geteilten State. Aber wenn man keinen vertreten Status hat, das ist ja eine staatliche Webseite oder ein staatischem Server, dann kann man den S-Round-Droppen benutzen und man verliert gar nichts. Hallo. Letztes Mal, als ich von Techniken gehört habe, wie D-Leuge, also DNS über HTTP. Was sind da die Vor- und Nachteile? DNS über HTTP ist jetzt eine Erweiterung, wo man nicht UDP oder TCP verwenden muss. Das heißt, wir können DNS direkt über HTTP verwenden und das ist ein Vorteil, weil man HTTP e-sprechten muss und wenn man JSON mag, dann geht das sehr gut. Aber es führt auch zu ein paar zusätzlichen, zu mehr Arbeit und zu mehr Daten übertragen werden müssen. Das heißt, man muss eine HTTP-Anfrage schrinken muss. Es gibt Vor- und Nachteile von unterschiedlichen Situationen und die DNS-Arbeitsgruppe diskutiert gerade diese ganze DNS über HTTP-Situation. Das heißt, ein großer Nachteil davon ist, dass normalerweise bei DNS UDP verwendet wird. Man hat eine sehr geringe Verzögerung. Aber wenn man TCP verwendet, dann müssen wir erst eine Verbindung aufbauen. Dann haben wir eine ziemlich große Roundship-Zeit, wo wir Daten verlaufen muss, bevor die Daten gesenden und empfangen werden können. Das Internet fragt, weißt du, ob es irgendwelche DNS-Erweiterungen gibt, die hilft bei ein Call-Sign zu einer Domain-Name zu übertragen. Weißt du, ob es DNS-Erweiterungen gibt, die für Ham Radio praktisch sind? Leider weiß ich das nicht, aber es ist gerne die Internet-Autorität für Namen von Zahlen, die haben allen Ressorts-Rekordtypen designt und das gibt eine zentrale Liste und man kann sich die anschauen und vielleicht findet man dort die Erweiterung, die man haben möchte. Hallo, meine Frage ist über GeoDNS. Zum Beispiel, wenn ich zu Wikipedia mich verbinden will von Singapur oder aus Europa, dann werde ich verbunden mit einem anderen Datenzentrum, Datencenter. Wie funktioniert das? DNS hängt davon ab. Das heißt, wir können zum Beispiel ein DNS-Servor so einrichten, dass es eine Anycast-Note ist. Das ist eine Routing-Erweiterung, eine Routing-Mechanismus, dass die selber IP-Adresse an unterschiedlichen Orten ankommt und der Nächste wird benutzt. Das heißt, wenn wir diesen Mechanismus benutzen, dann können wir einen Rechenzentrum in Singapur haben und eins in Europa, die die selber IP-Adresse für den Nameserver benutzen. Aber im Singapur-Rechenzentrum wird eine IP-Adresse aus Singapur angewendet, ausgesendet und die Europäische sendet eine europäische IP-Adresse aus. Eine Idee für dieses IDNS-Flegg für ein Nächtes Jahr ist das, auszurollen und zu versuchen, dass man als Client zusätzliche Informationen in die Anfrage senden kann über die eigene IP-Adresse. Das heißt, wenn man auf dem Server weiß, dass der Client in Europa ist, dann kann man ihn als Server mit einem europäischen Adresse beantworten. Das gibt unterschiedliche Mechanismen und man muss sich, muss das herausfinden und auswählen, welcher genau passt. Könntest du ein bisschen erklären, wie die DNS-Tunneling-Attacks funktionieren? Also wie kann man da Informationen aus Organisationen heraus extrahieren? Ja, darüber, wie man Daten herauskriegt, habe ich nicht viel geredet. Aber da DNS diese Domain-Names benutzt, kann man in einer Anfrage ziemlich viel Informationen reinschreiben. Das heißt zum Beispiel den Domain-Name und einen automatisch generierten Domain-Name und irgendeinen Inhalt da reinschreiben und damit kann man ein bisschen Daten von einem Client oder von einem kleinen Netzwerk heraus zu einem Server senden. Das ist sehr interessant, wenn man in einem Szenario ist, wo der Client überhaupt nicht mit der Außenwelt kommunizieren kann. Aber DNS wird durchgelassen und DNS funktioniert auch durch Proxies sind durch. Das heißt, wir können da Daten heraus senden. Außerdem gibt es sogar Implementationen, die IP über DNS sprechen. Das heißt, wenn in einer Situation ist, wo wir zum Beispiel in einem WLAN-Hotspot sind und wo aller Internetzugang verboten ist und was Geld dafür bezahlen, aber DNS immer noch durchgeht, dann kann man, wenn man den Server kontrolliert und den Client kontrolliert, dann kann man über DNS darüber kommunizieren, über diesen nicht bezahlten WLAN-Hotspot. Wir haben fast keine Zeit mehr, wir haben noch Zeit. Hallo, wie lützlich ist DNS dafür, Zertifikate für andere Protokolle wie Speed zu transportieren? Ich finde, es ist sehr sinnvoll, wenn wir DNS eine Vertrauensstruktur hätten. Wenn wir DNS benutzen und wir einen vertrauten Server haben, dann können wir alle anderen Zertifikate über DNS versenden. Die Dane-Arbeitsgruppe arbeitet an dieser Erweiterung und der schwächste Punkt aktuell ist, dass DNS-Sech ausgerollt oder noch nicht üblich ist. Viele benutzen es einfach nicht. Also das Internet fragt, was hältst du davon, DNS-Services von großen Konzernen wie Google oder Cloud-Fair zu verwenden? Das sollte man aber nicht benutzen. Es gibt unabhängige DNS-Resolver, die von nicht profitorientierte Organisationen, die auch ein paar Datenschutzrichtlinien und Gesetze haben, die nicht mitschreiben. Also ich würde einfach empfehlen, diese 1.1.1.1 Server, der 8.8.8 Server, 9.9 Server einfach nicht zu benutzen. Benutzt diese zentralisiert organisierten DNS-Resolver nicht, weil da bezahlt man nur mit seinen Daten. Die Organisation kriegt alle Daten. Aber was ihr machen sollt, ist Ihnen für seinen Vortrag bedanken und damit verabschieden wir uns auch aus der ...