For those who find their way here from trying to get the rfc2136 authenticator working for a wildcard certificate here is what sydney ( sydneyli ) wrote a few days after the above solution was made
“” Although nsupdate is useful for testing that your DDNS is set up correctly, the authenticator does not depend on it being installed to work properly. dnspython is explicitly listed as a dependency, and should be pulled automatically, via whatever installation method you chose for the Certbot plugin.
. . .
Just to be clear, Certbot’s RFC2136 authenticator does not directly touch your zone files; it follows RFC2136’s client API (just as nsupdate does) to tell a RFC2136-compatible DNS server to perform the proper updates. I also don’t think information on how to properly set up Dynamic DNS for BIND for a particular operating system belongs in Certbot’s documentation!""
So the issue is not setup information for Dynamic DNS so much as knowing what you have got in your BIND nameserver config out of the box. (also known as “named” in many distributions ) Simple troubleshooting info would be helpful on the documentation page though.
SINCE Certbot’s RFC2136 authenticator does not directly touch your zone files; it follows RFC2136’s client API to tell a RFC2136-compatible DNS server to perform the proper update. It requires a properly configured Dynamic Domain Nameserver (DDNS) to function properly. Many servers today run a variant of the Linux operating system which runs BIND as a nameserver.
However only a few come configured as DDNS systems and you may need to configure whatever version of BIND you are running to do “dynamic updates”. A good way to do this is to configure your name server to allow nsupdate to work properly. How you do that is beyond the scope of this page, however many RedHat based Linux distributions will have a /var/named/dynamic directory indicating it is already configured to be a DDNS. ( CentOS, Fedora, Mageia, RHEL ) Others have it in /var/lib/named/var/named/dynamic/ If you do an internet search for " /var/named/dynamic directory " you will find leaders to how to use that out of the box feature. If you have an another non RedHat based distribution then you will have to make sure nsupdate is set up and working to indicate the server can accept dynamic updates. One key issue is the zone file and directory will need to have a GROUP WRITE permission usually.
Since Certbot’s RFC2136 authenticator does not directly touch your zone files, it uses instead “DNSPYTHON” in conjunction with its coding which is written in Python to make the DNS challenges, and this is why nsupdate needs to be working as both use the RFC2136’s client API to tell a RFC2136-compatible DNS server to perform the proper update
It is recommended that you run dry-runs with the command=> certbot certonly --dry-run --dns-rfc2136 --dns-rfc2136-credentials /path to/credentials.ini -d “*.yourdomain.com” -d yourdomain.com --server https://acme-v02.api.letsencrypt.org/directory . . . . from a terminal window as root preferably . . .
which will log the run and report any errors for you and allow you to get Certbot’s RFC2136 authenticator working
when the dry-run returns successful, then remove the --dry-run or use a --force-renewal in its place that will modify the configuration files so a certbot renew can use the same successful run to renew the certificate when the time comes to do so
So . . . although nsupdate is useful for testing that your DDNS is set up correctly, the authenticator does not depend on it being installed to work properly. dnspython is explicitly Certbot’s RFC2136 authenticator dependency, and should be pulled automatically, via whatever installation method you chose for the Certbot plugin as for say an install via YUM will do. Since dnspython is difficult to troubleshoot directly — then if nsupdate is working - often Certbot’s RFC2136 authenticator will then work properly too
Dynamic Update uses a .jnl file extension of the same name as the zone which may or may not get written to the zone file, and then Certbot’s RFC2136 authenticator cleans up the challenge by removing the same TXT challenge it wrote or sent into the .jnl file
Certbot’s RFC2136 authenticator by default will wait 60 seconds for a propagation of the TXT challenge to complete and during this period you should or might be able to do a " DIG your domain TXT " to see the challenge strings waiting. If not, they are not likely propagating, however with the RedHat based Linux distributions and use of the /var/named/dynamic directory, you actually may not see the DIG work and the dry-run may still complete because of how the RedHat based Linux distributions DDNS is configured to also read the .jnl file. in the /var/named/dynamic directory
If there are not propagating a restart of BIND while the propagation is waiting will flush the TXT to the zone file and force a propagation and then it may work signalling and telling you that there is likely a permissions issue somewhere
Also the .jnl file may be left behind and has on occasion been know to prevent updates so a " rndc sync -clean " will also flush the jnl updates to the zone file and remove the jnl file itself afterwards
If these two things above do not work then usually the DNS or DDNS configuration or key setup is incorrect
Do Internet searches for how to configure your specific Linux distribution, and be sure it is for your Linux distribution or which ever OS you have. Setting up a working DDNS is different for each one