Nameserver nur unter einer TLD: Schlechte Idee

Der DENIC-DNSSEC-Vorfall als Warnsignal

DNS gilt oft als „unsichtbare Infrastruktur“ – bis es ausfällt. Genau das zeigte der Vorfall, bei dem DNSSEC-Probleme zeitweise zu erheblichen Erreichbarkeitsproblemen führten. Viele Domains unter .de waren betroffen oder zumindest potenziell gefährdet. Besonders unangenehm wurde es für Betreiber, die ihre autoritativen Nameserver ebenfalls ausschließlich unter .de betrieben haben.

Denn in solchen Situationen entsteht ein klassischer Single Point of Failure:

• Die Domain selbst liegt nicht unter der .de
• Die Nameserver heißen aber z. B. ns1.example.de und ns2.example.de
• Die Auflösung dieser Nameserver hängt wiederum von der Funktionalität der .de-Zone ab

Fällt die TLD-Infrastruktur oder deren DNSSEC-Kette aus, kann unter Umständen nicht einmal mehr der Nameservername selbst aufgelöst werden. Auch wenn die eigentliche Domain gar nicht betroffen gewesen ist.

Es fallen somit nicht nur die .de Domains aus sondern alle Domains des Unternehmens.

Das Problem ist strukturell – nicht technisch im engeren Sinne.

Das versteckte Risiko: Abhängigkeit von einer einzigen Registry

Viele Unternehmen verteilen ihre Nameserver zwar geografisch oder auf verschiedene Provider – übersehen aber eine entscheidende Ebene:

Die Abhängigkeit von derselben TLD-Registry.

Wer beispielsweise folgende Nameserver nutzt:

• ns1.provider.de
• ns2.provider.de

hat trotz zweier Server weiterhin eine gemeinsame Abhängigkeit:

• dieselbe TLD (.de)
• dieselbe Registry (DENIC)
• dieselbe DNSSEC-Trust-Chain
• denselben Registry-Betrieb

Kommt es dort zu Problemen, hilft die Redundanz der einzelnen Nameserver kaum noch.

Warum unterschiedliche TLDs deutlich robuster sind

Deutlich resilienter wird ein Setup, wenn die Nameserver unter unterschiedlichen TLDs betrieben werden, beispielsweise:

• ns1.provider.de
• ns2.provider.net

Damit verteilen sich kritische Abhängigkeiten auf unterschiedliche Infrastrukturen:

Ein Fehler in einer Registry betrifft dann nicht automatisch alle autoritativen Nameserver gleichzeitig.

Zwei TLDs reichen nicht immer – wenn sie vom gleichen Betreiber stammen

Ein häufiger Denkfehler lautet:

„Wir nutzen doch .com und .net, also sind wir abgesichert.“

Das stimmt nur teilweise.

Denn .com und .net werden z.B. beide von Verisign betrieben. Damit existiert weiterhin eine gemeinsame operative Abhängigkeit:

• gleiche Registry-Infrastruktur
• ähnliche Betriebsprozesse
• potenziell gemeinsame Fehlerquellen
• gleiche organisatorische Verantwortung

Ein schwerwiegender Fehler oder ein DNSSEC-Problem beim Betreiber könnte also weiterhin beide TLDs gleichzeitig betreffen.

Dasselbe gilt auch für andere TLD-Gruppen unter gemeinsamer Verwaltung.

Wirkliche Resilienz bedeutet: Unterschiedliche Registries

Ein robustes Nameserver-Design berücksichtigt deshalb nicht nur unterschiedliche TLDs, sondern auch unterschiedliche Registry-Betreiber.

Beispielsweise:

Dadurch werden Risiken auf mehreren Ebenen verteilt.

DNSSEC macht die Kette empfindlicher

Mit DNSSEC steigt die Sicherheit – aber auch die Komplexität der Vertrauenskette.

Wenn eine TLD durch fehlerhafte Signaturen, Key-Rollover-Probleme oder Validierungsfehler betroffen ist, können Resolver die gesamte Auflösung ablehnen.

Das Problem betrifft dann nicht nur die eigentliche Domain, sondern möglicherweise auch die Nameserver-Namen selbst.

Gerade deshalb wird die Diversifikation über verschiedene TLDs und Registries immer wichtiger.

Best Practices für resiliente DNS-Infrastrukturen

Nameserver unter unterschiedlichen TLDs betreiben

Nicht nur:

• ns1.example.de
• ns2.example.de

sondern beispielsweise:

• ns1.example.de
• ns2.example.net

Unterschiedliche Registry-Betreiber wählen

Ideal ist eine Kombination verschiedener Betreiber:

• DENIC (.de)
• Verisign (.com, .net)
• PIR (.org)
• EURid (.eu)
• etc.

Unterschiedliche DNS-Provider einsetzen

Noch robuster wird es mit:

• unterschiedlichen autoritativen DNS-Anbietern
• separaten Netzwerken