Die Erklärung des DNS-Kauderwelsches

Ein Leser schreibt, er habe mein Informatiker-Kauderwelsch zur DNS-Sperre für Russia Today nicht verstanden. Ob ich das nochmal erklären könnte.

Klar kann ich.

Ich hatte einen Artikel geschrieben, und der Leser schreibt

Hallo,

gerne lese ich Ihre Seite, aber bisweilen ist ihr Insider- oder Informatiker-Kauderwelsch abträglich. Z.B.:
„Trage ich die IP-Adressen direkt in /etc/hosts ein, umgehe also das DNS, kann ich auf de.rt.com zugreifen. Daher ist es zunächst mal eine Sperre der großen IP-Provider über deren zentrale DNS-Recursor, und vermutlich ist man davon nicht betroffen, wenn man über einen kleineren Provider geht oder aus einem Firmennetz heraus seinen eigenen Recursor betreibt.“ usw.

Erklären Sie mir/uns dann auch mal, was denn „rekursen“ heißt.

„rekursen“ war spontanes Danisch-Kauderwelsch, damit wollte ich sagen, dass ich mal eben (mit dem Befehl dig und entsprechenden Parametern) von Hand, manuell durchexerziert habe, was ein „Recursor“ automatisch machen würde, um nachvollziehen zu können, an welcher Stelle was nicht mehr geht, wo also diese Sperre der Webseiten von Russia Today ansetzt.

Die Frage ist also, was ein „Recursor“ ist.

Die Sache ist etwas komplexer. Ich hatte vor vielen Jahren, als ich damals in der Kinderpornosperrensache mal nach einer Knieoperation zwei Wochen zuhause rumsitzen musste, auch so ein Einführungsbändchen geschrieben, das ich schon immer mal zum DNS-Fachbuch aufbauen wollte, aber nie dazu gekommen bin.

Ich erkläre es mal stark vereinfacht, damit es in einen Blog-Artikel passt.

Das DNS, das Domain-Name-System, sorgt dafür, dass man mit symbolischen Namen, die mit den Internet-Domains, also alles, was hinten so auf .com, .de, .edu und so weiter endet, zusammenhängt, damit man diese symbolischen Namen verwenden kann, statt immer die IP-Adresse einzugeben. Wenn Ihr also auf meine Webseite unter www.danisch.de geht, dann sagt dieses DNS dem Browser, welche IP-Adresse zu „www.danisch.de“ gehört. Über den sogenannten A-Record (beim alten IPv4) oder den AAAA-Record (beim neuen IPv6). Und wenn Ihr mir eine Mail an meine Mailadresse schickt, dann sagt dieses DNS Eurem Mailsystem, und zwar über den sogenannten MX-Record, unter welcher IP-Adresse man den Mailserver (meinen) für die Domain danisch.de (das rechts vom Klammeraffen @ in der Mailadresse) findet, damit man da auch was hinschicken kann.

Wie funktioniert das nun?

Grob (und etwas vereinfacht) gesagt, gibt es drei Arten von Teilnehmern an diesem DNS. Wobei ich da einen nochmal in zwei unterscheide oder den alts vierte Art führen könnte. Ich erkläre die jetzt.

Aufbau von Domainnamen

Zunächst mal muss man verstanden haben, dass diese Domainnamen hierarchisch sind, und die Wurzel bzw. höhere Ebene ungewöhnlicherweise rechts steht. Hat man also einen Hostnamen wie www.danisch.de, dann ist der in der Hierarchie unter danisch.de und danisch.de unter der für Deutschland de und de unter … ja, worunter ist das dann eigentlich?

Dazu jetzt Geheim- und Insiderwissen. Eigentlich ist ein Name wie www.danisch.de zwar üblich, aber unvollständig, weil immer dann, wenn am Ende kein Punkt ist, noch die default-Domain probeweise drangehängt wird. Wenn Ihr also einer Firma mit der Domain beispiel.de seid, könntet ihr dort auch einfach www statt www.beispiel.de schreiben. Weil immer dann, wenn kein Punkt am Ende ist, noch die Default-Domain angehängt wird, um erst mal da zu suchen. Bei Rechnern, die das genau nehmen, könnte www.danisch.de also dann, wenn ich das in meinem Netzwerk mache, auf www.danisch.de.danisch.de rauslaufen. Deshalb sind die Browser und so weiter alle so gebaut, dass die diese vereinfachte Darstellung richtig behandeln, aber eigentlich heißt der Name richtig www.danisch.de. mit einem Punkt am Ende. Der nämlich zeigt an: Ende, Fertig, kommt nix mehr.

Und deshalb ist die Deutschland-Domain de , die richtigerweise de. (mit Punkt am Ende) heißt, in der Hiearchie unter der Domain . aufgehängt (die also nur aus einem Punkt besteht). Die ist die Wurzel des ganzen Domain-Name-Systems, daran ist das alles aufgehängt. Unter . gibt es de. und unter de. gibt es danisch.de. und darunter ist dann der Hostname www.danisch.de. eingetragen. Kann man beliebig lang machen. Ich kann problemlos auch www.mitte.berlin.danisch.de. als Namen verwenden. Oder www.hadmut.danisch.de. Das ist also wie so ein Baum konstruiert, bei dem die Wurzel am rechten Ende des Namens liegt und durch einen einzelnen Punkt dargestellt wird.

Authoritative Nameserver

Diese sogenannten Authoritative Nameserver sind solche, die nur für eine (oder mehrere) Domains als Quelle der Information zuständig sind.

Denn irgendwo muss die Information ja herkommen. Kann ja nicht jeder den anderen fragen „Pssst, sag mal, weißt Du, wo …?“ Dann fragen die sich ja ewig im Kreis und keiner weiß es.

Es muss also Nameserver geben, die Fragen beantworten können, ohne selbst noch jemanden fragen zu müssen, einfach weil sie es wissen. Weil sie die Quelle des Wissens sind. Da gibt es beispielsweise Nameserver, die für die Domain danisch.de. (aber nicht nur für die, auch noch für ein paar andere) zuständig sind, und wenn man die fragt, können die direkt sagen, dass der A-Record für www.danisch.de. auf die IP-Adresse 116.203.181.35 lautet. Das weiß der Nameserver dann so, ohne noch irgendwen fragen zu müssen, weil er selbst zuständig ist und die Ur-Auskunft gibt.

Woher weiß der das dann, wenn er es doch nirgends nachgefragt hat?

Der weiß das, weil ich das da reingeschrieben habe. Ich persönlich. Ich habe das in eine solche „Zonendatei“ geschrieben, und der authoritative Nameserver für danisch.de. ist der Weg, auf dem ich der Welt mitteile, wo man mein Blog findet. Genau so dann auch für de.rt.com für Russia Today, nur halt dann eben deren Nameserver und nicht meiner.

Was anderes macht der nicht. Wenn man den fragt, wie etwa die Adresse von www.google.com oder www.bundeskanzler.de lautet, dann sagt der „Weiß ich nicht. Dafür bin ich nicht zuständig!“. Weil man dafür einen Recursor fragt und keinen Authoritative. Warum und was das ist – dazu kommen wir gleich.

Clients

Dann gibt es noch die auf der anderen Seite, die das DNS nutzen.

Wenn Ihr also beispielsweise im Browser www.danisch.de eingebt oder mir eine Mail an meine Mailadresse schickt, dann sagen der Browser oder das Mailprogramm zum Betriebssystem: Löse mir mal www.danisch.de oder danisch.de in eine IP-Adresse auf! Mach mal, mir egal wie, aber hole eine Antwort.

Jetzt hat man das aber so gebaut, dass Euer Rechner damit möglichst wenig zu tun hat und möglichst doof sein kann, und deshalb ist Euer Recher im Normalfall (wenn Ihr keinen eigenen Recursor dort installiert habt) gar nicht in der Lage, www.danisch.de aufzulösen, weil er nicht weiß, wo der Nameserver für danisch.de steht, um ihn zu fragen.

Euer Rechner kann auch nur ganz doof fragen.

Also fragt Euer Rechner einen Recursor, Du, sag mal, kannst Du mir sagen, welche IP-Adress zu www.danisch de gehört? Oder eben zu de.rt.com?

Dann dauerts etwas und es rumpelt etwas, und dann antwortet der Recursor entweder mit „Ja, klar, kann ich, hier ist die Antwort“, oder mit „T’schudigung, hat nicht geklappt, kann ich gerade nicht“, und dann zeigt der Browser eine Fehlermeldung Hostname not found oder irgendsowas.

Woher aber weiß der Rechner, wo er den Recursor findet, den er fragen muss?

Da gibt es verschiedene Methoden:

• Man kann es von Hand konfigurieren, das macht heute aber fast niemand mehr.
• Wenn Ihr den Rechner an das Netzwerkkabel oder WLAN anschließt, bekommt der per DHCP eine IP-Adresse zugewiesen, und dabei meist auch die Angaben, wie die Default-Domain (zu bist jetzt in der Firma beispiel.de) heißt und unter welcher IP-Adresse man den Recursor findet.
• Wenn Ihr euch per DSL beim Provider einwählt (oder wie früher mit Modem oder ISDN) bekommt Ihr über das PPP-Protokoll den Recursor mitgeteilt.

Der Recursor

Der Recursor (gelegentlich auch Resolver genannt) ist das Bindeglied zwischen dem doofen Client (z.B. Euer PC mit Webbrowser), der bloß doof fragen kann „Was’n die IP-Adresse für www.danisch.de?“ und dem Authoritative Nameserver für “danisch.de”.

Also:

• Der Client fragt doof „Wie ist die IP-Adresse für www.danisch.de, damit mein Browser die Webseite abrufen kann?“
• Der Authoritative Server für “danisch.de” weiß zwar, wie die IP-Adresse ist, weil ich das da eingetragen habe, steht aber auch nur blöd rum und wartet, dass einer kommt und fragt.
• Der Recursor ist das Bindeglied zwischen beiden:
  1. Er macht ausfindig, wo der Authoritative Nameserver für danisch.de steht, also welche IP-Adresse der hat,
  2. dann fragt er ihn, was die IP-Adresse für www.danisch.de ist,
  3. und schickt die Antwort an den Client, der doof gefragt hat.

So funktioniert das. Wie aber findet der Recursor den Authoritative Nameserver für danisch.de um ihn zu fragen, wie die IP-Adresse von www.danisch.de ist?

Er macht es rekursiv. Deshalb heißt er Recursor.

Um herauszufinden, wo man den Nameserver für danisch.de. findet, geht er eine Stufe höher und fragt den Nameserver für de. danach. Läuft damit also in das Problem, ja noch nicht zu wissen, wo der Nameserver für de. steht um den nach danisch.de zu fragen. Jetzt die Rekursion (also ein Problem durch Lösung des gleichen Problems, aber kleiner, zu lösen): Er fragt die Nameserver für die Root-Domain . (nur der Punkt), wo er die Nameserver für de. findet. Das sagen die ihm. Und die fragt er, wo er den Nameserver für danisch.de findet. Sagen die ihm auch. Und den fragt er, weil er der Authoritative Nameserver ist und nicht auf einen anderen zeigt, sondern selbst weiß, was die IP-Adresse ist.

Der Recursor hat also nacheinander de. danisch.de. und www.danisch.de aufgelöst.

Woher aber wusste der Recursor, wo er die Nameserver für die Root-Domain . (nur der Punkt) findet? Antwort: Die kann er nicht finden. Die ändern sich sehr selten und werden deshalb fest eingetragen. Der Recursor weiß also immer, wo er mit der Suche anfangen muss.

Und weil das alles zu schrecklich vielen Anfragen führen würde, macht der Recursor noch etwas: Er ist ein Cache. Er speichert Informationen zwischen.

Jeder Authoritative Server, und da ist es egal, ob Ihr den für . nach de. fragt, den für de. nach danisch.de. oder den für danisch.de. nach www.danisch.de. fragt, gibt mit der Antwort auch an, wie lange diese Antwort gültig ist, bis sie neu erfragt werden muss. Wenn man etwas häufig ändert, kann man da kurze Zeiten von ein paar Sekunden eintragen. Und wenn man weiß, dass man es nur sehr, sehr selten ändert und das nicht hektisch passiert, kann man auch zwei Wochen oder mehr eintragen.

Trägt man also etwa für www.danisch.de eine Gültigkeit von einer Stunde ein, merken sich der Recursor (und manche Clients) die Antwort eine ganze Stunde lang. Auch wenn Ihr ganz viele Blogartikel bei mir lest, wir dann trotzdem nur einmal pro Stunde nach er IP-Adresse gefragt. Oder alle zwei Wochen, wenn man diese Frist einträgt.

Das macht ein Recursor.

Und mit „rekursen“ meinte ich, dass ich das, was ein Recursor macht, einzeln von Hand gemacht hatte, um herauszufinden, an welcher Stelle es genau nicht mehr funktionierte, als man de.rt.com sperrte.

Woher kommt er Recursor

Blöde Antwort: Es gibt zwei Wege. Man macht ihn selbst. Oder nicht.

Solche Recursor macht man normalerweise selbst, die Software ist frei verfügbar, und stellt normalerweise ein oder zwei pro Firmennetz auf. Typischerweise haben Firmennetze mindestens einen eigenen. Das ist ein PC, auf dem eine Software läuft. Fertig. Da muss man auch nicht viel konfigurieren oder pflegen, den stellt man hin und dann läuft der. Ziemlich einfache Sache.

Weil aber der Aufwand für Heimnetze und manche Kunden doch zu groß wäre, und manche Kunden erwarten, dass „Internet geht“, wenn man „Internetkabel reinsteckt“, ist es Standard, dass die Internetprovider auch noch Recursor betreiben, die man benutzen kann, und zwar ganz große. Das ist nicht nur komfortabel, sondern hat auch Geschwindigkeitsvorteile. Denn wenn Ihr Euch abends an den Rechner setzt, und auf www.danisch.de geht, müsste Euer eigener Recursor erst mal die ganze Kette auflösen. Das kann durchaus ein paar Sekunden dauern, wenn es ungünstig läuft. Fragt Ihr aber den Recursor des Providers, dann wird der oft ganz schnell antworten, weil ich schrecklich viele Leser habe, und die Wahrscheinlichkeit sehr hoch ist, dass kurz vor Euch ein anderer Kunde des Providers meine Webseite besucht hat, und die Antwort noch auf Lager ist, weil sie ja eine Stunde (oder was eben angegeben ist) zwischengespeichert wird, bevor man neu fragt. Das kann also von Vorteil sein.

Forwarder

Gerade wegen diesen Heimnetzen gibt es noch eine vereinfachte Form: Forwarder, wie Ihr Sie in Euren Home-Router habt.

Die tun zwar gegenüber alle Rechnern in Eurem Heimlan so, als wären sie ein großer Recursor, geben sich als Recursor per DHCP aus, können aber diese Kette, wie ich sie beschrieben habe, nicht selbst auflösen, weil sie nicht genug Speicherplatz und Rechenleistung haben. In Wirklichkeit schicken sie die Anfrage nur an den großen, dicken Recursor des Providers weiter. Also: Gaukeln Eurem LAN vor, sie wären ein Recursor, reichen die Anfrage aber dann an den Recursor des Providers weiter, als wären sie ein Client, und umgekehrt mit der Antwort.

So funktioniert das alles.

Wie funktionieren nun Sperren wie die Kinderpornosperre Ursula von der Leyens oder hier von RT?

Im Recursor des Providers wird eingetragen, dass für die Frage de.rt.com (oder ähnliches) keine Antwort erfolgt. Genauer gesagt: Schon eine Antwort, aber die Antwort „Weiß ich nicht…gibt’s nicht“, weil das auch eine Antwort ist, die zwischengespeichert wird. Was ein Authoritative antworten würde, wenn man ihn etwas fragt, was nicht eingetragen wurde, was er nicht kennt.

Und weil die ganzen Kunden über ihre Heim-Router, die Forwarder spielen und das alles an den Recursor des Providers weiterschicken, da dann auch mit dran hängen, sehen die dann die Webseite nicht mehr.

Warum ist es Bullshit?

Ganz einfach: Man bekommt zwar keine Antwort mehr, wenn man den Recursor des Providers verwendet. Das muss man aber nicht. Man kann sich ohne weiteres seinen eigenen Recursor bauen, Software gibt’s kostenlos, und nur wenig konfigurieren, und schon hat man die Sperre umgangen. Oder einfach einen anderen fragen. Es gibt öffentlich zugängliche Recursor.

Zumal all die Geschäftskunden und Unternehmen mit eigenem Recursor (eigentlich der Normalfall) davon gar nicht betroffen sind und funktionieren wie immer.

Verstanden?

Glückwunsch.

Wenn Ihr das jetzt verstanden habt, dann seid Ihr schlauer als Ursula von der Leyen und ihr Frauenministerium von 2009. Denen habe ich auch schon versucht zu erklären, warum es nicht funktioniert und man es trivial umgehen kann, und die haben es nicht kapiert. Die waren unverrückbar überzeugt, dass das DNS so eine Art Webseitenkarussel ist, und die Provider monolithische Webseiten wie ehedem BTX ausliefern.