DNS-01 challenge timing out with REFUSED responses

[akerl]

I'm seeing a strange mismatch now that I've updated to 5.0.1. I updated my run/renew commands to unify them, and for good measure I deleted all prior state to start fresh. When I request a certificate, it spins waiting for DNS propagation but then times out with the following:

2026-05-13T00:46:31.098493464Z ERROR Error error="obtain certificate: resolver: one or more domains had a problem: [metrics.servers.home.a-rwx.org: dns01: time limit exceeded: last error: recursive nameservers: NS 127.0.0.53:53 returned REFUSED for _acme-challenge.metrics.servers.home.a-rwx.org.]"

The strange thing is that throughout this command, running the following from the same host works:

[root@metrics ~]# dig _acme-challenge.metrics.servers.home.a-rwx.org. TXT @127.0.0.53

; <<>> DiG 9.20.22 <<>> _acme-challenge.metrics.servers.home.a-rwx.org. TXT @127.0.0.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39483
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_acme-challenge.metrics.servers.home.a-rwx.org.	IN TXT

;; ANSWER SECTION:
_acme-challenge.metrics.servers.home.a-rwx.org.	10 IN TXT "yzvDUmMZ-CmXDtgr3qvpGNuCsiRaBGGNAtuM9bGMS9g"

;; Query time: 18 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed May 13 00:51:38 UTC 2026
;; MSG SIZE  rcvd: 131

If I set LEGO_DNS_RESOLVERS=8.8.8.8 it works... but the above doesn't seem to make sense to me. Is lego doing something about its DNS query that would explain why it's seeing a REFUSED response despite me seeing a successful response entirely in parallel?

[ldez]

Sorry it's late for me: I deleted my comment, because I misread the log.

[akerl]

Hah, all good. I was midway through trying to walk down the NS call chain figuring out what it would be trying.

[ldez]

lego is only doing simple TXT call for the recursive NSs, there is nothing special.

There is only a fallback on TCP if the response is truncated.

The REFUSED is coming from what is answering (127.0.0.53:53), this is difficult to known why without more information.

Based on your dig, UDP seems allowed by your system.
I think, but I'm not sure, that the TXT response is not truncated in your context, but it may worth checking if TCP is allowed by your local DNS server.

[akerl]

Easy enough; even just setting LEGO_DNS_RESOLVERS=8.8.8.8 fixes the issue. So it's something unique to how the local resolver handles this, that didn't happen with how lego interacted with it in v4

[ldez]

My goal here is to produce the error with 8.8.8.8, this is why I asked to use LEGO_EXPERIMENTAL_DNS_TCP_ONLY=true

[akerl]

Ah, I misunderstood. Lemme give it a shot

[akerl]

Welp... it works with both those flags.

[ldez]

Cool, but sad, the TCP thing was the easier explanation.

[akerl]

Checking. FWIW, validated by setting LEGO_DNS_PROPAGATION_DISABLE_RNS=true, which makes it all work as expected.

[akerl]

That seems like it would be a problem, right? If you ask a local resolver for a record and you don't set RD, isn't it basically always expected to return REFUSED? Since you've told it you don't want it to recurse

[akerl]

100%; I've got days left til it really matters when certs start expiring, and I'm already pushing a change to update my stuff to the v5 syntax so I'll ust include the flag to disable recursive checks for now.

I really appreciate how fast you jumped in to help debug this <3

[ldez]

In fact, it is an easy fix, sometimes I'm glad to read the code my former self wrote and tell myself that the design was correct 😄

[ldez]

I created a PR to fix the problem #3080

I will merge it tomorrow because now it's too late be confident on the code I'm writing 😄