Warum ist DNS immer noch so schwer zu lernen?

• DNS wird seit den 1980er-Jahren seit über 35 Jahren genutzt und seine Struktur ist stabil, trotzdem brauchen viele Programmierer lange, bis sie grundlegende Probleme sicher debuggen können
• Die Schwierigkeit liegt weniger in der Komplexität von DNS selbst als in den vielen unsichtbaren Komponenten wie Resolver-Caches, lokalen DNS-Bibliotheken und der Kommunikation mit autoritativen Nameservern
• dig ist leistungsfähig, aber Ausgabeformat und Begriffe sind ungewohnt; Funktionen wie +norecurse sind zwar nützlich, die Interpretation der Ergebnisse ist aber nicht intuitiv
• Häufige Fallstricke wie Negative Caching, die frühere fehlende TCP-DNS-Unterstützung in musl, Resolver, die TTL ignorieren, dauerhaftes Caching durch nginx oder Kubernetes ndots lernt man nur schwer, solange einen niemand darauf hinweist
• Für Menschen, die nur selten mit DNS arbeiten, helfen Cheat Sheets; Probleme, bei denen Experimente riskant wirken, lassen sich durch sichere Experimentierumgebungen wie Mess With DNS entschärfen

---

DNS: alt, aber trotzdem schwierig

• DNS wird seit den Zeiten von RFC 1034 seit über 35 Jahren genutzt, kommt auf jeder Website im Internet zum Einsatz und funktioniert in vielerlei Hinsicht ähnlich wie vor 30 Jahren
• Trotzdem kann es lange dauern, grundlegende Probleme zu debuggen, etwa „Die Domain ist korrekt eingerichtet, wird aber nicht aufgelöst“ oder „dig und der Browser liefern unterschiedliche DNS-Ergebnisse“
• Menschen, die DNS schwierig finden, bleiben meist an folgenden Punkten hängen
  • Schon einfache DNS-Änderungen für eine Website fühlen sich nicht selbstverständlich an
  • Sie verwechseln, dass DNS-Records nicht gepusht, sondern gepullt werden
  • Sie kennen die Grundbegriffe, geraten aber bei Detailverhalten wie Negative Caching oder Unterschieden zwischen DNS-Abfragen von dig und Browsern durcheinander

Unsichtbare Resolver und Nameserver

• Der grundlegende Ablauf einer DNS-Anfrage vom Computer aus wirkt einfach
  • Der Computer stellt eine Anfrage an einen Server namens Resolver
  • Der Resolver prüft seinen Cache und fragt bei Bedarf erneut bei einem autoritativen Nameserver nach
• Mehrere für das Debugging wichtige Elemente sind standardmäßig nicht sichtbar
  • Es ist schwer zu erkennen, was sich im Cache des Resolvers befindet
  • Lokal ist nicht offensichtlich, welche DNS-Bibliothek die Anfrage verarbeitet
    • Möglich sind libc getaddrinfo, glibc, musl, Apples Implementierung, eigener DNS-Code des Browsers oder separate Custom-Implementierungen
    • Jede Implementierung unterscheidet sich leicht bei Konfiguration, Caching-Verhalten und unterstützten Funktionen
    • musl DNS unterstützte bis Anfang 2023 kein TCP
  • Die Kommunikation zwischen Resolver und autoritativem Nameserver ist nicht sichtbar
    • Wenn man nachvollziehen könnte, welcher autoritative Nameserver abgefragt wurde und welche Antwort er geliefert hat, ließen sich viele DNS-Probleme leichter verstehen

Ansätze, um versteckte Systeme sichtbar zu machen

• Schon zu zeigen, welche versteckten Komponenten es gibt, hilft beim Lernen enorm
  • Wer nicht weiß, dass selbst auf einem einzelnen Computer je nach Situation mehrere DNS-Bibliotheken verwendet werden können, kann lange verwirrt bleiben
• Mess With DNS versucht einen Fishbowl-Ansatz für Experimente, bei dem normalerweise unsichtbare Teile sichtbar werden
  • Es macht Teile der Kommunikation zwischen Resolver und autoritativem Nameserver sichtbar
• Eine weitere Möglichkeit ist, Debugging-Informationen in DNS-Antworten aufzunehmen
  • Es gibt bereits eine Funktion namens Extended DNS Errors oder EDE
  • Tools fügen EDE-Unterstützung nach und nach hinzu

Hinweise durch Extended DNS Errors

• Extended DNS Errors sind eine neue Methode, mit der DNS-Server in Antworten zusätzliche Debugging-Informationen bereitstellen können
• Fragt man die nicht existierende Domain xjwudh.com mit dig @8.8.8.8 xjwudh.com ab, kann folgender zusätzlicher Fehler erscheinen

; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)

• Dieses Beispiel scheint sich auf DNSSEC zu beziehen; wichtig ist, dass in der Antwort eine zusätzliche Debug-Meldung mitgeliefert wird
• Um das obige Beispiel zu sehen, war eine neuere Version von dig erforderlich

Leistungsfähig, aber schwer zu lesen: dig

• Um den internen Zustand von DNS zu prüfen, ist dig nützlich
• Mit dig +norecurse lässt sich prüfen, welche Records ein bestimmter DNS-Resolver im Cache hat
  • 8.8.8.8 scheint SERVFAIL zurückzugeben, wenn die Antwort nicht im Cache ist
  • google.com ist im Cache und liefert daher NOERROR sowie einen A-Record zurück
  • homestarrunner.com ist nicht im Cache und liefert SERVFAIL, aber das bedeutet nicht, dass es keinen DNS-Record gibt
• Die Ausgabe von dig ist schwer zu lesen, wenn man sie nicht gewohnt ist
  • Überschriften wie ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION: und ANSWER SECTION: sind ungewohnt
  • Zeilenumbrüche und Leerzeichen zwischen den Abschnitten wirken nicht konsistent
  • Bei MSG SIZE rcvd: 47 ist schwer zu erkennen, ob es außer rcvd noch andere Felder gibt
  • Man muss wissen, dass zwar von 1 Record in der Sektion ADDITIONAL die Rede ist, tatsächlich aber die OPT PSEUDOSECTION diese Rolle übernimmt
• Die Ausgabe von dig wirkt weniger wie ein von Anfang an bewusst entworfenes Format, sondern eher wie ein Skript, das mit der Zeit organisch gewachsen ist

DNS-Tools lesbarer machen

• Dokumentation, die die Ausgabe von dig selbst erklärt, ist hilfreich
  • how to use dig erklärt die Struktur der dig-Ausgabe und wie man die Standardausgabe kürzer einstellt
• Man kann auch freundlichere Tools bauen
  • Es gibt Alternativen wie dog, doggo und DNS lookup tool
  • Wenn man jedoch fortgeschrittene Funktionen wie +norecurse braucht, kann es besser sein, alles mit dig zu erledigen
  • Den großen Funktionsumfang von dig zu ersetzen, ist eine große Aufgabe
• Denkbar wäre auch, der dig-Ausgabe eine Option wie +human hinzuzufügen, die dieselben Informationen strukturierter darstellt
  • Header, Anfrage, Antwort, zusätzliche Sektionen, Zeit, Server, Protokoll und Antwortgröße könnten klar getrennt werden
  • Der Ansatz wäre nicht, Informationen zu reduzieren, sondern dieselben Informationen lesbarer darzustellen
• Aktuelle Versionen von dig haben ein Ausgabeformat +yaml
  • Es kann klarer wirken, ist aber so ausführlich, dass selbst eine einfache DNS-Antwort unter Umständen nicht auf einen Bildschirm passt

Häufige, aber schwer zu lernende DNS-Fallstricke

• Bei DNS gibt es Fallstricke, denen man relativ häufig begegnet, die man aber nur schwer erkennt, solange einen niemand darauf hinweist

• Negative Caching

  • Wenn man eine Domain besucht, für die es noch keinen DNS-Record gibt, kann der „nicht vorhanden“-Status dieses Records gecacht werden
  • Wenn dieser Zustand mehrere Stunden im Cache bleibt, wird es sehr lästig

• Unterschiede bei getaddrinfo-Implementierungen

  • musl unterstützte bis Anfang 2023 kein TCP-DNS

• Resolver, die TTL ignorieren

  • Selbst wenn man die TTL eines DNS-Records auf 5 Minuten setzt, können manche Resolver sie ignorieren und deutlich länger cachen, etwa 24 Stunden

• nginx-Konfigurationsprobleme

  • Wenn nginx falsch konfiguriert ist, kann es DNS-Records dauerhaft cachen

• Kubernetes ndots

  • ndots kann Kubernetes-DNS verlangsamen

Fallstricke teilen und dokumentieren

• Wissen über seltsame Fallstricke ist schwer zu bekommen, und es ist ineffizient, wenn Menschen dieselben Probleme immer wieder neu entdecken müssen
• Wenn man ein Thema erklärt, ist es sehr hilfreich, häufige Fallstricke gleich mit anzusprechen
  • Als Beispiel außerhalb von DNS erklärt Josh Comeaus Einführung in Flexbox die minimum size gotcha
• Auch Community-Sammlungen häufiger Fallstricke sind nützlich
  • Bei Bash ist shellcheck als Sammlung von Bash-Fallstricken sehr hilfreich
• Die Dokumentation von DNS-Fallstricken ist auch deshalb schwierig, weil verschiedene Nutzer auf unterschiedliche Probleme stoßen
  • Wer alle drei Jahre einmal DNS für eine persönliche Domain einrichtet, erlebt andere Fallstricke als jemand, der DNS für eine stark frequentierte Domain betreibt

Seltene Nutzung und schwieriges Experimentieren

• Viele Menschen arbeiten nur sehr selten mit DNS
  • Wenn man nur alle drei Jahre einmal mit DNS zu tun hat, ist es ganz natürlich, dass es schwer zu lernen ist
  • Cheat Sheets wie „Ablauf zum Ändern von Nameservern“ können hilfreich sein
• DNS ist außerdem eine Technik, mit der man nur ungern experimentiert, weil man die eigene Domain kaputtmachen könnte
  • Mess With DNS wurde entwickelt, um diese Hürde beim Experimentieren zu senken

[GN⁺]

Meinungen auf Hacker News

• Dem stimme ich nicht zu. DNS ist meiner Ansicht nach nicht wirklich schwer zu lernen; es gibt nur wenige, die sich die Zeit nehmen, es zu lernen.
  Das Gute an DNS ist, dass das System bei Anfragen seinen internen Zustand offenlegt. Man kann sich DNS-Server für bekannte Zonen ansehen und ihr Verhalten leicht nachvollziehen, und kostenlose Tools wie dig sind weit verbreitet verfügbar.
  Es hat mich in meiner Laufbahn immer wieder überrascht, dass sich Leute, mit denen ich zusammengearbeitet habe, vor allem an mein DNS-Wissen erinnern, weil ich nicht das Gefühl habe, etwas Mysteriöses oder Besonderes zu wissen. DNS ist sehr gut standardisiert, gängige Server- und Client-Implementierungen halten sich strikt an die Standards, und mit kostenlosen Tools lässt es sich leicht beobachten. Es braucht nur Mühe und Zeit, wirklich schwierig ist es nicht.

  • Aus der Perspektive der Person, die diesen Artikel geschrieben hat, möchte ich zur Sichtweise, dass DNS eigentlich nicht schwer ist, ein paar Dinge sagen. Es hat mehrere Jahre gedauert, bis ich DNS-Probleme wirklich entspannt debuggen konnte, und ich habe den Artikel geschrieben, um zu erklären, warum es für mich schwierig war.
    Früher dachte ich, „Nein, eigentlich ist es einfach!“ sei eine Ermutigung als Antwort auf „es ist schwer zu lernen“. Ich mag DNS und finde es in vielerlei Hinsicht erstaunlich einfach. Unter https://implement-dns.wizardzines.com zeige ich zum Beispiel, wie man mit einfachem Python-Code einen Spielzeug-DNS-Resolver von Grund auf implementiert.
    Mit der Zeit habe ich aber gelernt, dass „Nein, es ist leicht zu lernen!“ oft weniger als „Du schaffst das!“ verstanden wird, sondern eher als „Es ist nicht schwer, du bist nur dumm“. Wenn man bei einem Thema jahrelang verwirrt war, hilft es nicht besonders, zu hören: „Eigentlich ist es doch einfach.“
    Deshalb sage ich das inzwischen nicht mehr, sondern investiere viel Mühe darin, zu verstehen, warum Menschen bestimmte Dinge schwierig finden, und diese Hürden zu senken.
  • Gemessen an den Tools zum Lernen von DNS finde ich schon, dass es schwer zu lernen ist.
    BIND macht seine Aufgabe hervorragend, aber die Konfigurationsdateien sind nicht besonders schön, das Handbuch ist lang und trocken und manchmal unnötig kompliziert. dig ist mächtig, kürzt aber alles so ab, als wären wir noch in der Zeit von 80-Spalten-Terminals. Beim Debuggen von DNS-Problemen war Wireshark für mich manchmal ein besseres Tool als dig.
    Wenn man PowerDNS oder einen anderen modernen DNS-Server verwendet, dürfte es viel einfacher sein, einen funktionierenden DNS-Server einzurichten. Einen guten modernen DNS-Client kenne ich nicht wirklich, also habe ich mich letztlich an dig gewöhnt. Als jemand, der beim ip-Befehl das Flag --color nutzt, würde ich mir wünschen, dass Tools wie dig eine modernere Ausgabe hätten. Die Kommandozeilen-Flags packe ich mir schon in Aliasse; ich wünsche mir nur, dass die Funktion eingebaut wird.
    Ernsthaft: MSG SIZE rcvd: 71 hätte man nicht abkürzen müssen. Auch flags: qr rd ra hätte man ausschreiben können. Ich weiß auch nicht, was die Semikolons am Zeilenanfang vermitteln sollen; sie sorgen eher für Verwirrung.
    Es ist nicht verwunderlich, dass Leute verwirrt sind, wenn sie DNS mit dem verfügbaren Material lernen.
  • Du hast gesagt, du stimmst „diesem Artikel nicht zu“, aber du gehst kaum auf die Argumente des Artikels ein und scheinst eher nur dem Titel zu widersprechen. Außerdem scheinst du DNS ist schwierig und DNS zu lernen ist schwierig zu vermischen.
    Wenn es „nur ein wenig Mühe und Zeit“ braucht: Wie viel Mühe und Zeit genau? Mehrere Leute in diesem Thread sagen, sie hätten es gelernt, indem sie einen Server implementiert haben, und erzählen, dass sie Monate gebraucht haben, um es zu verstehen, nur um dann zu wiederholen: „Wenn man es einmal verstanden hat, ist es ziemlich einfach.“ Können wir uns dann nicht darauf einigen, dass es für etwas so Allgegenwärtiges und konzeptionell Einfaches in der Praxis tatsächlich schwer zu lernen ist?
  • Wenn man den Artikel liest, steht dort, warum es schwer zu lernen ist. Die Konzepte sind einfach, aber beim Vermitteln der Konzepte werden nicht alle Details des modernen Internets einbezogen.
    Zum Beispiel: Welche Regeln gelten dafür, wie ein Browser DNS-Einträge cached und ablaufen lässt? Sind diese Regeln über Browser hinweg konsistent?
  • DNS ist meiner Ansicht nach eine dieser Technologien, bei denen man die ganze Karriere über hier und da nur Bruchstücke aufschnappen und weitermachen kann. Wenn mehr Leute gezwungen wären, sich direkt damit auseinanderzusetzen, würde es sich weniger komplex anfühlen, als es tatsächlich wahrgenommen wird; in der Branche bekommen solche Dinge dadurch eine Art Mystik.

• Ich finde, der Artikel trifft den Kern sehr gut. DNS selbst ist nicht schwierig, aber DNS in der realen Welt zu lernen ist schwierig. Denn vieles auf dem Weg von der beabsichtigten Abfrage bis zum erwarteten Ergebnis ist verborgen.
  Früher bestand die grundlegende Internetverbindung aus einer Schnittstelle, einem Gateway und einem DNS-Server-Anbieter. Heute ist man manchmal gleichzeitig über mehrere WANs wie LTE und WiFi verbunden, und für Nutzer ist schwer zu erkennen, welcher Auflösungspfad tatsächlich genutzt wurde. Unklar ist auch, ob es der Browser war, die Standardschnittstelle der C-Bibliothek des Systems, ein lokaler Resolver oder ein rekursiver Resolver dazwischen, ob es einen lokalen Cache gibt oder ob standardmäßig spezielle Optionen angehängt werden.
  Selbst wenn alles funktioniert, kann man nicht blind darauf vertrauen, dass die Anfrage und Antwort einer Anwendung denselben Pfad genommen haben wie bei einer anderen Anwendung. Drei Browser können jeweils unterschiedliche Methoden verwenden, das Betriebssystem verhält sich wieder anders, und mDNS kann noch eine fünfte Option hinzufügen.

• Es gibt den Witz, dass es in der Informatik nur drei schwierige Probleme gibt: Cache-Invalidierung und Namensgebung.
  Und DNS ist ein Caching-System für die Namen von Dingen.
  https://reddit.com/comments/15c2ul2/comment/jtty9dy

  • Fairerweise ist DNS eines der Beispiele, bei denen Namensgebung richtig gemacht wurde.
    Es wird global verwaltet (IANA), ist hierarchisch, föderiert und leicht zu ändern.

• DNS ist eine Technologie, bei der es eine Diskrepanz zwischen dem gibt, wie einfach sie wirkt, und dem Schwierigkeitsgrad, der sich in der Praxis zeigt.
  Wir nutzen DNS täglich, und es wirkt sehr einfach. Die Alltagssprache von DNS besteht aus Domainnamen, Lookups und IP-Adressen. Diese Sprache ist direkt im Browser sichtbar, und aus dieser Sichtbarkeit entsteht ein mentales Modell dafür, wie es funktioniert.
  Im Inneren gibt es jedoch eine völlig andere Sprache: Zonen, Resolver, delegierte Autorität und den seltsamen Punkt hinter Top-Level-Domains.

  • Dieser seltsame Punkt heißt Root. Ohne Punkt ist ein Name nicht vollständig; mit Punkt ist der Name vollständig definiert. Der Kontext ist also alles. Fehlt der Punkt, kann der Resolver die eigene Domain oder Teile davon immer wieder anhängen.
    Zum Beispiel wissen wir beide, was host.example.co.uk bedeutet, aber ohne abschließenden Punkt könnte ein Resolver versuchen, host.example.co.uk.example.co.uk aufzulösen.
    Mit den Windows-Standardeinstellungen kann es in so einem Fall passieren, dass host.example.co.uk.example.co, host.example.co.uk.example, erneut host.example.co.uk.example und dann host.example.co.uk. versucht wird, um ein Ergebnis zu bekommen. Allerdings habe ich noch nie gesehen, dass Windows tatsächlich den ersten Versuch macht; dieses Verhalten scheint dafür entworfen worden zu sein, Unternehmensumgebungen mit einem föderierten Monstrum namens Active Directory zu bewältigen.
    Heutige Browser schleichen sich ohne Zustimmung der Nutzer mit hoher Wahrscheinlichkeit zu DNS-over-HTTPS(DoH)-Servern davon und treiben sich mit allerlei fragwürdigen Gegenstellen herum. DNS-Lookups sind grundlegende Daten, und ISPs mochten es, sehen zu können, wohin Nutzer gehen. Betriebssystemanbieter können natürlich ebenfalls „Telemetrie“ senden. Google besitzt zwar nicht den Desktop, aber den Browser; wenn man Nutzer dazu bringt, statt des von ihnen konfigurierten DNS einen „sicheren“ DNS-Server zu verwenden, ist das gut für Google. Durch solche Tricks ist IT-Fehlersuche deutlich spannender geworden als früher.
    Um den abschließenden Punkt muss man sich nicht allzu große Sorgen machen. Wahrscheinlich nutzt man ohnehin fast sicher nicht den DNS-Server, den man zu nutzen glaubt. Ich verstehe, warum DoH entwickelt wurde, und für manche normalen Nutzer gibt es auch Gründe dafür. Wenn etwa jemand, der kein IT-Profi ist, einen bösartigen WLAN-Hotspot nutzt, bietet es einen gewissen Schutz, wenn der Browser für DNS-Lookups sicher nach Hause telefoniert. Ob Browseranbieter deshalb die Endpoint-Security-Entscheidungen der Nutzer übergehen dürfen, ist aber eine andere Frage.
    DNS ist viel komplexer als bloß Adressen nachzuschlagen. Heute geht es um Geld, und eigentlich war das seit etwa 2000 schon immer so. Inzwischen gibt es viele sehr eigensinnige Großunternehmen, die darüber bestimmen wollen, wer über die Nutzer profitiert.
  • Schwierig ist meiner Ansicht nach der verteilte Teil. Oberhalb der atomaren Ebene einzelner Knoten passiert enorm viel schwarze Magie, und sie erzeugt den Großteil der Komplexität und den Großteil der Undurchsichtigkeit.
    DNS selbst ist einfach. Die Verteilung von Informationen ohne Bindung an eine Organisation ist wirklich knifflig.

• Vor ein paar Jahren wurde mir klar, dass ich DNS nur bruchstückhaft verstand. Ich kannte dig(1), BIND und das CS101-Niveau der Konzepte dazu, wie rekursive DNS-Auflösung funktioniert, aber mir fehlte das Praxiswissen, das nötig ist, um nichttriviale Systeme zu entwerfen und zu implementieren oder nicht funktionierende Systeme zu debuggen.
  Also las ich „DNS and BIND“ fast von Anfang bis Ende und setzte für ein paar weniger wichtige persönliche Websites auch echte BIND-Server auf. Es war nicht schwer, erforderte aber eine ordentliche Zeitinvestition. BIND ist nicht für viele Anwendungsfälle die richtige Antwort, war aber sehr wertvoll, weil viele DNS-Konzepte und -Begriffe weiterhin aus BIND stammen.
  Ich denke, Bücher werden beim Lernen solcher Dinge unterschätzt. Materialien im Web sind meistens entweder High-Level-Theorie, etwa Blockdiagramme rekursiver Lookups, aufgabenorientierte Anleitungen wie rekursive Lookups mit dig, oder Low-Level-Material, bei dem man Quellcode liest, um die Retry-Policy des lokalen DNS-Clients zu verstehen. Um die einzelnen Teile zu verstehen, wie sie ineinandergreifen, was sie erreichen sollen, und bis hin zur Implementierung, etwa wo Caches sitzen, gibt es kaum einen Ersatz für den ganzheitlichen Ansatz, den man oft in Büchern findet. Im Web gibt es das nicht gar nicht, aber es ist selten.

• Alle IT-Verantwortlichen sollten am besten Praxiswissen zum Debuggen von DNS-Problemen haben.
  DNS war historisch ein Einfallstor für wichtige Sicherheitslücken und wird es wahrscheinlich weiter bleiben. Solche Schwachstellen führen zu Angriffswegen in fast allen anderen Protokollen, etwa SMTP. Selbst das für HTTPS verwendete Zertifizierungsstellen-System hängt stark von einem grundsätzlich unsicheren Protokoll ab. Würde man merken, wenn eine Bank statt eines OV-Zertifikats ein DV-Zertifikat gekauft hätte? Vermutlich nicht.
  Deshalb ist es nicht unbedingt schlecht, wenn DNS für Menschen ohne ausreichendes Interesse schwer zu lernen wirkt. Denn man sieht auch heute noch Leute, die DNS-bezogene Funktionen bauen, ohne sich die Zeit zu nehmen, die Geschichte von Dingen wie Port-Randomisierung, Cache Poisoning und AXFR wirklich zu verstehen.

  • Alles, was auf irgendeiner Schicht des Netzwerks Routing-Entscheidungen broadcastet oder behauptet, wirkt oberflächlich einfacher, als es ist, und fühlt sich potenziell gefährlich an.

• Als schamlose Werbung für ein Nebenprojekt: Im Artikel hieß es, es wäre schön, einen „Debug“-Modus für DNS-Auflösung zu haben; die Web-UI von ComfyDNS hat genau diese Funktion :3
  https://comfydns.com/
  Das Bild oben mit TRACE google.com A IN zeigt diese Funktion.
  ComfyDNS ist auch ein Projekt, mit dem ich ein persönliches Jucken gekratzt habe. Ich war es leid, bind9-Zonendateien von Hand zu bearbeiten, und wollte außerdem wissen, wie DNS funktioniert. Die Oberfläche kannte ich, die Details nicht, also habe ich die RFCs „von Grund auf“ implementiert. Netty habe ich verwendet, aber keine DNS-Library. Es hat ziemlich Spaß gemacht.
  Bitte verzeiht, wenn die Website dem Traffic nicht standhält und ausfällt. Es ist eine Rails-App, die im Free Tier von Oracle Cloud läuft.

• Der Witz, den man immer hörte, war, dass DNS die zwei schwierigsten Probleme der Informatik kombiniert: Namensgebung und Cache-Invalidierung.

  • DNS hat Gültigkeitszähler in Sekunden, und beim Zählen dieser Sekunden darf man ziemlich locker sein.
    Es ist nicht die schwierige Art von Cache-Invalidierung. Tatsächlich muss man fast nie etwas „invalidieren“.
    Auch serverseitig ist es völlig zulässig, eine Zeit lang alte und neue Version gemischt auszuliefern.
  • Das ist kein Witz, sondern stimmt.

• Es fühlt sich an, als wäre schon wieder so ein Artikel erschienen. In den 1990ern war das Internet kleiner, und Computer waren viel langsamer und leistungsschwächer, aber wir haben es sehr leicht gelernt.
  Für ISPs waren Dinge wie DNS, LDAP, SMTP, IMAP damals absolutes Grundwissen, und die Leute haben tatsächlich offizielle Dokumente wie RFCs gelesen. Wer im Internet Server betreiben wollte, musste das lernen, und mit etwas Zeitaufwand – also bezahlter Arbeitszeit – konnte man es lernen.
  Die heutige Generation von Entwicklern und DevOps-Leuten hat keine Geduld oder Eigeninitiative, erwartet, alles vorgekaut zu bekommen, und kopiert wahllos irgendetwas von StackOverflow und aus minderwertigen Blogs. Statt die Grundlagen zu lernen, auf denen das Internet aufgebaut ist, greifen sie zum neuesten hippen Wrapper-Tool der Woche und folgen miserablen Blog-Anleitungen. Wenn dann alles zusammenbricht und die Firma viel Geld verliert, fühlen sie sich ungerecht behandelt. Das liegt daran, dass sie sich nie die Zeit genommen haben, die Grundlagen dazu zu lernen, wie es im Internet wirklich funktioniert.
  Ich habe das immer wieder gesehen. Es ist wirklich nicht so schwer. Man muss einfach seine Hausaufgaben machen.

• Es ist nicht schwer. DNS ist eine der wenigen Technologien, die sich nicht stark verändert haben, und seine Funktionsweise ist ziemlich intuitiv.
  dig kann etwas verwirrend sein. Es kann mehr als das alte nslookup, ist aber weniger intuitiv. Nebenbei: nslookup funktioniert immer noch gut.
  Einer der Gründe, warum jüngere Leute in der Branche bei DNS und den Kernprotokollen durcheinanderkommen, ist meiner Meinung nach, dass heute zu viele Dinge „einfach funktionieren“.
  Ein heutiger WLAN-Router zum Beispiel funktioniert direkt nach dem Auspacken „einfach“. Anfang der 2000er brauchte man für die Einrichtung solcher Dinge einen Netzwerktechniker, der DNS, IP, Ethernet, RFC1918, echte Routing-Protokolle und vieles andere kannte – und wahrscheinlich auch gut wusste, warum es so konfiguriert wurde.
  Wenn man DNS aus Client-Sicht verwirrend findet, sollte man mal BIND konfigurieren ;-)
  /Gejammer eines alten Unix-Barts

  • Mit 14 habe ich die Active-Directory-Umgebung eines Restaurants, inklusive Mail, Web und CIFS, stümperhaft verwaltet, ohne DNS oder DHCP zu verstehen.
    Ich hätte den DHCP-Server des WRT54G so einrichten müssen, dass er die statische IP des Domain Controllers als DNS-Server für die korrekte Namensauflösung verteilt. Stattdessen habe ich alles irgendwie mit IP-Adressen und Einträgen in der hosts-Datei zum Laufen gebracht. Den MX-Record der Domain habe ich ebenfalls auf die WAN-IP des Routers gesetzt, und PTR-Records gab es nicht. Rückblickend ist es ein Wunder, dass die E-Mail-Zustellung so reibungslos funktioniert hat.
    Ein paar Jahre später habe ich verstanden, wie DNS tatsächlich funktioniert, und Anfang 20 habe ich ein internes Intranet geerbt, das BIND als Nameserver für alle externen Unternehmens-Domain-Zonen nutzte. Um die Zuverlässigkeit zu erhöhen, habe ich diese Konfiguration auf VPS umgezogen und dabei enorm viel über Zonentransfers, SOA und Ähnliches gelernt. Für diese Erfahrung bin ich dankbar, aber heute wird fast alles davon für einen erledigt, sodass es zu einer Tätigkeit mit geringem Wert geworden ist. Ob gut oder schlecht: „IT“ wird nicht auf dieselbe Weise bewertet wie „Software Engineering“.
  • Dass die Funktionsweise vergleichsweise intuitiv ist, stimmt – aber nur, wenn man alle möglichen seltsamen Verhaltensweisen wie Server, die TTL ignorieren, ausblendet.
    Ich werde nie das Update vergessen, mit dem Firefox DNS-over-HTTPS standardmäßig aktiviert hat. Wir verteilten per DHCP interne DNS-Server an die Workstations, und plötzlich kamen lauter Meldungen wie „Meine E-Mails sind verschwunden! Alles ist kaputt!“ herein. Internes Webmail und Intranet-Webserver sahen aus, als wären sie einfach verschwunden.
    Herauszufinden, was passiert war, dauerte unnötig lange. Zum Teil lag das an dem Gedanken: „Es ist DNS – warum sollte das plötzlich kaputtgehen?“ Aber es ist ziemlich offensichtlich, dass Mozilla dieses leicht vorhersehbare Problem nicht vorausgesehen hatte.
  • Die hier genannten Dinge sind nur ein kleiner Teil von DNS.
    Wenn ich zum Beispiel thing.behind.cdn.it auflöse, bekomme ich eine Antwort, während jemand anderes für denselben Namen eine andere Antwort bekommt. Das ist an sich ziemlich offensichtlich, wird aber kompliziert, wenn jemand vernünftigerweise fragt: „Könnt ihr für thing.behind.cdn.it ein Loch in die Firewall öffnen?“
    Manche Server leiten Anfragen weiter, manche delegieren, manche lösen stellvertretend auf und manche nicht. Dazu kommt die Magie der Suchdomains auf Client-Seite, und es ist unklar, ob Clients oder interne Resolver-Bibliotheken TTLs einhalten.
    Es gibt unzählige Record-Typen, und manchmal fordert ein Server dazu auf, statt über UDP erneut per TCP zu verbinden.
    Deshalb ist DNS ziemlich komplex. Es funktioniert sehr gut, und die meisten schwierigen Teile sind in Dinge abstrahiert, die „im Großen und Ganzen einfach funktionieren“, wodurch die Illusion entsteht, es sei simpel.
  • Was das Wissen über alte Protokolle angeht: In den letzten Wochen habe ich Networking for System Administrators gelesen und viele Anki-Karten dazu erstellt und wiederholt.
    Es ist erstaunlich, wie viel sicherer ich mich jetzt dabei fühle, Networking auf hoher Ebene zu verstehen – einschließlich DNS und den darunterliegenden Dingen wie ethtool und Ethernet-Frames.
    Ich mag es, Dinge von Grund auf zu verstehen, und habe deshalb an der Uni Elektrotechnik statt Informatik gewählt; vielleicht sollte mich das also nicht überraschen.
  • Stimmt, BIND zu konfigurieren ist schwierig. Unbound/nsd sind viel leichter zu handhaben. Allerdings ist schon das Finden der richtigen Dokumentation eine nervige Übung.
    Das Prinzip von DNS ist nicht so schwer, wenn man versteht, dass es rekursiv ist. Aber wenn man es mit Blick auf Sicherheit konfigurieren, die richtige Infrastruktur haben und jedes letzte Detail korrekt hinbekommen will, gibt es viel zu lernen. Wenn man BIND ausklammert, ist es nicht so schwer.