Closed ldez closed 10 months ago
Quick feedback, tried this but it errors out with
[test.tecf.de] [test.tecf.de] acme: error presenting token: bunny: could not find DNSZone zone=_acme-challenge.test
Quick feedback, tried this but it errors out with
yes, my fault, I updated the code.
It seems to work, the TXT records are set and it's waiting for dns propagation
the fix should be good now.
The propagation timed out but I think thats because I'm currently having some funky DNS stuff going on :D Should be fine. @kengodwin can you try this aswell? :)
I didn't see your answer :smile:
So I waiting for your approval.
Github refresh is random: my answer was about this message but when I posted my message you already posted another message :smile:
@kengodwin is it OK for you?
We always find solutions, you will not need to use the exec provider :smile:
@kengodwin is it OK for you?
We always find solutions, you will not need to use the exec provider 😄
I'm still waiting on DNS propagation.
Hmm, the propagation detection seems to be broken aswell. dig
shows the TXT records for me but lego does not seem to detect them
Yeah I'm experiencing the same. The txt record is in Bunny.net and dig but not being detected by lego.
can you check manually with TXT query?
can you check manually with TXT query?
dig _acme-challenge.test.tecf.de TXT
shows the entries fine if thats what you mean. Feel free to try yourself on that domain if you mean something different, it's just for testing anyways :)
can you check manually with TXT query?
µ dig _acme-challenge.test.dev-ops.minfra.space @1.1.1.1 TXT [0] : 0.062s
; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> _acme-challenge.test.dev-ops.minfra.space @1.1.1.1 TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27926
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_acme-challenge.test.dev-ops.minfra.space. IN TXT
;; ANSWER SECTION:
_acme-challenge.test.dev-ops.minfra.space. 20 IN TXT "ygXATbU3UKOifVkPG7OWVFLAVS5c-M1PTaJIW0HigFo"
;; Query time: 15 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sun Sep 03 10:51:56 EDT 2023
;; MSG SIZE rcvd: 126
can you provide the error message?
can you provide the error message?
[test.dev-ops.minfra.space] propagation: time limit exceeded: last error: could not determine authoritative nameservers
I can bypass this like I do for my traefik setup if that is the solution I believe.
@TECHNOFAB11 have you the same error?
@TECHNOFAB11 have you the same error?
just reran it, yes its the same error
It's because the DNS server has an unexpected behavior: it's authoritative but doesn't have NS...
Cleary it's a Bunny DNS problem.
$ drill test.dev-ops.minfra.space NS
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 9552
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; test.dev-ops.minfra.space. IN NS
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 39 msec
;; SERVER: 192.168.1.1
;; WHEN: Sun Sep 3 16:57:21 2023
;; MSG SIZE rcvd: 43
$ drill test.tecf.de NS
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 21436
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; _acme-challenge.test.tecf.de. IN NS
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 14 msec
;; SERVER: 2a02:842b:5a8:b601::1
;; WHEN: Sun Sep 3 16:57:54 2023
;; MSG SIZE rcvd: 46
Yeah there is a reason I only use BunnyDNS and other "low end" providers for personal stuff with no commercial viability lol
Are we just bypassing the search for the authoritative NS and calling it a day with the command line flag?
Weird that it randomly changed though, worked fine for a long time
Weird that it randomly changed though, worked fine for a long time
I feel the same way about the people I switched off of before using Bunny for DNS. Unfortunately, this get broken from time to time.
Are we just bypassing the search for the authoritative NS and calling it a day with the command line flag?
I'm not sure what you mean, but you can disable the propagation check, this can lead to an error related to slow propagation (the TXT records will not be present when LE checks the record).
Are we just bypassing the search for the authoritative NS and calling it a day with the command line flag?
I'm not sure what you mean, but you can disable the propagation check, this can lead to an error related to slow propagation (the TXT records will not be present when LE checks the record).
Yeah that is how I've been dealing with it since I switched to Bunny yesterday.
So we will say it's OK because I'm not able to fix a problem related to Bunny DNS itself :smile_cat:
So we will say it's OK because I'm not able to fix a problem related to Bunny DNS itself 😸
Seems fair. Do you want me to raise an issue with Bunny support and see what they say?
yes, it can be a good idea. Keep us informed about their answer.
Thank you @TECHNOFAB11 for the tests and be present to maintain this provider :heart:
yes, it can be a good idea. Keep us informed about their answer.
Will do.
Bunny support says they will fix something I noted that is possibly a fix for this but with no ETA.
Soo... do we want to wait for the response of Bunny, or merge this PR, or both?
I don't know I have the same questions.
Maybe I can create a conditional behavior: if the domain is equal to the zone then split the zone. EDIT: it will not work
any news from Bunny?
If not we will merge the PR.
No news other than the promise they'll fix it at some point. Feel free to merge.
so @dmke will merge the PR, you can review it.
Bunny support says they will fix something I noted that is possibly a fix for this but with no ETA.
I can assure you 100% they will not fix it. I opened the same issue on February 10th 2023. They kept promising a fix. I kept pinging them until they finally closed the issue without a fix.
fixes #2011