Bunny Provider for the DNS challenge is non-functional

[kengodwin]

Welcome

• [X] Yes, I'm using a binary release within 2 latest releases.
• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, I've included all information below (version, config, etc).

What did you expect to see?

A working certificate message.

What did you see instead?

root@dev:~/docker-services# docker run -e BUNNY_API_KEY=[removed] goacme/lego --email [removed] --dns bunny --domains [removed] --server "https://acme-staging-v02.api.letsencrypt.org/directory" --accept-tos --dns-timeout=90  --dns.resolvers=1.1.1.1 run
2023/09/03 13:28:13 No key found for account [removed]. Generating a P256 key.
2023/09/03 13:28:13 Saved key to /.lego/accounts/acme-staging-v02.api.letsencrypt.org/[removed]/keys/[removed].key
2023/09/03 13:28:13 [INFO] acme: Registering account for [removed]
!!!! HEADS UP !!!!

Your account credentials have been saved in your Let's Encrypt
configuration directory at "/.lego/accounts".

You should make a secure backup of this folder now. This
configuration directory will also contain certificates and
private keys obtained from Let's Encrypt so making regular
backups of this folder is ideal.
2023/09/03 13:28:13 [INFO] [[removed]] acme: Obtaining bundled SAN certificate
2023/09/03 13:28:13 [INFO] [[removed]] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/8081289974
2023/09/03 13:28:13 [INFO] [[removed]] acme: Could not find solver for: tls-alpn-01
2023/09/03 13:28:13 [INFO] [[removed]] acme: Could not find solver for: http-01
2023/09/03 13:28:13 [INFO] [[removed]] acme: use dns-01 solver
2023/09/03 13:28:13 [INFO] [[removed]] acme: Preparing to solve DNS-01
2023/09/03 13:28:14 [INFO] [[removed]] acme: Cleaning DNS-01 challenge
2023/09/03 13:28:14 [WARN] [[removed]] acme: cleaning up failed: bunny: could not find DNSZone zone=_acme-challenge.[removed] 
2023/09/03 13:28:14 [INFO] Deactivating auth: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/8081289974
2023/09/03 13:28:14 Could not obtain certificates:
    error: one or more domains had a problem:
[[removed]] [[removed]] acme: error presenting token: bunny: could not find DNSZone zone=_acme-challenge.[removed]

How do you use lego?

Binary

Reproduction steps

See What did you see instead as it has reproduction steps.

Bunny.net provides a free trial of 14 days if you want to test yourself.

Version of lego

root@dev:~/docker-services# docker run goacme/lego --version
lego version 4.14.0 linux/amd64

Logs

Refer to what you see instead section

Go environment (if applicable)

```console $ go version && go env # paste output here ```

[kengodwin]

Continuation of https://github.com/go-acme/lego/issues/2008 as requested

[ldez]

Can you provide a bit more detail?

• Since when? is it related to an update of Traefik or lego?
• are you using a CNAME?

Bunny.net provides a free trial of 14 days if you want to test yourself.

It's a CDN trial, not a free domain trial :wink:

[ldez]

ping @TECHNOFAB11

[kengodwin]

Can you provide a bit more detail?

Basically, previous DNS provider (while the dns integration worked with lego) was not reliably providing DNS information so it would randomly break Lets Encrypt on wild card cert renewals so I changed providers to Bunny yesterday.

When I ran into the issue, I switched to exec and can confirm with exec (using a different languages API Client for Bunny API) it works fine.

With my monkey patch to bunny.go, it also works fine (linked in the previous issue).

Since when? is it related to an update of Traefik or lego?

Well I'm using the lego docker container, so I'm assuming this is just straight lego binary and the fact my monkey patch only required modification to bunny.go it seems to be a lego issue.

It's a CDN trial, not a free domain trial 😉

It provides free for all its services, including DNS, for 14 days. I'm not sure why you arguing with me on this. I have 0 CDN services and it works just fine.

[ldez]

Are you using a CNAME?

is it related to www.developersunchained.com ?

[kengodwin]

Are you using a CNAME?

No. Its just an A record subdomain with an ip address.

is it related to www.developersunchained.com ?

No.

[TECHNOFAB11]

I will check if it still works for me (eg. if something broke, maybe Bunny changed something etc.)

[ldez]

@kengodwin can you check that the SOA query works? the SOA query could return the start of the authority for your subdomain, i.e. the apex of the domain.

[kengodwin]

https://www.nslookup.io/domains/minfra.space/dns-records/soa/

@kengodwin can you check that the SOA query works? the SOA query could return the start of the authority for your subdomain, i.e. the apex of the domain.

[ldez]

can you provide the SOA of your subdomain not of the apex?

[ldez]

@TECHNOFAB11 for me it's not related to the Bunny API.

The problem seems related to the zone detection, so for me it's related to a DNS configuration, a local DNS, or a firewall.

[kengodwin]

can you provide the SOA of your subdomain not of the apex?

https://www.nslookup.io/domains/test.dev-ops.minfra.space/dns-records/soa/

[ldez]

your getDomain function is just a way to try to get the apex of a subdomain (the auth zone).

func getDomain(authZone string) (string, error) {
    u, err := url.Parse("https://"+authZone)
    if err != nil {
            return "", err
    }
    parts := strings.Split(u.Hostname(), ".")
    actualDomain := parts[len(parts)-2]+"."+parts[len(parts)-1]
    /*fmt.Println("u: ", u)
    fmt.Println("Hostname: ", u.Hostname())
    fmt.Println("Parts", parts)
    fmt.Println("actualDomain", actualDomain)
    fmt.Println("record name: ", domain, "?authzone=", actualDomain)*/

    return actualDomain, nil
}

That is why I am asking you for the SOA result of your subdomain.

Your previous message confirmed what I think: the SOA answer of the subdomain is not right, it should be minfra.space. and not test.dev-ops.minfra.space..

[ldez]

@TECHNOFAB11 can you try with a subdomain that you own?

[kengodwin]

Your previous message confirmed what I think: the SOA answer of the subdomain is not right, it should be minfra.space. and not kiki.bunny.net.

That may be the case but I don't have control over the SOA record with bunny.net as far as I'm aware.

[ldez]

That may be the case but I don't have control over the SOA record with bunny.net as far as I'm aware.

It can be related to the way that you have setup your subdomain.

[TECHNOFAB11]

@TECHNOFAB11 can you try with a subdomain that you own?

Yep I'm on it, just have to get everything setup again :D (a nix flake would be awesome btw)

[ldez]

you just need a drill or a dig: drill <your_subomain> SOA

[TECHNOFAB11]

Shit, I get the same error. @ldez dig'ing gives me the wrong SOA aswell

test.tecf.de.           900     IN      SOA     kiki.bunny.net. hostmaster.bunny.net. 2020032201 7200 900 1209600 86400

[ldez]

ok, so I have a fix if you can confirm that the apex is always the effective zone.

[TECHNOFAB11]

ok, so I have a fix if you can confirm that the apex is always the effective zone.

I'm not sure what you mean by that, sorry. If I understand correctly the authZone in findZone is wrong? Like, it should not contain any subdomains?

[ldez]

The goal of find zone is to find the zone ("the domain") where the DNS record will be created with the API.

the question is about the zone used by the API, if the zone is always the apex (ex: example.com for foo.example.com or foo.bar.example.com)

[TECHNOFAB11]

The goal of find zone is to find the zone ("the domain") where the DNS record will be created with the API.

the question is about the zone used by the API, if the zone is always the apex (ex: example.com for foo.example.com or foo.bar.example.com)

Ahh gotcha, yeah I think its always the apex. Tried printing the zones before and it printed the apex for every domain I have added to Bunny