caddy-dns / hetzner

Caddy module: dns.providers.hetzner
MIT License
32 stars 9 forks source link

Does not work with sub-subdomains #2

Closed ngdio closed 4 years ago

ngdio commented 4 years ago

I'm trying to use Let's Encrypt certificates in my internal network, so I'm using DNS challenges to obtain them. However, when using sub-subdomains (e.g. abc.def.example.com), this module does not find the correct zone.

I'm using Caddy with the builder image in a Docker environment. Using sub-subdomains on a Cloudflare-managed domain worked in the same environment.

Caddyfile (redacted):

abc.def.example.com {
    reverse_proxy http://localhost:1234

    tls {
        dns hetzner <CHALLENGE>
    }
}

Log output (domains changed accordingly):

{"level":"info","ts":1602725241.0834517,"logger":"tls.obtain","msg":"acquiring lock","identifier":"abc.def.example.com"}
{"level":"info","ts":1602725241.0839012,"logger":"tls.obtain","msg":"lock acquired","identifier":"abc.def.example.com"}
{"level":"info","ts":1602725241.084835,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["abc.def.example.com"]}
{"level":"info","ts":1602725241.0849154,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["abc.def.example.com"]}
{"level":"info","ts":1602725242.789842,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"abc.def.example.com","challenge_type":"dns-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
{"level":"error","ts":1602725243.1575782,"logger":"tls.issuance.acme.acme_client","msg":"cleaning up solver","identifier":"abc.def.example.com","challenge_type":"dns-01","error":"no memory of presenting a DNS record for abc.def.example.com (probably OK if presenting failed)"}
{"level":"error","ts":1602725243.372287,"logger":"tls.obtain","msg":"will retry","error":"[abc.def.example.com] Obtain: [abc.def.example.com] solving challenges: presenting for challenge: adding temporary record for zone def.example.com.: Not Found (404) (order=https://acme-v02.api.letsencrypt.org/acme/order/99341992/5693576092) (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":2.288363091,"max_duration":2592000}

Zone "def.example.com" does not exist, only "example.com" does. I'm assuming this is the problem, but I'm not sure how to fix it. The Cloudflare API does not behave differently, but Caddy seems to feed it the right part of the domain.

matthiasng commented 4 years ago

I did some tests and i can not reproduce your issue. For me, it works with example.com or abc.test.example.com

Are you using split DNS ? If so caddy-dns/cloudflare#12 and caddy-dns/cloudflare#13 could help you.

ngdio commented 4 years ago

I'm using split dns, but explicitly specifying outside DNS servers does not change anything. It's only used for determining the zone name anyway. Like I said, with Cloudflare, I haven't had these issues at all, no matter if I was using custom resolvers or not. I would have filed this report in the main Caddy repo otherwise.

matthiasng commented 4 years ago

I missed something important in your logs yesterday.

Docs says:

Note: In the DNS Console, it is not possible to create DNS zones for subdomains! Here subdomains can only be defined as described in the section Sub domain.

but we can see that certmagic uses def.examle.com as zone.

[abc.def.example.com] Obtain: [abc.def.example.com] solving challenges: presenting for challenge: adding temporary record for zone def.example.com.: Not Found (404)

This line resolves the zone by traversing up your domain and looking for a SOA record.

You say that cloudflare works fine. That means for me at the moment, the only plausible cause of your problem is that there is an SOA record on def.example.com. According to the docs, this is only possible if you have delegated the subdomain to another DNS server.

Could you please check this with dig

dig abc.def.example.com SOA
dig def.example.com SOA
dig example.com SOA -> only this one sould return a SOA record
ngdio commented 4 years ago

Okay, as it turns out it was indeed related to DNS resolving. Had to change it for the entire Docker container though. I just didn't realise because it caused another problem and I can't still get a certificate: Caddy sets a record for "_acme-challenge.abc.def.example.com" instead of "_acme-challenge.abc.def". If the SLD is in the record name, the TXT record does not resolve correctly. Seems like this is caused by the custom resolver. Not sure how to fix this.

I'll close this here since I don't think this is caused by this problem at all, sorry for that :x Still appreciate any help though!