DNSSEC has been a standard for over a decade, yet adoption remains uneven. The cryptography is well-understood; the operational model is well-documented. What stops many organizations from enabling it is custody: the signing key (KSK) and zone signing key (ZSK) are the trust roots of the entire zone, and most enterprises do not want those keys in a vendor's hands.
Cloud DNS providers offer DNSSEC sign-and-serve, but the keys live in the provider's KMS. The provider can revoke, rotate, or be subpoenaed — your zone integrity is conditional on the provider's continued operation. Some organizations accept this trade-off; many in regulated sectors (government, defense, finance) cannot.
The historical alternative is to operate a self-managed DNSSEC signing pipeline: BIND with custom key management, scripts to rotate keys on schedule, external HSM integration, slave configuration to receive signed records. This works, but the operational overhead is significant and the failure modes are silent (expired RRSIG, missing NSEC chain).
TR7 GTM brings DNSSEC into the same operator surface as the rest of the authoritative DNS plane — per-domain opt-in, signed records as first-class data, zone transfer that carries signing — without depending on an external signing service.
DNSSEC is a per-domain feature flag combined with first-class support for all DNSSEC record types. Sign-and-serve happens on the TR7 GTM node; key custody stays with the operator.
Each DNS domain in TR7 GTM independently enables or disables DNSSEC via a boolean schema field. Mixed deployments — some signed zones, some unsigned — coexist on the same fleet without forcing a fleet-wide commitment.
DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY are part of the supported record type list alongside A, AAAA, CNAME, MX and the rest. The schema treats them as data, not as a separate subsystem.
Operator chooses how SOA serial increments: DEFAULT (YYYYMMDD01 format), INCREASE (+1 per change), EPOCH (UNIX timestamp), or OFF (manual control). Serial advancement matters for DNSSEC validators and for downstream slaves.
AXFR/IXFR transfers DNSSEC records alongside other record types. Express-mode slaves serve the master's signed responses without re-signing — single point of signing, multiple points of serving.
DNSSEC at TR7 GTM covers the operational surface — schema, transfer, serving, integrity — without delegating to a third-party signer.
Each DNS domain carries a `dnssec` boolean field. When true, the zone is treated as DNSSEC-active: DNSKEY and DS records are expected, RRSIG records accompany each RRset on the wire, and NSEC/NSEC3 records cover the zone's name space.
DNSKEY records (the zone's public keys) are managed as regular records in the schema. Operators import or define DNSKEY content; rotation is handled by adding new DNSKEY records ahead of removal of old ones, following standard pre-publish rollover patterns.
DS records (Delegation Signer) are managed in the parent zone. When the parent and child zones are both hosted on TR7 GTM, DS records propagate naturally; when the parent is elsewhere, operators export DS records for upstream submission.
NSEC and NSEC3 records prove that a queried name does not exist. NSEC3 adds salt and iterations to defeat zone enumeration. Both record types are first-class in the schema and serve as part of the zone.
RRSIG records carry the cryptographic signatures over RRsets. The schema supports RRSIG as a record type; AXFR/IXFR transfer carries RRSIGs alongside the signed RRsets.
CDS and CDNSKEY records communicate the child zone's intended DS state to the parent — enabling parent-side automation (RFC 7344). Useful for organizations operating delegations across multiple DNS providers.
Four operator-selectable modes for SOA serial advancement: DEFAULT (date-based YYYYMMDD01), INCREASE (+1 per change), EPOCH (UNIX timestamp), OFF (manual control). Serial values are critical for DNSSEC because signed zones must advance the serial on every change to invalidate cached signatures.
Each domain can list slave server IPs to which it pushes signed zone updates via NOTIFY. Operators run their own downstream slaves (PowerDNS, BIND, NSD) and receive signed copies for distributed serving.
Express-mode domains pulled from an upstream master inherit the master's DNSSEC state. If the master signs, TR7 serves the signed responses; if the master does not sign, TR7 serves unsigned. The signing decision belongs to the master.
The full record-type list (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) includes eight DNSSEC-related types as first-class members.
DNSSEC at TR7 GTM is operated together with zone transfer, key rotation, parent delegation, and validator expectations.
DNSSEC is enabled per domain. Operators roll out DNSSEC zone by zone, validating each before expanding. Mixed states are supported indefinitely — some zones signed, some unsigned, on the same TR7 fleet.
DNSKEY rollover follows standard pre-publish / double-signature patterns: add new key as DNSKEY record, wait for caches to refresh, switch active signer, retire old key. The schema treats each key as data; the rollover schedule is operator-controlled.
RRSIG records carry validity intervals. Operators define refresh cadence — typically signatures are refreshed before expiry to avoid validator failures during transient signing-pipeline issues. The platform surfaces upcoming expiries for operator action.
NSEC enables zone walking (an attacker can enumerate all names); NSEC3 adds salt and iterations to prevent walking. Operators choose per zone — public-facing zones often use NSEC3 to prevent enumeration; closed zones may use NSEC for simplicity.
Zone-cut delegation requires the parent to publish a DS record. When the parent zone is hosted on TR7, DS records are part of the parent's record set. When the parent is elsewhere, operators export DS values from CDS records and submit them upstream.
Downstream slave servers receive signed zones via AXFR/IXFR and serve them. Slaves do not re-sign; they trust the master's signatures. This supports distributed serving (multiple slave POPs, regional caches) without re-signing overhead.
Public-sector zones requiring DNSSEC integrity for compliance must often keep signing keys inside the security boundary. TR7's on-prem DNSSEC supports the requirement without delegating to a cloud provider.
Banking and payment-processing zones use DNSSEC to prevent DNS spoofing attacks against customer-facing services. Per-domain opt-in lets banks roll out DNSSEC zone by zone, validating each before broader rollout.
Master signs the zone; TR7 nodes act as Express slaves and serve the master's signed responses. Signing happens once; serving happens at scale without per-edge re-signing overhead.
Organizations using multiple DNS providers for redundancy publish CDS records via TR7 so the parent zone can automatically learn the current DS values. Parent-side automation reduces manual rollover coordination.
Walk through on-prem DNSSEC with TR7 GTM: per-domain opt-in, all DNSSEC record types as first-class data, zone transfer that carries signatures intact.