Summary

  • RFC 9103 protects AXFR and IXFR payloads from passive collection on a cleartext transfer path. It does not hide that nameservers communicate, erase size and timing signals, stop DNSSEC enumeration or make ordinary authoritative answers private.
  • A defensible XoT claim needs a chain of receipts: authenticated primary, zone-specific request authorization, TLS-only transfer, accepted replica, XoT-only transfer group and separate evidence for the recipient's custody of the copied zone.

One connection, five different questions

A secondary nameserver asks a primary for a zone. The request may seek the entire zone through AXFR or only the changes through IXFR. If the response travels in cleartext, a passive observer on that network path does not need to defeat the primary's access-control list or steal a TSIG key. The observer can simply read the records as they cross the wire.

RFC 9103 closes that collection path by specifying XFR over TLS, or XoT. It is a Standards Track document, published in August 2021, and it applies to both AXFR over TLS and IXFR over TLS. Its achievement is substantial because a transfer can expose a whole operational namespace in one flow: host names, service names, addresses and relationships that would otherwise have to be assembled query by query.

The useful sentence is still narrower than “the zone is secure”. Five questions sit inside that phrase.

Who was at the far end of the TLS connection? Was this client authorized for this zone and this request? Did every transfer message remain inside the authenticated TLS channel? What happened to the replica after the secondary accepted it? Which parts of the same namespace remain discoverable through public DNS behavior?

RFC 9103 helps answer the first three. It deliberately does not answer the last two for an operator. That boundary is not a weakness in the specification. It is the discipline that makes the result auditable.

Encryption removes the wire observer

The RFC's threat model considers the current contents and size of a zone sensitive during transfer. It does not try to conceal the existence of the zone, the fact that a transfer occurs or the identities of the nameservers involved. An observer can still see endpoints and traffic patterns. Even with padding, the size and timing of encrypted IXFR traffic may reveal something about update activity.

What TLS changes is the payload's visibility. A person able to monitor the route between primary and secondary should no longer receive the resource records in readable form merely because the transfer used ordinary TCP. That is the property XoT creates.

The distinction matters because TSIG does a different job. RFC 8945 lets parties sharing a secret authenticate DNS messages and protect their integrity. RFC 5936 describes TSIG as a way to authorize transfer clients. But a message authentication code is not encryption. A perfectly valid TSIG attached to a cleartext transfer can prove where the message came from while leaving its contents visible to a passive observer.

Nor is an encrypted connection automatically an authorized transfer. RFC 9103 requires the secondary to authenticate the primary under a strict TLS profile. The primary must separately validate that the client may request or proxy the transfer. It can use mutual TLS, or an IP-based access-control list combined with a valid TSIG or SIG(0) signature. In common implementations, that admission decision is made per request. A TLS session accepted at a listening socket is not a grant to copy every zone reachable through that server.

A fallback can undo the claim

Opportunistic TLS sounds close to the desired result, but RFC 9103 rejects it as the protection profile for XoT. Opportunistic modes may continue without authenticated server identity or fall back to cleartext when TLS is unavailable. That can be useful in other contexts; it cannot support the statement that this transfer was protected from an active attacker or that a cleartext weak link was forbidden.

The same problem appears at group scale. RFC 9103 calls the complete set of primaries and secondaries for a zone the transfer group. Confidentiality for the group requires all AXFR and IXFR paths to use XoT consistently. One legacy secondary, one migration exception or one proxy-to-backend hop that returns to cleartext can preserve the observation path the operator thought it had removed.

This makes the unit of proof larger than a packet capture from one successful connection. A receipt has to name the relevant transfer group, the allowed authentication pattern and the fallback rule. It has to record whether a TLS proxy terminates the protected channel before the primary. It must say whether reuse of a connection changes the per-zone authorization check. “Port 853 answered” proves none of those things.

Some checks are comparatively straightforward. An operator can attempt a transfer without TSIG, from an unauthorized address or over cleartext and confirm refusal. Other checks are harder: whether every secondary rejects unsigned data, whether all peers use strict rather than opportunistic TLS, and whether a third-party secondary carries the same policy into its own onward transfers. RFC 9103 explicitly leaves coordination and enforcement of those policies outside its scope.

The encrypted payload becomes somebody else's copy

Suppose every wire control works. The secondary authenticates the primary; the primary authorizes the secondary; TLS 1.3 protects the payload; an IXFR completes; the secondary accepts the new serial. The cleartext observer is gone.

Now the zone exists in another administrative domain.

The secondary may store a journal, a full zone file, a database snapshot and backups. Operators and support systems may have local access. The replica may be sent to additional secondaries. The authoritative service will intentionally answer ordinary queries for published records. These are not failures of TLS. They are custody and publication consequences of successful replication.

That is why a recipient's identity cannot be the last receipt. A complete operating record needs the secondary's retention boundary, access policy, backup treatment, logging surface, onward-transfer list and deletion or rotation process. If a provider operates several layers of secondary infrastructure, the transfer map must follow the content rather than stop at the first certificate.

ZONEMD illustrates another boundary. RFC 8976 defines a digest mechanism for a standalone zone, and RFC 9103 describes it as complementary and orthogonal to channel protection. A digest may help a consumer authenticate a whole-zone object. It does not hide that object in transit. Conversely, a confidential TLS channel does not prove that the zone's records are correct, current or approved by the right human principal.

Public DNS remains public DNS

RFC 9103 also refuses to merge transfer confidentiality with zone-enumeration protection. NSEC denial records can allow a signed zone to be walked. NSEC3 was designed to make that enumeration harder by hashing owner names, but it is not a statement that XoT has concealed every name. The RFC notes that enumeration and transfer eavesdropping are orthogonal paths aimed at some of the same information.

Ordinary authoritative queries form a third path. A record meant to answer a public query remains available through that service. A party can collect such answers over time, follow naming conventions or combine them with other public data. XoT makes bulk collection from the replication stream harder; it does not redesign the publication contract of DNS.

This is the right place for restraint. An operator should not claim that all public zone data are secret. It should state which collection path has been closed, which paths remain and which names or addresses should never have been published in the zone at all.

A transfer-confidentiality receipt

The operational result can be recorded in eight rows.

Scope identifies the zone, policy version, transfer group and accountable operators. Primary identity records the authentication domain name or SPKI pin, certificate result, TLS version and endpoint reached. Secondary admission records mutual-TLS identity or IP ACL plus TSIG/SIG(0), the zone-specific authorization decision and negative-test results.

Transport says AXoT or IXoT, defines cleartext prohibition and fallback, and exposes every proxy boundary. Completion records requested and accepted serials, IXFR-to-AXFR fallback and the actual terminal state. Replica custody names storage, local access, backup, logging and onward-transfer controls.

Residual exposure records ordinary-query publication, NSEC or NSEC3 posture, visible endpoint relationships and remaining timing or size signals. Revalidation lists the changes that expire the receipt: a new certificate, key, ACL, proxy, secondary, topology, signing policy or operator.

No row should be allowed to turn all the others green. A successful TLS handshake is evidence of a channel. A valid TSIG is evidence about a message. A completed transfer is evidence of delivery. An accepted serial is evidence of replica state. None is, by itself, evidence of accurate zone content, authorized onward use or complete confidentiality.

Sources