Capability

On-Prem DNSSEC

Sign authoritative zones on your own infrastructure — DNSSEC integrity without handing key custody to a third party.

DNSSEC turns DNS from an unauthenticated lookup into a cryptographically verifiable service. The price most organizations pay is custody: cloud DNS providers manage the signing keys, perform the signing, and serve the signed responses — convenient, but the keys never sit inside your security boundary. TR7 GTM offers DNSSEC sign-and-serve on the appliance itself. Per-domain DNSSEC opt-in keeps the rollout granular. All 35 supported DNS record types coexist with the DNSSEC layer — DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY records are first-class in the schema, transferred over AXFR/IXFR like any other record type, and served with the rest of the zone. SOA edit modes (DEFAULT YYYYMMDD01, INCREASE, EPOCH, OFF) give operators control over how zone serials advance — important for both DNSSEC and downstream slave consistency. Zone transfer carries signed records as-is, so Express-mode slaves serve the master's signed responses without re-signing. The result: a DNSSEC-capable authoritative DNS plane that keeps signing keys, key rollover decisions and zone integrity under your operational control — not under a SaaS contract.

DNSSEC record types — DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG, CDS, CDNSKEY

Per-domain

DNSSEC opt-in — mixed signed and unsigned zones coexist

DNSSEC

Validated on the way back — a forged answer never reaches the cache

On-prem

Key custody stays under operator control

DNSSEC adoption is held back by key custody, not by cryptographic complexity.

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.

Our approach

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.

Per-domain DNSSEC opt-in

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.

Eight DNSSEC record types as first-class data

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.

SOA edit modes control serial advancement

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.

Zone transfer carries signed records intact

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.

Capabilities

DNSSEC at TR7 GTM covers the operational surface — schema, transfer, serving, integrity — without delegating to a third-party signer.

Validation, not only signing

Signing proves your zones to the world. Validation protects your own users: answers coming back through the recursive resolver are checked against the chain of trust, so a forged or tampered response breaks before it is cached — and a sudden rise in bogus verdicts is an alarm, because it is either an attack or a broken zone, and both need to be known now.

Per-domain DNSSEC boolean flag

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 record management

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 record support for parent-zone delegation

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 authenticated denial-of-existence

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 signature records

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 for automated parent updates

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.

SOA edit modes for serial control

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.

Slave server IPs for signed-zone replication

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.

Compatible with Express mode for hidden-master signing

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.

35 total DNS record types including 8 DNSSEC types

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.

Operational depth

DNSSEC at TR7 GTM is operated together with zone transfer, key rotation, parent delegation, and validator expectations.

Per-domain opt-in granularity

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.

Key rotation via record management

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 validity windows

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 vs NSEC3 selection

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.

Parent delegation coordination

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.

Slave server compatibility

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.

When to use it

Government and defense DNS integrity

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.

Financial sector signed zones

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.

Hidden-master architectures with signed serving

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.

Multi-provider DNS with CDS-based parent coordination

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.

Frequently asked questions

Does TR7 manage DNSSEC keys, or do I have to bring my own?

DNSSEC keys (DNSKEY records) are managed as records in the schema. Operators import existing keys or generate new ones; TR7 stores and serves them, manages their lifecycle as data, and pairs them with RRSIG records. Key generation tooling and HSM integration are operator choices — the schema is open about what holds the keys.

Can I use DNSSEC on Express-mode zones?

Yes. Express-mode zones inherit the master's DNSSEC state. The master signs; TR7 pulls signed records via AXFR/IXFR and serves them. No re-signing happens at the TR7 layer — the master's signatures are served as-is.

How does SOA edit mode affect DNSSEC?

DNSSEC requires the SOA serial to advance on every zone change so that validators and caching resolvers know the zone has been updated. SOA edit modes — DEFAULT (YYYYMMDD01), INCREASE (+1), EPOCH (UNIX timestamp), OFF (manual) — let operators choose how that advancement is computed. DEFAULT and INCREASE are most common for signed zones.

What about NSEC zone walking?

NSEC records can be walked to enumerate the entire zone, which is sometimes a privacy or reconnaissance concern. NSEC3 adds salt and iterations to defeat enumeration. The choice between NSEC and NSEC3 is per zone — operators trade off simplicity (NSEC) against walking resistance (NSEC3).

How are slave servers handled with DNSSEC?

Slave servers receive signed zones via AXFR/IXFR transfer. Slaves serve the master's signatures without re-signing. TR7 GTM can act as both a master (signing) and as a slave to another master (serving the upstream signatures). Distributed serving works without re-signing overhead.

Is DNSSEC compatible with the GSLB and DC-selection features?

Yes. DNSSEC operates at the zone-integrity layer; GSLB and DC selection operate at the answer-selection layer. The GSLB picks which records to return; the DNSSEC layer ensures those records arrive with valid signatures. The two are orthogonal — combining DNSSEC with weighted, geographic and multi-source GSLB is supported.

Sign your zones on your own infrastructure.

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.