Encrypted Zone Transfers

Why Encrypt Zone Transfer?

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:

  • Person-laptop.example.org
  • MX-for-Location.example.org
  • Service-tenant-from-another-org.example.org

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.

Specifications

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.

Implementations

Both BIND (from 9.18) and NSD (from 4.3.7) support zone transfer of TLS (XoT). See this table for more details.

Configuration

BIND

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!

NSD

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