Added and tested configuration for Zonomi DNS provider.
Resolve CNAMEs
I have also added the LEGO_EXPERIMENTAL_CNAME_SUPPORT variable (from LEGO documentation) along with a brief description.
This allows resolving _acme-challenge.<YOUR_FQDN> in case it has a CNAME pointing to a different domain. With this, one can set a FQDN and then set up authentication for the DNS provider of the domain it points to*.
The default setting is 'false' as this won't interfere with the way the current configurations are and maintains the current behavior. Those who need it can enable it as they would be on the lookout for such an option.
This is an obscure setting and admittedly still 'experimental' according to LEGO, however I tested it and it worked out like a charm for my setup, so I wanted to increase visibility for anyone else in my situation.
If this is not wanted, please let me know and I'll remove it to simply add Zonomi ☺
*_An example setup would be requesting a cert for DOMAIN_A.com while setting a CNAME record with DNS_PROVIDER_A of _acme.challenge.DOMAIN_A.com pointing to _acme.challenge.DOMAIN_B.com , then in your config you can provide the API/password for DNS_PROVIDER_B who is in charge of DOMAIN_B.com_
The config values for the above example would look something like this:
_CERT_HOSTS='DOMAIN_A.com'_
_LEGO_EXPERIMENTAL_CNAME_SUPPORT=true_
_DNS_PROVIDER=DNS_PROVIDER_B_
_DNS_PROVIDER_TOKEN=DNS_PROVIDER_B_API_KEY_
_The benefit of this setup is that in case of an API key compromise only DOMAIN_B.com is exposed while not interfering with the DNS of your main domain (in this case DOMAIN_A.com). The damage would be limited in that an attacker would only be able to create TXT influencing _acme.challenge.DOMAIN_A.com (as well as full DNS control of DOMAIN_B.com, of course) but could quickly be mitigated by pointing DOMAIN_A.com away from DOMAIN_B.com with DNS_PROVIDER_A_
Zonomi
Added and tested configuration for Zonomi DNS provider.
Resolve CNAMEs
I have also added the
LEGO_EXPERIMENTAL_CNAME_SUPPORT
variable (from LEGO documentation) along with a brief description.This allows resolving
_acme-challenge.<YOUR_FQDN>
in case it has a CNAME pointing to a different domain. With this, one can set a FQDN and then set up authentication for the DNS provider of the domain it points to*.The default setting is 'false' as this won't interfere with the way the current configurations are and maintains the current behavior. Those who need it can enable it as they would be on the lookout for such an option.
This is an obscure setting and admittedly still 'experimental' according to LEGO, however I tested it and it worked out like a charm for my setup, so I wanted to increase visibility for anyone else in my situation.
If this is not wanted, please let me know and I'll remove it to simply add Zonomi ☺
*_An example setup would be requesting a cert for
DOMAIN_A.com
while setting a CNAME record withDNS_PROVIDER_A
of_acme.challenge.DOMAIN_A.com
pointing to_acme.challenge.DOMAIN_B.com
, then in your config you can provide the API/password forDNS_PROVIDER_B
who is in charge ofDOMAIN_B.com
_The config values for the above example would look something like this:
CERT_HOSTS='DOMAIN_A.com'
_LEGO_EXPERIMENTAL_CNAME_SUPPORT=true
_DNS_PROVIDER=DNS_PROVIDER_B
_DNS_PROVIDER_TOKEN=DNS_PROVIDER_B_API_KEY
__The benefit of this setup is that in case of an API key compromise only
DOMAIN_B.com
is exposed while not interfering with the DNS of your main domain (in this caseDOMAIN_A.com
). The damage would be limited in that an attacker would only be able to create TXT influencing_acme.challenge.DOMAIN_A.com
(as well as full DNS control ofDOMAIN_B.com
, of course) but could quickly be mitigated by pointingDOMAIN_A.com
away fromDOMAIN_B.com
withDNS_PROVIDER_A
_