Securing Domain Zone Transfers with TSIG Keys and ACLs

An unrestricted zone transfer is a goldmine for attackers. In seconds, they can download every A, MX, and TXT record for your domain, map internal subdomains, and craft highly targeted phishing or lateral-movement attacks.

Yet organisations cannot simply switch transfers off; secondary name servers are vital for uptime and compliance with service-level objectives.

This guide shows IT and security teams how to balance resilience with confidentiality. By combining TSIG authentication, robust DNS access controls, and, where possible, encrypted transport, businesses can harden their DNS zone transfer security without introducing operational friction.

How Zone Transfers Work and Why They Must Be Secured

Authoritative DNS servers replicate data via two transfer modes: AXFR copies the entire zone, while IXFR sends only the delta since the last SOA serial seen by the secondary. Both travel in clear text by default.

If any host may request an AXFR, your full zone file leaves the building, ready for reconnaissance, social engineering, and credential-stuffing campaigns. Passive network taps can also harvest data during transit.

Outright disabling transfers breaks redundancy, so the goal is controlled replication. Implementing DNS zone transfer security through TSIG keys and layered DNS access controls prevents unauthorised disclosure while keeping secondaries current.

TSIG: Authenticate Zone Transfers Without Heavy PKI

TSIG adds a cryptographic signature to each DNS message, verifying that the request truly came from an authorised peer and that it was not tampered with en route. Because it relies on HMAC and a shared secret, no public-key infrastructure is required, and almost every modern DNS server supports it by default.

What TSIG Provides And When To Use It

TSIG uses a shared HMAC key to authenticate AXFR and IXFR messages, giving message-level integrity and peer verification without the overhead of certificates. It is lightweight, widely supported, and therefore the first control most teams deploy.

The main caveat is managing key lifecycle and distribution; lose the secret, and you lose the protection.

Key Generation, Storage, and Distribution (Operational Steps)

Generate keys with strong entropy and avoid reusing the same secret across multiple secondaries. Store TSIG secrets in a dedicated secrets manager rather than plaintext configuration files.

Common distribution patterns include:

• CI/CD pipelines that inject keys at deployment time
• Vault-to-server sync jobs that rotate secrets automatically
• Ephemeral credentials for short-lived automation containers
• Adopt a rotation policy—quarterly is common—with a short overlap window so old and new keys both work during the change.
• Align TSIG rotation with your wider secrets-management policy and retain a documented rollback procedure.

Using ACLs And IP Allowlists Effectively

Where TSIG confirms who is talking, ACLs decide who may speak at all. Restricting AXFR/IXFR to known secondary IP addresses slashes the number of potential attackers who can even attempt a transfer.

Combined with TSIG, ACLs create defense-in-depth.

Static Allowlists: Simple, Fast, But Brittle

Static ACLs are ideal for on-premises setups with fixed IPs. Configuration is a single line in most DNS servers, and the control takes effect immediately. The drawback is brittleness: if a secondary’s address changes and the ACL is not updated promptly, legitimate transfers fail, causing stale records and possible downtime.

Dynamic Environments: Automation Patterns For ACLs

Cloud autoscaling, multi-region failover, and container-based secondaries are hostile to manual ACLs. Use provider APIs or orchestration hooks to update allowlists whenever infrastructure changes.

For example, a CI/CD job can push the current list of secondary IPs to the DNS firewall each time Terraform finishes applying.
Couple ACL automation with the secrets pipeline for TSIG key distribution so both controls stay in sync.

Remember: ACLs reduce noise, but they should never replace authentication for critical DNS zone transfer security.

When to Use ACLs Alone Versus Combined Controls

Use ACLs plus TSIG by default. Rely on ACLs only as a temporary stopgap in highly trusted, static networks where rapid TSIG rollout is impractical.

Encrypted Zone Transfers: When And How To Adopt Them

TSIG authenticates but does not hide zone data in transit. Encrypted transports, such as DNS over TLS for transfers defined in RFC 9103, add confidentiality, thwarting passive eavesdroppers.  Adoption, however, hinges on software support across all primary and secondary servers.

Transport Options And What They Add

Emerging options include DNS over TLS, HTTPS, and QUIC for zone transfers, each wrapping AXFR/IXFR inside an encrypted channel.

The extra layer blocks network-level snooping, reducing reconnaissance via intercepted packets. Support is already present in several mainstream authoritative servers, though it is still patchy across managed DNS providers.

Compatibility, Testing, and Staged Rollout

Start by creating a compatibility matrix of your primary and every secondary. Build a staging environment, enable encrypted transfers on one pair, and monitor performance and log output.

During pilot stages, keep TSIG + ACL in place as a fallback. Validate that monitoring picks up failures and that rollbacks can complete inside your standard maintenance window.

When to Prioritise Transport Encryption

Prioritise encryption if transfers cross shared or untrusted networks, or if regulations demand data confidentiality in flight. Otherwise, schedule it for medium-term adoption while TSIG and ACLs continue to protect authenticity and access.

Operational Best Practices: Key Lifecycle, Monitoring, and Testing

Technology controls are only as strong as the processes that surround them. Automate wherever possible and watch the logs relentlessly.

Automate Key Rotation And Secure Storage

Implement automated rotation that generates new TSIG keys, updates server configs, and restarts services during a controlled overlap window. Store both old and new keys securely and remove retired secrets immediately after the window closes.

Limit automation-tool privileges to the specific secrets and zones they manage.

Logging, Alerting, and Observability

Log every AXFR and IXFR request, successful or not, including source IP, key name and transfer size. Alert on unexpected source addresses, repeated failed TSIG validations, or transfers that exceed normal size baselines. Retain logs long enough to support incident investigations and compliance audits.

Regular Tests, Audits, and Incident Playbooks

Schedule quarterly audits to verify ACL accuracy, key inventories, and log coverage.

Run simulated unauthorised transfer attempts in a lab environment to ensure alerts fire. Maintain an incident playbook outlining how to revoke keys, update ACLs, reauthorise secondaries, and restore service rapidly.

Take Control of DNS Zone Transfers Today

Layering TSIG authentication, well-managed ACLs, and, where feasible, encrypted transports lets organisations replicate DNS zones confidently while denying reconnaissance opportunities.

Automate key rotation, keep ACLs current and instrument robust monitoring so security keeps pace with infrastructure change.

Ready to take action? At Crazy Domains, we help businesses identify DNS zone transfer risks, eliminate misconfigurations, and build resilient, secure replication architectures. Get in touch with us for more info!