DNSSEC in Multi-Provider-DNS sicher planen und betreiben

TL;DR:

DNSSEC erhöht die Vertrauenswürdigkeit autoritativer DNS-Antworten, macht aber jede Abweichung zwischen DNS-Providern operativ relevant. In einer Multi-Provider-Architektur müssen Zonensignierung, DNSSEC-Schlüssel, DS-Records, Delegation und Failover als zusammenhängender Prozess geplant werden. Ein redundanter DNS-Betrieb ist nur dann belastbar, wenn alle Provider validierbare und konsistente Antworten liefern.

Viele DNS-Architekturen behandeln DNSSEC wie eine Option, die nach dem Aufbau von Redundanz aktiviert wird. Bei Multi-Provider-DNS ist diese Reihenfolge riskant. Sobald mehrere autoritative Systeme dieselbe Zone ausliefern, müssen nicht nur A-, AAAA- oder MX-Records synchron sein. Auch DNSKEY-, RRSIG- und gegebenenfalls NSEC- beziehungsweise NSEC3-Records müssen zum Signierungsmodell passen.

Der zentrale Trade-off lautet: Wer signiert die Zone, und wer besitzt die DNSSEC-Schlüssel? Eine gemeinsame Signaturquelle vereinfacht die Konsistenz, erhöht aber die Abhängigkeit von diesem Signer. Unabhängige Signierung stärkt die Entkopplung der Provider, erfordert jedoch präzise Abstimmung bei Delegation, Schlüsselwechseln und negativen Antworten. DNSSEC ist damit ein Bestandteil der Betriebsarchitektur – nicht nur eine zusätzliche Sicherheitsfunktion.

1. Multi-Provider-DNS braucht ein eindeutiges Signierungsmodell

Für redundantes DNS sind zwei Modelle verbreitet. Beim Single-Signer-Modell wird eine Zone an einer zentralen Stelle signiert und anschließend von mehreren autoritativen Providern verteilt. Alle Provider liefern dann dieselben DNSSEC-Daten aus. Das vereinfacht die Schlüsselhoheit und reduziert Unterschiede bei RRSIG- und DNSKEY-Records.

Beim Multi-Signer-Modell signieren mehrere Provider die Zone unabhängig voneinander. Die Zonendaten müssen dabei inhaltlich übereinstimmen, während jeder Signer eigene Schlüssel und Signaturen verwendet. Die Delegation kann mehrere passende DS-Records enthalten. Dieses Modell reduziert die Abhängigkeit von einem einzelnen Signer, vergrößert aber die Zahl der zu koordinierenden Zustände.

Entscheidend ist, dass ein Provider nicht nur „irgendwie“ erreichbar ist. Er muss im gewählten Modell vollständige, valide und zeitlich aktuelle Antworten liefern. Anycast DNS und Multi-Provider-DNS verbessern Verfügbarkeit und Verteilung, ersetzen aber keine konsistente DNSSEC-Strategie . Im Umfeld der ayedo Edge Cloud muss deshalb vorab feststehen, welche Rolle die Edge-Plattform im Signierungs- und Bereitstellungsprozess übernimmt.

2. DNSSEC-Delegation und Schlüsselhoheit getrennt planen

Die Vertrauenskette von DNSSEC beginnt beim DS-Record in der übergeordneten Zone und führt über DNSKEY-Records zur signierten Zone. Ein Schlüsselwechsel ist deshalb nicht auf die autoritative Zone beschränkt. Auch die Delegation muss passend vorbereitet und zeitlich korrekt geändert werden. Falsche oder veraltete DS-Records führen dazu, dass Resolver Antworten als ungültig verwerfen.

Schlüsselhoheit bedeutet dabei mehr als die Frage, wer Dateien speichern darf. Sie umfasst Generierung, Zugriff, Rotation, Wiederherstellung, Freigabeprozesse und den Umgang mit kompromittierten Schlüsseln. Besonders wichtig ist die Abgrenzung zwischen KSK- und ZSK-Rollen, auch wenn konkrete technische Abläufe je nach Signierungsmodell variieren.

Bei einem Providerwechsel darf der bisherige DNSSEC-Schlüssel nicht vorschnell entfernt werden. TTLs, Caches und Signaturgültigkeiten müssen berücksichtigt werden. Ein sicherer Ablauf hält alte und neue Vertrauensinformationen lange genug parallel vor, bevor die Delegation bereinigt wird. Die Verantwortung für DNSSEC-Schlüssel sollte vertraglich und organisatorisch eindeutig geregelt sein – unabhängig davon, ob die Zone bei ayedo, einem anderen Provider oder mehreren Plattformen betrieben wird.

3. Synchronisierung entscheidet über die tatsächliche Redundanz

Die häufigste Fehlannahme lautet, dass mehrere Nameserver automatisch ein ausfallsicheres DNS ergeben. Bei DNSSEC kann ein einzelner fehlerhafter Provider die Redundanz praktisch entwerten. Liefert ein Provider noch eine alte Zonenversion, fehlen RRSIG-Records oder passt sein DNSKEY-Set nicht zur Delegation, entstehen abhängig vom Resolver SERVFAILs oder Validierungsfehler.

Für jede autoritative Zone gehören daher mindestens folgende Prüfungen in den Betrieb:

• gleiche fachliche Zonendaten auf allen Providern,
• erreichbare und vollständige DNSKEY- sowie RRSIG-Records,
• gültige Signaturzeiträume,
• konsistente SOA-Serien und TTLs,
• korrekte Antworten für nicht existente Namen,
• erwartete Antworten über IPv4 und IPv6,
• erfolgreiche Validierung aus Sicht externer Resolver.

Auch negative DNS-Antworten sind relevant. Werden NSEC- oder NSEC3-Daten nicht konsistent ausgeliefert, können Resolver legitime Antworten ablehnen. Monitoring darf deshalb nicht bei Erreichbarkeit oder HTTP-Statuscodes enden. Es muss die DNSSEC-Kette und das Verhalten jedes autoritativen Providers einzeln prüfen. Traffic- und Nutzungsstatistiken an der Edge können den Betrieb ergänzen, ersetzen aber keine Validierung der DNS-Antworten.

4. Failover und Änderungen müssen DNSSEC-fähig sein

Ein Failover zwischen Providern ist nur dann sicher, wenn beide Seiten dieselbe Vertrauensbeziehung unterstützen. Ein typischer Fehler besteht darin, bei Problemen den Traffic auf einen ungesicherten Provider umzuschalten, während der DS-Record weiterhin aktiv ist. Validierende Resolver akzeptieren diese Antwort nicht. DNSSEC bietet hier keinen Fallback auf „unsicher“, sondern erzwingt die konfigurierte Vertrauenskette.

Change-Prozesse müssen deshalb DNSSEC-spezifische Vorbedingungen enthalten. Dazu zählen Tests der vollständigen Delegation, die Prüfung von Signaturgültigkeiten und ein kontrollierter Umgang mit TTLs. Bei Änderungen an der Zone sollte zunächst die Verteilung geprüft werden, bevor ein Provider als aktiv oder bevorzugt betrachtet wird.

Für Platform- und SRE-Teams bedeutet das: DNSSEC gehört in Runbooks, Bereitschaftsprozesse und automatisierte Pre-Deployment-Checks. Zuständigkeiten zwischen DNS-Betrieb, Security und Anwendungsteams müssen klar sein. Die ayedo Edge Cloud kann als Bestandteil einer Anycast- und Multi-Provider-DNS-Architektur den öffentlichen DNS-Eingang verteilen; die konkrete Schlüsselhoheit und der Signierungsprozess müssen jedoch ausdrücklich architektonisch festgelegt werden.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API-Zone über zwei autoritative DNS-Provider. Im ersten Modell signiert ein zentraler Signer die Zone und verteilt sie an beide Provider. Ein Ausfall eines Providers bleibt beherrschbar, solange der zweite dieselben signierten Daten ausliefert. Der zentrale Signer bleibt jedoch ein kritischer Betriebsbestandteil.

Im zweiten Modell signieren beide Provider unabhängig. Ein Schlüsselwechsel bei nur einem Provider kann dann zu einer funktionierenden Antwort bei einem Resolver und zu einem Validierungsfehler bei einem anderen führen, wenn DS-Records oder DNSKEY-Sets nicht abgestimmt sind. Vor einer Migration sollte das Unternehmen daher eine Testzone verwenden, beide Provider getrennt validieren und erst danach Delegation und Produktionsbetrieb ändern. Redundanz entsteht nicht durch die Anzahl der Provider, sondern durch konsistente Vertrauensketten.

FAQ

Verschlüsselt DNSSEC DNS-Abfragen? Nein. DNSSEC schützt Authentizität und Integrität signierter DNS-Daten. Die Abfragen selbst werden dadurch nicht vertraulich übertragen.

Kann ein ungesicherter Provider als Notfall-Fallback dienen? Nicht solange ein passender DS-Record delegiert ist. Validierende Resolver verwerfen unsignierte oder falsch signierte Antworten typischerweise als ungültig.

Wer sollte DNSSEC-Schlüssel besitzen? Das hängt vom Signierungsmodell und den Governance-Anforderungen ab. Entscheidend sind klare Zuständigkeiten für Zugriff, Rotation, Wiederherstellung und Delegationsänderungen.

Fazit

DNSSEC macht Multi-Provider-DNS nicht komplizierter, weil mehrere Nameserver existieren, sondern weil mehrere Systeme dieselbe Vertrauenskette zuverlässig abbilden müssen. Signierung, Schlüsselhoheit, Delegation, Synchronisierung und Failover gehören deshalb in ein gemeinsames Betriebsmodell. Eine Edge-Plattform wie die ayedo Edge Cloud ist in diesem Zusammenhang Teil einer verteilten DNS- und Traffic-Architektur. Ihre Redundanz entfaltet ihren Wert jedoch nur, wenn auch die DNSSEC-Antworten providerübergreifend geplant, geprüft und sicher geändert werden.