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.
TR7 behandelt DNS-Management nicht als Record-Eingabemaske, sondern als Betriebsschicht, die autoritative DNS-Fähigkeit mit der GSLB-Entscheidungs-Engine vereint.
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-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.
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.
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.
Das DNS-Record-Management konsolidiert klassische DNS-Record-Abdeckung, DNSSEC, Zonentransfer, dynamische Updates und GTM-Record-Verhalten in einem einzigen Modell.
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 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.
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.
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.
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 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.
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.
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.
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.
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.
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-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.
Das DNS-Record-Management arbeitet zusammen mit Domain-Standardisierung, IP-Normalisierung, AXFR-Verhalten, Port-Bereichen, Cache und SOA-Serial-Management.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.