Most GSLB solutions focus on A, AAAA and CNAME records for basic traffic routing. That may be sufficient for simple application steering, but real enterprise DNS operations cover a much broader surface: MX, TXT, SRV, PTR, CAA, TLSA, DNSSEC records, reverse zones, dynamic DNS updates and zone transfers.
When that coverage is missing, the organization must run two separate DNS layers. One interface for GSLB, another authoritative server for advanced DNS records, separate CLI operations for DNSSEC, manual transfers for zone import and additional scripts for migration. The result is fragmented ownership over the same domain and increased operational risk.
DNSSEC management is one of the most sensitive points of this fragmentation. A signed zone requires correctly generating and publishing DNSKEY, DS, RRSIG, NSEC and NSEC3 records. Leaving this entirely to CLI commands or manual file editing raises the risk of error.
Zone migration and multi-authoritative architectures create similar problems. Taking records from a legacy DNS source, managing conflicting records, correctly setting SOA serial behavior and providing zone transfers to secondary servers all require a consistent policy. Manual zone file copying and reload workflows are insufficient for modern GSLB operations.
TR7 DNS Record Management makes full DNS management a native part of the GTM platform through 35 record types, DNSSEC, AXFR primary/secondary, DNS UPDATE, SOA edit modes and smart AXFR collision policies.
TR7 treats DNS management not as a record-entry screen, but as an operations layer that unites authoritative DNS capability with the GSLB decision engine.
TR7 combines authoritative DNS capabilities with a REST API and management interface. Operators manage record types, zone settings, TTL values and GTM behaviors from a single interface.
DNSSEC support can be activated at domain level. DNSKEY, DS, RRSIG, NSEC, NSEC3 and related record types are treated as part of the DNS management model.
TR7 can act as primary and serve zone transfers to secondary servers, or operate as secondary and pull zones from an external authoritative source via AXFR. This model is used for migration, redundancy and distributed DNS architectures.
When records arriving via AXFR conflict with existing records, the operator can select useNew, preserveCurrent or combine behavior. Zone migration and multi-source consolidation therefore never become a blind overwrite.
DNS Record Management consolidates classic DNS record coverage, DNSSEC, zone transfer, dynamic updates and GTM record behaviors in a single model.
TR7 covers 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 and URI. This breadth matters for full DNS operations beyond GSLB records. Mail, certificate security, service discovery, reverse DNS and DNSSEC needs can all be served on the same platform, without a separate DNS tool.
DNSSEC can be enabled at domain level. NSEC, NSEC3, NSEC3PARAM, RRSIG, DNSKEY, DS, CDS and CDNSKEY record types are supported as part of DNSSEC operations. This increases zone verifiability and adds a security layer against DNS spoofing risks. Operators no longer need to treat DNSSEC as a separate manual process outside GSLB record management.
In primary mode, TR7 can act as the authoritative zone source and serve zone transfers to secondary servers. Full zone transfer and incremental transfer behavior can be used according to the DNS architecture. This is required for high availability and multi-DNS server deployments. Managing the zone from a single point and propagating it to other servers ensures operational consistency.
In secondary mode, TR7 can receive a zone from another authoritative source via AXFR. This model is useful for migration, express management or transitioning to the TR7 GTM layer without disrupting existing DNS infrastructure. While records are pulled from an external source, management and decision engine integration can be established on the TR7 side. Gradual migration is possible without abandoning existing DNS investments all at once.
DNS NOTIFY lets secondary parties learn of an update need after a zone change. TR7 can evaluate incoming notification statistics within its monitoring scope. This visibility is important for understanding whether zone transfer behavior is actually working. In large DNS architectures, transfer delays and update chains are easier to track.
DNS UPDATE allows application or infrastructure components to update DNS records programmatically. For example, an application server can dynamically publish its own A record. This behavior is valuable in automation and elastic infrastructure scenarios. Dynamic update permissions should be carefully restricted and planned alongside a security policy.
DEFAULT mode can use a date-based serial approach; EPOCH mode targets Unix time, INCREASE mode targets +1 increment, and OFF mode disables automatic adjustment. SOA serial behavior is critical for the primary/secondary transfer chain. Incorrect serial management can cause secondary servers to miss changes. TR7 makes this behavior configurable as a domain setting.
TTL is managed per record via recordObj.ttl; the default is 3600 seconds. Low TTL on critical GTM records enables fast switchover and failover, while more static records can use high TTL for cache efficiency. TTL is the fundamental tradeoff between performance and rate of change in DNS operations. TR7 presents this value as a natural part of record management.
In local mode TR7 owns the zone and records become fully editable. In express mode, records are pulled from an external DNS source via AXFR, enabling a pass-through or gradual transition model. This distinction matters for organizations that cannot migrate their entire DNS infrastructure in one step. The migration process becomes more controlled and reversible.
During AXFR import, incoming records may conflict with existing ones. useNew mode promotes the new record, preserveCurrent retains the existing record, and combine merges both. These options reduce the risk of data loss or unexpected overwrites during migration. The operator can choose the right collision strategy for each zone import process.
Domain and subdomain validation ensures records are defined under the correct zone. IPv4 and IPv6 addresses are normalized to canonical form. Trailing dot behavior is aligned with the DNS standard. These controls reduce the typographic and format errors commonly seen in manual record entry.
Domain metadata fields can carry additional information for zone behavior or external system integrations. REST API access can be managed per DNS instance with an API key. This structure matters for automation, integration and multi-instance DNS operations. Record management is not limited to the UI — it is also open to API-driven processes.
DNS record management operates together with domain standardization, IP normalization, AXFR behavior, port ranges, cache and SOA serial management.
The subdomain check verifies that an entered record belongs under the relevant domain. Trailing dot and domain matching are both considered. This behavior reduces the risk of entering records under the wrong zone.
DNS domain strings are handled with a trailing dot in canonical form. A missing trailing dot can be completed automatically. This keeps absolute domain name behavior consistent.
A records are normalized using IPv4 correctForm logic, AAAA records using IPv6 correctForm logic. This prevents different notations of the same IP from creating noise in the record inventory. Normalization simplifies auditing and comparison operations.
In AXFR sync operations, record types other than SOA can be included in synchronization scope. SOA carries separate serial and authority behavior and is handled specially. This distinction increases control over zone transfers.
The useNew, preserveCurrent and combine options determine how conflicting records are handled during import. useNew favors the incoming data, preserveCurrent favors the existing data, and combine aims to retain both records. The correct behavior should be selected according to the migration plan.
Inner, API, forwarder inner and forwarder API port ranges for DNS instances can be planned separately. This separation reduces port conflicts in multi-instance and forwarder architectures. The operations team can place DNS services in a more organized way.
Query cache TTL, negative query cache TTL and maximum cache entry values can be managed at instance level. Cache has a direct effect on DNS response time and the load on the authoritative backend. GTM records requiring low TTL should be planned together with overall cache behavior.
The SOA edit mode determines how the serial value changes on primary writes. A separate setting can be used for lower-serial behavior on secondary sides. Correct serial management is the foundation of continuous zone transfer.
An organization can enable DNSSEC for its domains and bring the DNSKEY, DS, RRSIG and NSEC/NSEC3 chain under management. The zone becomes verifiable. DNS security is handled inside TR7 DNS management without being fragmented across manual CLI operations.
The zone is pulled via AXFR from the legacy authoritative source and records are reviewed on the TR7 side. On conflict, a useNew, preserveCurrent or combine policy is applied. The organization can migrate in a controlled manner without moving all DNS in one step.
Zone records held in multiple DCs can be collected via the smart AXFR process. Conflicting records are merged or preserved according to the chosen policy. This is used to centralize a fragmented DNS inventory.
An application server or automation system can update its own record via DNS UPDATE. In elastic infrastructures, a DNS record can be automatically created when a new node comes online. Update permissions should be restricted through a security policy.
in-addr.arpa or IPv6 reverse zone structures can be maintained under TR7 DNS management. PTR records are managed for network inventory and reverse resolution needs. Reverse zone security can also be strengthened together with DNSSEC.
CAA records can be used to restrict which certificate authorities may issue certificates for the domain. TLSA records publish certificate binding context over DNS in DANE scenarios. These records unite DNS security with application and certificate operations.
35 record types, DNSSEC, AXFR zone transfer and DNS UPDATE — in a single management layer. Let us walk you through a live setup on your own infrastructure.