Zone Transfer Check: a beginner's guide

A zone transfer (technically AXFR — Asynchronous Full Transfer Zone, RFC 5936) is a DNS feature designed for backing up an entire DNS zone from one authoritative nameserver to another. In the original 1983 design, secondary nameservers stayed in sync by periodically asking the primary for a complete copy of the zone. AXFR was the mechanism. It was designed at a time when nameserver replication was a friendly operation between trusted servers on a friendly internet, and there was no thought given to the security implications of outsiders being able to ask the same question.

You should care because on the modern internet, an open zone transfer is a security finding. If your nameservers respond to AXFR from anyone, an attacker gets a complete dump of every DNS record in your zone — every subdomain, every internal hostname, every test environment, every email gateway, every legacy system. The treasure-map nature of the leak is what makes AXFR exposure a critical-severity issue.

Severity depends on what's in the zone. A leaked zone of mostly CNAME glue is bad but not catastrophic. A zone with TXT, CAA, SRV, or TLSA records is much worse — TXT typically holds SPF includes, DKIM keys, and verification tokens (revealing every third-party SaaS the org uses); CAA reveals certificate-issuance policy; SRV reveals service topology. A modern check reports the record-type breakdown, not just "records exposed: 247."

Refusing AXFR isn't enough — NSEC walking still leaks. A zone that correctly refuses AXFR can still be enumerable if it's DNSSEC-signed with legacy NSEC rather than NSEC3 (RFC 5155). Each NSEC record points to the next existing name in the zone, alphabetically. Asking for a non-existent name returns the NSEC chain that brackets it; ask enough negative questions and you walk the entire zone. NSEC3 hashes the names before chaining, making walking computationally hard (RFC 9276 gives the modern parameter guidance). A complete check therefore tests both AXFR exposure and whether NSEC walking is feasible — refusing one without the other is a false sense of security.

The five things a real zone-transfer check looks at:

• Is AXFR allowed from arbitrary sources? Connect to each authoritative NS on TCP port 53 and send an AXFR request. RCODE=0 with records returned means the zone leaks.

• Have all NSes been verified? It's common to harden the primary and forget the secondaries.

• What does the leaked zone contain? Record-type counts (A, MX, TXT, CNAME, CAA, SRV, etc.). High-sensitivity types (TXT, CAA, SRV, TLSA) sharply elevate severity.

• Is NSEC walking feasible? Even if AXFR is refused, the zone may still be fully enumerable via legacy NSEC.

• Provider-specific remediation. Hosted providers (Cloudflare, Route 53) refuse AXFR by default; the most common findings are on self-hosted BIND, PowerDNS, NSD, and Knot — each has a different `allow-transfer` syntax.

Three questions a zone-transfer check answers:

• Is any nameserver leaking the entire zone to anyone who asks?

• If AXFR is refused, is the zone also protected against NSEC walking — or is enumeration still trivial?

• What kinds of records are in the zone, and how sensitive is the leak?

The cost of an open zone transfer is silent reconnaissance: an attacker gets a free map. The fix is one configuration change per nameserver — and on hosted providers it's already the default. The most-missed corollary is the NSEC-walking check: closing AXFR without addressing NSEC3 parameters leaves the door half open.

In one sentence: Test for [DNS (Domain Name System)](/guides/dns-lookup) zone transfer vulnerability

Tests for zone transfer (AXFR (Asynchronous Full Transfer Zone)) vulnerabilities by attempting real TCP-based AXFR requests against each authoritative nameserver. Reports which servers allow transfers, how many records are exposed, and provides security hardening recommendations per the official internet standard and CIS DNS (Domain Name System) benchmarks.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Resolves all authoritative nameservers, then sends real AXFR (Asynchronous Full Transfer Zone) queries (the official internet standard) to each. Reports per-server result (vulnerable, refused, timeout), total records exposed, sample owner-names, and a record-type breakdown — TXT, CAA, SRV, and TLSA are flagged as `high_sensitivity_types_present` since these typically expose SPF (Sender Policy Framework) includes, verification tokens, certificate-issuance policy, and service topology that are far more sensitive than CNAME (Canonical Name record) glue. When AXFR is refused, cross-references the DNS-nsec-walkability check: zones using legacy NSEC (rather than NSEC3) can still be enumerated by walking the NSEC chain, so `alternative_enumeration_risks.nsec_walkable` surfaces this. Detects the authoritative DNS (Domain Name System) provider and returns provider-keyed `remediation_snippets` — paste-ready `allow-transfer` config for BIND, PowerDNS, NSD, Knot, plus notes for Cloudflare DNS and Route 53 (which don't support AXFR by default).

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Zone Transfer Check tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

A 2022 survey found ~12% of organizations had at least one nameserver allowing unauthorized zone transfers. Most AXFR (Asynchronous Full Transfer Zone) tools stop at "vulnerable yes/no", but the severity of an exposed zone depends entirely on what's in it — a leaked zone full of SPF (Sender Policy Framework) includes and verification tokens is much worse than one with mostly CNAME (Canonical Name record) glue. The record-type breakdown turns "you're vulnerable" into "your TXT records are leaking; here's exactly what's exposed". The NSEC cross-reference catches a frequently-missed case where AXFR is correctly refused but enumeration is still possible. The provider-keyed remediation makes the fix concrete instead of generic.

Picture this in real life. Imagine a penetration tester. Here's the situation they're walking into: During reconnaissance, test for zone transfer to discover all subdomains and internal hosts. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Zone Transfer Check tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Zone Transfer Check tool is built for you:

• Is my domain pointing to the right place right now?

• Did the DNS change I just made actually take effect everywhere in the world?

• Is anything in my DNS misconfigured in a way that could break email or break the website?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders running their own infrastructure, marketers coordinating launches, IT admins inheriting domains from a former employee, and ops engineers troubleshooting live outages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you're flying blind on the one piece of config that decides whether your website and email work at all. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the Zone Transfer Check tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a penetration tester, a security engineer, and a compliance officer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Security Assessment

Imagine you're a penetration tester. During reconnaissance, test for zone transfer to discover all subdomains and internal hosts.

Why it matters: Quickly map the complete DNS (Domain Name System) infrastructure if zone transfer is allowed.

Story 2: DNS Security Audit

Imagine you're a security engineer. Audit organization DNS (Domain Name System) servers to ensure zone transfers are restricted.

Why it matters: Identify and remediate zone transfer vulnerabilities before attackers exploit them.

Story 3: Compliance Verification

Imagine you're a compliance officer. Verify DNS (Domain Name System) servers meet CIS benchmark requirements for zone transfer restrictions. Document AXFR (Asynchronous Full Transfer Zone) controls for SOC 2 (Service Organization Control 2), ISO 27001 (ISO/IEC 27001 information security management standard), and NIST SP 800-81 compliance.

Why it matters: Demonstrate DNS (Domain Name System) security controls with specific compliance framework evidence.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Zone Transfer Check tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• Right before launching a new website or migrating to a new host.

• After making any DNS change, to confirm the new settings are live everywhere.

• When customers report that your site or email "just stopped working" out of nowhere.

• As a recurring monthly health check to catch silent misconfigurations early.

If you can see yourself in even one of those bullets, the Zone Transfer Check tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Zone Transfer Check tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the Zone Transfer Check tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with Zone Transfer Check. If you're already running this check, the related ones often answer the next question that comes up:

• Nameservers — List nameservers and detect DNS provider

• DNS Lookup — Query any of 22 DNS record types or ALL at once with DNSSEC validation

• DNSSEC Check — Verify DNSSEC signing and validation

• NSEC Walkability — Grade zone-enumeration risk from NSEC3PARAM configuration

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check Zone Transfer Check and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

A record (Address record) — A DNS entry that points a domain name to a specific server address.

CNAME (Canonical Name record) — A DNS entry that says "this name is just an alias for that other name."

SPF (Sender Policy Framework) — A list, published in your DNS, of which servers are allowed to send email pretending to be you. Helps stop spammers from forging your address.

RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.

SOC 2 (Service Organization Control 2) — A widely used security audit. Proves to customers that you handle their data responsibly.

ISO 27001 (ISO/IEC 27001 information security management standard) — An international certification that shows your company has a documented, working security program.

AXFR (Asynchronous Full Transfer Zone) — The DNS protocol for transferring an entire zone from one authoritative nameserver to another (RFC 5936). When an attacker can run AXFR, they get a complete dump of every record in the zone.