6.4 DNS

Warum DNS entstanden ist

In kleinen Netzen lassen sich Namen und Adressen noch in lokalen hosts-Dateien pflegen. Mit wachsender Teilnehmerzahl werden zentrale Verteilung, Aktualisierung und Konfliktvermeidung jedoch unbeherrschbar. Paul Mockapetris beschrieb DNS 1983 zunächst in RFC 882 und RFC 883. Die grundlegenden RFC 1034 und RFC 1035 ersetzten diese Dokumente 1987 und wurden seitdem durch zahlreiche Standards erweitert.

DNS ist heute zugleich Namensraum, verteilte Datenbank und Protokoll. Seine Aufgabe ist nicht auf die Zuordnung eines Hostnamens zu einer IP-Adresse beschränkt. Es veröffentlicht unter anderem zuständige Nameserver, Mailserver, Textinformationen, Dienstparameter und kryptografische Daten für DNSSEC.

Labels, Domainnamen und FQDN

Ein Domainname besteht aus einer geordneten Folge von Labels. In der üblichen Schreibweise werden Labels durch Punkte getrennt. Die Hierarchie wird von rechts nach links gelesen: Bei www.example.de steht de näher an der Root, darunter folgt example und darunter www. Der abschließende Punkt in www.example.de. stellt das leere Root-Label ausdrücklich dar und kennzeichnet den vollständig qualifizierten Namen.

Ein Label umfasst im DNS-Wire-Format höchstens 63 Oktette. Der vollständige Name darf dort einschließlich Längenangaben und Root-Label höchstens 255 Oktette belegen. Die ältere pauschale Regel, jedes Label müsse mit einem Buchstaben beginnen, gilt nicht allgemein; für Hostnamen sind jedoch strengere Zeichenregeln üblich. Internationalisierte Namen werden für das DNS über IDNA in ASCII-kompatibler Form dargestellt.

Root, TLD, Domain und Delegation

Die Root-Zone steht an der Spitze des globalen DNS. Sie delegiert Top-Level-Domains wie de, ch, com oder org an deren zuständige Nameserver. Länderspezifische TLDs werden als ccTLDs bezeichnet; generische TLDs als gTLDs. Die heutige Auswahl ist wesentlich größer als die ursprünglich wenigen generischen TLDs.

Eine Delegation überträgt die Verantwortung für einen Teilbaum des Namensraums an andere autoritative Nameserver. Die übergeordnete Zone veröffentlicht dafür NS-Einträge und bei Bedarf Glue Records mit Adressen, damit die delegierten Server erreichbar sind. Eine Domain ist ein Bereich des Namensraums; eine Zone ist der administrativ zusammenhängend veröffentlichte Teil davon. Beide Begriffe sind daher nicht immer deckungsgleich.

Autoritative Nameserver und Resolver

Ein autoritativer Nameserver beantwortet Anfragen aus den maßgeblichen Daten einer Zone. Sowohl Primary- als auch Secondary-Server sind autoritativ. Der Primary bezieht die Zone typischerweise aus einer lokal gepflegten Quelle; Secondaries übernehmen sie über Zonentransfer oder andere Bereitstellungsverfahren. Die ältere Aussage, ein Secondary sei nicht autoritativ oder seine Daten seien grundsätzlich ungesichert, ist falsch.

Ein rekursiver Resolver sucht Antworten im Auftrag seiner Clients und speichert Ergebnisse zeitlich begrenzt im Cache. Er ist für fremde Zonen normalerweise nicht autoritativ. Ein einzelner DNS-Serverprozess kann je nach Konfiguration mehrere Rollen besitzen, diese sollten aber begrifflich getrennt bleiben.

Rekursive und iterative Namensauflösung

Bei einer rekursiven Anfrage soll der angesprochene Resolver die vollständige Auflösung übernehmen. Autoritative Server beantworten dagegen typischerweise die Frage aus ihrer Zone oder liefern einen Verweis auf zuständigere Server. Der rekursive Resolver führt diese iterativen Schritte aus.

Vor externen Anfragen prüft der Resolver seinen Cache. Resource Records besitzen eine Time to Live, kurz TTL. Sie begrenzt, wie lange ein Ergebnis weiterverwendet werden darf. Auch negative Antworten wie NXDOMAIN können zwischengespeichert werden. Änderungen an einer Zone sind deshalb nicht sofort überall sichtbar, sondern verbreiten sich abhängig von vorherigen Cacheeinträgen und deren Restlaufzeit.

Root-Server richtig verstehen

Das Root-Server-System veröffentlicht die Root-Zone. Es gibt 13 benannte Root-Serveridentitäten von A bis M, weil das historische Protokoll- und Paketformat diese überschaubare Menge begünstigte. Diese Bezeichnungen stehen nicht für nur 13 physische Rechner. Jede Identität wird über viele weltweit verteilte Anycast-Instanzen bereitgestellt.

Ein rekursiver Resolver fragt Root-Server nur, wenn sein Cache keine ausreichenden Delegationsinformationen enthält. Root-Server kennen normalerweise nicht die Adresse jedes beliebigen Hosts. Sie verweisen auf die zuständigen Nameserver der Top-Level-Domain. Die IANA-Funktionen für die Root-Zone werden durch Public Technical Identifiers im ICANN-Umfeld ausgeführt; die Root-Server werden von mehreren unabhängigen Organisationen betrieben.

DNS-Nachrichten und Transport

Klassisches DNS verwendet Port 53 über UDP und TCP. Kleine Anfragen und Antworten werden häufig über UDP übertragen. TCP ist jedoch kein reiner Sonderweg für Zonentransfers: DNS-Implementierungen müssen TCP unterstützen, unter anderem für große Antworten, abgeschnittene UDP-Antworten und robuste Kommunikation. AXFR-Zonentransfers verwenden TCP; Benachrichtigung und Prüfung von Seriennummern folgen eigenen Abläufen.

Die historische UDP-Nutzlastgrenze von 512 Byte gilt für klassisches DNS ohne Erweiterungen. EDNS(0) erlaubt größere UDP-Nachrichten und zusätzliche Optionen. Zu große UDP-Antworten können fragmentiert werden oder verloren gehen. Resolver müssen das gesetzte TC-Bit als abgeschnittene Antwort erkennen und gegebenenfalls auf TCP wechseln. Eine übermäßig große angekündigte EDNS-Puffergröße ist nicht automatisch sinnvoll.

Aufbau einer DNS-Nachricht

Anfrage und Antwort verwenden denselben Grundaufbau. Ein 12 Byte langer Header enthält Transaktionskennung, Flags und Zähler für die folgenden Bereiche. Danach folgen Question, Answer, Authority und Additional. Namen können innerhalb einer Nachricht per Zeiger komprimiert werden.

Wichtige Resource-Record-Typen

Ein Resource Record besteht unter anderem aus Name, Typ, Klasse, TTL und typabhängigen Daten. Records gleichen Namens und Typs bilden ein RRset. CNAME ist kein beliebiger Zusatztext, sondern kennzeichnet einen Alias, dessen Zielname weiter aufgelöst wird. PTR wird für Reverse DNS genutzt und liegt bei IPv4 unter in-addr.arpa beziehungsweise bei IPv6 unter ip6.arpa.

Zonenverwaltung und Zonentransfer

Der SOA-Record enthält unter anderem eine Seriennummer. Secondaries vergleichen den Stand und können eine vollständige Zone per AXFR oder Änderungen per IXFR übernehmen. NOTIFY kann sie auf eine mögliche Änderung hinweisen. Transfers dürfen nicht unkontrolliert für beliebige Clients zugänglich sein, weil Zonendaten interne Strukturen offenlegen können.

Redundanz erfordert mehrere autoritative Server, möglichst in getrennten Fehlerdomänen. Eine hohe Seriennummer allein beweist jedoch keine korrekte oder konsistente Zone. Betreiber müssen Syntax, Delegationen, DNSSEC-Zustand, Erreichbarkeit über IPv4 und IPv6 sowie Antworten über UDP und TCP überwachen.

DNSSEC: Herkunft und Integrität prüfen

DNS Security Extensions ergänzen kryptografische Signaturen und eine Vertrauenskette von der Root über Delegationen bis zur signierten Zone. RRSIG enthält Signaturen zu RRsets, DNSKEY veröffentlicht Zonenschlüssel und DS verknüpft eine Delegation mit dem Schlüssel der untergeordneten Zone. NSEC beziehungsweise NSEC3 ermöglichen den authentisierten Nachweis, dass ein Name oder Record nicht existiert.

Ein validierender Resolver unterscheidet erfolgreich validierte Daten, absichtlich unsignierte Bereiche und fehlerhafte beziehungsweise bogus Antworten. DNSSEC bietet Datenherkunftsauthentisierung und Integrität, aber keine Vertraulichkeit. Schlüsselwechsel und Signaturgültigkeit müssen sorgfältig betrieben werden; alte Nutzungsstatistiken oder ein einzelnes Root-Key-Rollover-Datum sind keine dauerhafte Beschreibung des Verfahrens.

DoT, DoH und DoQ

DNS over TLS, DNS over HTTPS und DNS over QUIC verschlüsseln die Verbindung zwischen Client und Resolver. Dadurch können Beobachter auf diesem Abschnitt die DNS-Nachrichten nicht ohne Weiteres mitlesen oder verändern. Der verwendete Resolver sieht die Anfragen weiterhin, und die weitere Auflösung zu autoritativen Servern ist nicht automatisch Ende-zu-Ende verschlüsselt.

DoT verwendet einen eigenen Port und ist im Netz vergleichsweise eindeutig erkennbar. DoH nutzt HTTPS und kann sich daher in gewöhnlichen Webverkehr einfügen. DoQ verwendet QUIC. Welcher Resolver gewählt wird, welche Protokolle zulässig sind und ob Geräte einen Unternehmensresolver umgehen dürfen, ist eine Betriebs- und Datenschutzentscheidung und keine pauschal für alle Netze gleiche Antwort.

Interner DNS und eigener Resolver

Unternehmen verwenden DNS häufig für interne Namen, Active-Directory-nahe Dienste, Split DNS, lokale Richtlinien und die Erkennung schädlicher Ziele. Ein selbst betriebener Resolver kann Kontrolle und Protokollierbarkeit verbessern, erzeugt aber Verantwortung für Updates, Härtung, Verfügbarkeit, Datenschutz und Missbrauchsschutz.

Verschlüsseltes DNS verhindert nicht grundsätzlich Load Balancing, CDN-Nutzung oder Malware-Schutz. Probleme entstehen vor allem dann, wenn ein Client einen nicht vorgesehenen externen Resolver wählt und dadurch interne Ansichten oder Richtlinien umgeht. Moderne Planung definiert deshalb Resolverauswahl, Fallback, mobile Geräte, Gastnetze und Ausfallszenarien ausdrücklich.

• rekursive Anfragen nur für berechtigte interne Clients zulassen
• keinen offenen Resolver für das Internet betreiben
• redundante Resolver und erreichbare Fallbackpfade planen
• DNSSEC-Validierung und verschlüsselten Clientzugang getrennt konfigurieren
• Abfrageprotokollierung datensparsam und mit klarer Aufbewahrung gestalten
• interne und öffentliche Zonen sowie Split-DNS-Verhalten dokumentieren

Angriffe und Missbrauch

DNS-Spoofing und Cache Poisoning versuchen, falsche Antworten als gültig erscheinen zu lassen. Zufällige Transaktionskennungen, zufällige Quellports, Bailiwick-Prüfungen und DNSSEC-Validierung erschweren solche Angriffe. DNS-Amplification missbraucht offene rekursive Resolver oder falsch konfigurierte autoritative Server als Reflektoren gegen gefälschte Quelladressen.

DNS kann außerdem als Steuer- oder Exfiltrationskanal missbraucht werden, beispielsweise durch auffällige TXT-Abfragen oder lange, ständig wechselnde Subdomains. TXT ist dabei nicht „der Schadkanal“, sondern ein legitimer Record-Typ, der missbraucht werden kann. Erkennung benötigt Kontext, Baselines, Rate-Limits und gegebenenfalls Analyse ungewöhnlicher Namen und Antwortmuster.

Alternative Namenssysteme und Blockchain-DNS

Blockchain-basierte und andere dezentrale Namenssysteme verwenden teilweise domainähnliche Namen, sind aber nicht automatisch Teil des globalen DNS. Sie können andere Vertrauens-, Governance- und Auflösungsmodelle besitzen und benötigen häufig besondere Resolver, Browsererweiterungen oder Gateways.

Dezentralität beseitigt nicht automatisch Namenskonflikte, Schlüsselverlust, Missbrauch, Datenschutzprobleme oder die Notwendigkeit einer verlässlichen Softwareverteilung. Solche Systeme sind deshalb nicht pauschal „der Nachfolger von DNS“. Sie müssen nach Interoperabilität, Verwaltung, Wiederherstellung, Sicherheitsmodell und tatsächlicher Verbreitung beurteilt werden. DNSCrypt, Proxies, VPN, Tor oder I2P sind ebenfalls keine direkten DNS-Nachfolger, sondern lösen jeweils andere Transport-, Datenschutz- oder Erreichbarkeitsprobleme.

DNS systematisch prüfen