{"id":60158,"date":"2026-01-01T22:01:00","date_gmt":"2026-01-01T14:01:00","guid":{"rendered":"https:\/\/www.crazydomains.com\/learn\/?p=60158"},"modified":"2026-01-30T21:03:24","modified_gmt":"2026-01-30T13:03:24","slug":"dns-zone-transfer-security","status":"publish","type":"post","link":"https:\/\/www.crazydomains.com.au\/learn\/dns-zone-transfer-security\/","title":{"rendered":"Securing Domain Zone Transfers with TSIG Keys and ACLs"},"content":{"rendered":"\n\n\n
DNS zone transfer security refers to the controls that protect AXFR and IXFR replication between authoritative name servers by enforcing authentication, access restrictions, and data integrity.<\/em><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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\u00a0lateral-movement attacks<\/a>.<\/p>\n

Yet organisations cannot simply switch transfers off; secondary name servers are vital for uptime and compliance with service-level objectives.<\/p>\n

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.<\/p>\n

How Zone Transfers Work and Why They Must Be Secured<\/h2>\n

Authoritative\u00a0DNS servers<\/a>\u00a0replicate 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.<\/p>\n

If any host may request an AXFR, your full zone file leaves the building, ready for reconnaissance, social engineering, and\u00a0credential-stuffing campaigns<\/a>. Passive network taps can also harvest data during transit.<\/p>\n

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.<\/p>\n

TSIG: Authenticate Zone Transfers Without Heavy PKI<\/h2>\n

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.<\/p>\n

What TSIG Provides And When To Use It<\/h3>\n

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.<\/p>\n

The main caveat is managing key lifecycle and distribution; lose the secret, and you lose the protection.<\/p>\n

Key Generation, Storage, and Distribution (Operational Steps)<\/h3>\n

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.<\/p>\n

Common distribution patterns include:<\/p>\n