Domain Name System absichern mit DNSSEC
Seite 2: DNSSEC: Zwickmühle
Zwickmühle
Bis man DNSSEC in der Form hatte, wie es jetzt ist, mussten etliche Hürden überwunden werden. Zu Beginn der Entwicklung stand die Suche nach einem geeigneten Verfahren. Dabei kam man ziemlich schnell zur asymmetrischen Kryptografie. Grundsätzlich betrachtet setzt das Verfahren ein Schlüsselpaar aus einem privaten und einem öffentlichen Schlüssel ein (Private und Public Keys), um Nachrichten zu signieren und deren Echtheit zu prüfen.
Bei diesem Prinzip werden beliebige Nachrichten mit dem privaten Schlüssel signiert: Zuerst wird ein Fingerabdruck der Nachricht berechnet (Hash) und dann verschlüsselt; das Resultat wird Signatur genannt. Sie wird der Nachricht hinzufügt. Wenn der Empfänger den zugehörigen öffentlichen Schlüssel hat, kann er damit die Nachricht entschlüsseln und prüfen, ob sie unversehrt ist — er berechnet dafür selbst den Fingerabdruck der Nachricht. Ist der berechnete mit dem gesendeten identisch, gilt die Nachricht als unverändert. Wenn der Absender dem Empfänger bekannt ist und sichergestellt ist, dass nur der Absender Zugriff auf seinen privaten Schlüssel hat, kann der Empfänger zudem eindeutig auf den Verfasser der Nachricht rückschließen. Damit Nachrichten nur berechtigte Personen signieren können, hält man den privaten Schlüssel also geheim.
Die Sicherheit, die die asymmetrische Kryptografie bietet, nimmt mit der Länge der Schlüssel zu – aber mit der Schlüssellänge steigt auch der Rechenaufwand drastisch, sodass dafür teure Hardware erforderlich ist. Als zu Beginn der 1990er Jahre das DNSSEC-Verfahren langsam Form annahm, wurde schnell klar, dass die hohen Investitionen kaum einer der großen Domain-Betreiber aufbringen wollte, sodass das DNSSEC-Verfahren auf der Kippe stand. Ein Ausweg aus dieser Zwickmühle wäre eine Methode mit kürzeren Schlüsseln gewesen, bei der die Schlüssel immer mal wieder gewechselt werden, damit Angreifer möglichst wenig Zeit haben, sie zu knacken.
Diese Auslegung allein genügte jedoch nicht, denn bei näherem Hinsehen stellte sich heraus, dass der einfache Kompromiss lediglich den Aufwand verlagern würde: Die kürzeren Schlüssel würden den Betreibern zwar die Anschaffung teurer Hardware ersparen, aber den Administratoren zusätzliche Arbeit aufbürden, weil jeder neue Schlüssel vom übergeordneten Administrator signiert werden muss. Für sich betrachtet ist das ein einfacher Vorgang. Bei hunderten oder tausenden Domains wird der Aufwand für den Schlüsseltausch aber einfach zu hoch.
Mit einem weiteren Trick lässt sich aber auch dieser Aufwand verringern: Man setzt zwei verschiedene Typen von Schlüsseln ein, nämlich einen langen Key Signing Key von langer Lebensdauer (KSK, z. B. 2048 Bit) und einen kurzen Zone Signing Key von kurzer Lebensdauer (ZSK, z. B. 512 Bit zum Signieren der DNS-Records), jeweils als privat und öffentlich ausgeführt. Mithin hat eine Domain mindestens vier Schlüssel. Um den gleitenden Wechsel von einem abgelaufenen zu einem neuen Schlüssel zu gewährleisten, hat eine Domain in der Regel sogar mehrere Exemplare gleichzeitig, auch mehrere KSK (sinnvoll, um unterschiedliche Signieralgorithmen nutzen zu können).
Wenn der Domain-Betreiber seinen aktuellen KSK dem Administrator der übergeordneten Domain bekannt gegeben hat, kann er mit diesem anschließend alle Schlüssel der eigenen Zone signieren und nutzen. Alle anderen Daten der Zone werden mit dem aktuellen ZSK signiert. Neue ZSK kann man nach Gutdünken erzeugen und ohne Meldung gegenüber der Registry nutzen. Die übergeordnete Domain erkennt selbstständig, dass sie gültig sind, wenn man sie mit dem aktuellen KSK signiert hat, weil ihr dieser ja gemeldet worden ist. Ist ein Nameserver auf DNSSEC umgestellt, liefert er ausschließlich signierte Antworten.
Eine Besonderheit der ersten DNSSEC-Version hat zu vielen Problemen und letztlich zu der Neuimplementation vom März 2005 geführt: Im DNS gibt es keine Möglichkeit, dem Empfänger mitzuteilen, dass eine bestimmte Domain nicht existiert. Wenn ein DNS-Server eine Anfrage für eine Domain erhält, die er nicht kennt, antwortet er sinngemäß "keine Ahnung". Zum Beispiel würde ein .se-Nameserver die Anfrage nach der nicht existierenden Domain zzz.se mit der Meldung „Name Error: The domain name does not exist on this server“ beantworten. Für den anfragenden Client bleibt aber unklar, ob es die Domain wirklich nicht gibt oder ob sich der befragte Server nicht zuständig fühlt, die Anfrage zu beantworten. Um präzisere Antworten zu ermöglichen, hat man deshalb den NSEC-Record eingeführt, mit dem ein DNSSEC-Server explizit mitteilt, dass eine Domain nicht existiert.
Doch leider hatten es die Vordenker mit NSEC zu gut gemeint: Der Server teilt nämlich ungefragt auch noch mit, welche Domains der gesuchten am nächsten kommen; er liefert eine alphabetisch sortierte Liste – über eine Reihe von Anfragen lässt sich also die komplette Liste einer Zone ermitteln (Zone Enumeration, Zone Walking). Das dürfte für den Server von kleinkleckersdorf.de kein Problem sein, denn er wird ohnehin nur wenig frequentiert und deshalb wird er NSEC-Antworten selten liefern. Eine Registry wie DE-NIC mit über 12 Millionen Subdomains sieht das aber nicht ganz so gelassen. Viele Domain-Betreiber betrachten ihre Zonendatei als ein Geschäftsgeheimnis und lehnen NSEC schon deshalb ab. Aber vor allem störten sie sich daran, dass Zone Walking die Last auf den Servern drastisch erhöht hätte. Erste Tools zum automatischen Zone Walking wurden bereits kurz nach Fertigstellung der NSEC-Erweiterung veröffentlicht.
Deshalb lehnten die großen und länderspezifischen Domain-Betreiber NSEC und damit auch DNSSEC zunächst ab – ohne die ganz großen Mitspieler wäre DNSSEC aber kein Erfolg beschieden. Also wurde mit NSEC3 eine überarbeitete Spezifikation entworfen (auch als Hashed Authenticated Denial of Existence bekannt). Diese ist seit März 2008 festgeklopft und unter den Domain-Betreibern akzeptiert. Mit NSEC3 kann ein Server dem Client weiterhin eindeutig mitteilen, wenn eine Domain nicht existiert, aber er plappert nicht ungefragt weitere Domain-Namen aus (RFC 5155).
