DNS-01: DNS Propagation Check Timed out if the Domain is Delegated

[zzrcxb]

Welcome

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

What did you expect to see?

Check the delegated nameserver instead of the "main" nameserver during the DNS record propagation check step. (#1597 similar issue?)

Details: Assume I own example.com and wait to obtain a certificate for test.i.example.com. Due to security concerns around API access, I delegated i.example.com from provider A to Cloudflare by creating NS records for i.example.com. I tried to obtain a certificate for test.i.example.com via the dns-01 challenge using the command lego --dns cloudflare --domains "test.i.example.com" --email [email protected] --dns.resolvers 1.1.1.1:53 run. However, lego stuck at "acme: Waiting for DNS record propagation." and timed out 2 minutes later, reporting that it could not find the TXT record for _acme-challenge.test.i.example.com on the nameserver from provider A. The same error is observed when using NixOS's security.acme setting instead of lego cli.

Update 1: Tried the latest Docker image, same error.

Update 2: Tried --dns.propagation-disable-ans=true but consistently got the error of "invalid authorization: acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.test.i.example.com - check that a DNS record exists for this domain".

With this option on, I didn't see any pause to wait for DNS propagation. So I suspect the ACME server checked the record before the update is propagated. That's why my current workaround is --dns.propagation-wait 10s.

Debug effort: I tried dig @1.1.1.1 _acme-challenge.test.i.example.com TXT and it returned the correct result. I also tried certbot, which can successfully obtain the certificate.

Current workaround: Use the --dns.propagation-wait 10s flag to skip the propagation check and hope that 10s is enough for propagation.

What did you see instead?

Follow the NS records of i.example.com to retrieve DNS records from Cloudflare instead of provider A, and successfully obtain the certificate.

How do you use lego?

Docker/Binary

Reproduction steps

1. Create a zone for example.com on Cloudflare.
2. Delegate i.example.com to Cloudflare by adding corresponding NS records.
3. Create a Cloudflare API token for example.com with the DNS:Edit permission.
4. Set the Cloudflare API token and invoke lego with lego --dns cloudflare --domains "test.i.example.com" --email [email protected] --dns.resolvers 1.1.1.1:53 run.

Effective version of lego

lego version 4.22.2 linux/amd64

Logs

(Sensitive information is removed or redacted.)

00:15:49 [INFO] [test.i.example.com] acme: Obtaining bundled SAN certificate
00:15:49 [INFO] [test.i.example.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/<redacted>/<redacted>
00:15:49 [INFO] [test.i.example.com] acme: Could not find solver for: tls-alpn-01
00:15:49 [INFO] [test.i.example.com] acme: Could not find solver for: http-01
00:15:49 [INFO] [test.i.example.com] acme: use dns-01 solver
00:15:49 [INFO] [test.i.example.com] acme: Preparing to solve DNS-01
00:15:51 [INFO] cloudflare: new record for test.i.example.com, ID <redacted>
00:15:51 [INFO] [test.i.example.com] acme: Trying to solve DNS-01
00:15:51 [INFO] [test.i.example.com] acme: Checking DNS record propagation. [nameservers=1.1.1.1:53]
00:15:53 [INFO] Wait for propagation [timeout: 2m0s, interval: 2s]
00:15:53 [INFO] [test.i.example.com] acme: Waiting for DNS record propagation.
00:15:55 [INFO] [test.i.example.com] acme: Waiting for DNS record propagation.
// more "acme: Waiting for DNS record propagation."
00:17:51 [INFO] [test.i.example.com] acme: Waiting for DNS record propagation.
00:17:53 [INFO] [test.i.example.com] acme: Cleaning DNS-01 challenge
00:17:54 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz/<redacted>/<redacted>
00:17:54 Could not obtain certificates:
        error: one or more domains had a problem:
[test.i.example.com] propagation: time limit exceeded: last error: NS <domain name of a nameserver from provider A>:53 did not return the expected TXT record [fqdn: _acme-challenge.test.i.example.com., value: <redacted>]:

Go environment (if applicable)

N/A.

[ldez]

You should use --dns.propagation-disable-ans=true

[zzrcxb]

Another thing I don't quite understand is why --dns.resolvers 1.1.1.1:53 seemed to have no effect. Even with this option, lego still tried to check the nameserver from provider A instead of Cloudflare for DNS propagation.

[ldez]

I think you are behind a firewall, or you are using something that interacts with DNS calls.

--dns.propagation-disable-ans disables the check of the Authoritative Nameserver (the Cloudflare NS), theoretically, those NSs are always available.

If, when you use --dns.propagation-disable-ans, the propagation "doesn't wait", it's proof that something is interacting with DNS calls.

ACME is an RFC, not a server. The goal of the propagation check is to wait before asking the ACME server (Let's Encrypt) to ensure the record availability when the ACME server does the challenge.

[ldez]

Even with this option, lego still tried to check the nameserver from provider A instead of Cloudflare

By default, lego checks ANS (Authoritative Nameservers) and RNS (Recursive Nameservers).

--dns.resolvers defined the RNS.

If you are not using --dns.propagation-disable-ans lego will check the ANS (theoretically the Cloudflare NSs).
In this context, if you still show the NSs of provider A, it can be because the NS records are not propagated for now, or because you have a DNS cache, or because something interacts with DNS calls.

[zzrcxb]

Thank you for the clarification!

It puzzles me that certbot works but lego doesn't, even if it's the same DNS setup and test environment. As I'm not familiar with the details of either tool, I'll dig deeper another time.

[ldez]

It puzzles me that certbot works but lego doesn't,

It's because certbot doesn't check the propagation; it just uses a sleep.