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-md5;
secret "";
};
acl xot-acl { !{ !xot-secondaries; any; }; key xot-key ;};
zone {
type primary;
...
allow-transfer transport tls { xot-acl; };
...
}
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-md5;
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-md5
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-md5
secret: ""
};
NSD also supports mutual TLS authentication, see TLS Auth Declarations