Domain Name System

Abkürzung: DNS

Ohne DNS müsste jeder Dienst unter seiner IP-Adresse angesprochen werden. Die eigentliche Leistung liegt aber nicht in der Übersetzung, sondern in der Verteilung: Niemand hält alle Namen, und trotzdem findet jede Anfrage ihre Antwort.

Wie eine Auflösung abläuft

Beteiligt sind vier Rollen. Der Stub-Resolver im Betriebssystem stellt die Frage. Der rekursive Resolver — beim Zugangsanbieter, im eigenen Netz oder bei einem öffentlichen Anbieter — beantwortet sie, indem er die Hierarchie abläuft. Die autoritativen Server halten je einen Teil der Daten, eine Zone.

Stub-Resolver                 Rekursiver Resolver        Autoritative Server
  "netzikon.net A?"  ────────▶
                                   "netzikon.net A?" ───▶  Wurzelzone  .
                                   ◀─── "frag die net-Server"
                                   "netzikon.net A?" ───▶  Zone  net.
                                   ◀─── "frag ns1.example"
                                   "netzikon.net A?" ───▶  Zone  netzikon.net.
                                   ◀─── "203.0.113.10"
  ◀──── "203.0.113.10"

Die Unterscheidung dabei: Der Stub-Resolver fragt rekursiv — er will die fertige Antwort. Der rekursive Resolver fragt die autoritativen Server iterativ; die antworten nicht mit dem Ergebnis, sondern mit dem Verweis auf die nächste Stufe.

Der Weg wird nur beim ersten Mal vollständig gegangen. Danach liegen die Zwischenergebnisse im Speicher des Resolvers.

Die wichtigsten Eintragsarten

Eine Eigenheit, die regelmäßig für Fehler sorgt: Ein CNAME darf nicht neben anderen Einträgen desselben Namens stehen. Deshalb lässt sich die Wurzel einer Domain — example.net ohne Unterdomain — nicht per CNAME umleiten, denn dort müssen NS und SOA liegen. Anbieter umgehen das mit eigenen Konstruktionen, die nicht Teil der Norm sind.

Die Abfrage im Werkzeug

$ dig netzikon.net A

;; QUESTION SECTION:
;netzikon.net.                  IN      A

;; ANSWER SECTION:
netzikon.net.           3600    IN      A       203.0.113.10

;; Query time: 24 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)

Die Adressen sind hier Beispiele aus den für Dokumentation reservierten Bereichen. Aufschlussreich sind die drei Angaben rechts: 3600 ist die Haltbarkeit in Sekunden, IN die Protokollfamilie, A der Typ. Fehlt der Abschnitt ANSWER und steht stattdessen AUTHORITY, hat die Zone den Namen nicht — eine Antwort, die ebenfalls eine Antwort ist.

Zwischenspeicher und Haltbarkeit

Jeder Eintrag trägt eine Haltbarkeit, die Time to Live. Solange sie läuft, beantwortet ein Resolver die Frage aus dem Speicher, ohne jemanden zu fragen.

Daraus folgt die Verzögerung bei Änderungen — und ein verbreitetes Missverständnis. Es gibt keine „DNS-Propagation", bei der sich eine Änderung durch das Netz verteilt. Nichts wird verteilt: Die autoritativen Server antworten unmittelbar neu, und die Resolver erfahren es jeweils dann, wenn ihre gespeicherte Kopie verfällt. Die gefühlte Ausbreitung ist nur das Auslaufen vieler unabhängiger Haltbarkeiten.

Praktisch heißt das: Wer eine Umstellung plant, senkt die Haltbarkeit vorher — Tage im Voraus, denn auch die alte Haltbarkeit muss erst ablaufen — und hebt sie danach wieder an.

Auch die Nichtexistenz wird gespeichert. Ein Name, der zu früh abgefragt wurde, bleibt deshalb eine Weile unauffindbar, selbst wenn er inzwischen eingerichtet ist.

Transport

DNS nutzt Port 53, über UDP und TCP. Historisch galt UDP für Abfragen und TCP nur für Zonenübertragungen und zu große Antworten.

Diese Arbeitsteilung ist durch die Erweiterung EDNS(0) verschoben worden: Sie erlaubt größere UDP-Antworten, als die ursprünglichen 512 Byte vorsahen, und ist Voraussetzung für DNSSEC, dessen Signaturen die Antworten erheblich vergrößern.

Zu große UDP-Antworten werden auf IP-Ebene fragmentiert, und fragmentierte Pakete gehen auf manchen Strecken verloren. Das erzeugt ein unangenehmes Fehlerbild: Die Auflösung funktioniert für kleine Antworten und scheitert bei großen — also etwa für eine signierte Zone, aber nicht für eine unsignierte. Wer solche Fälle sucht, prüft zuerst, ob der Rückfall auf TCP funktioniert.

Verschlüsselt wird der Transport über DNS over TLS auf Port 853 oder DNS over HTTPS auf Port 443.

Reverse Lookup

Die Auflösung einer Adresse zu einem Namen läuft nicht spiegelbildlich, sondern über eigene Zonen. Die Adresse wird dafür umgedreht und an eine feste Domain gehängt: Aus 203.0.113.10 wird 10.113.0.203.in-addr.arpa, bei IPv6 entsprechend unter ip6.arpa.

Verwaltet werden diese Zonen von dem, der den Adressbereich zugewiesen bekommen hat — also beim Anbieter, nicht beim Domaininhaber. Deshalb lässt sich ein PTR-Eintrag für eine Adresse nicht einfach selbst setzen, und deshalb stimmen Vorwärts- und Rückwärtsauflösung oft nicht überein. Für Mailserver ist das relevant, weil viele Empfänger einen passenden PTR-Eintrag verlangen.

Was DNS nicht leistet

Im ursprünglichen Entwurf fehlen beide Sicherheitseigenschaften, und das ist kein Versehen, sondern dem Alter geschuldet.

Keine Echtheit. Eine Antwort gilt als gültig, wenn sie formal passt. Gefälschte Antworten lassen sich einschleusen, siehe DNS-Spoofing. Nachgerüstet wird das über DNSSEC.

Keine Vertraulichkeit. Abfragen und Antworten sind im Klartext mitlesbar. Dafür gibt es DNS over TLS und DNS over HTTPS.

Beide Nachrüstungen sind unabhängig voneinander und ersetzen sich nicht.