← Zurück zur Übersicht
Protokolle

DNSSEC

DNS Security Extensions

DNSSECDNSSignaturRRSIGDSKSKZSK

DNSSEC erweitert DNS um kryptografische Signaturen. Jede DNS-Antwort wird digital signiert – der Empfänger kann prüfen, ob die Antwort echt ist und nicht manipuliert wurde. Schützt vor DNS-Spoofing und Cache-Poisoning.

Root Zone. (Punkt) signiertTLD .comDS-Record von Rootexample.comDS-Record von .comA-RecordRRSIG-SignaturDNSSEC Record-TypenDNSKEYÖffentlicher Schlüssel der ZoneRRSIGSignatur über DNS-RecordsDSHash des DNSKEY der SubzoneSchlüsseltypenKSKKey Signing Key – signiert ZSKZSKZone Signing Key – signiert Records

Entstehung und Beteiligte

DNSSEC wurde in der IETF entwickelt, nachdem klar wurde, dass normales DNS Antworten nicht authentifiziert. Frühe Arbeiten erschienen 1997; die heute maßgebliche Neufassung aus RFC 4033 bis 4035 wurde 2005 veröffentlicht. Die Root-Zone wurde 2010 signiert.

Welches Problem sollte gelöst werden?

Ein Angreifer kann gefälschte DNS-Antworten einschleusen und Nutzer zu falschen Servern lenken. Resolver sollten kryptografisch prüfen können, ob Daten vom zuständigen Zonenbetreiber stammen und unverändert sind.

Technische Hürden und Lösungen

Vertrauensketten müssen vom Root-Schlüssel über Delegationen reichen. Schlüsselwechsel, große Antworten, negative Antworten und Uhrzeitabhängigkeit erhöhen Betriebsaufwand. DNSSEC verschlüsselt Anfragen nicht und bestätigt nicht, dass der Zielserver ungefährlich ist.

Standardisierung und Einordnung

Internetprotokolle werden überwiegend in offenen RFC-Dokumenten beschrieben. Ein RFC kann ein historischer Vorschlag, ein aktueller Standard oder inzwischen überholt sein. Implementierungen müssen nicht nur das Papier befolgen, sondern mit fehlerhaften Gegenstellen, Paketverlust, Zeitüberschreitungen, Sicherheitsangriffen und jahrzehntealten Erweiterungen umgehen. Interoperabilität entsteht dadurch, dass unabhängige Hersteller dieselben Zustandsautomaten, Nachrichtenformate und Fehlerfälle testen.

Technik im praktischen Betrieb

Für den produktiven Einsatz zählt die konkrete Protokollversion. Alte und neue Varianten können denselben Port verwenden, besitzen aber völlig unterschiedliche Sicherheits- und Funktionsmerkmale. Administratoren sollten daher Aushandlung, Zertifikate, Timeouts, maximale Nachrichtengrößen und Fehlercodes sichtbar machen. Proxys, NAT und Firewalls verändern häufig den Datenpfad. Gute Tests erfolgen aus derselben Netzposition wie die betroffene Anwendung und prüfen nicht nur einen offenen Port, sondern einen vollständigen gültigen Vorgang.

Warum das Thema heute noch relevant ist

Die ursprüngliche Entstehungszeit erklärt viele heutige Sicherheitslücken: Frühe Internetgemeinschaften waren klein und Vertrauen wurde vorausgesetzt. Authentifizierung, Verschlüsselung und Missbrauchsschutz kamen oft erst später als Erweiterung hinzu. Moderne Implementierungen müssen deshalb sichere Voreinstellungen verwenden, alte Varianten abschalten und dennoch mit Gegenstellen kommunizieren, die einen älteren Stand besitzen. Versionsnummer, Aushandlung und tatsächlich aktive Option sind aussagekräftiger als der bloße Protokollname.

Daten und Meilensteine

  • 2005: RFC 4033 bis 4035 definieren modernes DNSSEC.
  • 2010 wird die DNS-Rootzone signiert.
  • DS-Einträge verbinden Eltern- und Kindzone.
  • DoH und DoT schützen Transport; DNSSEC schützt Datenursprung und Integrität.

Was ist DNSSEC?

DNSSEC (DNS Security Extensions, RFC 4033–4035) erweitert DNS um kryptografische Integrität. Ohne DNSSEC kann ein Angreifer DNS-Antworten fälschen (Cache Poisoning, Man-in-the-Middle) – du rufst example.com auf, wirst aber auf einen bösartigen Server umgeleitet.

DNSSEC signiert DNS-Records digital. Der Empfänger prüft die Signatur anhand des öffentlichen Schlüssels der Zone. Die Vertrauenskette reicht von der Root-Zone bis zur Subdomain.

DNSSEC-Vertrauenskette

  1. Root-Zone (.) hat einen DNSKEY und ist selbst-signiert (RRSIG). Browser und OS vertrauen dem Root-DNSKEY.
  2. Root signiert DS-Record für .com-TLD (Hash des .com DNSKEY).
  3. .com-TLD signiert DS-Record für example.com.
  4. example.com hat zwei Schlüssel: KSK (Key Signing Key, selten gewechselt) und ZSK (Zone Signing Key, häufig gewechselt).
  5. ZSK signiert alle DNS-Records (A, MX, TXT...) mit RRSIG-Records.
  6. Resolver prüft Kette: RRSIG → ZSK → KSK → DS → übergeordnete Zone → Root.

DNSSEC in der Praxis

DNSSEC schützt nur die Integrität – nicht die Vertraulichkeit! DNS-Anfragen sind trotzdem lesbar. Für Vertraulichkeit: DNS-over-HTTPS (DoH, RFC 8484) oder DNS-over-TLS (DoT, RFC 7858).

DNSSEC-Verbreitung ist noch gering: ~20% der Domains weltweit. Komplexe Key-Verwaltung und Rollover sind Herausforderungen. Wichtige TLDs (.de, .com, .net) sind DNSSEC-signiert.