DNS challenge failing: NXDOMAIN looking up TXT

domain list looks like this:

foo.com www.foo.com othersub.foo.com

removing www.foo.com makes it fail on the then 2nd domain (fails on othersub.foo.com like you suggested)

i dont see the www.foo.com updated so i guess the script is troublesome.

It does seem that way - hence suggesting raise an issue with the script author.

I’m going to be out for the next few hours - but will then be back and can help if you want to try getssl - although hopefully lucas will be pretty quick helping you out with his script.

looks nice, will try it out.

well it has its issues :slight_smile: and i am uncapable of figuring out how to implement lukas hook for dns into that.


./getssl -d foo.com
checking for required openssl … /usr/bin/openssl
checking for required curl … /usr/bin/curl
checking for required nslookup … /usr/bin/nslookup
checking for required sed … /bin/sed
checking for required grep … /bin/grep
checking for required awk … /usr/bin/awk
checking for required tr … /usr/bin/tr
current code is version 1.01
Most recent version is 1.01
Making temp directory - /root/.getssl/foo.com/tmp
reading config from /root/.getssl/foo.com/getssl.cfg
getting certificate for foo.com from remote server
local certificate doesn’t exist, saving a copy from remote
certificate /root/.getssl/foo.com/foo.com.crt exists
enddate is Jun 6 17:52:00 2016 GMT
certificate for foo.com needs renewal
archiving old certificate file to /root/.getssl/foo.com/foo.com.crt_2016-03-08_2016-06-06
creating account key
./getssl: line 794: : No such file or directory
domain key exists at /root/.getssl/foo.com/foo.com.key - skipping generation
created SAN list = subjectAltName=DNS:foo.com,DNS:www.foo.com,DNS: stats.foo.com
domain csr exists at - /root/.getssl/foo.com/foo.com.csr
Error opening Private Key
139691615983264:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen(’’,‘r’)
139691615983264:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load Private Key
Error opening Private Key
140641438586528:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen(’’,‘r’)
140641438586528:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load Private Key
Registering account
url https://acme-staging.api.letsencrypt.org/acme/new-reg
payload {“resource”: “new-reg”, “contact”: [“mailto: admin@foo.com”], “agreement”: “https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf”}
payload64 eyJyZXNvdXJjZSI6ICJuZXctcmVnIiwgImNvbnRhY3QiOiBbIm1haWx0bzogYWRtaW5Ac21kdGsuY29tIl0sICJhZ3JlZW1lbnQiOiAiaHR0cHM6Ly9sZXRzZW5jcnlwdC5vcmcvZG9jdW1lbnRzL0xFLVNBLXYxLjAuMS1KdWx5LTI3LTIwMTUucGRmIn0
nonce sMzJbIZqw9Ejh9MJqi3vjdIIabx5N-SaebQ3OtSSGJQ
protected {“alg”: “RS256”, “jwk”: {“e”: “”, “kty”: “RSA”, “n”: “”}, “nonce”: “sMzJbIZqw9Ejh9MJqi3vjdIIabx5N-SaebQ3OtSSGJQ”}
Error opening key file
140305006560928:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen(’’,‘r’)
140305006560928:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load key file
data for account registration = {“header”: {“alg”: “RS256”, “jwk”: {“e”: “”, “kty”: “RSA”, “n”: “”}}, “protected”: “eyJhbGciOiAiUlMyNTYiLCAiandrIjogeyJlIjogIiIsICJrdHkiOiAiUlNBIiwgIm4iOiAiIn0sICJub25jZSI6ICJzTXpKYklacXc5RWpoOU1KcWkzdmpkSUlhYng1Ti1TYWViUTNPdFNTR0pRIn0”, “payload”: “eyJyZXNvdXJjZSI6ICJuZXctcmVnIiwgImNvbnRhY3QiOiBbIm1haWx0bzogYWRtaW5Ac21kdGsuY29tIl0sICJhZ3JlZW1lbnQiOiAiaHR0cHM6Ly9sZXRzZW5jcnlwdC5vcmcvZG9jdW1lbnRzL0xFLVNBLXYxLjAuMS1KdWx5LTI3LTIwMTUucGRmIn0”, “signature”: “”}
responseHeaders HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: application/problem+json
Content-Length: 98
Replay-Nonce: LlB2o-L4e5ApTmUfsvRtChNgy73f-Ia6h_pLFtohq5s
Expires: Sat, 11 Jun 2016 08:10:28 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Sat, 11 Jun 2016 08:10:28 GMT
Connection: close
response {
“type”: “urn:acme:error:malformed”,
“detail”: “Invalid JWK in JWS header”,
“status”: 400
}
code 400
getssl: Error registering account
/root/letsencrypt.sh/dns-01-nsupdate-script: line 24: 4: unbound variable



cat /root/letsencrypt.sh/dns-01-nsupdate-script
#!/usr/bin/env bash

Example how to deploy a DNS challenge using nsupdate

set -e
set -u
set -o pipefail
umask 077

updatefile="$(mktemp)"

NSUPDATE="nsupdate -k /root/letsencrypt.sh/K_acme-challenge.foo.com.+157+12323.private"
done=“no”

if [[ “$1” = “deploy_challenge” ]]; then
printf “update add _acme-challenge.%s. 300 in TXT “%s”\n\n” “${2}” “${4}” > “${updatefile}”
$NSUPDATE "${updatefile}"
done="yes"
fi

if [[ "$1" = "clean_challenge" ]]; then
    printf "update delete _acme-challenge.%s. 300 in TXT \"%s\"\n\n" "${2}" "${4}" > "${updatefile}"
$NSUPDATE "${updatefile}"
            done="yes"
            fi

            if [[ "${1}" = "deploy_cert" ]]; then
                # do nothing for now
            done="yes"
            fi

            rm -f "${updatefile}"

            if [[ ! "${done}" = "yes" ]]; then
        echo Unkown hook "${1}"
    exit 1

fi

exit 0


Back now - I’ll message you and sort out the issues

1 Like

I also had this problem, and solved it by upgrading to BIND 9.10.

The problem was that in BIND ≤ 9.9, the way to implement split DNS was to define an internal view and an external view in named.conf, each incorporating some zones:

view "internal" {
    match-clients { … };
    zone "private.example.org" { … };
};
view "external" {
    match-clients { … };
    zone "private.example.org" { … };
    zone "example.org" { … };
};

The problem is, BIND does not necessarily serve consistent responses for example.org through both views. Even though I make a query (through the internal view) to verify that the correct TXT record is in place before proceeding with the ACME challenge, the wrong response could still be served through the external view.

One workaround is to use, say, Google’s 8.8.8.8 DNS server when looking for the TXT record, so that the verification is done on the external view.

A better solution is to upgrade to BIND 9.10, which supports the in-view directive, so that both views refer to the same zone definition.

view "internal" {
    match-clients { … };
    zone "private.example.org" { … };
};
view "external" {
    match-clients { … };
    zone "private.example.org" { in-view "internal" };
    zone "example.org" { … };
};