Reloading new certs for DNS over HTTPS

[Richard T.A. Neal]

On 9/9/21 06:35 PM, Grant wrote:
>> I think the rndc reconfig should pick the new cert/key, but I am not 
>> sure if we have actually implemented this.

> Drive by comment:

> Should BIND /need/ to take any action for a /reconfig/ if it's configuration hasn't change?  --  To me the
> configuration is the same.

> This seems more like an issue where I would expect to HUP a daemon, or something more
> than /just/ a /reconfig/.

Three things here;

1. I've just (re)tested this on BIND 9.17.17 running on Ubuntu 21.04 and if I change the contents of the certificate files (NOT changing the certificate file names, just changing the contents, which is exactly what certbot does when it does a renewal) then a rndc reconfig *does* cause BIND to use the new certificate.

2. This process seems somewhat flaky however. I occasionally get the following when curl'ing following a certificate change (fixed by a full sudo systemctl restart bind9):

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ns2.flodns.net:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ns2.flodns.net:443

3. Offering my response to Grant's drive-by comment: yes, BIND *should* take action here. The configuration *has* changed because it's a different certificate. Although you might say "yes, but the configuration is still pointing to the same file - the configuration hasn't changed" then I would argue that BIND has a duty to read the contents of all explicitly referenced files when running a reconfig. Why? Well it's similar to how the named.conf no longer contains actual configuration information. It's instead standard practice for named.conf to reference named.conf.options (and others). So if BIND were to read named.conf, see that it was still being asked to read named.conf.options, it could stop there and say "yep, I've already read that file. Nothing more to do here".

Best,
Richard.