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.