Funktion

On-Prem-DNSSEC

Signieren Sie autoritative Zonen auf Ihrer eigenen Infrastruktur — DNSSEC-Integrität, ohne die Schlüsselverwahrung an Dritte abzugeben.

DNSSEC verwandelt DNS von einem nicht authentifizierten Lookup in einen kryptografisch verifizierbaren Dienst. Der Preis, den die meisten Organisationen zahlen, ist die Verwahrung: Cloud-DNS-Anbieter verwalten die Signing-Keys, führen das Signing durch und liefern die signierten Antworten aus — bequem, aber die Schlüssel liegen nie innerhalb Ihrer Sicherheitsgrenze. TR7 GTM bietet DNSSEC Sign-and-Serve auf der Appliance selbst. DNSSEC-Opt-in pro Domain hält den Rollout granular. Alle 35 unterstützten DNS-Record-Typen koexistieren mit der DNSSEC-Schicht — DNSKEY-, NSEC-, NSEC3-, NSEC3PARAM-, RRSIG-, CDS-, CDNSKEY- und DS-Records sind First-Class im Schema, werden wie jeder andere Record-Typ über AXFR/IXFR übertragen und mit dem Rest der Zone serviert. SOA-Edit-Modi (DEFAULT YYYYMMDD01, INCREASE, EPOCH, OFF) geben Operatoren Kontrolle darüber, wie Zonen-Serials voranschreiten — wichtig sowohl für DNSSEC als auch für die Konsistenz nachgelagerter Slaves. Der Zonentransfer trägt signierte Records unverändert, sodass Express-Mode-Slaves die signierten Antworten des Masters ohne Re-Signing servieren. Das Ergebnis: eine DNSSEC-fähige autoritative DNS-Ebene, die Signing-Keys, Schlüssel-Rollover-Entscheidungen und Zonen-Integrität unter Ihrer operativen Kontrolle hält — nicht unter einem SaaS-Vertrag.

DNSSEC-Record-Typen — DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY

Pro Domain

DNSSEC-Opt-in — gemischte signierte und unsignierte Zonen koexistieren

DNSSEC

Auf dem Rückweg validiert — eine gefälschte Antwort erreicht den Cache nie

On-Prem

Schlüsselverwahrung bleibt unter Operator-Kontrolle

Die DNSSEC-Adoption wird durch Schlüsselverwahrung gebremst, nicht durch kryptografische Komplexität.

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.

Unser Ansatz

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.

DNSSEC-Opt-in pro Domain

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.

Acht DNSSEC-Record-Typen als First-Class-Daten

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.

SOA-Edit-Modi steuern das Serial-Voranschreiten

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.

Zonentransfer trägt signierte Records intakt

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.

Funktionen

DNSSEC bei TR7 GTM deckt die operative Oberfläche — Schema, Transfer, Serving, Integrität — ohne Delegation an einen Drittanbieter-Signer.

Validierung, nicht nur Signierung

Signieren beweist Ihre Zonen der Welt. Validieren schützt Ihre eigenen Nutzer: Antworten, die über den rekursiven Resolver zurückkommen, werden gegen die Vertrauenskette geprüft, sodass eine gefälschte oder manipulierte Antwort bricht, bevor sie in den Cache gelangt — und ein plötzlicher Anstieg an Bogus-Urteilen ist ein Alarm, denn es ist entweder ein Angriff oder eine defekte Zone, und beides muss sofort bekannt sein.

Boolesches DNSSEC-Flag pro Domain

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-Record-Management

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-Record-Unterstützung für Parent-Zone-Delegation

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-Authenticated-Denial-of-Existence

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-Signatur-Records

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 für automatisierte Parent-Updates

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.

SOA-Edit-Modi für Serial-Kontrolle

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.

Slave-Server-IPs für Replikation signierter Zonen

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.

Kompatibel mit Express-Modus für Hidden-Master-Signing

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.

35 DNS-Record-Typen insgesamt, davon 8 DNSSEC-Typen

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.

Betriebliche Tiefe

DNSSEC bei TR7 GTM wird zusammen mit Zonentransfer, Schlüsselrotation, Parent-Delegation und Validator-Erwartungen betrieben.

Opt-in-Granularität pro Domain

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.

Schlüsselrotation per Record-Management

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-Gültigkeitsfenster

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.

Auswahl zwischen NSEC und NSEC3

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.

Koordination der Parent-Delegation

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.

Slave-Server-Kompatibilität

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.

Wann einsetzen

DNS-Integrität für Behörden und Verteidigung

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.

Signierte Zonen für den Finanzsektor

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.

Hidden-Master-Architekturen mit signiertem Serving

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.

Multi-Anbieter-DNS mit CDS-basierter Parent-Koordination

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.

Häufig gestellte Fragen

Verwaltet TR7 DNSSEC-Schlüssel, oder muss ich eigene mitbringen?

DNSSEC-Schlüssel (DNSKEY-Records) werden als Records im Schema verwaltet. Operatoren importieren bestehende Schlüssel oder generieren neue; TR7 speichert und serviert sie, verwaltet ihren Lebenszyklus als Daten und paart sie mit RRSIG-Records. Schlüsselgenerierungs-Tooling und HSM-Integration sind Operator-Entscheidungen — das Schema ist offen, was die Schlüssel hält.

Kann ich DNSSEC auf Express-Mode-Zonen verwenden?

Ja. Express-Mode-Zonen erben den DNSSEC-Status des Masters. Der Master signiert; TR7 zieht signierte Records per AXFR/IXFR und serviert sie. Auf der TR7-Schicht erfolgt kein Re-Signing — die Signaturen des Masters werden unverändert serviert.

Wie wirkt sich der SOA-Edit-Modus auf DNSSEC aus?

DNSSEC erfordert, dass die SOA-Serial bei jeder Zonen-Änderung voranschreitet, damit Validatoren und cachende Resolver wissen, dass die Zone aktualisiert wurde. SOA-Edit-Modi — DEFAULT (YYYYMMDD01), INCREASE (+1), EPOCH (UNIX-Timestamp), OFF (manuell) — erlauben Operatoren zu wählen, wie dieses Voranschreiten berechnet wird. DEFAULT und INCREASE sind für signierte Zonen am gängigsten.

Was ist mit NSEC-Zone-Walking?

NSEC-Records können durchlaufen werden, um die gesamte Zone zu enumerieren, was manchmal eine Datenschutz- oder Aufklärungssorge ist. NSEC3 fügt Salt und Iterationen hinzu, um Enumeration zu verhindern. Die Wahl zwischen NSEC und NSEC3 erfolgt pro Zone — Operatoren wägen Einfachheit (NSEC) gegen Walking-Resistenz (NSEC3) ab.

Wie werden Slave-Server mit DNSSEC behandelt?

Slave-Server erhalten signierte Zonen per AXFR/IXFR-Transfer. Slaves servieren die Signaturen des Masters ohne Re-Signing. TR7 GTM kann sowohl als Master (signierend) als auch als Slave zu einem anderen Master (Serving der Upstream-Signaturen) agieren. Verteiltes Serving funktioniert ohne Re-Signing-Overhead.

Ist DNSSEC mit den GSLB- und DC-Auswahl-Funktionen kompatibel?

Ja. DNSSEC arbeitet auf der Zonen-Integritätsschicht; GSLB und DC-Auswahl arbeiten auf der Antwort-Auswahlschicht. GSLB wählt die zurückzugebenden Records; die DNSSEC-Schicht stellt sicher, dass diese Records mit gültigen Signaturen ankommen. Beide sind orthogonal — die Kombination von DNSSEC mit gewichtetem, geografischem und Multi-Source-GSLB wird unterstützt.

Signieren Sie Ihre Zonen auf Ihrer eigenen Infrastruktur.

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.