Open bryanpedini opened 2 years ago
hi, i think i have a related or similar problem. Im using hetzner DNS for DNS challenge with traefik with a CNAME Entry to a dyndns provider so i could run my services @home with changing ip adresses.
in the last 90 days something must have changed, i only get ssl certs vor my subdomains but not for the root domain. Also the logged error strips the subdomain from the referenced dyndns provider (mysub.ddns.net)
error presenting token: hetzner: could not get zone for domain ddns.net
After changing the traefik.mydomain.net CNAME mysub.ddns.net
to traefik.mydomain.net A <myPublicIP>
the letsencrypt certs get generated as expected.
hi, i think i have a related or similar problem. Im using hetzner DNS for DNS challenge with traefik with a CNAME Entry to a dyndns provider so i could run my services @home with changing ip adresses.
in the last 90 days something must have changed, i only get ssl certs vor my subdomains but not for the root domain. Also the logged error strips the subdomain from the referenced dyndns provider (mysub.ddns.net)
error presenting token: hetzner: could not get zone for domain ddns.net
After changing the
traefik.mydomain.net CNAME mysub.ddns.net
totraefik.mydomain.net A <myPublicIP>
the letsencrypt certs get generated as expected.
I also got a similar problem :).
The error message I get (for some reason I don't know) is:
2023/05/25 14:00:56 [WARN] [example.de] acme: cleaning up failed: hetzner: could not get zone for domain de not found
Yes, there is the TLD "de" without "example." in front of it.
After skimming through some of the source code, I found out, that the CNAME record is the only response returned, when lego actually wants to know the SOA record (I think this is normal DNS behaviour?).
I fixed it by using a public nameserver for the DNS challenge with --dns.resolvers 8.8.8.8
(the CNAME is only within my internal network).
@voruti to disable the CNAME support you have to set the env var LEGO_DISABLE_CNAME_SUPPORT
to true
.
I tried this env var before (and just retried now, too) and it doesn't work. As above: domain "de" not found.
when lego actually wants to know the SOA record (I think this is normal DNS behaviour?).
Yes, it's the expected behavior.
I think your problem is related to your local DNS and the SOA calls.
I'm using a pi.hole including the DHCP server. After its filtering is done, it's using Google DNS as well.
Any News to the original subject on this? We have the same problem.
fyi
If you're running into acme: error presenting token: hetzner: could not get zone for domain foo.bar not found
, while using Hetzner's DNS servers, this might also be because you have over 100 domains/zones. Hetzner's API does pagination and only shows 100 entries at most. lego fixed this issue in #1815, but the version in Debian (4.9.1) does not have the fix. Use a newer version from Github instead.
Welcome
How do you use lego?
Through Traefik
Detailed Description
Basically following up on https://github.com/traefik/traefik/issues/8910, I called up Hetzner the other day to ask about making a third level domain zone for my company, and they straight up told me that that wasn't possible and to just make a second level domain zone and put NS records pointing at Hetzner's servers only for the subdomain. So since Hetzner's DNS server are authoritative and not recursive, there would be no way that anybody would use them as primary resolver, hence not being able to use our main domain and not find the appropriate records.
Maybe that "rule" from Hetzner could be used to just call up Hetzner's APIs directly asking for the zone ID by just stripping everything past the second level domain, to avoid this error caused by internal DNS servers for
home.mydomain.com
?