DNS challenge failing: NXDOMAIN looking up TXT


#1

Hi guys,
I’m having an issue while testing dns-01 challenges

Here’s the response I’m getting from Letsencrypt:

ERROR: Challenge is invalid! (returned: invalid) (result: {"type":"dns-01","status":"invalid","error":{"type":"urn:acme:error:connection","detail":"DNS problem: NXDOMAIN looking up TXT for _acme-challenge.test.quietthyme.com"},"uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/3L6SZlSkL7RWpMh1FFyQ6YRWuDn_H6XxNqicISapDkM/13839727","token":"GRjyvBUpztmnvStNc68LyMiJtdw1uIQs8PtXYzbZS7Y","keyAuthorization":"GRjyvBUpztmnvStNc68LyMiJtdw1uIQs8PtXYzbZS7Y.fE99lU76p5nJJpUFuJWHZnaXGP5u9SNVvo-vJLXLWcg"})

Dig has the following output:

$dig -t TXT _acme-challenge.test.quietthyme.com

; <<>> DiG 9.8.3-P1 <<>> -t TXT _acme-challenge.test.quietthyme.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43734
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_acme-challenge.test.quietthyme.com. IN	TXT

;; ANSWER SECTION:
_acme-challenge.test.quietthyme.com. 300 IN TXT	"7W159IzsfrPE7WUNrv6pQNMEpiB3RiwIHpTfKF5Vo1k"

;; Query time: 9 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Wed Feb  3 12:23:21 2016
;; MSG SIZE  rcvd: 109

Just as an FYI, I have cloudflare running infront of my site.


#2

How long did you leave it after checking the the primary name servers were providing the correct txt response, and asking LE to confirm it was valid ? is it possible you asked LE to confirm before they were responding properly ?


#3

I tried adding a 5 second wait, but it didn’t help.
I’ll try a 2 minute delay and see if that helps.


#4

It depends if that’s a 5 second wait after setting it at cloudflare … or a 5 second wait after testing and confirming that the cloudflare servers are providing the correct answer :wink:

In my experience it typically takes cloudflare servers about 10 seconds to provide the correct response after updating them via the API, but I have seen it take over a minute. Having said that, once I’ve confirmed that the cloudflare dns servers are giving the correct response, then I’ve usually asked LE to verify straight away, and never had a problem.


#5

Related: DNS problem: SERVFAIL looking up TXT


#6

It’s essential that the challenge record be visible at all of the nameservers for a zone before proceeding. I have an example of how to do this programmatically here, part of a larger example of using nsupdate.

Although come to think of it, even that may not be an adequate guarantee if we’re talking about anycasted DNS. Hmm…


#7

I put in a 30 second delay and everything started working :slight_smile: Thanks guys


#8

May I take over this topic since I have the same problem: Requesting a certificate with multiple names, a few challenges do work and then suddenly I get “NIXDOMAIN” back from the LE server.

I use nsupdate in a hook script to publish the challenge RR on my bind9 DNS Servers (1 master, two slaves), called by letsencript.sh. Instead of just waiting some time, my hook script checks all NS, wether the challenge has bee published. It prints out its result of the check, so I can see the challenge worked. If there is just one or two SubjAltNames requested to be included in the certificate, it works well. If there are more than that, it often fails. The error is:
DNS problem: NXDOMAIN looking up TXT for _acme-challenge…

The part of the shell script that does the name server checking is:

# ensure all NS got the challenge
ok=0
# get all authoritative name servers
for ns in $(dig +noall +authority ${HOST} | sed -e "s/^.*\t//g"); do
        timestamp=$(date "+%s")
        dig_result="failed."
        echo -n "    + Checking challenge on $ns.. "
        # try max. 15 seconds
        while [ $(($(date "+%s")-$timestamp)) -lt 15 ]; do
                msg="$(dig +short "${ACME_STRING}.${HOST}" TXT @${ns} 2>/dev/null)"
                if [ $? -eq 0 -a $(echo "$msg" | wc -l) -gt 0 ]; then
                        dig_result="ok."
                        let "ok+=1"
                        break;
                fi
                sleep 1.5
        done
        echo "$dig_result"
done
# if there was no answer or just errors from dig exit non-zero
[ $ok -eq 0 ] && exit 1

I believe that when I see

+ Checking challenge on dns.3eck.net... ok.

the acme-challenge TXT record should be published and thus the challenge should work.

Thank you for your help!


#9

Ideally I’d say that rather than just check if the NS returns some value, you need to confirm that it returns the correct token.


#10

…indeed that helps. My assumption was too naive.

Thank you. I will post my hook script somewhere, as soon as I am sure it works and give a hint here.


#11

Maybe somebody finds this useful:
https://ente.limmat.ch/ftp/pub/software/bash/letsencrypt/letsencrypt_acme_dns-01_challenge_hook

It is a first version of a dns hook script to use with bind and letsencrypt.sh to run in a GNU userland.

Because “new users are limited to three replies” (how stupid is that?), I answer the question of “whocares” here:

The script letsencrypt_acme_dns-01_challenge_hook uses dig to query all your nameservers with the published challenge. If you get the Error “None of the name server(s) answer the challenge correctly.” the challenge did not get published. Most probable reason is an error in the permission set up. The result of nsupdate is printed at the end of the line starting with “+ Updating DNS”. If you see “refused” you need to check your named.conf.local and verify the grant statement within the zone definition of the domain you are working on.


#12

hi, thank you for your work.

i have issues getting it running though.
the RR gets updated and deleted.

it fails at this step: ERROR: None of the name server(s) answer the challenge correctly. (the first domain gets accepted, the following domains are not validated)

  • Responding to challenge for foo.com
  • Challenge is valid!
  • Responding to challenge for www.foo.com
    ERROR: Challenge is invalid! (returned: invalid) (result: {
    “type”: “dns-01”,
    “status”: “invalid”,
    “error”: {
    “type”: “urn:acme:error:connection”,
    “detail”: “DNS problem: NXDOMAIN looking up TXT for _acme-challenge.www.foo.com”,

#13

Can you provide a little more information please ? What client are you using ? (it may also be worth asking for help on github or with whoever wrote your client). is there a debug option on that client to provide a little more information ? Have you checked with the DNS that the result is valid ?


#14

early morning response, awesome :smiley:
anyway i tried the letsencrypt.sh client with the dns-01 hook

i tried two different scripts.
one provided by phloggu in this thread: DNS challenge failing: NXDOMAIN looking up TXT

https://ente.limmat.ch/ftp/pub/software/bash/letsencrypt/letsencrypt_acme_dns-01_challenge_hook

the other is from here:

both with the same error. updates to my dns server work.


#15

I’d suggest opening an issue with Lukas on his github page, since he wrote the script.

Are your authoritative nameservers accessible from everywhere ? since the "“error” is that they are not returning the correct value due to a connection error.


#16

i am seeing the requests from letsencrypt servers for the RR in question.
66.133.109.36#13771 (_ACmE-ChALlenGe.foo.cOm): query: _ACmE-ChALlenGe.foo.cOm IN TXT…


#17

adding an entry “manually” with nsupdate works - also requesting that RR via google dns servers.
8.8.8.8

dig +short _acme-challenge.www.foo.com TXT
"blaaaaaaaaaaaaaaaaaaa"


#18

It does sound to me like an issue in the script you are using then - hence suggesting raising an issue with the author.

I just checked that the dns-01 challenge is working correctly by obtaining a certificate for a couple of my test domains.

One thought - does your DNS server respond correctly to requests for domains using a mix of lower and upper case letters ?


#19

dig +short wWw.FoO.com A
198.175.x.x

dns challend fails always on the second domain (a subdomain of the first one) this makes it so strange for me.


#20

I don’t use letsencrypt.sh I’m afraid - so can’t help a lot there. I wrote / use a different bash script.

I assume it is the order that matters ( i.e. if you change the order of the domains, it still fails on the second one ? )