 So, hört man mich? Ja, sieht so weit gut aus. Wir haben auch Bild. Ach, perfekt. Genau, also wir kommen zu meinem Vortrag DNSSEC und dann. Also es geht um die Vorstellung von DNSSEC und um Implikationen daraus, sowohl positiver als auch negativer Art. Ja, kurz der Aufbau. Ich werde erstmal dennoch, weil vielleicht noch nicht alle mit DNSSEC vollständig vertraut sind, die sich hier herbegeben haben, die Grundlagen durchgehen. Was ist das? Warum macht man das? Wie funktioniert das? Ein bisschen auf die technischen Details eingehen. Also was wurde dafür genau eingebaut? Was hat sich geändert gegenüber dem DNS, was seit vielen Jahren eigentlich sehr fest konstant war? Dann ein bisschen darauf eingehen, was muss man machen, wenn man das selber einsetzen möchte, sowohl validierend als auch als Betreiber einer Domain. Ja, dann Fun and Profit, also was passiert so Lustig ist und wie kann man es exploiten? Und dann wird noch im Prinzip das und dann erledigt. Das ist mit mich, was bietet uns den DNSSEC an Möglichkeiten, die wir vorher gar nicht hatten, an gesicherte Infrastruktur, an neuen Möglichkeiten Daten zu verteilen. Ja, und dann links und Hinweise auf den Workshop, die diese Nachveranstaltung gebe ich auch vorher schon mal. Der findet nicht nach diesem Talk direkt statt, weil Leute wollten auch den Vortrag nach DNSSEC, der zum Thema TLS ist, hören. Der passt auch ganz gut, sondern nach dem TLS-Vortrag gehen wir mal in den Shared Space, da kann man gemütlich dann hinsetzen, ein bisschen ausprobieren. Steht aber auf die letzten Folie nochmal. Also, warum DNSSEC? Im Prinzip entwickelt wurde das Ganze, weil bei DNS das Thema Spoofing immer problematischer wurde, DNS ist UDP basiert. DNS-Caching-Resolver lassen sich mit böse geformten Paketen dazu bringen, falsche Daten zu caschen. Das wurde auch in der Praxis real dann immer häufiger genutzt, nachdem da immer bessere Methoden bekannt wurden. Und man wollte halt verhindern, dass Antworten aus dem DNS von beliebigen Leuten verändert werden können. Und Facebook dann plötzlich bei Facebook EU landet oder sowas. Dabei hat man eben eine Infrastruktur erschaffen, die DNS absichert und das ermöglicht auch andere Daten sicher im DNS zu verwalten. Und deswegen gibt es jetzt auch viele Drafts, RFCs, die neue Records im DNS vorschlagen, um dort Informationen abzulegen. Ganz wichtig an der Stelle ist DNSSEC, heißt zwar DNSSEC, aber es verschlüsselt nix. Das heißt, eure Anfragen laufen weiterhin ganz normal durchs Internet, die können gelesen werden. Die sind nicht wie ein TLS oder ähnliches verschlüsselt, die sind lediglich signiert. Es hilft einem also nix im offenen WLAN, wenn derjenige nicht möchte, dass man sieht, dass man auf irgendeine Pornoseite zugreift oder im Ende auf die Firmenseite oder ähnliches. Es hilft auch nicht, sich gegen die Nile of Service zu schützen. DNS ist ja durchaus bekannt geworden als Amplifier für den Nile of Service Attacken. Betreiber von Zone-Servern sind damit auch Multiplayer in diesem Nile of Service Netz geworden. Da hilft DNSSEC gar nichts gegen. Wie der nächste Punkt sagt eher, das Gegenteil ist der Fall, DNSSEC macht es fast angreifbarer und besser geeignet. Ja, was ist DNSSEC? Das Ganze ist hierarchisch. Das heißt, es gibt wie das DNS, das DNS selber ist streng hierarchisch. Es gibt die Punktzone, die ist ganz oben. Unter der Punktzone sind die Second Level Domains, wie zum Beispiel die Lender Domains und die ganzen tollen neuen Domains. Und das ist eben hierarchisch von oben nach unten aufgebaut und genauso läuft die Signatur. Die Hutzone ist signiert, noch nicht so lange, aber seit 2010 jetzt dann doch. Und von da geht es runter für Lender Domains und so weiter. Um das zu erreichen, wurden neue Records eingefügt, Schlüssel, Signaturen, was man so braucht. Und es wurden ein paar Weiterungen im DNS-Protokoll vorgenommen. Das bedeutet, es mussten Flex eingeführt werden, damit die Server sich mitteilen können. Ich kann das und so weiter. Das heißt, es ist nicht mehr so kompatibel mit der Infrastruktur, die man für DNS jahrelang benutzt hat. Davor war DNS eigentlich immer konstant. Das Protokoll hat sich nicht gerne, die Software hat sich weiterentwickelt. Aber im Protokoll war nicht viel. Mit DNSSEC wurde doch einiges verändert. Man braucht auch neue Software-Versionen. Man kann nicht mit seinem Uralt-Bind aus dem Jahr 1990 DNSSEC machen. Was bei dem Design von DNSSEC ganz relevant war, die wollten das Offline-Signing tauglich haben. Das heißt, es muss kein Server wie bei TLS oder sowas in dem Moment Live-Schlüssel zur Verfügung haben, wo man eine Verbindung zu ihm aufbaut. Sondern man signiert eine Zone und man signiert Records mit Schlüsseln und dann kommen fertige Records raus. Die sind aber einfach Hackstrings wie normaler DNS-Record. Das kann man theoretisch auf seinem Rechner ohne Internet machen und dann per Dispete zu seinem Nameserver bringen. Ist natürlich in der Praxis nicht ganz so praktikabel. Aber man kann jetzt zum Beispiel für die ganz wichtigen Schlüssel machen. Und für die öfters geänderten, die die aktuellen Einträge signieren, da kommen wir später noch drauf. Die macht man halt dann online. Das ist also designt, dass da nichts live signiert werden muss und dass kein Schlüsselmaterial auf irgendwelchen Online-Internet-Servern erforderlich ist. Das ist soweit eigentlich ganz gut. Hat aber auch ein paar Nachteile, die auch zu einem der größten Nachteil von DNSSEC nachher führen. Wem vertrauen wir, wenn wir DNSSEC benutzen? Das ist eine schwierige Frage. Weil irgendwie muss man immer vertrauen und hier vertrauen wir als erstes mal den Amerikanern. Den vertrauen wir aber heute nicht mehr so viel. Jedenfalls der Punkt ist, die ICAN sitzt da ganz oben drüber auf der Routzone. Und die hat den Schlüssel für die Routzone. Das heißt, die ist in der Lage, Subzonen von root, also DE und so weiter zu signieren. Den Signaturprozess macht Veri-Sahlen. Den Schlüssel hält die ICAN. Und man selber hat in seinem Resolver, den man benutzt, eben im Prinzip den Public Schlüssel, den die ICAN hat gespeichert. Als einzigen Anker in dieses ganze System. Also ähnlich wie man in seinem Browser-Zertifikate von V-Restern und so weiter hat, hat man hier ein Trust Anchor. Der einen auf diesen einen Schlüssel verweist, so dass man sicher weiß, der stimmt. Und von da an ist dann alles signiert und kann dynamisch verändert werden. Was die ICAN gemacht hat, um ein bisschen das Vertrauen in dieses ganze Verfahren zu stärken. Die machen eine ganz tolle Key-Signing-Ceremony. Jedes Mal, wenn sie da neue Schlüssel erzeugen, kann man sich auch Videos anschauen. Da gibt es an zwei Enden des Landes Datacenter, wo dann zwei Tresore sind, wo sich Member aus der Community mit Key-Cards autorisieren. Da sind dann so viele von so vielen nötig, um das schön Security-Seater zu veranstalten. Wirkt eigentlich auch gar nicht so schlecht. Das Verfahren ist als solches gut. Aber ob man jetzt völlig vertrauen kann, dass Veri-Sahlen nicht in der Lage ist, dennoch einfach irgendwas zu unterschreiben, wenn die Regierung Ihnen sagt, unterschreibt uns das. Ich will es nicht beschwören. Das Gute ist, das Ganze wird delegiert. Das heißt, die Schlüssel für die verschiedenen Zonen sind in den Händen der entsprechenden Länder nix. Anders als bei X509, dem bisher größten verbreiteten Zertifizierungssystem, wo letztendlich jede CA, die euer Browser hat, und ihr könnt mal durchgucken, das sind einige 100, für alle Domains der gesamten Welt Zertifikate ausstellen kann. Das heißt, auch eine deutsche Bank, die beim deutschen Registrar seine Domain hat, kann von irgendeiner niederländischen CA oder noch schlimmeren eine neue Zertifikat bekommen, was ein Angreifer nutzen kann. Das ist bei den Essig nicht so. Da kann wirklich nur das DE-Nick Zonen unterhalb von DE signieren. Und das ist das Schöne an der Stelle. Wenn wir sagen, wir trauen Veri-Sahlen nicht. Wir finden aber, das DE-Nick ist eigentlich gut. Da haben wir eh unsere Domain, die können sie sowieso spufen, wenn sie wollen. Die sind vertrauenswürdig. Das heißt, ich habe den Trust Enker für DE auch in meinem Resolver verankern. Das heißt, ich habe nicht nur die Routzone von Veri-Sahlen, den Rout-Key von Veri-Sahlen drin, sondern ich tue mir auch vom DE-Nick, den Public Key, bei mir abspeichern. Und dank dieses RFC 5011, was ich da erwähne, ist es sogar so, dass die in Schlüssel erneuern können und sich mein Trust Enker automatisch erneuert. Das ist jetzt keine Common Practice. Das macht nicht jeder so, dass er sich die Länderzonen da selber als Trust Enker verankert. Das ist vielleicht ganz sinnvoll, insbesondere wenn man eben sagt, ich traue hier meine lokalen Umgebungen mehr als eben der gesamten Routzone. Und man kann natürlich auch noch tiefer machen. Ich könnte auch meine Firmendomain bei mir in meinem Resolver verankern, um zu sagen, meine Zone ist in meinem Griff. Das heißt, meine Hosts können dem tatsächlich trauen, was in meiner Domain gilt. Um das Ganze ein bisschen komplizierter zu machen, hat man sich überlegt, man macht da zwei verschiedene Arten von Schlüsseln. Das hat technisch keine richtige Relevanz. Das müsste man nicht machen, aber es ist eben etablierter Standard. Und zwar erzeuge ich mir immer mindestens zwei Schlüssel für so eine Domain oder Subdomain. Einmal einen Key, Signing Key, den ich dazu benutze, die Schlüssel meiner Zone zu unterschreiben und dann einen Zone Signing Key, der von diesem Key Signing Key unterschrieben ist und der dann alle Records in meiner Zone unterschreibt. Der Vorteil ist, ich lasse von der übermehrliegenden Zone, also wenn ich eine CLD bin, lasse ich es von Veris und wenn ich eine deutsche Domain habe, lasse ich es vom DENEC, mir nur meinen Key Signing Key unterschreiben und kann meinen Zone Signing Key dann wechseln, wie ich möchte und kann auch diesen Key Signing Key in Schrank packen, den Private Key dazu und nur benutzen, wenn ich neue Zone Signing Keys erstellen muss. Das ermöglicht mir auch, dass ich für den Zone Signing Key geringere Bitlängen verwende. Das ist durchaus relevant, weil dadurch die übertragenen Daten kleiner werden und weil auch der Rechenaufwand kleiner wird, den meiner Resolver zu tun haben, wenn sie Records auflösen. Das heißt, da ist durchaus heute noch üblich mit Keys um die 1040 Bit zu arbeiten, wo man sagen würde, bei TLS Katastrophe wird kein Verifier dir noch als OK durchgehen lassen, weil das ist ja in halb weniger Jahre geknackt. Das ist bei DENEC völlig egal. Wenn den Key jemand Jahre nachdem er benutzt wurde, knackt, die Daten sind ja e-öffentlich. Das geht nur um die Signaturen. Kann er damit nicht viel anfangen. Das heißt, da sind kleinere Keys, die öfters gewechselt werden, durchaus üblich, dadurch aber schnelleres Rechnen und kleinere Daten. Was an der Stelle ganz wichtig ist, bisschen schandelt es ganz unten auf der Folie steht. Wenn ihr sowas macht und euch Schlüssel austauscht, solltet ihr euch genau die entsprechenden Dokumente zum Thema Key Rollover durchlesen. Das heißt, da wird beschrieben, Rekords haben eine Lebensdauer im DNS. Eure Cachings, Resolver oder Resolver irgendwo bei Providern haben eure Daten gecached. Wenn ihr jetzt einfach irgendein Schlüssel tauscht, kann das breaken. Und das Relevante ist, wenn das DNSsec bregt, seid ihr vom Google Nameserver aus nicht mehr auflösbar. Und den benutzen ja doch einige. Und natürlich auch von allen anderen vari-feinden Resolvern. Wenn man DNSsec bregt, dann kommt dann nicht irgendwie, das ist unsicher, wollen sie trotzdem weitermachen, dann ist es kaputt. Und von daher sollte man solchen Schlüssel-Austausch-Verfahren wirklich ganz genau darauf achten, dass man das richtig macht. Meistens heißt das, ich tue erst einen neuen Schlüssel erzeugen, warte dann, bis der sicher propagiert ist, signiere dann die Sachen mit dem neuen Schlüssel, dann ist es doppelt signiert und so weiter, aber da gibt es ausführliche Dokumente, je nachdem, welchen Schlüssel man tauscht und in welchen Szenarien, wie man davor zu gehen hat. So, einmal ganz grob so eine Struktur, wie das aussieht. Da ist jetzt oben die Routzone, im Prinzip dieser ganze Kasten. Der hat ganz oben einen Schlüssel, der nur auf sich selbst verweist. Das ist der Trustenker, den ich auch bei mir verwaldet habe. Der verweist dann tiefer auf die DE-Zone und die DE-Zone verweist dann auf die hypotelische DomainfNord-CDE. Und so ist das eben aufgebaut. Und wenn ich weitere TLDs hätte, dann stand der hier neben DEU noch NL und so weiter. Das heißt eben von oben nach unten. Und wir sehen hier auch schon, da ist eben einmal ein Schlüssel, das ist dann dieser Key-Signing-Key und ein zweiter Schlüssel, der Zone-Signing-Key, der dann den eigentlichen Rekord unterschreibt. Also im Falle der echten Domain unterschreibt dann dieser Zone-Signing-Key eben den SOA-Rekord, den A-Rekord, den X-Rekord. Was man typischerweise eben so an Rekords hat. Wie ist das ganze technisch umgesetzt? Gar nicht sagt hier vorne jemand. Ja, das stimmt natürlich. Es ist in der Tat eine Sache, die etwas langsam gestartet ist. Aber ich würde sagen, seit 2012 kommt es noch richtig ins Rollen und es gibt eben auch durchaus viele Firmen, die darauf achten. Und wir kommen später noch auf ganz schöne Beispiele, die das schon einsetzen. Also ich würde sagen im Vergleich zu IPv6 ist DNS-Sack momentan vorne. Na, was eher passiert, das volle Deployment oder das Ende des Öls, das ist eine andere Frage, aber auf jeden Fall vor IPv6 ist momentan DNS-Sack. Genau, das eine ist, es wurden neue Bits eingeführt in der DNS-Ko-Munikation. Das eine ist das DO-Bit. Das sagt im Prinzip, ich verstehe DNS-Sack und das bedeutet mir schickt eben jemand auch die entsprechenden Bits mit, die durch DNS spezifiziert sind. Andernfalls sind die Antworten nicht enthalten. Ein weiteres Bit, was mir der Anfrage schicke, ist Checking Disabled. Das heißt, ich habe zwar einen DNS-Sack fähiger Resolver. Ich will aber nicht, dass der prüft, sondern der soll mir einfach bitte alle Daten geben, egal ob es korrekt ist oder nicht, ich prüfe selbst. Das kann zum Beispiel Software machen oder Plugins, die eben selber sinnvolle Infos ausgeben wollen. Denn im anderen Fall, wir sehen hier, das ist normalerweise, das heißt, es kommt AD zurück. Das heißt, der Resolver, den ich benutze, sagt mir, ich habe das geprüft, das ist alles gut. Und wenn er das nicht konnte, schickt er nicht die Antwort zurück ohne AD, sondern schickt er zurück Surf-Fail. Das heißt, wenn ich mit DNS-Sack meinen Resolver nach einem Rekord frage, der nicht korrekt signiert ist, weil gespuft wurde oder was viel häufiger vorkommt, weil es jemand verkackt hat, dann bekomme ich nicht eine Antwort ohne AD, sondern bekomme ich ein Surf-Fail, dass das gleiche ist, wie wenn die Zone völlig kaputt ist, wenn die expired ist, wie auch immer. Ich kriege einfach gar nichts. Das heißt, wenn ich die Daten trotzdem möchte, muss ich sagen Checking Disabled, dann kriege ich die Daten trotzdem. Wie ich vorhin schon sagte, Verschlüsselung ist da nicht drin. Das heißt, es signiert nur die Daten, es signiert nicht die Pakete. Ich habe also keine Verschlüsselung zwischen mir und dem Resolver oder ähnliches. Das heißt, in der Regel macht man das lokal. Dass der Google Resolver DNS-Sack unterstützt, das ist zwar toll, aber wer traut in dem Internet zwischen sich und dem Google Resolver? Das ist völlig sinnlos, den zu benutzen, um den DNS-Sack aufzulösen. Das passiert zwar oft auch ohne, dass man es überhaupt merkt, wenn man einfach ein normales Setup hat, aber es bringt einem nichts. Den sollte man nicht vertrauen, wenn man das wirklich einsetzen möchte, dann muss man es lokal machen. So, denn die neuen Ressource-Records, die eingeführt sind, das sind Daten, die in eurer Zone einträgt. Das ist zum einen der delegation signer-Record, das in einer Elternzone steht, um auf euren Signing-Key zu verweisen. Das ist ein Fingerprint eures Kies eingetragen von z.B. dem DENEC. Der DNS-Key, das ist euer Schlüssel selbst, den tragt ihr damit in der Zone ein. Und dann das eigentlich Wichtigste, das RSIK, das ist die Signatur über ein Record Set. Record Set ist in DNS eben alle Records eines Types, z.B. alle A-Records zu einer IP, wenn man mehrere hat, oder alle MX-Records zu einem Hostnamen oder eben alle DNS-Key-Records zu einer Domain. So ein Set wird mit einem RSIK-Record von einem Key unterschrieben. Davon kann man auch mehrere haben. Wenn ich mehrere Kies einsetze, z.B. während so einem Austausch, kann ich auch zu einem Record Set mehrere RSIK-Signaturen haben. Aber auf jeden Fall unterschreibe ich damit eben die Records. Ja, und jetzt kommen die etwas lustigeren Erweiterungen, NSEC und NSEC3, die dienen dazu, Nicht-Existenz von Daten zu signieren. Da kommen wir gleich noch zu, weil das ist nämlich ein bisschen schwieriger. So, jetzt ist ein ganz generelles Ausstatt aus dem Bild vorne. Wir haben oben den Delegation Signer, der signiert einen DNS-Key, eben einen Key-Signing-Key, der signiert meinen Zone-Signing-Key, der signiert einen A-Record in diesem Fall. Ja, eine Frage. Die Frage war, weil hier Chemikowohn ist, ob sich das unterscheiden kann von der Struktur, die durch NS-Records und SOA-Records gebildet ist. Ich kann natürlich durch technische Fehler das erzeugen. Eine gültige. Na gut, ich kann im Prinzip auf ein Nameserver mit einem NS-Record verweisen, der nicht der aktuelle Gültige ist und auf dem trotzdem einen richtigen Schlüssel hinterlegen. Aber es gibt kein sinnvolles Konstrukt, würde ich sagen. Normalerweise folgt das genau der Delegation. Genau, so sieht das dann in der Zone aus. Also, wir haben hier oberhalb der Linie, das ist alles jetzt für y.nu, aber die Records oberhalb der Linie befinden sich in der nu-Root-Zone. Sprich, da ist ein DS-Record für y.nu und eine Signatur über diesen DS-Record. Innerhalb der Zone y.nu sind jetzt zwei DNS-Key, eben der Key-Signing-Key und der Zone-Signing-Key. Die unterscheiden sich im Wesentlichen durch diese eine Bit hier vorne bei der 2.750 bis 2.650. Das sind sowieso alles ganz tolle Felder, von denen y.nu das letzte eine echte Relevanz hat aus diesem einen Bit, weil das andere ist das Bit 8 immer gesetzt, das andere ist immer 3, das kommt aus historischer Entwicklung, aber inzwischen ist nur noch das in Verwendung. Und hinten ist der Algorithmus, der sagt, wofür benutze ich diesen Schlüssel? Mach ich da Schar 2.650 mit RSA oder mach ich da DS-A, da gibt es verschiedene Varianten, wie so ein Schlüssel eingesetzt werden kann. Genau, und das Ganze ist wieder signiert. Also, sprich, dieser Signatur signiert das DNS-Record-Set, dann ist hier ein A-Record und eine Signatur auf dem A-Record. Also, so sieht diese Signatur innerhalb der Zone dann aus. Das müsst ihr in der Regel nicht von Hand eintippen, das macht dann die Software für euch. So, und jetzt zu dem Endseck. Da geht es um die Signatur von ungültigen Servernamen. Man will ja im Prinzip auch eine definierte Antwort haben, diesen Namen gibt es nicht, wenn man hinter eines bufender Angreifers ein Beispiel Namen verschwinden lassen aus der Zone. Da aber das normalerweise dem DNS eine Antwort als Fehler ist, da kommt ein NX Domain zurück, das ist ein Error, das im Bitt letztendlich in der Antwort, der sagt, das gibt es nicht und keinen Ressourcerecord, das gibt es nicht, gibt. Kann ich auch nichts unterschreiben, das gibt es nicht. Was stattdessen gemacht wird, ich unterschreibe alles, was es gibt. Das heißt, es wird eine zyklische verketterte Liste aller Records in der Zone gebildet über diese Endseck-Records, die sagen, nach A kommt B, nach B kommt C, nach C kommt D, nach D kommt Z. Das heißt, ich weiß, für den D und Z ist nichts und wenn ich diese Records alle unterschrieben habe, weiß ich also, okay, F kann es nicht geben, weil Läge zwischen D und Z gibt es nicht. Da ist eine Frage da hinten. Das ist nicht für den Typ, das ist für den Namen. Da steht es ja die Typen dann nachher drin, die es gibt, aber es gibt nur das, was da steht. Wenn wir sagen, es gibt für diesen Typ keinen Eintrag, das ist in der Liste halt nicht enthalten. Hier steht drin, für diesen Namen gibt es A, M, X und irgendwas. Das sehen wir gleich noch. Aber du schreibst nicht, was es nicht gibt. Du schreibst einfach alles, was es gibt in diese Liste. Wer sich schon gedacht haben wird, das Problem davon ist, wenn ich so eine Liste von Records habe, kann ich den natürlich durchlesen. Ich fange ganz oben an und weiß dann, oh, danach gibt es das erste, danach ist es das zweite. Das heißt, was wir vor vielen Jahren alle abgeschaltet haben, das Transferieren von Zonen, von unseren Nameservern, ist jetzt wieder möglich, weil ich es einfach durchwalken kann. Das ist jetzt nicht schlimm, wenn man eine Zone hat, in der man den WWW-Server, den Mailserver und Nameserver hat, die WWW-Mail und NS heißen. Also 99% der klassischen Domainzonen für irgendeine Webseite, für irgendwas, haben damit kein Problem, weil die enthalten keine geheimen Records. Typ eigentlich sollte eine DNS-Zone generell keine geheimen Records enthalten. Das ist zwar sowas, wo Leute dann sagen, oh, das war schon beim Sohn-Transfer damals, so ein Thema, Lutz Donnerhacker hat vor einiger Zeit mal geblockt, dass das alles schwachsinn ist, er macht das absichtlich an, kann man doch sehen, was im DNS steht. Aber wir wissen, die Praxis ist, die jungen Firmen, große Firmen haben ihre ganze Büro-Infrastruktur da abgelegt, weil die es einfacher ist, weil die Leute den Google-Nameserver drin haben und trotzdem aufs interne Wikisäulen. Und ja, also jedenfalls normalerweise, wenn man damit kein Problem hat, ist das Insekt durchaus eine gute Wahl, weil wir kommen gleich zur Lösung. Die hat auch nacht, ist das noch eine Frage? Ist das nicht auch ein großes Performance-Problem für Top-Level-Domains mit Millionen von Einträgen, wenn Sie immer die komplette Liste nach einer Änderung neu signieren müssen? Die müssen nicht die komplette Zone neu signieren, die müssen nur die Stelle, die Sie geändert haben, neu signieren. Weil das ist ein Insekt-Rekord für den Namen, nach diesem Namen folgt. Das heißt, diesen Rekord muss sich neu signieren, die ganzen anderen bleiben gleich. Also ich habe dann eine Änderung von drei Rekords oder so, das muss ich jetzt genau überlegen, oder zwei, die Liste wird etwas eingefügt. Das ist nicht das Problem, es gibt nur durchaus andere Probleme mit der Initial-Signierung. Die Mit-Ein-Grund-Auch ist für die Erweiterung, also erst mal ein Beispiel einer Zone, die mit INSEC walken kann. Die NASA glaubt, sie hat keine geheimen Rekords. Da kriegt man von NASA-Kopf, kommt 3D-Printing NASA-Kopf, nach 3D kommt Unterstrich SPF 4, SPF 6 und so weiter. Und da hinten sieht man auch immer, was das jeweils ist. Das ist ein A-Rekord. Und so viel das sehen wir, ist eine Subdomain. Da gibt es also unter SPF IPv4 eine Delegation. Und so sieht das einfach aus, immer ein INSEC-Rekord, eine Signatur für den INSEC-Rekord. Ein INSEC-Rekord, dass wenn ich jetzt schon nach 3D-Printing, noch 4D-Printing einfügen wollen würde, dann müsste ich diesen Rekord ändern und einen neuen signierten einfügen. Das wären zwei neue Signaturen, die ich hätte. Gut, aber wenn man jetzt nicht die NASA ist und doch was zu verbergen hat, dann nimmt man eben INSEC 3. Das ist eine Frage dahinten. Oder eine Anmerkung? Wieder wiederholen. Eine der Gründe, warum man das nicht haben will, ist, dass man Spam-Schleudern die Arbeit sehr viel leichter macht, wenn die meine Domains durchgehen können und jeden PC in meinem Netz anschießen können. Wenn die deine Domains durchgehen können? Wenn sie ein Walk über alle definierten Namen machen können, dann haben die deutlich weniger Aufwand, damit alle Rechner, also die Botnetzer haben dann weniger Aufwand, meinen Rechner anzugreifen. Also das hat schon seinen Sinn, dass man dann irgendwann mal weitergebaut hat. Das hängt eben ganz davon ab, was du in deiner Zone drin hast. Wenn du zum Beispiel alle deine Host in einem V4-Subnetz hast, in der Regel schneller gescannt, wenn du ein riesiges Netz hast auf 200 Standorten und das über dein DNS leicht zu finden ist, dann ist es eben ein Nachdrucksprecher. Wenn du eine Zone hast, die hat WWW-Mail und NS, dann hast du kein Problem damit. Wenn du eine komplexe Zone hast wie die NASA, ist es vielleicht nicht so geschickt. Das ist genau der Punkt. Und eben, dass DENEC hat gesagt, wir haben ein ganz großes Problem. Wir tun die Liste aller unserer DENEC-Domains seit Jahren mühsam geheimhalten, weil das natürlich für Spammer interessant ist und das hat DENEC gesagt, wir signieren erst, wenn das verbessert ist und hat mitgearbeitet mit Standard NSEC3. Und in solchen Zonen ist der auch sinnvoll. Er kann auch in anderen Zonen sinnvoll sein, aber in solchen ist er auf jeden Fall sinnvoll. Sprich, in der DENEC-Second-Level-Zone, wo alle DENO-Mains drin stehen, wäre NSEC relativ unschön. Da hätte man mich jetzt Wort, die Liste aller DENO-Mains und zwar auch der, die mit DNS gar nichts zu tun haben. Was die deswegen gemacht haben ist, sie haben gesagt, wir machen nicht mehr die Namen rein, das ist die Art. Und gegen Brutforcen tun wir das Ganze noch mit Iteration in einem Salt versehen. Das wird mehrfach gehächt und es gibt einen eindeutigen Salt, damit es keine Rainbow Tabels gibt. Ein bisschen verwirrend, wenn man das Ganze umsetzt und die ganzen Docos dazu liest, vor allem wenn man Docos liest, die vor 2012 sind und ähnliches. Diese Algorithmen für die Schlüssel, wo sagt, das ist RSA mit SHA1 und so weiter. Die gibt es dann in zwei Varianten, einmal RSA mit SHA1 und einmal RSA mit SHA1 für NSEC3. Das dient nur dazu, dass ein Resolver, der zu alt für NSEC3 ist, weiß, das verstehe ich nicht. Bei Verfahren, die neuer sind als NSEC3, wie zum Beispiel RSA SHA256, was ich generell so als aktuellen Standard sehen würde, gibt es diese beiden Varianten nicht, weil der ist ja neuer als NSEC3, das heißt, jeder, der den kann, kann auch NSEC3. Aber das kann einem so lesen von Anleitung ein bisschen verwirren. Genau. Das Problem ist natürlich, BrutForce ist weiter möglich. Und eben, wenn man so einen alten Algorithmus hat, das wird aber jetzt keiner erst neu anfängt haben, da muss man den Algorithmus erst mal wechseln, wenn man NSEC3 einsetzen kann. Das Ganze sieht dann so aus, also die YNU-Tune zum Beispiel, diese und die Tune, die viele Hosts enthält, weil sie auch subtominient weiter enthält. Da halte ich es für sinnvoll. Da ist dann nur noch ein HashYNU und danach kommt dieser HashYNU. Das heißt, da sieht man erst mal nichts daraus. Das kann man zwar durchworken, aber das ist nicht so gut. Genau. Die Probleme dabei ist aber nicht nur, dass man es hacken kann, sondern auch, dass es Probleme macht. Nämlich, das HashYN, wo ich die Interaktion so weiter habe, muss beim Resolven gemacht werden. Das bedeutet, jemand kann mir ein Paket schicken, da steht drin, sagt mir diesen Namen und dann muss mein Resolver erst mal haschen. Braucht CPU. Das hat mit einem einfach ein Paket, kann jemand dazu bringen, N mal zu haschen. Und das ist natürlich nicht so gut. Aber das Resolver ist der gleiche wie der Treiber der Domain. Sonst könnte ich eine böse Domain erstellen, in der steht drin, 10 Millionen Interaktionen sind für meinen Namen nötig und dann die Google Nameserver ganz oft nach diesen Namen fragen. Deswegen sagt das RFC, die Anzahl der Interaktionen ist begrenzt und die haben sich so etwas überlegt, zu sagen, wir versuchen das so abzuschätzen, dass die Rechenkomplexität für das HashYN ähnlich groß ist, wie die für die RSA-Operation sowieso nötig ist. Das RSA-Schlüssel. Da gibt es ein RFC zu, das beschreibt es relativ genau und es sagt, bei Schlüsseln bis 1024 darf man 150 Interaktionen machen, bis 2048 darf man 5 Interaktionen machen und bei allen größeren Schlüsseln darf man 2.500 Interaktionen machen. Da 1024 die kleinste, übliche Schlüsselgröße ist, gilt die 150 eigentlich nur genau dafür. Ich würde daher 1025-Bit-Schlüssel anlegen, dann kann man zumindest die Option haben, mehr Interaktionen einzusetzen. Ist aber nicht viel wiriger zum Rechnen. Genau. Allerdings muss man dazu sagen, es gibt ein gewisses Ungleichgewicht zwischen Angreifern und legalen Betreibern hier, weil die Angreifer haben Dank Bitcoin, Essex und so weiter inzwischen und GPUs. HashYN-Hardware zur Verfügung, die macht Gigahashes pro Sekunde, während der Nameserver in der Regel auf normaler GPU arbeitet und einfach haschen muss. Das heißt 150 Interaktionen, das lockt, sage ich mal, keinen HashCat, benutzt er mir hinterm Ofen vor. Aber immerhin ein Grundervorteil, der Hash ist über den gesamten Namen. Das heißt hostname.subdomain. Und damit kann man nicht einfach eine Rainbow-Table für übliche Namen bilden. Gut als Salt gäbe es auch noch dazu, aber vielleicht hat irgendjemand benutzt alles als default Salt aus der Doku oder sowas. Könnte man eine Rainbow-Table für viele Domain setzen, kann man nicht, eine Rainbow-Table hilft immer nur für die eine Domain. Damit ist sie eigentlich sinnlos. Eine Frage noch dazu? Wie reagiert das Ganze mit der Umsitte manchmal ein und denselben Zonefall mit Add Origin mehrfach zu inkludenden unterschiedlichen Orten im Fully Qualified domain nehmen? Geht das noch? Wenn du das gleiche Zonefall, das hängt natürlich von der Software, die du einsetzt und du das gleiche Zonefall einfach mehrfach verwenden willst, aber du schreibst heutzutage nicht die Rekord selber in deinem Zonefall, sondern du nutzt bindinline-signing. Und wenn du dann die Zone einfach kopierst, dann ist das für beiden verschiedene Dateien, du hast ja mehrfach in der Konfig definiert. Und dann wird er darunter dir einfach alle für die jeweiligen Namen haschen. Genau. Das ist das, was wir heute machen wollen. Erstmal, ich bin klein und möchte sicher auflösen können. Wie gesagt, so was Netz macht das Ganze nur begrenzt sind. Man hat ein total sicheres Netz, den man völlig vertraut. Dann muss ich auch einen zentralen Resolver hinstellen. Aber das ist ja heutzutage, ihr macht ja auch kein Tellnet in eurem Laden, obwohl ihr eurem Laden vielleicht vertraut. Also ist eher unüblich. Man würde heutzutage sich selber einen Resolver installieren anbauen und ist da ein relativ schlanker, aber ein normaler, moderner Bein geht eigentlich auch. In modernen Distrus, ich habe das auf Fedora getestet, das direkt funktioniert. Und wenn man auf Fedora einfach den Anbau installiert, hat er den Trust Anchor drin und verifiziert. Und den trägt man sich dann eben ein in der Resolve-Konf. Man entabelt noch die Option EDNS0. Das ist aber gar nicht so wichtig für das DNS-Signal. Das ist eher für Sachen wichtig, die dann auch die neuen Records benutzen wollen, die etwas größer sind. Das bedeutet letztendlich, ich verstehe moderneres Protokoll. Ich kann UDP-Pakete über 512-byte empfangen. Weil vor EDNS0-Extension war einfach UDP 512-byte Ende und danach muss man PCP-Fallbacken. Während auf dem Localhost auch nicht so schlimm, aber in der Regel setzt man das. Ganz wichtig ist, man sollte keine anderen NSer als Fallback in der Resolve-Konf haben. Wie wir gesehen haben, das ist gar nicht so logisch. Wie wir gesehen haben ist, man sagt, solange meine Online ist, funktioniert der, aber DNS-Verification Failure heißt, ich retöne, retöne Fail. Und dann tut der Resolver zum Nächsten gehen. Das heißt, bei jedem angegriffenen DNS, bei jedem ungültigen DNS würde er zum Nächsten gehen. Das ist definitiv kein sinnvolles Verhalten. Und auch wenn der Nächste ein verifizierender Google ist, wollte er das vielleicht nicht unbedingt. Wenn man dafür hier im Netz ist, stellt man fest, man kriegt natürlich eine neue Resolve-Konf übergebügelt, wenn man das nicht wegkonfiguriert hat. Und der Resolver hier im Netz ist auch DNS-Zack verifizierend. Das heißt, wenn man es dann auflöst, merkt man das erstmal gar nicht, ist alles noch weiterhin sicher. Deswegen CHATRE weg, wenn man nicht seine Software im Griff hat. Und ganz sicher weiß, ich habe das wirklich abgeschaltet. Ich habe meinen Network Manager, meinen SystemD, meinen Pöttering im Griff. Und ich bin da erstmal sicher. Wenn ihr das eingelichtet habt, es gibt so einen schönen Test-Rekord, der returned einem ein Text-Rekord, in dem drin steht, es war DNS-Zack oder nicht. Das heißt, mit diesem Dickaufruf bekommt ihr eine Antwort, entweder ihr benutzt DNS-Zack oder ihr benutzt es nicht. Wenn ihr das jetzt eingebt bei euch, werdet ihr wahrscheinlich bekommen, ihr benutzt das, weil wie gesagt der Resolver, der hier im Laden verteilt wird, DNS-Zack signiert. Alternativ gibt es auch eine Website, die dort einen tollen JavaScript-Test, der irgendeinen Image lädt, das ist eigentlich relativ leicht eingerichtet. Das würde ich durchaus jedem empfehlen, einfach mal zu machen, dann habt ihr schon mal auf eurem Kleint sicheren Namensauflösung seit gegen komische, klassische Spoofing-Attacken gesichert. Was muss ich machen, wenn ich meine Domäne sichern möchte? Ich sollte mir einen möglichst modernen Nameserver installieren, der, wenn ich es irgendwann möchte, auch N-Sack 3 kann, also so ein Bind-Up 9.9, vielleicht besser sogar 9.10, ist dafür gut geeignet oder auch Power-DNS von einem dynamischen Sachen nach Daten machen möchte, einigermaßen modernen Zone-Server. Ich sollte mich mit den Dokus beschäftigen. Das hier ist kein Vortrag, der eine vollständige Einführung in den Sack bietet, sondern beginn mal durchlegen, was es in Autos gibt, überlegen, wie groß will ich mir den Schlüssel machen? Was will ich für Schlüssel machen? Es gibt noch Ideen, dass man sich eine Reserve-Schlüssel bereitlegt, dass man sich ein offline Reserve-Schlüssel bereitlegt, der schon mal signiert ist, dass man leichter wechseln kann, je nachdem, wie wichtig die Zone ist, die man betreibt, also sprich, ob man jetzt mobile.de ist oder irgendwie mein Fricklverein.de ist mit beschäftigt. Was relativ leicht ist, ist, ist, Bein-Inline-Signing zu verwenden, das heißt, sie nehmen so ein Bein 9.9, setzt dem ein paar Schlüssel rein, macht man eine Zone ganz normal und sagt, dem signiert die und sagt, der man nicht wegen noch macht NSSack 3-Records dafür, und dann macht er die ganzen Sachen automatisch und erzeugt er immer neu, wenn sie aktualisiert wird. Was er nicht wirklich macht, ist das Schlüssel-Austausch für einen. Da gibt es dann Pakete wie OpenDNS-Sack, man kann das in der Zone verfahren, den Delays, Abwarten der TTLs und so weiter erledigen, ist aber erstmal mehr Setup-Aufwand. Also ich würde jetzt Leuten empfehlen, dass man mal ausprobieren wollen, nehmt mich so ein Bein irgendwo, macht Inline-Signing-Pult erst mal aus. Wenn ihr das aber euch lokal laufen habt für euren Zone Server, dann ist der Punkt, ich gehe an mein Registrar. Da ist jetzt die große Frage in.de, ich würde sagen ein Viertel oder so was, der üblichen Registries bietet inzwischen an, so ein DS-Record zu setzen. Ich will da was ganz Komisches, ich will dieses DNS-Sack verwenden, da ist so ein Rekord und dann wird er einem eingebaut. Wenn alles nicht geht, habt ihr euch einen schlechten Registrar gesucht, sprich vielleicht die Domain mal umziehen. Genau und wer nach einfach mal spielen möchte, ich habe wie gesagt die y-Punkt-NU signiert, die ist relativ schön kurz, da könnt ihr irgendwie einfach Subdomains delegieren, sprich irgendwo ein Server einrichten, ich delegiere euch das, signiere euch das, dann könnt ihr mal mal testen. Dazu mehr im Workshop nachher. Zumindest eurer Subdomain von y, ich glaube ja nicht, dass eure Firma und eure neue GmbH darauf gründen werdet. Wobei also verbieten will ich es euch nicht. Aber genau, so fun and profit. Was sind so die lustigen Sachen, die dabei passieren? Das erste ist Veryfire lesen die RFCs nicht. Ich hatte hier diesen Fall, ich hatte die unglaublich hohe Zahl von 147 Terrations gesetzt, das war noch, als ich einen Bit, und dieser Veryfire macht mir den schönen Test gelb, Fehler, weil es als irgendeinem Grund glaubt, das Limit sei 100. Ich habe keine Ahnung, vielleicht ist das ganze Code schon ein bisschen älter. Ist allerdings der Veryfire den die Menschen, der in U-Domain verwenden, sprich, die haben mir gesagt, du hast ein Fehler. Da habe ich ihnen gesagt, ne, leider, ich habe das RFC nicht gelesen. Aber damit muss man auf jeden Fall rechnen, also nur weil ein Veryfire sagt, euer Setup ist falsch, ist nicht zwingend euer Setup falsch, es könnte auch der Veryfire einfach von 2010 sein. Oder diese Stelle des Codes. Was wesentlich häufiger heute da ankommt, ich habe jetzt nur zwei Beispiele für, die ich jetzt mitfällst von Anbietern. Das hier war ein sehr lustiger, da hat HBO irgendwie passend zu einem Apple-Event angekündigt. Wir machen HBO Now, das ist Fernsehen übers Internet. Ihr braucht keinen Kabelanbieter mehr, ihr könnt Online-Fernsehen alles großannounced. Und die Kunden von Comcast, einem großen Kabelanbieter in Amerika, konnten auf HBO Now nicht zugreifen. Kommt wirklich Verschwörungstheorie her, Comcast blockiert HBO Now. Das ist ja mal wirklich peinlich, haben die Angst vor der neuen Internetwelle und so was ja. Was aber wahr war, Comcast ist ein moderner ISP, der macht den SSEC-Verifikation. Wie sinnvoll das ist, wie gesagt, ist fraglich, man soll das lieber selber machen. Und HBO hat toll gelornscht, aber es den SSEC verkackt. Das heißt also nicht, die große Verschwörung war, Comcast verhindert den Zugriff, sondern Comcast ist auf der modernen Stand und die haben es nicht verstanden. Es hieß dann der Presse, sie haben es gefixt, was sie gemacht haben ist, sie haben den DS-Rekord aus der Zone rausgenommen. Die haben gesagt, wir verstehen das nicht, wir kriegen das nicht gefixt, mach das weg. Gut, kann man machen, ist natürlich das schnellste in so einem Fall. Aber davon gibt es hunderte von Beispielen, jetzt ganz neu war zum Beispiel die Kenia Top-Level-Domain. Ich fand das ganz lustig, weil auf der Mailingliste rumkam, kennt zufällig irgendwer jemand in Kenia, die gehen nicht ans Telefon. Der DS-Rekord zeigt auf einen Schlüssel, der revoked ist und auch nicht mehr das RR-Set signiert. Sprich, die ganze Kenia-Zone war halt einfach kaputt. Und das heißt eben, jeder, der eine dort signierte Domain abruft, bekommt Surf-Fail. Bekommt nicht noch unsigniert, sondern bekommt dann nichts mehr. Ist für eine Top-Level-Domain, gut, Kenia benutzen wir jetzt hier nicht so, aber in Kenia ist das nicht gut. Das heißt, also auch wirklich Betreiber von Top-Level-Domains laufen ab und zu den Probleme und eben genau hier in diesem schönen Thema des Key-Roll-Overs sprich, die haben diesen Prozess in irgendeiner Form falsch gemacht. Wahrscheinlich haben sie sofort publiziert und eben einfach Schlüssel rausgenommen, das Update im DS-Rekord war halt noch nicht durch, weil das dauert natürlich logischerweise, in so einer Routzone wird auch nicht so oft neu geladen von den Resolvern. Deswegen gibt es eben diese genauen Verfahren, wie man dazu Roll-Overn hat. Gut, wirklich in Kenia jetzt auch umgesprochen haben, schätzlich. Jetzt kam auf der Mailingliste auch irgendwie eine Antwort, ja, ich bin ja mit den Leuten schon im Kontakt und sie haben da gerade irgendwie zu viele Rekords und so weiter und so fort. Aber so was passiert immer wieder. Da gibt es gerade Comcast, alle Fälle, die sie so aufgefallen haben, nachlesen kann und das sind hunderte. Also so die List of Shame, Hall of Shame von Leuten, die DNS-Stacks verkackt haben und ihr könnt auch dabei sein, wenn ihr demnächst das mal bei euch einbaut. Genau. Ja, was wir schon sagten für das Instac-Walking, da kann man eben mit viel Spaß mit haben, nachdem man früher mit dem ARXFR anschauen konnte, was Leute haben, geht jetzt mit LDS Walk. Das ist jetzt auch kein blödes Hacker-Tool, sondern das ist einfach in so einem Standard-Paket, das war bei mir sogar, die mir den ganzen DNS-Autilis erstelliert hatte, mit drauf, ein normales Diagnosetool. Das ist auch zum Debacken sinnvoll, wenn du mal gucken möchtest, ob deine Rekord da sind, mal durchschauen willst und das ist durchaus noch verbreitet, weil erstens, wie gesagt, das gar nicht zwingend falsches ist zu benutzen und zweitens allerdings, weil viele auch nicht über nachdenken und es eben benutzen. Also, dass die NASA da 1927 für die Öffentlichkeit geeignete Rekords hat, bezweifle ich einfach mal so viele Server, die man benutzt, glaube ich eher nicht. Aber das ist ja auch ein interessanter Service, muss ich mal anschauen. Gut, wäre natürlich langweilig, wenn es das für INSEC 3 nicht auch gäbe. Das ist allerdings ein böses Hacker-Tool, also müsst auf die Hacker-Tool-Paragrafen achten, das dient nur den bösen Zwecken, würde ich sagen, ist auch nicht in irgendwelchen Standarddistributionen enthalten, ist ein C-Source, der auf DNS-Curve-Org runterzuladen ist. Sehr überraschend, wer in uns DNS-Curve von DJB, der meint, DNS-Curve wäre das Bessere als DNS-SEC. Kann man drüber diskutieren, natürlich durch den Vortrag von ihm auf den Kongress anschauen, aber jedenfalls der hat wohl gesagt, er sieht dieses Böse so ein bisschen, sage ich mal, wie Edison, der den Elefant gegrillt hat, hat der halt gesagt, ich baue jetzt das Tool, dass ihr mal seht, dass dieses DNS-SEC böse ist. Was der generell macht, das erst mal er tut mit zufälligen Hashes in die Domäne hineinfragen und hofft halt, dass er einfach dazwischen die Hashes trifft, die es gibt. Wenn das nur eine Hand vorgibt, ist man der sehr schnell fertig, wenn es halt eine Million gibt, dann muss man natürlich mindestens eine Million Pakete schicken, wer stochastig, versteht, weiß, es ist viel mehr, die man schicken muss, weil man halt immer wieder die gleichen Lücken trifft. Sprich, was man alle Lücken einmal getroffen hat, kann das schon sehr, sehr lange dauern. Das heißt, da schickt man tatsächlich noch Anfragen, die auch auf einen Tonenserver ankommen, die auch gerätlimittet werden könnten, wenn man das beschränkt, sind es aber in der Regel nicht in dem Umfang, wo man es da braucht. Aber da arbeitet man, also mit dem DNS, das ist erkennbar an der Stelle der Angriff. Was dann kommt, ist das Hashen. Das ist wie so ein Hashcat-Angriff der einmal die Hashes gesammelt hat, die wirklich echte Arbeit macht man offline. Dieses Tool, was hier auf den S-Curve liegt, ist relativ unbrauchbar. Es ist das, glaube ich, Einzige, wirklich einfach verfügbare. Sprich, wer das momentan machen möchte, wird wohl das verwenden. Das ist sehr ineffizient. Das ist Python, das benutzt zwar ein kleines C-Programm, um die Hashes zu haschen, aber es ist auch nicht benutzt von Hardwarebeschleunigungen, wird keine GPU benutzt, es werden erst recht keine Bitcoin-Mining-Hardware benutzt und es benutzt auch ein einfaches Wörterbuch und die Buchstaben durchprobieren, aber überhaupt nicht auf DNS angepasst. Also zum Beispiel, wie man bestimmte Rekordtypen sucht, wie Unterstrich-TLSA und so was, ist da nicht gemacht, nach Sternrekord sucht er überhaupt nicht. Also Sternpunkt, irgendwas könnte auch Signets sein, findet er nicht. Da ist noch viel Raum für Verbesserungen. Ich bin jetzt nicht so ganz unglücklich darüber, dass es da keine guten Tools gibt, weil N630 das Beste, was wir haben, wenn wir nicht wollen, dass man unsere Zonen listet. N650 ist in der Mache, aber ich rechne nicht, dass es in der Mache verteilt werden wird. Das ist immer so, weil das zweite verkackt man immer. Ich musste es neu schreiben, bevor ich es weggeschmissen habe. Ich weiß nicht, ob es einen N640-Standard gibt, aber N650 ist der, der momentan die höchste Chance hat, dass der N630-Standard ablösend wird, aber nicht nächstes Jahr und wahrscheinlich auch nicht über nächstes Jahr. Obwohl dieses Tool so völlig unbrauchbar ist, ich habe es mal eine Stunde, da habe ich einen Tag auf die Punkt Milldomain losgelassen und er sagt mir, er hat 81% der Rekords gefunden. Das liegt natürlich auch daran, dass die große Fans der langer sprechenden Namen sind, wie AFQMRI.mil, was dann das Emeril-Mangel-Mil vor irgendetwas ist. Also sprich, solche Namen findet man natürlich mit so einem Cracking Tool dann doch noch relativ gut. Wenn man das Ganze auf die DEzone loslässt, dann muss man viele Tage rumarbeiten und hat vielleicht 3 oder 4%. Wobei das war jetzt jemand, das habe ich nicht selber gewohnt, da gibt es einen Paper von jemandem zu, der hat auch kein spezielles deutsches Wörterbuch dafür benutzt. Da wäre es vielleicht ein bisschen mehr, wenn man die Striche und so weiter zwischen den Wörtern wird er schlechter und da müsste man dann ein besseres Tool haben. Was derjenige mit dem Paper auch versucht zu bauen, der hat ein bisschen Hashcat-Technik eingebaut, aber kann man sich anstellen, wenn man sich einen interessiert, ich habe es noch nicht ausprobiert und mal schauen, ob man damit weiter vorankommt. Aber im Prinzip, also alle Domains der DEzone kriegt man damit trotzdem noch nicht. Und was ich an der Stelle vielleicht auch noch gar nicht erwähnt hatte, im Ensec 3 hatte sich das derjenige auch noch gewünscht, dass es noch keine Option gibt. Das heißt, der Ensec 3-Rekord signiert einem nur die Sachen, die auch DNS-Sec geprüft sind. In der DEzone finde ich mit diesem Verfahren, wenn überhaupt, dann nur die DNS-Sec signierten Subdomains, was ein sehr geringer Prozentsatz ist. Alle anderen werden einfach übersprungen von diesen Hashes. Und damit ist es ein komplettes Walken der DEzone auch für Spammer durch DNS-Sec jetzt noch nicht wirklich möglich. Ja, wer das mal Walking at Home machen möchte und nicht Lust hat, bei den Mil- oder Gov- oder Ähnlichem auf die Alertliste zu kommen, für den habe ich die runtergescannten Datei mal bereitgelegt. Das heißt, also die Liste der Hashes, wohlgemerkt nicht der gehackten Namen, könnt ihr euch hier auf der Insecurity-NU-DNS-Sec Seite runterladen. Wie man sieht hier, für DE habe ich 98% der Hashes gefunden, das sagt einem das Tool, weil es einfach so viele sind, dass man noch mehr Probes machen müsste, dass man die 100 hat. Bei kleineren Zonen wie FBI.gov hat man irgendwann die 100 erreicht, bei Punkt Gov immer 99%. NL habe ich gerade mal noch am Scan, damit ich Backblood einmal in die Finger kriege, was der für Domains hat. Aber NL hat 2 Millionen signierte Domains, DE so 290.000. Das heißt, bei NL ist das Ganze deutlich aufwendiger, weil die ja schon viel eher mit angefangen haben. Ich glaube, die NL-Zone war auch schon viel länger signiert als die DE-Zone. Und natürlich sind die Länder auch einfach viel fortschrittlicher. Genau, hier steht es doch, da hatte ich auf die Erfolge darauf, dass mit dem Opt Out kriege ich eben nur die Sachen, die signiert sind. Wenn ich jetzt eine Domain durchworke, heißt das natürlich nicht, dass die darunter liegenden auch N-Sec 3 benutzen. Das heißt, im Prinzip könnte man für jeden, der Haus, den man da findet, dann testen, dass es unter Punkt Gov interessant ist, wo es dann noch mehr Sub-Domains gibt, dass die Sub-Domain davon wieder N-Sec workbar ist. Wie eben z.B. NASA Gov, wo man dann sofort die Kondite Liste hat. Und dann macht er ein bisschen diskutiert, was er da für Records bei der NASA gefunden hat, die vielleicht nicht für die Öffentlichkeit gedacht sind. Was an der Stelle ganz spaßig ist und ein bisschen gegen dieses Security und so weiter Konzept spricht von wegen, ich konnte der Netz jetzt sowieso scannen, wenn man Virtual Web Hosts hat. Die kann man durch scannen so erstmal nicht finden. Wenn ich IP-Range scanne und der nicht ein Zertifikat ausspuckt, was mir verrät, welche Namen da drauf sind, finde ich so ein Virtual Host nicht. Über so ein Walking Foundation finde ich durchaus Hosts, die ich sonst durch einfache Scans mit Hackertools nicht finden würde. Die Google kennt sie trotzdem, weil das alles kennt und eure Browserhistorik ist downloadt und so weiter, aber so ein normales Scantool würde solche Virtual Hostnames, die nicht der primary Hostname sind, die nicht in SSL drin sind, nicht finden. Also von daher ist das durchaus praxismäßig nicht ganz unrelevant. Aber gut, wer das mal auswählen möchte, kann sich hier runterladen und feststellen, das Tool ist furchtbar uneffizient. Wer sich mit Bitcoin-Mining-Hardware auskennt und schaut, ob man das noch effizienter machen kann. Genau. Und was wir jetzt eigentlich wollten, das von meinem Vortrag das und dann. Also wir sehen, es hat Nachteile, es ist furchtbar, es macht alles kaputt. Was habe ich überhaupt davon? Außerdem Spoofing-Problemen, wo ich eigentlich noch nie wirklich ernstliche Wirklichkeit mit hatte, wenn ich nicht Facebook bin. Also man hat jetzt die Idee gehabt, wir haben da ein hierarchisches, signiertes, vertrauliches Directory, da können wir doch auch vertrauliche Daten rein, nicht vertrauliche Daten, sondern Daten, wie es eine schlechte Infrastruktur sonst gibt, sind SSH-Fingerprints. Wer kennt das nicht, er hat seinen neuen Laptop, SSH vom Kongress nach Hause und stellt fest, ist das wirklich mein Fingerprint. Verdammt, ich hatte vergessen zu Hause zu manchen SSH. Dafür gibt es SSH-CRs, aber die kannst du dir verteilen. Die hast du dir nicht automatisch. Hiermit kann ich dafür als V-House-Shover-Betreiber kann ich das einfach eintragen und irgendein Kunde von mir kann alle meine Houses sofort direkt prüfen. Also ich als Betreiber der Domain halte es durchaus für einen der momentan Praxistauglichsten neuen Records, weil die kann man tatsächlich einfach benutzen und für die eigenen Domains tut das dann auch einfach gut. Und wenn ich eben meine eigene Domain dann auch mit einem Trustenker in meinem Resolveranker bin ich auch noch vorwärig sein sicher. Das heißt, es ist dann tatsächlich ein auf die Domain festgenageltes, sicher signiertes Verfahren um meine Fingerprint zu verteilen. Was ein bisschen schade ist, dass es momentan nur bis ECDSA geht, das heißt die neuen Curve und auch immer nur mal Verfahren haben noch keinen Recordtyp da drin. Ich weiß nicht, ob es das jetzt vielleicht schon gibt, da wäre da vielleicht Recordtyp 5 oder sowas. Hier sieht man wieder, dass da vorne ist der Typ des Schlüssel, dass hinten ist, wie er gehescht ist. Da gibt es momentan einen Schade 1 und einen Schade 1, wie ich ihn wünsche, das heißt, man legt 2 Hesche zu einem Key ab für den Fall, dass der Client noch nicht so modern ist. Aber genau, für die Verfahren ist eben noch nicht ECDSA momentan spezifiziert. Aber das wird sicher jetzt auch dann kommen, weil das ist ja aus relativ neu in OpenSSH drin. Hingegen, diese Verifikation ist schon ewig drin. Also OpenSSH 5.0 irgendwas kann das schon, also auch auf eurem Debian 7 oder was ihr sonst an Gabelsystem haben könntet. Oder im Redhead 6 oder irgendwelchen Sachen, die seit Jahrzehnten, seit vielen Jahren keine neuen Software-Version mehr gekriegt haben, ist das zumindest schon drin. Um es zu benutzen, muss man natürlich einen lokalen Resolver einrichten. Ein paar Parameters setzen, dass man das prüfen möchte. Das kann man eben in der Konfig machen oder wie ich es jetzt hier mache, auf der Kommando-Zeile. Und wenn man es dann ausprobiert, stellt man fest, man wird einfach nicht mehr nach dem Key gefragt. Sondern wenn das alles funktioniert, kommt dann direkt, entweder man lockt sich mit seinem Private Key direkt ein oder man wird dann mal ein Passwort gefragt. Wenn es nicht passt, dann kommt natürlich in entsprechende Meldung WHO, DNS, WRONG sind Sie sicher, dass dieser Fingerprint hier schafft. Verify Hostkey DNS YES sagen Verify Hostkey DNS ASK dann wird er einem nur sagen, ich habe das geprüft und es ist okay. Hier ist der Fingerprint, willst du es übernehmen. Das ist etwas konservativerer Ansatz, da bekommt man nur die zusätzliche Info, okay, sieht erst mal gut aus, aber ich tu wie gehabt, doch mal mit Wundern. Die Hex-Trin kommt mir so komisch vor, ihr kennt die sicher alle auswendig bei euch. Was so ein bisschen unschönig ist, ich hab noch nicht allzu genauer rum, aber er tut die dann nicht hinterlegen. Wenn ich mich fragen lasse, dann hinterlegt er. Wenn ich mich automatisch mache, macht das nicht. Das heißt, wenn ich es einmal, was ich bei SSH sonst habe, dass ich im ersten Connect angegriffen werden muss und alle danach haben keine Chance mehr, weil dann ist der Schlüssel halt gespeichert, ist hier nicht mehr so. Hier tust du jedes Mal neu verifizieren, das heißt wer es doch irgendwie schafft, dein DNS Sack zu hacken, weil er seinen Resolver umgeleitet hat, weil du eben nicht den CHAT-Triple kann dich dann bei einem weiteren Connect plötzlich erwischen, weil es nicht bei dir hinterlegt wurde. Das heißt, eigentlich doch besser ASK verwenden, dann wird es mich auch in den known hosts gespeichert und es ist weiterhin nur für die erste Verifikation notwendig. Aber ansonsten benutzt ich das für meine hosts jetzt durchaus gerne und ist auch gar nicht so. Also sehe ich jetzt keine großen Probleme mit und ist wirklich hilfreich. Wie viele benutzen hier CAs für SSH Keys? Genau. Hat mich jetzt irgendwie erwartet. Was gibt es dann noch? Fast ein bisschen das Bekannte, sage ich mal, ist inzwischen Dane-TLSA, die DNS based authentication of named entities. Das ist einfach gesagt, das Interlegen von X519-Divikaten für sie kennen im DNS-Sack. Oder im DNS, aber mit DNS-Sack macht das Sinn. Ohne DNS-Sack kann ich es auch machen, die Records kann ich alle anlegen, auch wenn ich kein DNS-Sack habe, nur wenn ich kein DNS-Sack habe, dass es das Buch bei sich von allem was es gibt. Das ist ein relativ, ich wollte nicht sagen einfach, ist eigentlich ein relativ schwieriger Rekord, aber er sieht es mal einfach aus, da vorne steht ein Port, ein Protokoll, dann der Servername, TLSA, ein paar komische Zahlen und dann im Prinzip ein Hash oder auch anderes. Das gebe mich diese Zahlen an, da gibt es ganz viele verschiedene Felders, Certificate usage, ein Selector und ein Matching-Type. Das kann ich alle möglichen Varianten machen. Ich kann einen Certificat, das von einer CA unterschrieben ist, zusätzlich dort hinterlegen. Ich kann sagen, wofür dieses Certificat gut ist. Ich kann verschiedene Hashes dieses Certificat, verschiedene Formaten hinterlegen. Ich kann eben ein Nicht von einer CA signiertes Certificat hinterlegen und das kann ich eben nicht diese Flex alle angeben. Sie haben einen RFC nachgeschoben, was definiert, wie man das Ganze bezeichnet, weil die Leute über zu viel Crowderwelsch geredet haben. Aber generell eigentlich ein gutes Verfahren, wenn ich das wieder festgenagelt kriege und damit nicht mehr das Problem habe, dass mir irgendeine Firma NNL Digi Notar oder wie auch man sie heißen könnte ein neues Certificat ausstellt, von dem ich gar nichts weiß. Bringt allerdings nur was, wenn die Kleinswimmy das nutzen, was aktuell nicht der Fall ist. Deswegen ist momentan, würde ich sagen, von dem was benutzt wird, tatsächlich in irgendwelchen Installationen Dane für SMTP, das Verbreitete. Da gibt es tatsächlich Provider, die das machen. Insgesamt noch eher wenig, aber das gibt es zumindest. Und da muss der User erstmal nichts tun. Für dieses ad hoc TLS-Verschlüsseln zwischen Anbietern. Nach dem Motto, der NSA ist ein bisschen schwieriger machen, das ist zwar keine Ersatz für Ende-zu-Ende-Verschlüsselung, aber besser Krypto als kein Krypto, damit nicht so viel Klartext durchs Netz läuft, kann das helfen, weil ich eben gegen einfache Mensenmittel, DNS-Buchen und weiter Umleiterangriffe mich schützen kann und eben auch das Certificat festlegen kann und auch kommunizieren kann, ja, ich kann TLS, ich habe es mich in mein DNS reingelegt, dass ich es kann. Das heißt, wenn man Server ist, die nicht anbietet, läuft irgendwas faul. Weil das geht bei TLS natürlich immer. Das, beispielsweise bei Start-TLS-Verfahren, sprich die keinen Extra-Port für TLS haben, geht das immer, dass ich das Protokoll einfach unterbreche und dem anderen melde, ich kann gar kein TLS. Hier könnt ihr im DNS sicher nachvollziehen, Moment, der hat aber ein Rekord publiziert. Das kommt mir jetzt komisch vor, der sah aber kein TLS anbietet. Das heißt, da kann man sagen, dann breche ich ab, bau uns im Zweifel. Wird es da circa einem Jahr, wenn das von ersten Mail-Providern genutzt, auch in Deutschland, von denen die E-Mail-Mate in Germany machen, weil das wäre ja nicht auf Deutschland beschränkt, das wäre ja bescheuert, das geht ja gar nicht. Das würde international funktionieren. Wo kämen wir denn dann hin? Dann haben wir gar keine Kunden. Nein, ich will da nicht zu sehr lasten, generell Verschlüsselung gut, aber das ist eigentlich die Variante, wie man TLS-Verschlüsselung zwischen beliebigen Providern halt hinbekommt. Das Ganze kann ich natürlich auch für HTDP machen. Es gibt auch extra RFCs, die das beschreiben. Eigentlich ist es nicht wirklich nötig, weil das alles gleiche letztendlich ist, und das werden wir ja niemals in RFCs beschrieben. Ist deswegen im kalben Browser nix-native vorhanden, anders als SMTP, das ist für den Post-Fix-Native implementierbar. Aber so Browser oder ähnliches, die es für HTDP können, gibt es nicht. Es gibt Plug-ins für Firefox, Google mag es nicht, wird es deswegen also in Chrome auch absehbare Zeit nicht geben, weil Google, wie wir im Vortrag nach diesem Vortrag, weswegen ich den Workshop verschoben habe, hören werden, andere Sachen propagiert, eben Certificate-Pinning und ähnliches Preloading von Sachen, wo sie meinen, ich habe ein Problem gefixt, Kriege, und dann brauche ich keinen DNS-Sek, weil das sei böse und so weiter. Da gibt es auch verschiedene Dokumente dazu, warum sie das zu sehen, ist auch nicht alles völlig falsch. Muss man sich überlegen, Praxis ist jedenfalls für HTDP, ist momentan der Certificate-Pinning und ähnliches der üblichere Standard, wie man seine Certifikate sicher bekommt. Also sprich, den nächsten Vortrag anhören, nehme ich jedenfalls mal an, das hier wird einem wenig bringen, weil es einfach kein User hat. Zum Beispiel für Irisi gibt es ein Patch, der auch so ein TLS-A-Record ausliest. Warum auch nicht, sind einfach X109, kann ich damit runterladen. Gut, was gibt es dann noch? Das nächste, wo wir ein Problem haben, so Key-Signing-Partys kennt jeder, wenn ich meine Domain habe, warum nicht meine Schlüssel in meine Domain legen. Ich kenne viele Leute, die ihre PGB-Key per HTTPS auf ihrer Webseite downloadbar machen. Das ist auch ein Trust-Anker, weil dann weiß derjenige zumindest, der Domainbetreiber ist auch der, und so weiter. Aus dem gibt es ja kein Standard für, wo liegt der Schlüssel genau, sprich, ein Mail client kann nicht automatisch von HTTPS ein Key runterladen, kann ich den nur links schicken. Hier kann man es hinterlegen, wie genau müsst ihr hier im RFC durchlesen, prinzipiell ist das eine gehäschte E-Mailerisse-Local-Part, sprich, da wird der Name, triffel, Ray at Irgendwas, wird dann Ray gehäscht, wird dann der Hash hingelegt, OpenPGB, Key und so weiter, und dann kommt ein Keyring. Man möchte nicht alle mit reinpacken, weil wenn es der Rekord sehr groß wird, so dass der Empfänger auch noch die Chain of Trust prüfen kann. Aber er weiß jedenfalls, der Domain-Oner hat den Key da reingetan, also sowas könnte durchaus in Clients mal kommen, dass man sagt, okay, ich habe ein Key mit den S gefunden, der ist sicher, ich habe sicher abgefragt, willst den benutzen. Damit wäre PGB ad hoc sicher tatsächlich machbar, und was er bei Key Silver nicht viel bemängelt wurde, da könnt ihr irgendein hochladen, du kriegst den nicht mehr revoked. Fever hat das Problem zum Beispiel, mit dem Key Silver kriegt man den nicht mehr weg. Bei Key Silver sagen, du musst eine Revocation-Zertifikat haben, um dir löschen zu können. Da gibt es keinen, ich schick dir die E-Mail, dann klickst du drauf, der wird das gelöscht, sondern du hast den Key hochgeladen, musst dir revoken können. Hier, du hast die Zone, du kannst ihn rausnehmen, ist einfach. Das Gleiche gibt es auch für Esmime, das ist allerdings noch sehr in Entwicklung. Dann ist es die Frage, Esmime ist in mehr Clients drin, PGB benutzen mehr Leute, in der Hacker-Welt, sag ich mal, der PGB-Record ist sehr ähnlich wie TLSA aufgebaut, also auch ein bisschen schwieriger als der Open-PGB-Record. Aber, ja, ist im Prinzip das gleiche Idee, die gar nicht gleiche Vorteile ergeben sich, und eben bei X500 neu wie das Vorteil, ich habe meinen einen definierten Trastenker, die DE-Zone signiert, meine zu Domänen, und nicht irgendwelche anderen können für meine Domänen Schlüssel ausstellen. Was bei Esmime genau so geht, bei Esmime hat man genau wie behalte DP das Problem, dass jede CA einen Schlüssel ausstellen kann und im Zweifel auch irgendein Behörden Schlüssel ausstellt, um für die komischen Sachen, die man erkennt. Jetzt hat man noch einen, der was ausstellen kann, aber ich kann dem natürlich auch noch extra, wenn ich in der Firma einsetzen möchte, kann ich meine Domänen da aber wieder verankern, das heißt, ich weiß, bei mir innerhalb der Firma klappt das, oder ich traue den Deutschen zumindest mal für DE und so weiter. Irgendwie muss man trauen, aber ich traue nicht mehr der ganzen Welt. Das ist durchaus schon fokussierter, sag ich mal, weil, genau. So, wir kommen auch schon zum Abfluss, welchen Minuten? Ein paar Links. Das heißt, da sind die Links, da sind die Download von den Hashtag-Teilen und so weiter. Aber was wir auf jeden Fall machen, können wir uns eigentlich den kleinen Test machen, kriegt man das böse Gesicht oder das liebe Gesicht und dieser Visualizer, der macht solche Bilder, wie ich sie vorhin auch gezeigt habe, dieser Key zeigt auf diesen, zeigt auf diesen Rekord. Das ist sehr hilfreich und sehr schön, wenn man eben mal gucken möchte, was wurde denn da jetzt erzeugt. Genau, dann noch ein paar RFCs, die Sie jetzt schon später nachlesen, die in dem ganzen Kontext ganz sinnvoll sind. RFCs lesen sind immer so ein bisschen trocken, aber die sind teilweise ganz praktisch, gerade die Operational Practices. Ansonsten hat die Hautaus lesen, die es maschenhaft im Netz gibt. Und wie gesagt, ich warte jetzt hier den nächsten Vortrag noch ab und wenn er das ganze Mal zum Beispiel eine Subdomain delegiert haben möchte oder noch kompliziertere Fragen hat oder mir sagen möchte, was ich hier getan habe, ist alles Unsinn, weil Google hat Recht. Wir treffen um 16.30 Uhr nach dem TLS Talk gegenüber, also gegenüber dem Nebengebäude im ersten Stock, Workshop Raum 3, so ein kleiner Raum kann man sich hinsetzen. Kann ich euch auch direkt mal so ein Nameserver-Rekord eintragen auf eure Delegation, wenn ihr irgendwo ein Rootserver habt mit dem Nameserver. Richtet euch einen Bein 99 ein, delegiere ich euch wegen der Domain. Funky.nu fertig. Für die Leute in den Stream schauen, würde ich euch auch noch machen, wenn ihr mir eine Mail schickt oder also das Video nachher anschauen. Genau, jetzt ganz kurze Fragen, die einfach sind noch. Ausführliches bitte im Workshop und ansonsten vielen Dank fürs eine Stunde zu hören. Vielen Dank. Gibt es eigentlich für diese Surf-Fail-Geschichte, dass man da eigentlich keine so richtige Information kriegt? DNS-Sack hat jetzt irgendwie gefehlt. Gibt es da irgendwie ein Grund dafür, dass man da nicht mehr Infos rüber reicht? Ich vermute, der Grund ist, dass es kompatibel bleiben sollte. Dass sie wollten, dass man die Resolver libt, hat da gar kein API dafür. Also deine Clients müssen dafür nicht wirklich angepasst werden, dass das funktioniert, weil sie einfach abfragen, wie gehabt. Das dürfte der Grund sein. Wenn man sagt, Checking disabled, kann ein Fager-Client, der sagen, ich will selber prüfen. Dann schlust du mit CD-Fleck-Anfragen, bekommst alle Infos, wenn du in der Software bist, die weiß, was DNS-Sack ist. Das machen solche Plugins zum Beispiel. Keine Frage, kurze Anmerkung. Das TLSI-Verifying-Plugging gibt es auch für Chrome. Auf der gleichen Seite, irgendwo beim tschechischen Nick, glaube ich war das. Und das zweite, du hattest gesagt, bind mit Inline-Signing ist für einen Einsteiger ganz praktikabel und nimmt einem viel Arbeit ab. Das nimmt einem unter anderem auch das Key-Rollover ab. Und zwar, weil bind regelmäßig in seinen Keys-Directory guckt, ob die neue Keys liegen und ob die gerade gültig sind. Also die haben ja jeweils eine Publish-Time, eine Activate-Time, etc. Es nimmt einem das Rollover, man muss den neuen Key eigentlich nur anlegen. Das stimmt schon, aber es nimmt einem nicht so viel Arbeit ab, wenn man sagt, ich möchte ein Algorithm Change machen und sagen, ich möchte erst nur das RR-Set signieren und dann die Records signieren und so was, was diese Verfahren vorschlagen. Das macht nicht, das signiert einfach automatisch mit allem, was man ablegt. Das stimmt. Und wenn ich dann jeweils zwei oder mehrere Keys habe, die sich jeweils um zwei, drei Tage überlappen, habe ich damit immer sicher in den Caches weltweit meine Records liegen. Man muss halt trotzdem selber noch hingehenden neuen Key anlegen. Wenn ich jetzt möchte, dass alle 30 Tage meinen Key ersetzt wird, muss ich mir ein Shell Script schreiben, was alle 30 Tage einen neuen Key generiert. Das ist eben ein Bord, das ist ein Kontab weiterentwickelt. Das Bein hilft einem schon, das signiert selber, aber es macht halt nicht selber neue Keys. Das meint ich. Wenn du viele Domains hast, musst du selber hingehen neue Keys erzeugen. Noch eine Frage oder gerne Anmerkungen? Anmerkungen noch lieber? Nee, eine Frage. Hast du mal geprüft, wie die Tools, die zum Beispiel den TLSR Records benutzen, ob die alle auch wirklich prüfen, dass es DNS signiert ist? Wenn es DNS-Seq gibt, kann ich den Keys bufen und der würde dann eventuell akzeptiert werden. Ich habe es natürlich nicht alle Tools probiert, über die normalen Plugins prüfen. Natürlich habe ich dann eine Antwort, den DNS-Seq fähig war. Alternativ sagen Sie dir, du musst eben sicherstellen, dass dein Resolver verrefined ist. Du sagst, ich habe die Local die Resolve Conf gefixt, ich habe sie festgenagelt und dann käme ja Surffeld zurück. Das heißt, da muss das Tool ja nichts mehr checken. Das Wichtige ist schon, dass man selber weiß, man traut dem richtigen Server, man hat nicht einfach eine Resolve. Letzte Frage, dann ist hier eine Minute aus? Dann nicht mehr. Also wie gesagt, gerne nach dem TLS Talk im Workshop Room 3, erster Stock nebenan. Okay.