Open Zone Transfer: When DNS Hands Out the Whole Zone

What a zone transfer is and what it was built for

A DNS zone is the set of all records answered authoritatively for a namespace: A and AAAA records for addresses, MX for mail delivery, CNAME pointers, TXT records for certificate proofs and sending domains, plus NS and SOA. For several name servers to give the same answers, this set has to travel from the primary server to the secondaries. That is exactly what the zone transfer was built for: the secondary server sends a query of type AXFR, the primary answers with the entire contents of the zone, framed by the SOA record. Because that answer usually does not fit into a single UDP packet, AXFR runs over TCP.

Alongside AXFR there is the incremental transfer IXFR, whose query type carries the number 251 at IANA (RFC 1995). Instead of the whole set, it transfers only the differences since a known serial number. If the server cannot supply that difference, it returns the complete zone and behaves like an AXFR. Anyone wanting to contain the disclosure therefore has to consider both query types, not just the better-known one.

• The SOA record with its serial number decides whether a secondary server pulls at all.
• A NOTIFY from the primary server shortens the waiting time but does not replace the transfer.
• AXFR delivers the entire set, IXFR as a rule only the changes since a serial number.
• The answer runs over TCP because it typically exceeds the size of a single UDP packet.
• Who is allowed to receive the transfer is not in the protocol but in the server configuration.

The last point is the decisive one. RFC 5936 records that a DNS implementation should provide means to restrict AXFR sessions to specific clients, and that a zone administrator has the option to restrict access to a transfer (RFC 5936). Both sentences speak of an option, not of a default. Whether the restriction is in place is an operational decision, and in practice that decision is often made unnoticed.

Why the whole zone weighs more than a single record

A single DNS record is publicly queryable as soon as somebody knows the name. The difference between "publicly queryable" and "readable in one go" is nevertheless large. In its guide to secure DNS deployment, NIST describes that a zone transfer has different security implications than a normal DNS query because it reveals a lot more information and consumes more bandwidth and response time (NIST SP 800-81-2). Whoever pulls a zone no longer has to guess names.

RFC 9103 gets specific here: the full zone contents expose all the IP addresses of the endpoints held in the records, which makes reconnaissance and attack targeting easier, particularly for IPv6 addresses and private networks (RFC 9103). That is the point at which a zone reveals more than an address list: it supplies the names along with it. "backup-db" and "staging" are not random strings but a description of purpose. How much a single response header already says about an installation is covered in our article on version banners and server headers.

The finding arises during a change, not at setup

Anyone creating a zone today gets a closed default from the common servers and control panels as a rule. So what stands out is not the initial installation but the change: a migration, an additional secondary server, a provider change, a move to a new control panel. In those moments a transfer permission is opened because the handover would otherwise fail, and afterwards it stays open.

• A provider change in which the zone was taken over via a transfer and the permission was not withdrawn afterwards.
• An additional secondary name server whose address was not yet fixed, which is why the permission was drawn widely for the time being.
• A restored system that brings an older configuration along from an old backup.
• A server built from a template in which the restriction was missing from the outset.
• A subdomain delegated to another name server whose configuration nobody reviews any more.

In these cases the permission is not an oversight but a deliberate intermediate step whose withdrawal was missing from the migration checklist. In the same way, a change tends to bury the question of whether all resolvers end up serving the same state, a check we described in our article on DNS propagation across multiple resolvers.

The check takes one minute

The question can be answered with standard tools. First determine the authoritative name servers of the zone, then address each one individually with an AXFR query. If the server answers with an error or the connection is dropped, the transfer is restricted. If a list of records comes back, it is open. The calls below use an example domain that resolves for nobody under RFC 2606.

The second call shows the desired behaviour: the server refuses the transfer. The third shows the finding. The line with the transfer size at the end is a clear signal, because it only appears when a transfer actually took place. For documentation, that one line together with the name of the answering server and the time of measurement is enough.

From zone dump to attack

A pulled zone is rarely the attack itself but its preparation. It shortens the phase in which somebody looks for a way in from days to minutes. Three routes typically lead onwards, and the first of them is the takeover of dangling pointers, which we described in detail in our article on dangling CNAME records and subdomain takeover.

The third route borders on the question of similarly spelled domains and on the situation in which the records themselves are no longer your own. How such access to the DNS administration can be detected is covered in a separate article. The open zone transfer sits at the start of that chain: it costs nothing and supplies the basis for everything that follows.

An open zone transfer is not a break-in. It is a disclosure nobody requested, containing everything a burglar would otherwise have to ask for first.

— XICTRAQ

Restricting: what is actually configured

The German Federal Office for Information Security (BSI) covers zone transfers in module APP.3.6 DNS servers. It states as a requirement that zone transfers must be configured so that they are only possible between primary and secondary DNS servers (BSI IT-Grundschutz, APP.3.6.A4). The same module supplies the reasoning in its threat section: without a restriction, any host able to send a query to the DNS servers can read out the entire domain information of those servers (BSI IT-Grundschutz, APP.3.6).

1. Keep the addresses of your own secondary name servers in a named list and permit the transfer only to them.
2. Close the default at server level so a newly created zone does not start out open.
3. Cover both query types, the full and the incremental transfer.
4. Additionally secure the permission with a shared key instead of tying it to addresses alone.
5. Measure again from the outside after every change to zone or server, instead of looking into the configuration file.

# Keep your own secondary name servers as a named list
# so the addresses do not have to appear in every zone
acl "mirrors" {
    198.51.100.14;
    203.0.113.9;
};

# Shared key for the transfer (TSIG). The value itself lives in a separate
# file readable only by the service and does not appear in this file.
key "transfer-key" {
    algorithm hmac-sha256;
};

options {
    # Default for all zones: no transfer
    allow-transfer { none; };
};

zone "example.invalid" {
    type primary;
    file "zones/example.invalid";

    # Opened deliberately: only your own mirrors, only with a key
    allow-transfer { key "transfer-key"; mirrors; };
};

# Directive names differ depending on the server software in use.
# What counts is the effect: closed default, named peers,
# signed transfer.

A restriction based on addresses alone is better than none, but it hangs on the source address of a packet. The BSI therefore recommends securing zone transfers additionally with transaction signatures (TSIG) (BSI IT-Grundschutz, APP.3.6.A18). NIST describes the same idea from the other side: these restrictions address the denial-of-service threat and potential exploits from unrestricted dissemination of information about internal resources (NIST SP 800-81-2). A shared key ties the permission to a secret instead of to an address that can be forged.

What the restriction does not solve: walking the zone

A closed zone transfer does not prevent the contents from being reconstructed another way. For signed zones using the older NSEC record, zone enumeration is trivially possible: queries for the authenticated denial-of-existence records allow a client to walk through the entire zone contents (RFC 9103). RFC 5155 phrases the same starting point for such signed zones by noting that the NSEC records present inside them enable the enumeration and that it is trivial to enumerate the zone contents by querying for names that do not exist (RFC 5155).

Its successor NSEC3 was designed precisely against this behaviour and makes enumeration considerably harder without ruling it out in every case. Anyone signing a zone should plan for that. How the signature chain is validated and monitored is described in our article on DNSSEC validation and its monitoring.

Transmitting confidentially instead of only restricting

Even a restricted zone transfer travels the network in cleartext. RFC 9103 names this as the starting problem right at the beginning: DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections (RFC 9103). The answer to that is the zone transfer over TLS. Under the same specification it should be established using port 853 unless primary and secondary explicitly agree on a different port (RFC 9103).

For an operation running its own name servers this is an achievable improvement. For an operation using managed DNS services it depends on what the environment in use supports. More important than the TLS question is therefore the order: first close the permission, then sign, then encrypt. An encrypted connection to a server that answers everybody anyway changes nothing about the disclosure.

Checked once is not checked

The state of a DNS zone is not a permanent state. It changes with every migration, every additional server, every restore from a backup. A one-off check therefore documents a point in time, not a property. The difference between the two modes of operation comes down to five questions.

In XICTRAQ this check is part of the security scan, which puts the same question to the zone regularly, and of DNS and domain monitoring, which reports records that newly appear or disappear. The same logic applies one layer down to the reachability of the addresses themselves; our article on BGP, RPKI and monitoring routes appears this week.

What the alert should set off

A finding without a recipient is an entry in a report. For the measurement to turn into an action, there has to be a path from the result to the person allowed to touch the server. For the open zone transfer that means: a notification over a channel that arrives, and a second one if nobody picks it up. How to set up alerting and escalation without drowning in noise is a question of its own.

This sequence transfers to other cases. It resembles the approach for interfaces whose retirement is announced via Sunset and Deprecation headers, and the one for clock changes that quietly shift time series. In all three cases the measurement is the easy part and the ownership is the hard one.

The zone transfer belongs on the checklist

Among DNS findings, the open zone transfer is one of those with a favourable ratio of effort to effect: one query per name server answers the question, one configuration line closes it, and the evidence is reproducible. It only becomes expensive when nobody asks.

1. List the authoritative name servers of the zone and check each one individually with an AXFR query.
2. Include delegated subdomains and self-managed reverse zones in the same check.
3. Limit the permission to your own secondary servers and close the default at server level.
4. Additionally secure the transfer with a shared key.
5. Measure again from the outside after every migration, every new server and every restore.
6. Move the check onto a schedule instead of tying it to an appointment.

In XICTRAQ that schedule runs as part of the security scan, the result appears in the report and on the status page, and the history shows since when a state has existed. Processed and hosted in Germany.