Maybe I’m not searching for the right key words, but how is there not an officially supported Bind9 client for the DNS challenge?
I don’t have a lot of experience with various clients, so maybe I’m missing something else.
there is under the not so sweet name of rfc2136, available for some distros (but not with certbot-auto)
https://certbot-dns-rfc2136.readthedocs.io/
4 Likes
Gee, how did I miss that obvious nugget? 
I agree with @gpatel-fr, as far as names go referring to things by an RFC number isn’t great for humans 
1 Like
I’m also pretty new to bind. What is the summary for this functionality? It looks like a key pair is generated which permits certain records to be modified on a remote DNS server. Does this mean that multiple web servers, for example, could run certbot with the appropriate get and obtain their own certificates, all through the central DNS server?
So I followed the instructions here for a sub-domain, “testing.example.com”:
https://certbot-dns-rfc2136.readthedocs.io/en/stable/index.html
and I get REFUSED response…a few discussions mentioned chmod g+w for the /etc/bind folder, but that didn’t resolve it.
I can obtain a certificate fine for “example.com” just fine. The docs at the link above give the impression that the same credential file could be used for any domain, I guess because you own the root domain.
Any ideas?
Hi @CanadaGuy
did you really used testing.example.com?
You can't create a certificate with that domain name.
Use your own, unique domain name.
1 Like
Sorry, I should have been clear, no I used my own domain. The key point being that I used a sub-domain rather than the base domain. The base domain in the following format works fine for multiple domains, so permissions and things seem fine:
sudo certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /root/rfc2136.ini -d example.com
works fine
sudo certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /root/rfc2136.ini -d testing.example.com
does not and gives a refused message. From the logs it looks like it is looking for the _acme-challenge name attached to the sub-domain (i.e. _acme-challenge.testing.example.com). Similar log entries exist for when it tries to add the record.
2019-06-25 15:24:40,938:DEBUG:certbot.error_handler:Calling registered functions
2019-06-25 15:24:40,938:INFO:certbot.auth_handler:Cleaning up challenges
2019-06-25 15:24:40,942:DEBUG:certbot_dns_rfc2136.dns_rfc2136:No authoritative SOA record found for _acme-challenge.testing.example.com
2019-06-25 15:24:40,943:DEBUG:certbot_dns_rfc2136.dns_rfc2136:No authoritative SOA record found for testing.example.com
2019-06-25 15:24:40,945:DEBUG:certbot_dns_rfc2136.dns_rfc2136:Received authoritative SOA response for example.com
2019-06-25 15:24:40,947:DEBUG:certbot_dns_rfc2136.dns_rfc2136:Successfully deleted TXT record
2019-06-25 15:24:40,947:DEBUG:certbot.log:Exiting abnormally:
Do I need to delegate the “testing.example.com” domain to a separate file? Right now, I’m including it in my “db.example.com” zone file as
testing IN A 1.2.3.4
If I change from this:
update-policy { grant remote. name _acme-challenge.example.com. txt; };
to this
update-policy { grant remote. name _acme-challenge.testing.example.com. txt; };
in my named.conf.local file I get a little further it seems, but I then get a SERVFAIL response. I’ll try digging in the bind logs to see if it is more clear there.
- After digging into bind logs, it seems as though it’s an AppArmor problem so I guess that’s a different issue to resolve, but doesn’t explain why the base domain “example.com” works, but sub-domains do not.
1 Like
If I change from this:
update-policy { grant remote. name _acme-challenge.example.com. txt; };
to this
update-policy { grant remote. name _acme-challenge.testing.example.com. txt; };
in my named.conf.local file I get a little further it seems, but I then get a SERVFAIL response. I’ll try digging in the bind logs to see if it is more clear there.
1 Like
For the record - since either this is either of no concern to you, or you are already aware of it - the documentation I linked to is not up to date (of course, it is already TWO years old, an eternity!)
from this post, as of Bind 9.13, tsig-keygen should be used instead of dnssec-keygen.
Thanks for the heads up. This script seems like a bit of a pain, all things considered. Is it maintained anymore or is there more detailed docs somewhere about requirements?
You might read the materials at: https://si.w5gfe.org/
Some turn-of-phrase might catch the right note.
this document says that it's a paraphrase of this article
The original article is a more easy read , being a simple one-page blog article (with comments)
Thanks, the original document you mentioned gets a step closer, but uses a different script it seems. Maybe going back to my original question: is Bind9 really not supported directly by Certbot? I saw a few mentions from a few years back, it is really surprising.
My reason for using the DNS challenge is that I want to run Certbot on one host to get a certificate for a mail server as a sub-domain mail.example.com with direct binding to port 80. I would also like to run a regular web server on this host that normally wouldn’t host the same domain.
After thinking it through, I suppose I could just run a virtual host for mail.example.com on port 80, and use the webroot method. Is this what people would generally do instead of the DNS challenge? Wildcards could solve part of this issue, but then I would need to move the actual certificate around which is more headache.
1 Like
I’d say acme.sh works better when dealing with dns challenge. much more dns api support.
1 Like
absolutely don't matter for the bind configuration, the linked article gives a procedure using nsupdate to test the bind part. Once it's done should work the same with certbot-rfc2136 or acme.sh.
Since I am only thinking of using rfc2136 at the moment (contrary to the certbot authors I actually like certbot-auto..., so can't use rfc2136) moving the certificate is what I do currently. It was not a huge headache IMO, there are tons of more annoying problems. It happens quite often that doing sub-optimal things that you know how to do eats much less of your time than trying to do elegant and optimal scripts involving stuff that you don't master.
This is done in 2 steps, on my mail server (on a different internet server) I run the default python web server loaded in a ad-hoc systemd service to reply to the letsencrypt challenge, I just mount the directory in a pre hook and unmount it in the post hook, and I pass 2 webroots to certbot, 1 with my local letsencrypt web server, and 1 with the mounted remote directory with the pseudo python web server used only for letsencrypt and its challenge directory.
For sending the certificate and reloading the mail server, I could have used the deploy hook but I have another script with sftp and ssh, since I don't need real time certificate updating, there is a delay of 30 days after all. It was just for testing the script without restarting certbot.
1 Like
Hmm, I guess I need to think about my architecture a bit more. certbot by itself with the HTTP challenge works so well, I guess I was thinking/hoping the same could be said for the DNS challenge. Truth is, they do things for different reasons which wasn’t obvious at the beginning. Thanks for the tips and description of your setup.
Filed a certbot issue for some of the improvements discussed here.
3 Likes
There is one more ACME client which can handle the DNS challenge using the BIND's nsupdate command: GitHub - bruncsak/ght-acme.sh: Get publicly trusted certificate via ACME protocol from LetsEncrypt or from BuyPass . Of course, the nsupdate has to be preconfigured that it could update the required _acme-challenge.domainname TXT record.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.