Verwaltet ein GSLB nur A- und CNAME-Records, bleibt die Hälfte des realen DNS-Betriebs außerhalb seiner Reichweite.
Die meisten GSLB-Lösungen konzentrieren sich auf A-, AAAA- und CNAME-Records für grundlegendes Traffic-Routing. Das mag für einfache Anwendungssteuerung ausreichen, der reale Unternehmens-DNS-Betrieb umfasst jedoch ein deutlich breiteres Feld: MX-, TXT-, SRV-, PTR-, CAA-, TLSA-, DNSSEC-Records, Reverse-Zonen, dynamische DNS-Updates und Zonentransfers.
Fehlt diese Abdeckung, muss die Organisation zwei separate DNS-Schichten betreiben. Eine Oberfläche für GSLB, einen anderen autoritativen Server für fortgeschrittene DNS-Records, separate CLI-Operationen für DNSSEC, manuelle Transfers für den Zonenimport und zusätzliche Skripte für die Migration. Das Ergebnis ist fragmentierte Verantwortlichkeit über dieselbe Domain und erhöhtes Betriebsrisiko.
Das DNSSEC-Management ist einer der sensibelsten Punkte dieser Fragmentierung. Eine signierte Zone erfordert die korrekte Generierung und Veröffentlichung von DNSKEY-, DS-, RRSIG-, NSEC- und NSEC3-Records. Dies vollständig CLI-Befehlen oder manueller Dateibearbeitung zu überlassen, erhöht das Fehlerrisiko.
Zonenmigration und Multi-Authoritative-Architekturen schaffen ähnliche Probleme. Records aus einer Legacy-DNS-Quelle zu übernehmen, konfliktierende Records zu verwalten, SOA-Serial-Verhalten korrekt zu setzen und Zonentransfers an sekundäre Server bereitzustellen, erfordern alle eine konsistente Richtlinie. Manuelles Kopieren von Zonendateien und Reload-Workflows reichen für den modernen GSLB-Betrieb nicht aus.
TR7 DNS-Record-Management macht vollständiges DNS-Management über 35 Record-Typen, DNSSEC, AXFR Primary/Secondary, DNS UPDATE, SOA-Edit-Modi und smarte AXFR-Kollisionsrichtlinien zu einem nativen Teil der GTM-Plattform.
Unser Ansatz
TR7 behandelt DNS-Management nicht als Record-Eingabemaske, sondern als Betriebsschicht, die autoritative DNS-Fähigkeit mit der GSLB-Entscheidungs-Engine vereint.
Autoritative DNS-Power über die TR7-UI verwaltet
TR7 kombiniert autoritative DNS-Fähigkeiten mit einer REST-API und einer Management-Oberfläche. Operatoren verwalten Record-Typen, Zonen-Einstellungen, TTL-Werte und GTM-Verhalten aus einer einzigen Oberfläche.
DNSSEC pro Zone aktivierbar oder deaktivierbar
DNSSEC-Unterstützung lässt sich auf Domain-Ebene aktivieren. DNSKEY, DS, RRSIG, NSEC, NSEC3 und verwandte Record-Typen werden als Teil des DNS-Management-Modells behandelt.
AXFR-Primary- und Secondary-Modi handhaben Zonentransfer
TR7 kann als Primary agieren und Zonentransfers an sekundäre Server bereitstellen oder als Secondary arbeiten und Zonen aus einer externen autoritativen Quelle per AXFR ziehen. Dieses Modell wird für Migration, Redundanz und verteilte DNS-Architekturen genutzt.
Smarter AXFR-Import verwaltet Kollisionen per Richtlinie
Wenn per AXFR eingehende Records mit bestehenden kollidieren, kann der Operator useNew, preserveCurrent oder combine-Verhalten wählen. Zonenmigration und Multi-Source-Konsolidierung werden so nie zum blinden Überschreiben.
Funktionen
Das DNS-Record-Management konsolidiert klassische DNS-Record-Abdeckung, DNSSEC, Zonentransfer, dynamische Updates und GTM-Record-Verhalten in einem einzigen Modell.
Sechzig Domains, ein DNS-Dienst — nicht sechzig Objekte
Ein DNS-Dienst hostet so viele Zonen, wie die Organisation besitzt, und alle antworten auf einer einzigen Listener-Adresse samt Port. Das klingt unspektakulär, bis man die Alternative sieht: Mehrere Wettbewerbsplattformen binden eine Zone je DNS-Dienst — eine Organisation mit sechzig Domains hat dann sechzig Objekte zu konfigurieren, zu überwachen, zu sichern und konsistent zu halten. Hier ist eine neue Domain eine Zone, die einem bereits vorhandenen Dienst hinzugefügt wird: keine neue Adresse, kein neuer Listener, kein neuer Monitoring-Eintrag, keine Zeile im Änderungsprotokoll für Infrastruktur, die sich gar nicht ändern musste.
35 DNS-Record-Typen bieten breite Zonen-Management-Abdeckung
TR7 deckt A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, DNSKEY, DS, RRSIG, NSEC, NSEC3, NSEC3PARAM, ALIAS, AFSDB, CERT, CDNSKEY, CDS, DNAME, HINFO, KEY, LOC, LUA, NAPTR, OPENPGPKEY, RP, SMIMEA, SPF, SSHFP, TLSA, TKEY, TSIG und URI ab. Diese Breite zählt für den vollständigen DNS-Betrieb jenseits von GSLB-Records. Anforderungen aus Mail, Zertifikatssicherheit, Service Discovery, Reverse-DNS und DNSSEC können alle auf derselben Plattform bedient werden, ohne ein separates DNS-Werkzeug.
DNSSEC-Unterstützung bringt signierte Zonen-Veröffentlichung in das Management-Modell
DNSSEC lässt sich auf Domain-Ebene aktivieren. NSEC-, NSEC3-, NSEC3PARAM-, RRSIG-, DNSKEY-, DS-, CDS- und CDNSKEY-Record-Typen werden als Teil des DNSSEC-Betriebs unterstützt. Das erhöht die Zonenverifizierbarkeit und ergänzt eine Sicherheitsschicht gegen DNS-Spoofing-Risiken. Operatoren müssen DNSSEC nicht mehr als separaten manuellen Prozess außerhalb des GSLB-Record-Managements behandeln.
AXFR-Primary-Modus liefert Zonentransfers an sekundäre DNS-Server
Im Primary-Modus kann TR7 als autoritative Zonen-Quelle agieren und Zonentransfers an sekundäre Server bereitstellen. Vollständiger Zonentransfer und inkrementelles Transfer-Verhalten können entsprechend der DNS-Architektur eingesetzt werden. Das ist für Hochverfügbarkeit und Multi-DNS-Server-Deployments erforderlich. Die Zone aus einem einzelnen Punkt zu verwalten und an andere Server zu propagieren, sichert die Betriebskonsistenz.
AXFR-Secondary-Modus kann Zonen aus einer externen autoritativen Quelle ziehen
Im Secondary-Modus kann TR7 eine Zone per AXFR von einer anderen autoritativen Quelle erhalten. Dieses Modell ist nützlich für Migration, Express-Management oder den Übergang zur TR7-GTM-Schicht ohne Unterbrechung der bestehenden DNS-Infrastruktur. Während Records aus einer externen Quelle gezogen werden, kann auf TR7-Seite Management- und Entscheidungs-Engine-Integration etabliert werden. Eine schrittweise Migration ist möglich, ohne bestehende DNS-Investitionen auf einen Schlag aufzugeben.
Der DNS-NOTIFY-Mechanismus verknüpft Zonen-Änderungen mit dem Transfer-Prozess
DNS NOTIFY informiert sekundäre Parteien nach einer Zonen-Änderung über den Update-Bedarf. TR7 kann eingehende Notification-Statistiken im Rahmen seines Monitorings auswerten. Diese Sichtbarkeit ist wichtig, um zu verstehen, ob das Zonentransfer-Verhalten tatsächlich funktioniert. In großen DNS-Architekturen werden Transfer-Verzögerungen und Update-Ketten leichter nachvollziehbar.
DNS UPDATE-Unterstützung deckt Szenarien dynamischer Record-Updates ab
DNS UPDATE erlaubt Anwendungs- oder Infrastruktur-Komponenten, DNS-Records programmatisch zu aktualisieren. Beispielsweise kann ein Anwendungsserver seinen eigenen A-Record dynamisch veröffentlichen. Dieses Verhalten ist wertvoll in Automatisierungs- und Elastic-Infrastructure-Szenarien. Dynamische Update-Berechtigungen sollten sorgfältig eingeschränkt und gemeinsam mit einer Sicherheitsrichtlinie geplant werden.
Vier SOA-Edit-Modi steuern das Zonen-Serial-Verhalten
Der DEFAULT-Modus kann einen datumsbasierten Serial-Ansatz verwenden; der EPOCH-Modus zielt auf Unix-Zeit, der INCREASE-Modus auf +1-Inkrement und der OFF-Modus deaktiviert die automatische Anpassung. SOA-Serial-Verhalten ist kritisch für die Primary/Secondary-Transfer-Kette. Falsches Serial-Management kann dazu führen, dass sekundäre Server Änderungen verpassen. TR7 macht dieses Verhalten als Domain-Einstellung konfigurierbar.
Für jeden Record kann ein eigener TTL-Wert definiert werden
TTL wird pro Record über recordObj.ttl verwaltet; der Standard liegt bei 3600 Sekunden. Niedrige TTL auf kritischen GTM-Records ermöglicht schnelles Switchover und Failover, während statischere Records hohe TTL für Cache-Effizienz nutzen können. TTL ist der grundlegende Tradeoff zwischen Performance und Änderungsrate im DNS-Betrieb. TR7 präsentiert diesen Wert als natürlichen Teil des Record-Managements.
Local- und Express-Management-Modi bieten unterschiedliche Migrationsstrategien
Im Local-Modus besitzt TR7 die Zone und Records werden vollständig editierbar. Im Express-Modus werden Records per AXFR aus einer externen DNS-Quelle gezogen, was ein Pass-Through- oder schrittweises Übergangsmodell ermöglicht. Diese Unterscheidung zählt für Organisationen, die ihre gesamte DNS-Infrastruktur nicht in einem Schritt migrieren können. Der Migrationsprozess wird kontrollierter und reversibel.
Die smarte AXFR-Kollisionsrichtlinie verwaltet Record-Konflikte sicher
Beim AXFR-Import können eingehende Records mit bestehenden kollidieren. Der useNew-Modus befördert den neuen Record, preserveCurrent bewahrt den bestehenden Record, und combine vereint beide. Diese Optionen reduzieren das Risiko von Datenverlust oder unerwartetem Überschreiben während der Migration. Der Operator kann für jeden Zonenimport-Prozess die richtige Kollisionsstrategie wählen.
DNS-Validierung und IP-Normalisierung reduzieren fehlerhafte Record-Eingaben
Die Domain- und Subdomain-Validierung stellt sicher, dass Records unter der korrekten Zone definiert sind. IPv4- und IPv6-Adressen werden auf eine kanonische Form normalisiert. Das Verhalten des Trailing Dots ist mit dem DNS-Standard abgestimmt. Diese Kontrollen reduzieren die typografischen und Format-Fehler, die bei manueller Record-Eingabe häufig auftreten.
Domain-Metadaten und API-Key-Management bieten Betriebsflexibilität
Domain-Metadatenfelder können zusätzliche Informationen für Zonen-Verhalten oder externe Systemintegrationen tragen. Der REST-API-Zugriff lässt sich pro DNS-Instanz über einen API-Key verwalten. Diese Struktur zählt für Automatisierung, Integration und Multi-Instance-DNS-Betrieb. Das Record-Management ist nicht auf die UI begrenzt — es ist auch für API-getriebene Prozesse offen.
Betriebliche Tiefe
Das DNS-Record-Management arbeitet zusammen mit Domain-Standardisierung, IP-Normalisierung, AXFR-Verhalten, Port-Bereichen, Cache und SOA-Serial-Management.
Subdomain-Validierung
Die Subdomain-Prüfung verifiziert, dass ein eingegebener Record unter die jeweilige Domain gehört. Sowohl Trailing Dot als auch Domain-Matching werden berücksichtigt. Dieses Verhalten reduziert das Risiko, Records unter der falschen Zone einzutragen.
Trailing-Dot-Standard
DNS-Domain-Strings werden in kanonischer Form mit einem Trailing Dot behandelt. Ein fehlender Trailing Dot kann automatisch ergänzt werden. Das hält das Verhalten absoluter Domain-Namen konsistent.
IPv4- und IPv6-Normalisierung
A-Records werden mittels IPv4-correctForm-Logik normalisiert, AAAA-Records mittels IPv6-correctForm-Logik. Das verhindert, dass unterschiedliche Notationen derselben IP Rauschen im Record-Inventar erzeugen. Die Normalisierung vereinfacht Audit- und Vergleichsoperationen.
AXFR-Sync-Scope
In AXFR-Sync-Operationen können andere Record-Typen als SOA in den Synchronisationsumfang einbezogen werden. SOA trägt eigenes Serial- und Authority-Verhalten und wird gesondert behandelt. Diese Unterscheidung erhöht die Kontrolle über Zonentransfers.
AXFR-Kollisionsoptionen
Die Optionen useNew, preserveCurrent und combine bestimmen, wie kollidierende Records beim Import behandelt werden. useNew bevorzugt die eingehenden Daten, preserveCurrent die bestehenden Daten und combine zielt darauf, beide Records zu erhalten. Das richtige Verhalten sollte gemäß dem Migrationsplan gewählt werden.
DNS-Port-Bereiche
Innerer, API-, Forwarder-innerer und Forwarder-API-Port-Bereiche für DNS-Instanzen lassen sich separat planen. Diese Trennung reduziert Port-Konflikte in Multi-Instance- und Forwarder-Architekturen. Das Operations-Team kann DNS-Dienste geordneter platzieren.
Cache-Einstellungen
Query-Cache-TTL, Negative-Query-Cache-TTL und maximale Cache-Eintragswerte können auf Instanz-Ebene verwaltet werden. Der Cache wirkt direkt auf DNS-Antwortzeit und Last des autoritativen Backends. GTM-Records mit niedrigem TTL-Bedarf sollten zusammen mit dem Gesamt-Cache-Verhalten geplant werden.
SOA-Serial-Management
Der SOA-Edit-Modus bestimmt, wie sich der Serial-Wert bei Primary-Writes ändert. Für niedrigeres Serial-Verhalten auf der Secondary-Seite kann eine separate Einstellung genutzt werden. Korrektes Serial-Management ist die Grundlage des kontinuierlichen Zonentransfers.
Wann einsetzen
Veröffentlichung DNSSEC-signierter Zonen
Eine Organisation kann DNSSEC für ihre Domains aktivieren und die DNSKEY-, DS-, RRSIG- und NSEC/NSEC3-Kette unter Management bringen. Die Zone wird verifizierbar. DNS-Sicherheit wird innerhalb des TR7-DNS-Managements abgewickelt, ohne in manuelle CLI-Operationen fragmentiert zu werden.
Migration aus bestehender DNS-Infrastruktur per AXFR
Die Zone wird per AXFR aus der Legacy-autoritativen Quelle gezogen und Records werden auf TR7-Seite geprüft. Bei Konflikt wird eine useNew-, preserveCurrent- oder combine-Richtlinie angewendet. Die Organisation kann kontrolliert migrieren, ohne das gesamte DNS in einem Schritt zu verlegen.
Bulk-Zonenimport aus mehreren Rechenzentren
In mehreren DCs gehaltene Zone-Records können über den smarten AXFR-Prozess eingesammelt werden. Konfligierende Records werden gemäß der gewählten Richtlinie zusammengeführt oder bewahrt. Dies wird verwendet, um ein fragmentiertes DNS-Inventar zu zentralisieren.
Anwendungs-Records per dynamischem DNS-Update pushen
Ein Anwendungsserver oder Automationssystem kann seinen eigenen Record per DNS UPDATE aktualisieren. In elastischen Infrastrukturen kann ein DNS-Record automatisch erstellt werden, sobald ein neuer Knoten online geht. Update-Berechtigungen sollten über eine Sicherheitsrichtlinie eingeschränkt werden.
Reverse-Zonen- und PTR-Record-Management
in-addr.arpa- oder IPv6-Reverse-Zonenstrukturen lassen sich unter dem TR7-DNS-Management pflegen. PTR-Records werden für Netzwerk-Inventar und Reverse-Resolution-Bedarf verwaltet. Reverse-Zonen-Sicherheit kann auch gemeinsam mit DNSSEC gestärkt werden.
Zertifikatssicherheit mit CAA und TLSA
CAA-Records können verwendet werden, um einzuschränken, welche Zertifizierungsstellen Zertifikate für die Domain ausstellen dürfen. TLSA-Records veröffentlichen den Zertifikatsbindungskontext per DNS in DANE-Szenarien. Diese Records vereinen DNS-Sicherheit mit Anwendungs- und Zertifikatsbetrieb.
Häufig gestellte Fragen
Wie viele DNS-Record-Typen unterstützt TR7?
Lässt sich DNSSEC pro Zone individuell aktivieren?
Wie werden kollidierende Records bei einem smarten AXFR-Import behandelt?
Was ist der Unterschied zwischen Local- und Express-Management-Modus?
Warum ist das SOA-Serial-Management wichtig?
In welchen Szenarien wird DNS UPDATE (RFC 2136) verwendet?
Kombinieren Sie vollständiges DNS-Management mit Ihrer GSLB-Plattform
35 Record-Typen, DNSSEC, AXFR-Zonentransfer und DNS UPDATE — in einer einzigen Management-Schicht. Lassen Sie uns Sie durch ein Live-Setup auf Ihrer eigenen Infrastruktur führen.