The contents of the zone could include information such as names of persons used in names of hosts. Best practice is not to use personal information for domain names, but many such domain names exist. The contents of the zone could also include references to locations that allow inference about location information of the individuals associated with the zone’s organization. It could also include references to other organizations. Examples of this could be:
Additionally, the full zone contents expose all the IP addresses of endpoints held in the DNS records, which can make reconnaissance and attack targeting easier, particularly for IPv6 addresses or private networks. There may also be regulatory, policy, or other reasons why the zone contents in full must be treated as private.
RFC 9103 - Zone Transfer over TLS (XoT) was standardized by the IETF in 2021. I describes how to use DNS over TLS to secure zone transfers in combination with TSIG, ACLs and certificate authentication of the server.
RFC 9250 - DNS over Dedicated QUIC connections (DoQ) additionally defines how to use DoQ for encrypted zone transfer in an entirely analogous way to using DNS over TLS.
Both BIND (from 9.18) and NSD (from 4.3.7) support zone transfer of TLS (XoT). See this table for more details.
To configure a BIND primary for XoT (secured by client ACL and TSIG key) use something like the following:
options {
...
listen-on port 853 tls "xot" {any;};
...
}
tls "xot" {
cert-file "<cert-file-path>";
key-file "<key-file-path>";
protocols { TLSv1.3; };
session-tickets yes;
};
acl xot-secondaries {b.b.b.b;};
key "xot-key" {
algorithm hmac-sha256;
secret "";
};
acl xot-acl { !{ !xot-secondaries; any; }; key xot-key ;};
zone {
type primary;
...
allow-transfer transport tls { xot-acl; };
...
}
(The double negation in the acl clause is to restrict access to servers that are both secondaries AND have the
correct key. Otherwise the first match behaviour of BIND will match any secondary and not go on to check the second clause, see
the last few paragraphs of section 6.1 here: Access Control Lists
To configure a BIND seconday for XoT (secured by authenticating the server certificate and TSIG key) use something like the following:
tls "xot" {
remote-hostname "my-xot-primary.org";
protocols { TLSv1.3; };
session-tickets yes;
};
key "xot-key" {
algorithm hmac-sha256;
secret "";
};
zone {
type secondary;
...
primaries { a.a.a.a port 853 key xot-key tls "xot" ;};
...
}
To help with testing there is the option to use a transient per named process key/cert on the
BIND primary. For this option, use
listen-on port 8853 tls ephemeral {any;};
in the primary config
and remove the remote-hostname from the secondary config. While this is
convenient for testing is is NOT secure enough to use in a production
environment!
To configure an NSD primary for XoT (secured by client ACL and TSIG key) use something like the following:
zone:
...
tls-service-key: "<path_to_private_key>"
tls-service-pem: "<path_to_certifcate_file>"
tls-port: 853
provide-xfr: b.b.b.b@853 "xot-key"
key:
name: "xot-key"
algorithm: hmac-sha256
secret: ""
};
To configure an NSD secondary for XoT (secured by authenticating the server certificate and TSIG key) use something like the following:
zone:
...
request-xfr: a.a.a.a "xot-key" "xot"
tls-auth:
name: "xot"
auth-domain-name: "my-xot-primary.org"
key:
name: "xot-key"
algorithm: hmac-sha256
secret: ""
};
NSD also supports mutual TLS authentication, see TLS Auth Declarations
This table is a work in progress - please notify us it updates/corrections are needed
This table reflects some of the current behaviour on implementations and also some features proposed in RFC9103. It is noted that some name servers will behave differently when starting up and first loading zones to steady state behaviour.
| Feature | BIND | NSD | Knot Auth | PowerDNS | ||||
|---|---|---|---|---|---|---|---|---|
| Features applicable to Secondary | Sec | Pri | Sec | Pri | Sec | Pri | Sec | Pri |
TCP: Typically performs AXFRs for different |
Y |
Y |
Y |
Y |
||||
| TCP: Typically performs IXFRs in parallel to AXFRs to the same primary using separate connections (in steady state) |
Y |
Y |
Y |
Y |
||||
| TCP: Connection re-use for XFRs to same primary is possible |
(a) | |||||||
| TCP: When re-using connections, will pipeline all XFR requests |
Y |
|||||||
| Handle empty AXFR responses | NT |
NT |
NT |
NT |
NT |
NT |
NT |
NT |
| Supports XoT | 9.18 | v4.3.7 | 3.3.0 | |||||
| Feature applicable to Primary | ||||||||
Handle pipelined XFR requests on one |
Y |
Y(b) | Y |
Y |
||||
| Always sends AXFR responses for different zones serially on the same connection (not intermingled) |
Y |
Y |
Y |
Y |
||||
Sends all AXFR/IXFR responses serially |
(d) | (b) | ||||||
| Handle sequential XFR requests on one connection for the same zone |
Y |
(c) | Y |
Y |
||||
| Default size of XFR response | ~20kB | 16kB | 16kB | 4-8kB | ||||
| Explicit configuration limit on num of concurrent XFRs | Y |
(e) | (e) | (e) | ||||
| Supports XoT | 9.18 | 3.3.0 | ||||||
KEY:
(a) Current release will re-use connections if the max outgoing TPC
connections is hit. This PR
provides a configuration option to make that behaviour the default.
(b) NSD does not support IXFR as a primary
(c) Because NSD requires a reload to update a zone, an old version of
the zone will currently be sent on a TCP connection opened before the
reload. A fix/workaournd is proposed.
(d) e.g. If BIND receives an IXFR request whilst sending a large AXFR
response, it will send the IXFR response immediately intermingled with
the AXFR response.
(e) Whilst there is no limit explicitly for XFRs, the primary has a
configuration option to limit the total number of incoming TCP
connections
(defaults for relevant limits are: BIND - 25, NSD - 100, Knot - one
half of the file descriptor limit for the server process, - PowerDNS
20
(g) See this issue for
progress. Support
was added in development release 9.17.10
Note that as of 2025 BIND and NSD support Zone transfers over DoT only, while KnoT supports DoQ only.