„Wo wohnt eigentlich beispiel.de?“

Niemand stellt diese Frage laut. Ihr Rechner stellt sie millionenfach am Tag, in Sekundenbruchteilen, ohne dass Sie etwas davon mitbekommen. Und irgendjemand muss sie beantworten.

Dieser Jemand hat einen Namen: das Domain Name System, kurz DNS.

Stellen Sie es sich wie die Auskunft in einem unfassbar großen Gebäude vor. Sie kennen den Namen der Person, die Sie suchen. Was Sie nicht kennen: die Tür, hinter der sie sitzt. Das Internet funktioniert nämlich nicht mit Namen, sondern mit Nummern. Mit IP-Adressen wie 93.184.216.34, an die sich kein Mensch erinnern will und auch nicht muss. Genau diese Übersetzungsarbeit erledigt DNS, leise und ununterbrochen: Es verwandelt das, was wir uns merken, in das, was Maschinen verstehen.

Festgeschrieben wurde das alles bereits 1987, in zwei Dokumenten, die bis heute das Fundament tragen: RFC 1034 für die Konzepte, RFC 1035 für die Umsetzung. Alt. Aber tragfähig wie gutes Mauerwerk.

Das Domain Name System beantwortet, welche IP-Adresse zu einer Domain gehört, und macht Websites über Namen erreichbar.

Warum ohne DNS niemand hineinfindet

Nehmen Sie der Auskunft ihre Liste weg. Das Gebäude steht weiter. Nur findet niemand mehr den Weg hinein.

Genauso ist es im Netz. Ohne DNS müssten Sie sich für jede Seite, jeden Dienst, jedes Postfach eine Zahlenkolonne merken. Und wehe, der Server zieht um: Die Adresse wäre tot, der Name aber bliebe. DNS legt deshalb eine eigene Schicht zwischen Sie und die Technik. Eine Namensschicht, die sich ändern darf, ohne dass Sie es merken. Server wandern, Anbieter wechseln, Rechenzentren fallen aus. Der Name beispiel.de bleibt.

Dass dieses System weltweit nicht zusammenbricht, liegt an zwei Eigenschaften: Es verteilt die Last (durch Delegation) und es vergisst klug (durch Caching). Dazu gleich mehr.

Die Ordnung dahinter: Wurzel, Zonen, Delegation

Eine einzige Behörde, die jeden Namen der Welt kennt? Das würde keine Woche überstehen.

Deshalb ist DNS hierarchisch gebaut, wie ein Baum, der auf dem Kopf steht. Ganz oben sitzt die Wurzel („Root“). Darunter die Top-Level-Domains wie .de oder .com. Darunter Namen wie beispiel.de. Und so weiter, Ebene für Ebene.

Verwaltet wird das in Zonen. Eine Zone ist ein Stück dieses Baums, betreut von autoritativen Nameservern, die für ihren Abschnitt die verbindliche Auskunft geben. Das Entscheidende heißt Delegation: Die Wurzel kennt nicht jeden Namen. Sie weiß nur, wer für .de zuständig ist. Und die .de-Verwaltung weiß, wer für beispiel.de zuständig ist.

Die Auskunft im Erdgeschoss kennt nicht jeden Mieter. Sie kennt die Etagenverantwortlichen. Und die kennen ihre Türen.

Wer hier wen fragt

Drei Rollen spielen zusammen, sobald Sie eine Adresse aufrufen.

Der Stub-Resolver steckt in Ihrem Betriebssystem. Er ist der Bote, der losgeschickt wird, selbst aber nichts weiß. Er reicht die Frage weiter an den rekursiven Resolver, meist betrieben von Ihrem Provider oder einem öffentlichen Dienst. Dieser ist der eigentliche Auskunftsprofi: Er klappert die Hierarchie ab, bis er die Antwort hat. Am Ende der Kette steht der autoritative Nameserver, der für die gefragte Zone die letztgültige Antwort liefert.

Eine Auflösung läuft dann ungefähr so:

1. Ihr Gerät fragt den rekursiven Resolver: „Wo wohnt beispiel.de?“
2. Der Resolver fragt bei Bedarf einen Root-Server und bekommt einen Verweis auf die .de-Server.
3. Die .de-Server verweisen auf die autoritativen Server der Zielzone.
4. Diese liefern endlich die Antwort, etwa einen A- oder AAAA-Record.
5. Der Resolver merkt sich die Antwort und gibt sie an Sie zurück.

Der Bote weiß nichts. Der Profi fragt sich durch. Und niemand muss alles wissen, damit das Ganze funktioniert. Eine bemerkenswert demokratische Architektur für etwas so Technisches.

Was unter der Haube passiert

Klassisch reist eine DNS-Anfrage über UDP auf Port 53, das schnelle, formlose Verfahren. Wird die Antwort zu groß oder geht es um Zonentransfers, springt das System auf TCP um.

Lange galt eine harte Grenze: Über UDP passten nur 512 Byte in eine Nachricht. Für das DNS der Frühzeit reichte das. Für DNSSEC, für moderne Zusatzinfos? Viel zu eng. Die Lösung heißt EDNS(0) (RFC 6891): eine Erweiterung, die größere UDP-Pakete erlaubt und Platz für Zusatzfelder schafft. Ohne sie wären viele heutige Funktionen schlicht nicht praktikabel.

Jede Nachricht trägt einen Header mit Status-Flags: QR (Frage oder Antwort), AA (autoritativ), TC (abgeschnitten), RD (Rekursion erwünscht), RA (Rekursion verfügbar), dazu ein RCODE für den Status. Klingt nach Kleingedrucktem. Ist aber das Vokabular, in dem sich die Server unterhalten.

Die Bausteine einer Zone: Resource Records

Eine Zone ist im Kern eine Sammlung von Einträgen, sogenannten Resource Records (RRs). Die vollständige, fortlaufend gepflegte Liste führt das IANA-Register. Im Alltag begegnen Ihnen vor allem diese:

• A / AAAA: die IPv4- bzw. IPv6-Adresse eines Hosts. Das Brot-und-Butter-Geschäft.
• CNAME: ein Alias, der auf einen anderen Namen zeigt.
• NS: benennt die zuständigen autoritativen Nameserver einer Zone.
• SOA: der „Start of Authority“, die Metadaten einer Zone (Primärserver, Seriennummer, Auffrisch-Intervalle).
• MX: der Mailserver einer Domain.
• TXT: freier Text, in der Praxis das Zuhause von SPF, DKIM und DMARC.
• CAA: legt fest, welche Zertifizierungsstellen für eine Domain Zertifikate ausstellen dürfen. Eine stille, wirksame Absicherung.
• SVCB / HTTPS: moderne Einträge (RFC 9460), die schon bei der Namensauflösung verraten, welche Protokolle ein Dienst spricht (etwa HTTP/3), und so spätere Nachfragen sparen.
• DNSSEC-Einträge wie DNSKEY, DS, RRSIG und NSEC: das kryptographische Beiwerk, zu dem wir gleich kommen.

Eine Stolperfalle gleich vorweg: Am Wurzelpunkt einer Zone (dem Apex, etwa beispiel.de.) ist ein CNAME nicht erlaubt. Wer dort trotzdem einen Alias braucht, weicht auf anbieterspezifische ALIAS- oder ANAME-Mechaniken aus, die serverseitig still in A/AAAA aufgelöst werden.

Gedächtnis mit Verfallsdatum: TTL und Caching

Stellen Sie sich vor, die Auskunft müsste jede Frage von Grund auf neu beantworten. Das Gebäude käme zum Stillstand.

Deshalb merkt sich jeder Resolver, was er erfahren hat, für eine bestimmte Zeit: die TTL (Time to Live). Kurze TTLs erlauben schnelle Änderungen, etwa beim Umzug auf einen neuen Server. Lange TTLs entlasten das System und beschleunigen die Auslieferung. Und ja, auch ein „Diesen Namen gibt es nicht“ (NXDOMAIN) wird zwischengespeichert, damit nicht tausend Anfragen gegen dieselbe Wand laufen.

Die Kunst liegt in der Mischung. Wo wird bei Ihnen oft umgezogen, und wo steht seit Jahren alles fest? Die Antwort gehört in Ihre TTL-Strategie.

Vertrauen, das man prüfen kann: DNSSEC

Jetzt wird es heikel. Bisher haben wir vorausgesetzt, dass die Auskunft die Wahrheit sagt. Aber was, wenn jemand einen gefälschten Zettel auf den Tresen schmuggelt?

Genau dieses Risiko adressiert DNSSEC. Es stattet DNS-Antworten mit kryptographischen Signaturen aus. Zonenbetreiber signieren ihre Einträge (RRSIG) mit privaten Schlüsseln; die passenden öffentlichen Schlüssel liegen als DNSKEY in der Zone. Über DS-Einträge entsteht eine Vertrauenskette von der übergeordneten Zone hinauf, im Idealfall bis zur Wurzel. Die Kernstandards stehen in RFC 4033 bis 4035.

Diese Wurzel ist signiert, und ihr oberster Schlüssel wird in regelmäßigen, hochformalisierten KSK-Zeremonien verwaltet, mit festen Rollen, Hardware-Sicherheitsmodulen und Zeugen. Wer einmal gesehen hat, wie IANA und ICANN das inszenieren, versteht: Hier geht es um das Schloss zum Generalschlüssel des Internets.

Ein Punkt, der oft missverstanden wird: DNSSEC verschlüsselt nichts. Es beweist nur, dass eine Antwort echt und unverändert ist. Wer mithört, hört weiter mit. Er kann nur nichts mehr fälschen.

Was DNSSEC nicht kann: verschlüsselte Transporte

Womit wir bei der zweiten Sicherheitsschicht sind. Klassisches DNS reist offen über die Leitung, lesbar für jeden auf dem Weg. Für die Vertraulichkeit braucht es eigene Verfahren:

• DoT (DNS over TLS) verpackt DNS in TLS auf Port 853.
• DoH (DNS over HTTPS) schickt Anfragen über HTTPS auf Port 443, mitten im Web-Verkehr.
• DoQ (DNS over QUIC) setzt auf QUIC und senkt Latenz und Blockaden gegenüber TCP-basierten Wegen.

DNSSEC sichert also die Daten, die verschlüsselten Transporte sichern den Weg. Das eine ersetzt das andere nicht. Erst zusammen ergeben sie ein rundes Bild.

Schnelligkeit mit Beigeschmack: ECS und Service-Binding

Manchmal will ein Dienst wissen, wo Sie ungefähr sitzen, um Sie an den nächstgelegenen Server zu schicken. Dafür gibt es EDNS Client Subnet (ECS, RFC 7871): Der Resolver gibt einen Teil Ihrer IP weiter. Schneller für CDNs, ja. Aber eben auch eine Spur, die verrät, von wo Sie fragen. Ein Tausch, den man bewusst eingehen sollte, nicht aus Versehen.

Die SVCB- und HTTPS-Records ziehen in eine andere Richtung: Sie liefern schon während der Auflösung Verbindungsparameter mit, etwa unterstützte Protokolle oder Hinweise für Encrypted Client Hello. Das spart Handshakes und beschleunigt den Verbindungsaufbau, ganz ohne zusätzliche Abfragen.

Wenn die Auskunft lügt: Cache-Poisoning

Erinnern Sie sich an den gefälschten Zettel auf dem Tresen? Auf genau diesen Trick zielt Cache-Poisoning. Wer es schafft, einem Resolver eine gefälschte Antwort unterzuschieben, vergiftet dessen Gedächtnis. Und plötzlich landen alle, die fragen, an der falschen Tür.

2008 führte der nach seinem Entdecker benannte Kaminsky-Angriff der Branche schmerzhaft vor, wie real diese Gefahr ist. Die schnelle Antwort lag im Detail: zufällige Quellports, zufällige Transaktions-IDs, strengere Prüfung der Antworten, gebündelt in RFC 5452. Die gründliche Antwort heißt DNSSEC.

Namen mit Umlauten: IDNA und Punycode

Das ursprüngliche DNS kennt nur ASCII. Kein ä, kein ü, kein kyrillisches oder arabisches Zeichen. Damit müller.de trotzdem funktioniert, übersetzt Ihre Software solche Namen nach IDNA2008 (RFC 5890) und Punycode (RFC 3492) in eine reine ASCII-Form, etwa xn--bcher-kva.example für bücher.example. Sie tippen den schönen Namen. DNS sieht den technischen.

DNS im Alltag: E-Mail und Betrieb

Kaum jemand merkt, wie sehr E-Mail an DNS hängt. MX legt fest, welcher Server Post annimmt. SPF, DKIM und DMARC liegen als TXT-Einträge in der Zone und entscheiden mit darüber, ob Ihre Mails ankommen oder im Spam versinken. Wer hier schlampt, wundert sich später über miese Zustellraten.

Auf der Betriebsseite zählen saubere NS-Sets, korrekte SOA-Parameter und eine disziplinierte Seriennummern-Pflege. Zonentransfers (AXFR/IXFR) zwischen Servern gehören abgesichert, etwa per TSIG. Und wer Ausfälle und Latenz minimieren will, verteilt seine autoritativen Server per Anycast über die Welt.

Die häufigsten Stolperfallen

• CNAME am Apex: nicht erlaubt. Auf ALIAS/ANAME ausweichen oder direkt A/AAAA pflegen.
• Inkonsistente NS-Einträge: führen zu sprunghaften Auflösungsfehlern. Delegation beim Parent und autoritative Zone müssen zusammenpassen.
• Überall zu kurze TTLs: erhöhen Last und Latenz. Differenzieren statt pauschalisieren.
• Ungesicherte Zonentransfers: nur mit Authentisierung und klaren Freigaben.

FAQ zu DNS

Ist DNSSEC dasselbe wie Verschlüsselung?
Nein. DNSSEC sichert die Echtheit der Daten, nicht ihre Vertraulichkeit. Für Verschlüsselung sorgen DoT, DoH oder DoQ.

Macht DNSSEC das Internet langsamer?
Spürbar kaum. Es kostet etwas Rechenarbeit und größere Pakete, was EDNS(0) auffängt. Sicherheitsgewinn deutlich, Tempoverlust gering.

Bringt ECS immer einen Vorteil?
Nein. Es kann Geo-Routing verbessern, kostet aber Privatsphäre. Bewusst und transparent einsetzen.

Was ist das Besondere an SVCB/HTTPS-Records?
Sie liefern Verbindungsparameter direkt über DNS und sparen Handshakes. Besonders nützlich für HTTP/3.

Was bleibt

DNS ist die stille Auskunft, die alles am Laufen hält und die niemand bemerkt, solange sie funktioniert. Erst wenn sie schweigt oder lügt, sieht man, wie viel an ihr hängt.

Die eigentliche Frage ist deshalb nicht, ob Sie DNS nutzen. Das tun Sie ohnehin, mit jedem Klick. Die Frage ist, ob Sie ihm so viel Sorgfalt schenken wie dem, was darüber sichtbar wird.

Denn ein Haus ist nur so verlässlich wie die Auskunft an seiner Tür.