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 8853 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