CoreDNS Zone Transfers Need an Explicit Allowlist
DNS zone transfers are a normal replication mechanism. They can also disclose every record in a zone to anyone who can reach the service and receives an answer. CoreDNS does not make transfer access automatic just because a file plugin serves the zone. The transfer plugin must be configured, and its to addresses define which clients receive AXFR or IXFR responses.
Understand the plugin relationship
The CoreDNS file plugin serves records from zone files. The transfer plugin handles outgoing transfers for authoritative plugins that implement the transfer interface, including file, auto, secondary, and kubernetes. The transfer plugin documentation explains that a matching zone must be served in the same server block and that to ADDRESS... limits transfer clients.
If the transfer plugin is absent, secondary servers cannot use CoreDNS as a primary. If it is present with an overly broad to list, the DNS listener can become an enumeration endpoint for the entire zone.
Keep transfers on the replication path
Use dedicated source addresses for secondary servers and allow transfers only to those addresses. If the service is reachable from multiple networks, verify that the transfer policy is applied on every listener and protocol. Restrict TCP port 53 to the replication network and separate it from the client resolver path where possible.
Review TSIG or other authenticated transfer configuration when the deployment supports it. Source IP filtering is useful, but it depends on correct network routes and cannot protect against a compromised secondary or an address translation error.
Avoid accidental internet exposure
Place CoreDNS behind a firewall policy that permits recursive queries only from intended clients and denies AXFR from the public internet. Check both IPv4 and IPv6. A service can appear protected on its primary interface while a second listener or host network bypasses the intended policy.
Inventory zone names, file paths, serial values, secondary addresses, and transfer logs. A transfer should be explainable by a known secondary. Repeated AXFR requests from an unknown address should trigger investigation, even if the request is denied.
Test the effective configuration
From an approved secondary, request the zone and verify that the serial and records match the primary. From an unapproved host, confirm that the transfer is refused or receives no zone data. Test IXFR and fallback behavior after a zone change.
After a Corefile edit, reload or restart the service according to the deployment process and repeat the tests. A configuration file that contains the correct transfer block does not prove that the running process loaded it.
Monitor change and drift
Alert on unexpected zone serial changes, new secondary addresses, transfer failures, and successful transfers outside the approved schedule. Compare the authoritative zone with the records observed by resolvers. If records appear that are not in the source file, investigate dynamic plugins, secondary sources, and generated zones.
CoreDNS zone transfer is a controlled replication feature, not a public debugging convenience. An explicit allowlist, network separation, and regular negative testing keep a useful secondary workflow from becoming a directory of internal names and service addresses.
Top comments (0)