Setting Up DNS Over TLS (DoT) on BIND

Introduction

Securing DNS queries with DNS over TLS (DoT) enhances privacy and security by encrypting DNS traffic. Unlike traditional DNS, which sends queries in plaintext, DoT ensures that your DNS lookups remain private and protected from eavesdropping and manipulation.

Note: This configuration was written for a BIND server running on OpenBSD. While the BIND configuration remains the same on Linux, paths may need to be adjusted accordingly to reflect the Linux filesystem structure. Additionally, OpenBSD uses rcctl for service management instead of systemctl on Linux.

Why Choose DNS Over TLS (DoT) Instead of DNS Over HTTPS (DoH)?

Both DoT and DNS over HTTPS (DoH) encrypt DNS queries to prevent interception and modification. However, DoT is often the preferred choice for network administrators for several reasons:

• Easier Network Management: DoT uses a dedicated port (TCP 853), making it easier to identify and manage DNS traffic within an enterprise or private network, while DoH is disguised as HTTPS traffic over port 443, making it harder to control.
• Better Performance for Recursors: Since DoT is a pure DNS protocol extension, it avoids the overhead of HTTP and TLS session management that DoH incurs, resulting in more efficient query handling for recursive resolvers.
• Preserving DNS Control: With DoH, clients can bypass local DNS resolvers and directly query external providers, potentially undermining network policies. DoT, on the other hand, integrates naturally with existing DNS infrastructures without circumventing enterprise policies.
• Reduced Attack Surface: DoH relies on web servers and browser-based implementations, increasing the complexity of security management. DoT, being a dedicated protocol, minimizes this risk by keeping DNS queries strictly within DNS services.

For those managing private or enterprise networks, DoT offers a balance between security and control, ensuring encrypted DNS queries without losing visibility and administrative oversight.

1. Preparing TLS Certificates

Before enabling DoT, ensure you have valid TLS certificates for your BIND server. The certificates should be placed in a dedicated directory.

Generating TLS Certificates

If you don’t have an existing certificate, you can generate a self-signed certificate for testing purposes:

openssl req -x509 -newkey rsa:4096 -keyout /etc/ssl/private/example.com.key \
    -out /etc/ssl/example.com.fullchain.pem -days 365 -nodes -subj "/CN=example.com"

Create the TLS Configuration File

Create the file /var/named/etc/tls_certs and add the following content:

vim /var/named/etc/tls_certs

tls wbyc {
    cert-file "/etc/ssl/example.com.fullchain.pem";
    key-file "/etc/ssl/private/example.com.key";
};

Organizing Certificates

Create a directory structure for storing certificates:

mkdir -p /etc/ssl/private

Ensure the certificate files are placed correctly:

tree /etc/ssl/
/etc/ssl/
|-- example.com.fullchain.pem
`-- private
    `-- example.com.key

1 directory, 2 files

Adjust file permissions to secure private keys:

chmod 600 /etc/ssl/private/example.com.key
chown bind:bind /etc/ssl/private/example.com.key

2. Configuring BIND for DNS Over TLS

Modify named.conf

Edit your named.conf file to include the TLS configuration:

include "/etc/tls_certs";

options {
    listen-on    tls wbyc  { 127.0.0.1; 192.168.2.0/24; 192.168.178.0/24; 10.0.20.0/24; 10.0.21.0/24; };
    listen-on-v6 tls wbyc  { any; };
};

This configuration ensures BIND listens for DoT requests on specified network ranges.

3. Configuring Forwarding to Secure Resolvers

To forward DNS queries securely, configure BIND to use an upstream resolver that supports DoT. For this example, we'll use multiple secure DNS providers to ensure redundancy.

Add Forwarder Configuration

Append the following configuration to your named.conf:

tls OpenDNS-DoT {
    ca-file "/etc/ssl/certs/IdenTrust_Commercial_Root_CA_1.pem";
    remote-hostname "dns.opendns.com";
};

tls Cloudflare-DoT {
    ca-file "/etc/ssl/certs/Cloudflare_CA.pem";
    remote-hostname "cloudflare-dns.com";
};

tls Quad9-DoT {
    ca-file "/etc/ssl/certs/Quad9_Root_CA.pem";
    remote-hostname "dns.quad9.net";
};

options {
    forwarders port 853 tls OpenDNS-DoT {
        208.67.222.222;
        208.67.220.220;
    };
    forwarders port 853 tls Cloudflare-DoT {
        1.1.1.1;
        1.0.0.1;
    };
    forwarders port 853 tls Quad9-DoT {
        9.9.9.9;
        149.112.112.112;
    };
};

This setup ensures that BIND forwards DNS queries securely over TLS to OpenDNS, Cloudflare, and Quad9, providing better redundancy and reliability.

4. Restart and Test BIND

After making these changes, restart BIND to apply the configuration:

On OpenBSD:

rcctl restart isc_named

To check if BIND is running properly:

rcctl check isc_named

On Linux:

systemctl restart named

Verify BIND is running correctly:

systemctl status named

You can also test if DNS over TLS is working by using dig:

dig +tls @127.0.0.1 example.com

If everything is set up correctly, you should see a valid DNS response.

Conclusion

By following this guide, you have successfully configured BIND to support DNS over TLS, improving privacy and security for your DNS queries. If you need additional security measures, consider implementing DNSSEC alongside DoT for a comprehensive secure DNS setup.

Note: If you are configuring BIND on Linux, ensure that you update the paths for certificate locations and configuration files as necessary to match the Linux file system layout. Also, use systemctl instead of rcctl for service management.