How open zone transfers expose your internal network

Executive summary: A DNS zone transfer (AXFR) is supposed to stay between a domain's primary and secondary nameservers. When it's left open to anyone, a single query returns a full list of every host in that zone. In recent reviews, Red Sift found zones in multiple estates handing over internal hostnames, unencrypted VoIP infrastructure, and full network maps to whoever asked. None of these organizations set out to expose that. It just accumulated.

Dont miss: Our first in this series blog on managing a dangling DNS.

• An open zone transfer returns every hostname in a zone in one query, no scanning or guessing required
• Parent domains are often locked down while a delegated subdomain, frequently owned by a different team, is left wide open
• What gets exposed isn't abstract. It's SIP endpoints, dev environments, and internal naming conventions an attacker can act on immediately
• Red Sift ASM discovers and monitors these assets continuously, including ones your team doesn't know exist

A DNS zone transfer, or AXFR, is the mechanism a primary nameserver uses to replicate its full zone file to a secondary nameserver. That's a normal, necessary part of running DNS. Two servers need the same records, so one copies the entire zone to the other.

The problem is that AXFR wasn't designed with the modern internet in mind. Unless a nameserver is explicitly configured to restrict transfers to trusted IP addresses, it will respond to a transfer request from anyone. Run dig axfr @nameserver domain.com against a misconfigured server and you get back every record in that zone. Every subdomain. Every internal hostname. Every IP address is tied to those hosts.

You don't need to brute-force subdomains or scan IP ranges to build a map of someone's infrastructure. You just ask for it.

Most security teams who've thought about this at all have locked down transfers on their primary domain. That's the zone everyone remembers to check.

What gets missed is delegation. When a domain hands off a subdomain to a different nameserver, maybe for a specific product, a regional office, or a platform a different team owns, that delegated zone runs its own configuration. Nobody re-checks it against the parent's standards, because nobody thinks of it as a separate zone. It's just "part of the domain."

Scale is the real problem here. Our analysis found the same exposure pattern across multiple organizations. Take one telecommunications company. Their parent nameservers were clean: transfers restricted, records current, nothing to flag. But one delegated subdomain, set up years earlier for a video conferencing platform, still allowed open zone transfers on six hostnames.

Nobody put it there on purpose. A subdomain gets delegated for a project, the team that owned it moves on, and the configuration never gets revisited. It just ended up that way.

A single dig axfr against that delegated zone came back with:

• The internal hostnames of Session Border Controllers running in two separate locations, communicating over unencrypted SIP
• A set of internal hostnames that mapped directly to specific business functions, making the internal naming convention immediately readable
• A development environment sitting inside what was otherwise a production zone
• An SOA serial number showing the zone hadn't been touched since 2019

None of that requires an attacker to do anything clever. It's a target list, handed over for free. Unencrypted SIP tells you exactly where to intercept a call. A dev environment inside a production zone tells you exactly where controls are probably weaker. A record last updated in 2019 tells you nobody's been checking.

A separate review, this time at a SaaS company, showed a different version of the same root cause. A network engineer had recently taken over infrastructure that had grown for years under different owners. They knew about some of the issues in the part of the zone they'd inherited. They didn't know about all of them.

One dig axfr returned close to 55 hosts, each with a resolvable IP address, in a single response. That's not a partial picture. That's a near-complete map of a meaningful chunk of the company's environment, handed over in one query to anyone who thought to ask.

Neither case involved a sophisticated attack. Both involved a standard DNS query that should have been refused and wasn't.

An open zone transfer isn't a theoretical risk sitting in a compliance spreadsheet. It's reconnaissance, done for the attacker, at no cost to them.

Once someone has a full list of your hostnames and IPs, they're not guessing where to look. They know which hosts run what. They know where a dev environment might have weaker patching. They know which infrastructure handles voice traffic and whether it's encrypted. Every failure mode in this post, an unrestricted transfer, an unmonitored delegation, a stale record nobody's revisited, points an attacker at the exact asset worth targeting next.

This is also why point-in-time checks don't hold up. The telecoms zone had presumably passed a review at some point. The delegation just never came up again after that. DNS estates don't stay still. New subdomains get delegated, new teams take ownership, and configurations drift without anyone deciding they should.

Test any nameserver you're responsible for with:

If it returns a full zone listing instead of a refusal, that server allows unrestricted transfers. Fix that by explicitly restricting transfers to a named list of trusted secondary IP addresses in your DNS server configuration, whether that's BIND, PowerDNS, or your DNS provider's equivalent setting.

Then go further than the parent domain. List every subdomain that's been delegated to a different nameserver, and test each one the same way. If you don't have a current list of what's been delegated and to whom, that's the actual finding. You don't have a zone transfer problem yet, you have a visibility problem, and the zone transfer is just where it shows up first.

This is hard to catch by checking your own domain occasionally, because the exposure usually isn't on the domain your team actively manages. It's on the one that got delegated three years ago and quietly dropped off everyone's radar.

Red Sift ASM continuously discovers and inventories your external-facing assets, including the ones your team doesn't know exist yet, by connecting directly to your registrars and managed DNS providers rather than relying on a manual list. It monitors DNS configuration across your full estate on an ongoing basis, not as a one-off audit, so a delegated subdomain that drifts out of policy gets flagged instead of forgotten. And because it shows you what an attacker sees from the outside, third-party and delegated infrastructure gets the same scrutiny as the assets your team set up directly.