Domain Name System absichern mit DNSSEC

Seite 5: DNSSEC kontrolliert Abschalten

Inhaltsverzeichnis

Soll das DNSSEC-Verfahren für eine Domain abgeschaltet werden, etwa wegen ADSL-Routern, die mit DNSSEC Probleme haben, muss zunächst die Registry den KSK aus ihrer Datenbank löschen. Andernfalls, also wenn der Domain-Betreiber den ZSK und KSK unkoordiniert aus seiner Zonendatei tilgt, kann seine Domain nicht mehr erreicht werden: Die Registry teilt nämlich bei Anfragen weiterhin mit, dass die betreffende Zone DNSSEC-gesichert ist, und deshalb behandeln Clients DNS-Antworten ohne DNSSEC-Daten als Fälschungen und verwerfen sie. Daher wartet man ab, bis der KSK aus der Registry gelöscht ist, kalkuliert wie üblich eine TTL-abhängige Frist ein und entfernt, wenn diese verstrichen ist, alle Schlüssel und Signaturen gefahrlos aus der Zonendatei.

Aus Sicherheitsgründen sollte jeder KSK von Zeit zu Zeit erneuert werden. Wenn ein KSK aber in einem Resolver fest eingetragen ist, wird der Resolver bei einem KSK-Wechsel alle mit dem neuen KSK signierten Antworten als gefälscht verwerfen. Der Administrator eines Resolvers muss daher den Schlüsseltausch aller ihm unterstellten Domains überwachen, andernfalls sind diese nicht mehr erreichbar – im Falle der Domain .se also ein ganzes Land. Top Level Domains veröffentlichen ihre neuen Schlüssel deshalb mit reichlich Vorlauf, damit Resolver-Administratoren Zeit genug haben, die Änderungen zu übernehmen.

DNSSEC ist nicht problemfrei. Das erste und auffälligste Problem betrifft die Zonendatei. Durch die Signatur wächst sie auf ungefähr den dreifachen Umfang gegenüber der Zonendatei ohne Schlüssel. Die weitaus meisten Domain-Betreiber wird das kaum stören, denn weil deren Domains klein sind, ist es auch die Zonendatei. Für Registries spielt es aber schon eine Rolle, denn deren Zonendateien können schon ohne DNSSEC leicht mehrere Gigabyte groß sein – unter Umständen müssen sie also ihre Server-Hardware an die erhöhten Anforderungen anpassen.

Der Empfänger eines DNS- Response prüft nach der Signatur schrittweise die Vetrauenswürdigkeit des Absenders, indem er die öffentlichen KSK der Glieder der Vertrauenskette von unten nach oben abfragt. Die Domain dnssec.jp gehört aber nicht zu den Domains, denen er vertraut (.se), sodass zwar der Response unverfälscht ist, aber nicht vertrauenswürdig.

Herkömmliche Resolver eignen sich für die DNSSEC-Anforderungen nicht; sie sind nicht für die aufwendigen kryptografischen Operationen ausgelegt, sodass man sie auf einen Schlag ersetzen müsste. Weil das teuer ist, kann man sie jedoch auch im herkömmlichen DNS-Modus weiterbetreiben (Stubresolver) und für die Verifizierung der signierten DNS-Antworten einen spezialisierten Resolver anschaffen – mehrere Stubresolver stützen sich dann auf einen zentralen Server. Diese Kommunikation ist jedoch eine Schwachstelle, denn prinzipiell können auf diesem Wege doch verfälschte DNS-Antworten eingeschleust werden. Man nimmt das Risiko aber zu Gunsten niedrigerer Kosten in Kauf.

Denial-of-Service-Attacken werden durch den erhöhten Rechenaufwand erleichtert. Wenn man davon ausgeht, dass die Nameserver-Hardware mit DNSSEC näher am Leistungslimit arbeitet, genügen weniger Angriffe, um sie lahmzulegen.