We have numerous hypervisors/containers/VM's that are provisioned and configured using Foreman/Puppet and we just deployed the acme.sh module so each server can automatically request and renew certificates for the services being provided (web, mail, etc).
Some simple testing has been performed on internal test servers to ensure a host can create a certificate request and that the DNS-01 interaction with our BIND server is working. Everything has been successful with a single host/subdomain but we're stuck on how to setup BIND to support all of our hosts.
Some restrictions/processes in place:
We can not have a wildcard domain. It won't pass our security requirements so each host needs it's own certificate
New hosts are created all the time and may need certificates so the host list isn't static
Our BIND configuration uses the update-policy for fine grained control over domain updates
An update-policy with a grant to allow any TXT updates to a zone may be possible but could be flagged as a security risk
So how can we setup BIND to support a dynamic subdomain list with acme.sh and Let's Encrypt certificates while maintaining our security requirements?
When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
I'm not personally familiar with how to configure BIND so I don't think I can help you with locking that part down (though I think other people here might have some ideas), but if you're concerned that a host might be able to request a certificate for a wildcard when you don't want it to, then you can limit that with CAA records.
It sounds like you're looking for advice about BIND management in general. But realistically, you're not going to find a ton of BIND experts on this forum and might be better served asking the question somewhere else that is more BIND focused.
That said here's my semi-educated guess. If your requirements force you to stick with BIND, you'll either have to build a way to dynamically update the update-policy as part of your host provisioning process or accept the security risk of a more open policy.
Obviously, you could also ditch BIND for an alternative authoritative nameserver software (or service) that supports more granular API permissions out of the box instead of having to build something yourself.
This was more of a general question about how people were using BIND with Let's Encrypt so I guess it's more of a BIND question than acme or Let's Encrypt. @Bruce5051 - Sorry for the lapse in using the form. Most of the questions didn't seem pertinent to the question at hand as we hadn't submitted any certificate requests yet nor were we using certbot.
Thanks for the feedback. I'll hit up a BIND forum/list to see if I can get some insight into what can be done.
So in the end, we ended up getting BIND setup to allow for updates to any TXT records in the zone for now. That may change later but at least we can get the automated certificate system deployed to our production environment.
@MikeMcQNumerous is a relative term in this case. I doubt we will hit rate limits with the number of systems we create, but thanks for the reminder!
