DNSSEC - Prinzip und Praxis

Seit dem 15. Juli 2010 ist die Rootzone des globalen DNS signiert, dem produktiven Einsatz von DNSSEC steht damit nichts mehr im Wege. Ab dem ISC Bind 9.6.2 verfügen Systemverwalter auch über die notwendigen Tools [1] und gute Vorlagen [2].

Neben der Rootzone müssen auch die einzelnen Top Level Domains DNSSEC unterstützen. Der Status bei den verschiedenen Verwaltungsstellen ist unterschiedlich [3]: Das Denic testet noch bis Ende des Jahres [4], während die österreichischen Kollegen bei »nic.at« lesenswerte Kritik an den Sicherheitserweiterungen üben [5]. Auf Anfrage des Linux-Magazins erklärte die Registratur jedoch, bis zum ersten Quartal 2011 eine Testumgebung einzurichten. Verisign will bei den TLDs ».com« und ».net« im Laufe des Jahres 2011 bereit sein [6].

Die schweizer- und liechtensteinische Registratur Switch bietet DNSSEC seit Februar 2010 produktiv an. Auf Anfrage erklärte sie, dass von 1,5 Millionen registrierten Domains 111 über DNSSEC verfügen. Das gilt auch für TLDs wie ».biz« und ».org«. Vorreiter ist Schweden: Das Land hatte DNSSEC bereits im Februar 2007 eingeführt.

Zu groß für DNS

Der ursprüngliche DNS-Standard stößt mit DNSSEC an seine Grenzen. Bei der Verwendung von UDP besteht ein Größenlimit von 512 Bytes pro Paket. Die kryptographischen Schlüssel und Signaturen sind dafür zu groß. DNS kennt auch keine Flags, um Statusinformationen zur Validierung auszutauschen.

Die Extension Mechanisms for DNS (EDNS) aus RFC 2671 heben diese Grenzen auf und erlauben größere Pakete und neue Flags. Deshalb sind sie Voraussetzung für die Nutzung von DNSSEC. Trotz der Tatsache, dass sie bereits seit 1999 spezifiziert sind, können einige wenige aktuelle Firewallmodelle mit ihnen aber nicht umgehen. Ein Administrator tut also gut daran, seine Umgebung entsprechend zu prüfen.

Kette des Vertrauens

DNSSEC bildet mit Hilfe einer PKI eine hierarchische Vertrauenskette vergleichbar mit den X.509v3-Zertifikaten und ihren CAs fürs Web [7]. Der Standard ergänzt eine Delegation um DS-Records und deklariert damit, welcher Key Signing Key (KSK) zu der jeweiligen Subdomain gehört. In diesem Zusammenhang fällt oft der Begriff Secure Entry Point (SEP). Innerhalb der Subdomain signiert (und legitimiert) der KSK die Zone Signing Keys (ZSK). Von ihnen sind auf den einzelnen Records Signaturen zu finden. Der KSK verrichtet also vergleichsweise wenig Arbeit und ist resistenter gegenüber der Kryptoanalyse.

Die ZSK und KSK sind in jeder Domain in Form von DNSKEY-Records zu finden. Sie stehen auf derselben Stufe wie der SOA. Um Signaturen abzubilden, erhält jede Ressource einen zusätzlichen RRSIG-Record. Die DNSKEY-Records weisen RRSIGs von KSK und ZSK auf, während bei den anderen Records lediglich eine RRSIG vom ZSK zu finden ist.

Abbildung 1 zeigt, wie die Delegation von »example.org« in der übergeordneten ».org«-Domäne mit DNSSEC ergänzt wird und welcher Schlüssel dabei was signiert. Die Delegation von ».org« in der Rootzone funktioniert dazu analog. Kennt ein rekursiver DNS-Server den KSK oder den SEP der Rootzone, kann er der Kette folgen. Bei autoritativen Servern muss der Verwalter für jede Zone ein Paar aus KSK und ZSK erstellen und publizieren.

Abbildung 1: In der Kette des Vertrauens referenziert der DS-Record einer Delegation von »org.« den von der Subzone »example.org.« verwendeten KSK. Der signiert seinerseits den ZSK, um schließlich einen A-Record zu unterzeichnen.

Um zu verhindern, dass ein Angreifer zwischen Client und Resolver einzelne Antwort-Records unbemerkt unterdrückt - und so beispielsweise den Einruck erweckt, eine Subdomain sei gar nicht signiert -, kommt NSEC zum Einsatz. Weil dies seinerseits alle Records einer Zone ringförmig verkettet, wären Angreifer in der Lage, sie vollständig auszulesen. Dieses Zonewalking unterbindet die neuere Erweiterung NSEC3 [8].