How to use a TLS proxy with a DNS nameserver

It is of course possible to configure a TLS proxy in front of a DNS nameserver to provide DNS-over-TLS. Example configurations for nginx and haproxy are given here.

A more comprehensive setup guide using Docker has been provided by Warren Kumari: dprive-nginx-bind (Thanks Warren!)

Limitations

One of the limitations of using a proxy is that without additional work this will normally mean that the client address is not visible to the nameserver, which can cause issues with NAT64, RRL, RPZ etc.  There are ways round this using address re-write rules but we don’t detail that here. In future a solution like https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ might become standard. 

Nameserver config

To use the following with BIND to offer a TLS service, configure BIND based on the following named.conf snippet

  • This assumes BIND 9.12 which supports response padding (comment that line out if you are using an earlier version)
  • The rncd and logging config is used to capture traffic volume stats - statistics can be dumped periodically with the ‘rndc stats’ command
options {
    directory "/home/sinodun";
    listen-on port 9999 { 127.0.0.1; };
    allow-query { 127.0.0.1; };
    tcp-clients 4000;
    statistics-file "/tmp/bind-stats";
    dnssec-enable yes;
    dnssec-validation auto;
    response-padding { any; } block-size 468;
};

Use with the following in named.conf, adjusting the allow list as needed:

key "rndc-key" {
    algorithm hmac-md5;
    secret "BIGSECRET";
};
 
controls {
    inet 127.0.0.1 port 9953
        allow { 127.0.0.1; } keys { "rndc-key"; };
};

logging {
    category default { null; };
    category unmatched { null; };
};

nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
worker_connections 1024;
# multi_accept on;
}

stream {
upstream dns_tcp_servers {
server 127.0.0.1:9999;

}

server {
listen 853 ssl;
proxy_pass dns_tcp_servers;

   ssl_certificate       /etc/nginx/lego/certificates/<cert>.crt;
   ssl_certificate_key   /etc/nginx/lego/certificates/<cert>.key;
   ssl_protocols         TLSv1.2;
   ssl_ciphers           ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
   ssl_session_tickets on;
   ssl_session_timeout   4h;
   ssl_handshake_timeout 30s;
}
}

haproxy.cfg

global
log /dev/log local0
chroot /var/lib/haproxy
user haproxy
group haproxy
maxconn 1024
pidfile /var/run/haproxy.pid
nbproc <processes>
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-options force-tlsv12

   # Default SSL material locations
   ca-base /etc/ssl/certs
   crt-base /etc/ssl/private
defaults
balance roundrobin
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout check 10s

listen dns
bind 145.100.185.15:853 ssl crt /etc/haproxy/lego/certificates/<cert>.pem
mode tcp
server server1 127.0.0.1:9999

For all but lightly loaded systems, you will need to tune the number of processes or threads available to HAProxy. Unlike the nginx configuration above, which specifies an automatic configuration of the number of worker processes, HAProxy needs to have these quantities set by hand. The simplest way is to set configuration item nbproc to an appropriate number; we suggest the number of threads or processes used by the nameserver. For more advanced tuning options, including setting CPU affinity, see the HAProxy documentation or this blog post.

If you use HAProxy and have generated your certificates from Let’s Encrypt then you need to combine the certificate chain and key into one file using a command similar to:

cat  /etc/letsencrypt/certs/000<N>_chain.pem /etc/letsencrypt/keys/<my_key>.key > /etc/letsencrypt/certs/<cert>.pem