DNS problem: NXDOMAIN looking up TXT for _acme-challenge.chargerback.net

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
chargerback.net
I ran this command:
M: Create certificate (full options)
It produced this output:
[.chargerback.net] Preliminary validation succeeded
[.chargerback.net] Authorization result: invalid
[*.chargerback.net] {
"type": "urn:ietf:params:acme:error:dns",
"detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.chargerback.net - check that a DNS record exists for this domain",
"status": 400
}
My web server is (include version):
IIS 10.0
The operating system my web server runs on is (include version):
Windows Server 2016
My hosting provider, if applicable, is:
Hosted locally
I can login to a root shell on my machine (yes or no, or I don't know):
Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
WinAcme Software version 2.1.22.1267 (release, pluggable, standalone, 64-bit)

This was just my latest attempt. Using an older version of wacs that calls my own external script for setting up the DNS records in GoDaddy. This has been working for many years. I tried going to the newest version of wacs, which has its own GoDaddy plugin, and I kept getting this error until I was rate limited. I thought it might be the GoDaddy plugin, it automatically cleans the TXT record it makes, which is why I tried my own and had it not delete the record. I verified that the record does exist, so that is not the problem. The problem is in LetsEncrypt's validation of the TXT record. Any suggestions?

2

GoDaddy has tightened the rules of whom may access their DNS API a little back ago.

See e.g. GoDaddy no longer allows API access to clients (e.g. for DNS-based cert renewal) if you have less than 50 domains.

Hm, although it seems I can see the TXT RR being there.. So maybe you're not limited by those API access changes..

Maybe wacs just needs to wait a little bit longer.

3 Likes
3

I agree with @Osiris this is likely related to that GoDaddy change

Although, right now I see that TXT record using https://unboundtest.com

Having some TXT record should have results in a "incorrect" error message rather than the NXDOMAIN "missing".

If you leave the existing record there and try wacs again which error do you get?

And, just as I was about to post this Osiris suggested a longer wait may be necessary. That's possible too.

3 Likes
4

That's why I tried my own GoDaddy script - to see if that was where the problem lies. It's not.

Are you suggesting that WinAcme is not waiting long enough before going to LetsEncrypt? Because my GoDaddy script updates the DNS, then it checks to see if the record has been updated before it returns control to wacs to send to LetsEncrypt. It retiries DNS lookups in 30 second intervals until it gets a positive response or 5 tries have been made, at which point it returns an error.

5

Your script might be testing GoDaddys nameserver X while Let's Encrypt validation servers (which are situated around the world) might be using nameserver Y. Note that different servers might have the same IP address (anycast).

It's worth a shot increasing it I think.

2 Likes
6

So does your script always leave a TXT record in place?

Do you still see NXDOMAIN errors then? Because that would be odd.

4 Likes
7

Thanks, my script is doing lookups from our DNS servers, which currently point to Cloudflare's DNS servers. So no, I'm not doing a lookup on GoDaddy DNS servers.

3 Likes
8

It is now - I made it leave it so I could confirm that it was actually being created. I have not yet tried your suggestion of rerunning it now that I have an existing record. I'll do that right now and post the results.

1 Like
9

You could use https://unboundtest.com to check the authoritive GoDaddy servers. Like while your script is running. Or, something like this:

nslookup -q=TXT _acme-challenge.chargerback.net ns67.domaincontrol.com

It wouldn't guarantee that all the GoDaddy were in sync but waiting a little longer after that success is a good bet.

4 Likes
10

Okay, since the record was already there this time, it gave me a different error.
Cached order has status invalid, discarding
[.chargerback.net] Authorizing...
[.chargerback.net] Authorizing using dns-01 validation (Script)
Script C:\WinAcme\Scripts\GoDaddyDNS.exe starting with parameters create chargerback.net _acme-challenge.chargerback.net 7VECPIO4lzUy8LJrRXaMRAQNXCOBTrhYg89DT13JxBc
Script finished
[.chargerback.net] Preliminary validation succeeded
[.chargerback.net] Authorization result: invalid
[*.chargerback.net] {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Incorrect TXT record "5PReMmjYLIcOQkPnoZd0QQqzrp5aY0XCwJLrfYmjVJM" found at _acme-challenge.chargerback.net",
"status": 403
}
No delete script configured, validation record remains

And, that is the old one. The curious part is, the TTL is 600 seconds. That's 10 minutes. But yesterday, when I was trying to troubleshoot this, at one point I went in and manually created a TXT record, with just some random text in it, and I was getting the same error as this one. That's what made me decide to try the old version with my GoDaddy script instead. Because it kept giving me this error even when I would try an hour after the first one.

I'll see if I can tweak some settings in WinAcme to wait longer, or more retries before giving up. Thanks to you and @Osiris for your help!

1 Like
11

The TTL won't affect the Let's Encrypt Server queries. It looks directly at the authoritive DNS servers. It could affect queries using your local resolver.

You can have multiple TXT record values. As long as one of them matches the validation suceeds. Given the error you showed it means the LE Server still did not see the new one. I see the new one now (starts with '7VEC...'). So, try waiting like 15 minutes after you add the new TXT record before returning to wacs. Then reduce on subsequent tests until you find the sweet spot. Usually it's not that long on good DNS systems (like a minute or two) but hard to say which is why I suggest 15min to start.

You should probably use the Let's Encrypt Staging system servers during this so you don't get temporarily rate limited by the production side for too many failed requests too soon (5 / hour)

4 Likes
12

Oh, I thought @Osiris said the exact opposite.

1 Like
13

No, we agree. TTL doesn't affect the LE Server queries. TTL only affects the life in a resolver cache (which LE doesn't have).

While LE will query the auth DNS server IP directly it may not be the same server as you see even if querying the same one. These servers are often widely disbursed around the world and so they must sync before being assured of giving the same response world-wide. LE auth servers exist and check from multiple locations so the DNS system sync is especially important. Anycast means you could query the same server IP from two different locations and be talking to different actual servers. Osiris mentioned this and is why I said you should wait even longer after getting a successful result when querying even the auth dns name.

Some DNS systems have an API to check whether their world-wide servers are in sync after a change. If you don't have that you just have to sleep and hope. Good DNS systems don't take very long anyway (less than a minute say) so it is often not a practical issue.

4 Likes
14

Got it! Thanks once again. I'm going to continue playing with timeout intervals. It's just odd that this has only recently started after working so well for so long.

3 Likes
15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.