Score:0

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

jp flag

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.

Patrick Mevzek avatar
cn flag
Your title and first line of text does not fit together. `TXT` records for Let's Encrypt are needed to issue certificates, and do not need any specific DNS configuration, while your whole text speaks about DNSSEC and you seem utterly confused. You don't need DNSSEC at all (and probably should not try to use it right now before fully understanding it), just to add one `TXT` record for Let's Encrypt.
Patrick Mevzek avatar
cn flag
"Documentation requires that a DNSSEC key" Where did you find a documentation on adding `TXT` records that asks you to set up DNSSEC?
Patrick Mevzek avatar
cn flag
"After wading through the algorithm's the only one which does not throw an error is DH" Don't do things like that. I mean not understanding at all what is happening and just blindly testing all values until you get one that works but you have no idea what it does and why it works. This will never work properly, and in case of DNS and even more so DNSSEC, will only cause you severe problems down the line...
Score:0
ar flag

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.

Score:0
cn flag

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.