Configuring BIND9 (ver 9.16) to allow TXT DNS updates from Letsncrypt

Solution to the below problem: Use $ddns-confgen or $tsig-keygen, the former provides you with the syntax to paste into your named.conf file

Problem:

I am trying to configure a BIND9 (ver9.161-Ubuntu) to allow me to create TXT records which Letsecrypt can use to validate the domain, ultimately to allow for the generation of SSL certs for internal/private systems.

There is plenty of documentation on the processes, in particular a step by step guide from Home Assistant (Home automation suite on configuring nginx + letsencrypt). HOWEVER, the algorithms and processes appear to have changed since the documentation was originally produced.

Documentation requires that a DNSSEC key is generated to allow for host updates

$dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST letsencrypt

dnssec-keygen: fatal: unknown algorithm HMAC-SHA512

If I run dnssec-keygen --help, it provides a list of algorithms which are

"RSASHA1 | NSEC3RSASHA1 | RSASHA256 | RSASHA512 | ECDSAP256SHA256 | ECDSAP384SHA384 | ED25519 | ED448 | DH"

If the above command is changed to: RSASHA512 and key size changes to 1024 then the system errors with:

dnssec-keygen: fatal: invalid DNSKEY nametype HOST

After wading through the algorithm's the only one which does not throw an error is DH, by setting the alogorithm to DH a key is generated.

The next issue is that the DH protocol is not recognised when used in the name.conf.local file.

adding a key section into the named.conf.local file:

key "letsencrypt" {
  algorithm DH;
  secret "averylongkey==";
};

but when I run:

$ sudo named-checkconf
/etc/bind/named.conf.local:14: unknown algorithm 'DH'

Basically the old documentation is asking you to use an outdated keygen method.

You don't need a DNSSEC key. You need a RNDC key. Run e.g. rndc-confgen to generate a proposed configuration and secret. You may have to adapt this config to suit your needs with regards to hosts that are allowed to update and interfaces bind should accept updates on.

This is really just setting up a normal config to allow dynamic updates to the zone.

Create a key that is suitable for TSIG, eg:

$ tsig-keygen letsencrypt-key
key "letsencrypt-key" {
        algorithm hmac-sha256;
        secret "igyPH4oXPjutSfJVpv3CTgTjxSOyehJ7uVO274UuUDo=";
};
$

and put this key in your config.

Then for the relevant zone add an update-policy that allows a client using this key to manage whatever record(s) it is that you need for this purpose.

Eg

zone "example.com {
...
    update-policy {
        grant letsencrypt-key. name _acme-challenge.www.example.com. TXT;
        grant letsencrypt-key. name _acme-challenge.example.com. TXT;
        ...
    };
};

Sidenote:
Do keep in mind that when a zone is configured to be managed via dynamic updates, it is not appropriate for anything but BIND itself to make changes to the zone file.
This does imply a somewhat different workflow if the file was being edited directly before, but overall I would say this is a more modern and less error-prone approach to have all changes made via the dynamic updates protocol, instead of outside processes writing to the zone file directly. Tooling like for example nsvi does allow for a similar editing experience but with the changes applied via dynamic updates.