DNS problem SERVFAIL - Unbound THROWAWAY result - Not able to create certificate

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. crt.sh | 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:synk.xyz

I ran this command: letsencrypt certonly --standalone -d rajan.synk.xyz
(running in docker, nginx running on host)

It produced this output:

Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for rajan.synk.xyz
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. rajan.synk.xyz (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://rajan.synk.xyz/.well-known/acme-challenge/RTn3jAUMfiuaPWeHUUwzZT8c9GPCdi2qKkqxGyIeOpU [13.64.69.28]: "\r\n404 Not Found\r\n<body bgcolor="white">\r\n

404 Not Found

\r\n
"

IMPORTANT NOTES:

My web server is (include version): nginx

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

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):certbot 0.28.0

Hi @rajan.shah

if you use --standalone and if you have that error

That looks like a problem of your docker setup. Standalone should always work, it starts an own webserver. And Letsencrypt can connect your domain, so it's not a DNS or a firewall problem.

So your docker setup doesn't work with that new startet webserver.

I am not getting any problem in docker but when I run

 #sudo certbot certonly --standalone -d rajan.synk.xyz
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for rajan.synk.xyz
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. rajan.synk.xyz (http-01): urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up CAA for rajan.synk.xyz

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: rajan.synk.xyz
   Type:   None

I get below error:
Failed authorization procedure. rajan.synk.xyz (http-01): urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up CAA for rajan.synk.xyz

That's

a completely different error.

Checked your domain via https://check-your-website.server-daten.de/?q=rajan.synk.xyz there is no explicit error visible. But your name servers have problems with the EDNS-checks.

Nameserver doesn't pass all EDNS-Checks: ns1-08.azure-dns.com: OP100: SOA expected, but NOT found, NOERR expectend and NOERR found, Version 0 expectend and found, no OPT100 expected, no OPT100 found. FLAGS: SOA expected, but NOT found, NOERR expectend and NOERR found, Version 0 expectend and found. V1: ok. V1OP100: ok. V1FLAGS: ok. DNSSEC: SOA expected, but NOT found, NOERR expectend and NOERR found, Version 0 expectend and found. V1DNSSEC: ok. NSID: SOA expected, but NOT found, NOERR expectend and NOERR found, Version 0 expectend and found. COOKIE: SOA expected, but NOT found, NOERR expectend and NOERR found, Version 0 expectend and found. CLIENTSUBNET: ok.

Checking your domain via unboundtest

https://unboundtest.com/m/CAA/rajan.synk.xyz/TM4ZZBX4

there is a SERVFAIL:

Response:
;; opcode: QUERY, status: SERVFAIL, id: 37210
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

With a lot of

query response was THROWAWAY

answers.

Unboundtest uses the same configuration as the Letsencrypt - unbound instance.

There was the DNS flag day - Redirectingā€¦

Perhaps wrong configured nameservers with EDNS problems -> now THROWAWAY results.

But I don't know if Unboundtest has changed (after the DNS flag day), so such EDNS errors now SERVFAIL errors.

PS: Checked via DNSSEC Analyzer - rajan.synk.xyz there are SERVFAILS:

ajan.synk.xyz
ns3-08.azure-dns.org returns SERVFAIL for rajan.synk.xyz/DS
ns2-08.azure-dns.net returns SERVFAIL for rajan.synk.xyz/DS
ns1-08.azure-dns.com returns SERVFAIL for rajan.synk.xyz/DS
ns4-08.azure-dns.info returns SERVFAIL for rajan.synk.xyz/DS
No DS records found for rajan.synk.xyz in the synk.xyz zone
Failed to get DNSKEY RR set for zone rajan.synk.xyz
No response from rajan.synk.xyz nameservers

Checked manual (with nslookup), no problem.

1 Like

Oh, what's that:

https://dnssec-analyzer.verisignlabs.com/ has an option to show more infos:

rajan.synk.xyz 	
  	Checking DS between synk.xyz and rajan.synk.xyz
  	Query to ns3-08.azure-dns.org for rajan.synk.xyz/DS
  	Error querying ns3-08.azure-dns.org/2a01:111:4000:0:0:0:0:8 for rajan.synk.xyz/DS: 'IPv6 transport disabled'
	ns3-08.azure-dns.org returns SERVFAIL for rajan.synk.xyz/DS
  	Query to ns2-08.azure-dns.net for rajan.synk.xyz/DS
	ns2-08.azure-dns.net returns SERVFAIL for rajan.synk.xyz/DS
  	Query to ns1-08.azure-dns.com for rajan.synk.xyz/DS
  	Error querying ns1-08.azure-dns.com/2603:1061:0:0:0:0:0:8 for rajan.synk.xyz/DS: 'IPv6 transport disabled'
	ns1-08.azure-dns.com returns SERVFAIL for rajan.synk.xyz/DS
  	Query to ns4-08.azure-dns.info for rajan.synk.xyz/DS
  	Error querying ns4-08.azure-dns.info/2620:1ec:bda:0:0:0:0:8 for rajan.synk.xyz/DS: 'IPv6 transport disabled'
	ns4-08.azure-dns.info returns SERVFAIL for rajan.synk.xyz/DS
	No DS records found for rajan.synk.xyz in the synk.xyz zone
	Failed to get DNSKEY RR set for zone rajan.synk.xyz
	No response from rajan.synk.xyz nameservers

Error querying ns3-08.azure-dns.org/2a01:111:4000:0:0:0:0:8 for rajan.synk.xyz/DS: 'IPv6 transport disabled'

Looks like the name servers have ipv6, but don't answer.

PS: I've updated your topic title. Looks like a new problem. Searching this forum "unbound THROWAWAY" there is only one older topic.

1 Like

For that error, the problem is that DNSSEC Analyzer doesn't support IPv6.

Compare:

http://dnsviz.net/d/dns-ipv6.mattnordhoff.net/dnssec/

(For unrelated reasons, dns-ipv6.mattnordhoff.net doesn't work reliably, but it works well enough for this demonstration.)

2 Likes

Thanks, good to know.

I can connect the name server via ipv6. But never seen such a list of Unboundtest errors with

query response was THROWAWAY

2 Likes

Unbound can do that for multiple reasons, if the response from the nameserver is badly invalid. For example, thatā€™s what it will log if the authoritative nameserver returns REFUSED.

In this case, Azure DNS seems to be responding to most queries for rajan.sync.xyz with a referral to itself ā€“ definitely not gonna work.

$ dig +norecurse rajan.synk.xyz @ns3-08.azure-dns.org

; <<>> DiG 9.15.1-Ubuntu <<>> +norecurse rajan.synk.xyz @ns3-08.azure-dns.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15805
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;rajan.synk.xyz.                        IN      A

;; AUTHORITY SECTION:
rajan.synk.xyz.         3600    IN      NS      ns1-08.azure-dns.com.
rajan.synk.xyz.         3600    IN      NS      ns2-08.azure-dns.net.
rajan.synk.xyz.         3600    IN      NS      ns3-08.azure-dns.org.
rajan.synk.xyz.         3600    IN      NS      ns4-08.azure-dns.info.

;; Query time: 26 msec
;; SERVER: 2a01:111:4000::8#53(2a01:111:4000::8)
;; WHEN: Wed Jul 24 14:36:13 UTC 2019
;; MSG SIZE  rcvd: 180
1 Like

if I run from my azure linux which is bind with synk.xyz than it get success

letsencrypt certonly --standalone -d rgs.synk.xyz

but when I run in docker than it give connection refusd

docker port
-p 127.0.0.1:81:81
-p 443:4443
-p 53:53
-p 53:53/udp \

can I run letsencrypt on another port?

No, you canā€™t. The use of port 80 is required by the ACME standard.

1 Like

However, Certbot can listen on any port, using the --http-01-port option. That can be useful when using reverse proxying or port forwarding.

1 Like

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