DNSSEC ist seit über einem Jahrzehnt ein Standard, dennoch bleibt die Adoption uneinheitlich. Die Kryptografie ist gut verstanden; das operative Modell ist gut dokumentiert. Was viele Organisationen davon abhält, es zu aktivieren, ist die Verwahrung: Der Signing-Key (KSK) und der Zone-Signing-Key (ZSK) sind die Vertrauenswurzeln der gesamten Zone, und die meisten Unternehmen möchten diese Schlüssel nicht in der Hand eines Anbieters wissen.
Cloud-DNS-Anbieter bieten DNSSEC Sign-and-Serve, doch die Schlüssel liegen im KMS des Anbieters. Der Anbieter kann widerrufen, rotieren oder per Subpoena verpflichtet werden — Ihre Zonen-Integrität hängt am fortgeführten Betrieb des Anbieters. Manche Organisationen akzeptieren diesen Trade-off; viele in regulierten Sektoren (Behörden, Verteidigung, Finanzen) können das nicht.
Die historische Alternative ist eine selbstverwaltete DNSSEC-Signing-Pipeline: BIND mit eigenem Key-Management, Skripte zur planmäßigen Schlüsselrotation, externe HSM-Integration, Slave-Konfiguration zum Empfang signierter Records. Das funktioniert, aber der Betriebsaufwand ist erheblich und die Fehlermodi sind still (abgelaufene RRSIG, fehlende NSEC-Kette).
TR7 GTM bringt DNSSEC in dieselbe Operator-Oberfläche wie den Rest der autoritativen DNS-Ebene — Opt-in pro Domain, signierte Records als First-Class-Daten, Zonentransfer, der das Signing mitführt — ohne von einem externen Signing-Dienst abhängig zu sein.
DNSSEC ist ein Feature-Flag pro Domain, kombiniert mit First-Class-Unterstützung für alle DNSSEC-Record-Typen. Sign-and-Serve geschieht am TR7-GTM-Knoten; die Schlüsselverwahrung bleibt beim Operator.
Jede DNS-Domain in TR7 GTM aktiviert oder deaktiviert DNSSEC unabhängig über ein boolesches Schemafeld. Gemischte Deployments — einige signierte, einige unsignierte Zonen — koexistieren auf derselben Flotte, ohne eine flottenweite Verpflichtung zu erzwingen.
DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY sind Teil der unterstützten Record-Typ-Liste neben A, AAAA, CNAME, MX und dem Rest. Das Schema behandelt sie als Daten, nicht als separates Subsystem.
Der Operator wählt, wie die SOA-Serial inkrementiert: DEFAULT (Format YYYYMMDD01), INCREASE (+1 pro Änderung), EPOCH (UNIX-Timestamp) oder OFF (manuelle Kontrolle). Serial-Voranschritte sind wichtig für DNSSEC-Validatoren und für nachgelagerte Slaves.
AXFR/IXFR überträgt DNSSEC-Records neben anderen Record-Typen. Express-Mode-Slaves servieren die signierten Antworten des Masters ohne Re-Signing — ein einziger Signing-Punkt, viele Serving-Punkte.
DNSSEC bei TR7 GTM deckt die operative Oberfläche — Schema, Transfer, Serving, Integrität — ohne Delegation an einen Drittanbieter-Signer.
Jede DNS-Domain trägt ein boolesches Feld `dnssec`. Ist es true, wird die Zone als DNSSEC-aktiv behandelt: DNSKEY- und DS-Records werden erwartet, RRSIG-Records begleiten jedes RRset auf dem Draht und NSEC/NSEC3-Records decken den Namensraum der Zone ab.
DNSKEY-Records (die öffentlichen Schlüssel der Zone) werden als reguläre Records im Schema verwaltet. Operatoren importieren oder definieren DNSKEY-Inhalte; die Rotation erfolgt durch Hinzufügen neuer DNSKEY-Records vor dem Entfernen alter, folgend den Standard-Pre-Publish-Rollover-Mustern.
DS-Records (Delegation Signer) werden in der Parent-Zone verwaltet. Wenn Parent- und Child-Zonen beide auf TR7 GTM gehostet sind, propagieren DS-Records natürlich; befindet sich der Parent anderswo, exportieren Operatoren DS-Records zur Upstream-Übermittlung.
NSEC- und NSEC3-Records beweisen, dass ein abgefragter Name nicht existiert. NSEC3 fügt Salt und Iterationen hinzu, um Zonen-Enumeration zu verhindern. Beide Record-Typen sind First-Class im Schema und werden als Teil der Zone serviert.
RRSIG-Records tragen die kryptografischen Signaturen über RRsets. Das Schema unterstützt RRSIG als Record-Typ; AXFR/IXFR-Transfer trägt RRSIGs neben den signierten RRsets.
CDS- und CDNSKEY-Records kommunizieren den vorgesehenen DS-Status der Child-Zone an den Parent — was Parent-seitige Automatisierung ermöglicht (RFC 7344). Nützlich für Organisationen, die Delegationen über mehrere DNS-Anbieter betreiben.
Vier vom Operator wählbare Modi für das Voranschreiten der SOA-Serial: DEFAULT (datumsbasiert YYYYMMDD01), INCREASE (+1 pro Änderung), EPOCH (UNIX-Timestamp), OFF (manuelle Kontrolle). Serial-Werte sind für DNSSEC kritisch, weil signierte Zonen die Serial bei jeder Änderung voranschreiten müssen, um gecachte Signaturen zu invalidieren.
Jede Domain kann Slave-Server-IPs auflisten, an die sie signierte Zonen-Updates per NOTIFY pusht. Operatoren betreiben eigene nachgelagerte Slaves (PowerDNS, BIND, NSD) und erhalten signierte Kopien für verteiltes Serving.
Express-Mode-Domains, die aus einem Upstream-Master gezogen werden, erben den DNSSEC-Status des Masters. Wenn der Master signiert, serviert TR7 die signierten Antworten; signiert der Master nicht, serviert TR7 unsigniert. Die Signing-Entscheidung gehört dem Master.
Die vollständige Record-Typ-Liste (A, AAAA, AFSDB, ALIAS, CAA, CERT, CDNSKEY, CDS, CNAME, DNSKEY, DNAME, DS, HINFO, KEY, LOC, MX, NAPTR, NS, NSEC, NSEC3, NSEC3PARAM, OPENPGPKEY, PTR, RP, RRSIG, SOA, SPF, SSHFP, SRV, TKEY, TSIG, TLSA, SMIMEA, TXT, URI) enthält acht DNSSEC-bezogene Typen als First-Class-Mitglieder.
DNSSEC bei TR7 GTM wird zusammen mit Zonentransfer, Schlüsselrotation, Parent-Delegation und Validator-Erwartungen betrieben.
DNSSEC wird pro Domain aktiviert. Operatoren rollen DNSSEC zone für Zone aus und validieren jede vor der Erweiterung. Gemischte Zustände werden unbegrenzt unterstützt — einige Zonen signiert, einige unsigniert, auf derselben TR7-Flotte.
DNSKEY-Rollover folgt Standard-Mustern wie Pre-Publish/Double-Signature: neuen Schlüssel als DNSKEY-Record hinzufügen, Caches aktualisieren lassen, aktiven Signer wechseln, alten Schlüssel ausmustern. Das Schema behandelt jeden Schlüssel als Daten; der Rollover-Plan wird vom Operator gesteuert.
RRSIG-Records tragen Gültigkeitsintervalle. Operatoren definieren die Refresh-Kadenz — typischerweise werden Signaturen vor Ablauf erneuert, um Validator-Fehler bei vorübergehenden Signing-Pipeline-Problemen zu vermeiden. Die Plattform zeigt bevorstehende Abläufe zur Operator-Aktion an.
NSEC ermöglicht Zone Walking (ein Angreifer kann alle Namen enumerieren); NSEC3 fügt Salt und Iterationen hinzu, um Walking zu verhindern. Operatoren wählen pro Zone — öffentlich erreichbare Zonen verwenden oft NSEC3, um Enumeration zu verhindern; geschlossene Zonen können der Einfachheit halber NSEC nutzen.
Die Zone-Cut-Delegation erfordert, dass der Parent einen DS-Record veröffentlicht. Wenn die Parent-Zone auf TR7 gehostet ist, sind DS-Records Teil des Record-Sets des Parents. Befindet sich der Parent anderswo, exportieren Operatoren DS-Werte aus CDS-Records und übermitteln sie upstream.
Nachgelagerte Slave-Server erhalten signierte Zonen per AXFR/IXFR und servieren sie. Slaves signieren nicht erneut; sie vertrauen den Signaturen des Masters. Das unterstützt verteiltes Serving (mehrere Slave-POPs, regionale Caches) ohne Re-Signing-Overhead.
Zonen des öffentlichen Sektors, die DNSSEC-Integrität für Compliance benötigen, müssen Signing-Keys oft innerhalb der Sicherheitsgrenze halten. Das On-Prem-DNSSEC von TR7 unterstützt diese Anforderung, ohne an einen Cloud-Anbieter zu delegieren.
Banking- und Payment-Processing-Zonen nutzen DNSSEC, um DNS-Spoofing-Angriffe gegen kundennahe Dienste zu verhindern. Opt-in pro Domain erlaubt Banken, DNSSEC zone für Zone auszurollen und jede vor breiterer Einführung zu validieren.
Der Master signiert die Zone; TR7-Knoten agieren als Express-Slaves und servieren die signierten Antworten des Masters. Das Signing geschieht einmal; das Serving skaliert ohne Per-Edge-Re-Signing-Overhead.
Organisationen, die mehrere DNS-Anbieter zur Redundanz nutzen, veröffentlichen CDS-Records über TR7, sodass die Parent-Zone die aktuellen DS-Werte automatisch lernen kann. Parent-seitige Automatisierung reduziert manuelle Rollover-Koordination.
Gehen Sie On-Prem-DNSSEC mit TR7 GTM durch: Opt-in pro Domain, alle DNSSEC-Record-Typen als First-Class-Daten, Zonentransfer, der Signaturen intakt mitführt.