ISC Bind9 with DNS over TLS (DOT) issue with certificates

phil80

I installed and setup Bind9 official package to test DNS forward zones based on source IP/subnets which unbound doesn't support

I properly set NAT forwards, changed listening ports on Bind9 and configured it for DNS over TLS (see below)

All works properly and DNS requests are properly forwarded and use TLS until I uncomment remote-hostname and/or ca-file options. Without them, as per Bind9 doc, encryption is granted but not TLS authentication

If I enable those options to ensure strict TLS authentication, clients cannot resolve DNS entries and I get the below errors in logs:

Jul 29 00:50:29	named	92197	query-errors: debug 4: fetch completed for readaloud.googleapis.com.intranet/A in 0.056869: TLS peer certificate verification failed/success [domain:.,referral:0,restart:1,qrysent:0,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
Jul 29 00:50:29	named	92197	query-errors: info: client @0x1414c4b10800 10.0.31.62#9512 (readaloud.googleapis.com.intranet): query failed (TLS peer certificate verification failed) for readaloud.googleapis.com.intranet/IN/A at query.c:7836

I tried with different ca-file values, but no success

My Bind9 config is:

Forwarder Configuration: Enable Forwarding : Unchecked to forward using custom options

Custom Options:

forwarders {
    1.1.1.1 port 853 tls cloudflare-tls;
    1.0.0.1 port 853 tls cloudflare-tls;
    2606:4700:4700::1111 port 853 tls "cloudflare-tls";
    2606:4700:4700::1001 port 853 tls "cloudflare-tls";
};

Global options:

tls cloudflare-tls {
//    ca-file "/usr/local/share/certs/ca-root-nss.crt";
//    ca-file "/usr/local/etc/ssl/cert.pem";
//    ca-file "/usr/share/certs/trusted/IdenTrust_Commercial_Root_CA_1.pem";
//    remote-hostname "one.one.one.one";
    prefer-server-ciphers yes;
};

Bind9 Docs:
https://bind9.readthedocs.io/en/v9.18.14/reference.html#namedconf-statement-prefer-server-ciphers

Strict TLS provides server authentication via a pre-configured hostname for outgoing connections. This mechanism offers both channel confidentiality and channel authentication (of the server). In order to achieve Strict TLS, one needs to use remote-hostname and, optionally, ca-file options in the tls statements used for establishing outgoing connections (e.g. the ones used to download zone from primaries via TLS). Providing any of the mentioned options will enable server authentication. If remote-hostname is provided but ca-file is missed, then the platform-specific certificate authority certificates are used for authentication. The set roughly corresponds to the one used by WEB-browsers to authenticate HTTPS hosts. On the other hand, if ca-file is provided but remote-hostname is missing, then the remote side’s IP address is used instead.

tinfoilmatt

Try "cloudflare-dns.com" for the remote-hostname in the global options entry. That's the correct hostname for TLS verification.

phil80

@tinfoilmatt said in ISC Bind9 with DNS over TLS (DOT) issue with certificates:

cloudflare-dns.com

I tried it and same result
Same also with google, quad9...

forwarders {
    1.1.1.1 port 853 tls "cloudflare-tls";
    1.0.0.1 port 853 tls "cloudflare-tls";
    2606:4700:4700::1111 port 853 tls "cloudflare-tls";
    2606:4700:4700::1001 port 853 tls "cloudflare-tls";

    8.8.8.8 port 853 tls "google-tls";
    8.8.4.4 port 853 tls "google-tls";
    2001:4860:4860::8888 port 853 tls "google-tls";
    2001:4860:4860::8844 port 853 tls "google-tls";

    9.9.9.9 port 853 tls quad9-tls;
    9.9.9.9 tls quad9-tls;
    149.112.112.112 port 853 tls quad9-tls;
    2620:fe::fe port 853 tls quad9-tls;
    2620:fe::9 port 853 tls quad9-tls;
};

And the Global options:

tls cloudflare-tls {
    //ca-file "/usr/local/share/certs/ca-root-nss.crt";
    //ca-file "/usr/local/etc/ssl/cert.pem";
    //ca-file "/usr/share/certs/trusted/IdenTrust_Commercial_Root_CA_1.pem";
    //remote-hostname "one.one.one.one";
    //remote-hostname "cloudflare-dns.com";
    prefer-server-ciphers yes;
};

tls google-tls {
    //ca-file "/usr/local/share/certs/ca-root-nss.crt";
    //ca-file "/usr/local/etc/ssl/cert.pem";
    //ca-file "/usr/share/certs/trusted/IdenTrust_Commercial_Root_CA_1.pem";
    //remote-hostname "dns.google";
    prefer-server-ciphers yes;
};

tls quad9-tls {
    //ca-file "/usr/local/share/certs/ca-root-nss.crt";
    //ca-file "/usr/local/etc/ssl/cert.pem";
    //ca-file "/usr/share/certs/trusted/IdenTrust_Commercial_Root_CA_1.pem";
    //remote-hostname "dns.quad9.net";
    prefer-server-ciphers yes;
};

I also tried copying the certs to a folder with ownership bind:bind, same result

tinfoilmatt

Remove the "//remote-hostname "one.one.one.one";" line.

tinfoilmatt

This post is deleted!

phil80

@tinfoilmatt said in ISC Bind9 with DNS over TLS (DOT) issue with certificates:

Remove the "//remote-hostname "one.one.one.one";" line.

Those are commented lines
It doesn't change removing them
I'll try in a jail on a vm and check if it's a pfsense pkg bug

phil80

@phil80
I opened a redmine issue as it is clearly a pfsense package bug
https://redmine.pfsense.org/issues/16345

pkg install bind920 in pfsense works

tinfoilmatt

@phil80 Please keep chasing. This could be a great supplement to DNS Resolver in forwarding mode if TLS auth is strictly enforced. Unbound, without any DoT client config and utilizing pfB in Python mode, could be forwarded to BIND locally. And then BIND forwared to DoT-enabled recursive resolver of choice, as you've done here, but taking advantage of BIND's strict TLS auth.

Can anyone confirm that strict TLS auth is or is not happening with unbound configured in DoT forwarding mode (and properly configured DNS servers under System / General Setup, of course)?

phil80

@tinfoilmatt
Unbound works properly with DOT in n forwaring mode
Bind9 pfsense implementation no
Bind9 with pkg install works
What unbound is missing is forwarders by zone. Actually it is only global. When you override dns in dhcp, you cannot forward 53 to dot in unbound. You have to block it in fw rules and enforce a dot rule to the given server. But you could loose tls auth too as dhcp overrides do not provide domain name. It'll need to be set in client

Basically, bind has the advantage of forwarding by zone and much more