Is Let's Encrypt DNS not liking my domain name server?



I’m using the autocert ( client in an app I’m writing.

When running the app and trying to get a cert for my dev domain (, no problem to get a cert (through the TLS-SNI challenge by default I think).

However, when trying to get a cert for the production domain (, more precisely for the host, I get this error:

“acme: identifier authorization failed”.

Now, by adding some prints here and there in the client, it seems to me that the client is properly sending the reply stating it is ready to accept the TLS-SNI-01 challenge, but it looks like the server then never tries to connect to actually verify the challenge.

And since I have this problem for one domain and not the other, I’m suspecting the DNS for Let’s Encrypt has some trouble resolving the problematic domain, and therefore the VA never connects where we expect it to.

Could someone with access to the server-side help me confirm that hypothesis please, so I can try and figure out what I need to fix on the domain (I have access to the authoritative DNS for that Let’s Encrypt does not like?

Any kind of logs related to these attempts would help too.

Are there any docs on the production setup of the DNS for Let’s Encrypt? This way, I could run boulder myself in a similar fashion and try and figure out what’s going on.

The client is running on either Ubuntu 14 or CoreOS (on Google Compute Engine).



I don’t have access to the server side - but I can confirm you have DNS errors - see


Ah, as it seemed to resolve fine from different hosts with client tools like dig, I didn’t know what else to look for. I’ll look into that, thanks!


I can confirm that our Unbound instance wasn’t able to resolve to an IP address.

There aren’t as far as I’m aware. Perhaps you could open an issue on the Boulder repo describing what sort of documentation you would like to see? Boulder outsources the heavy lifting to Unbound and we don’t include this in the local development environment presently. Reproducing will be a little tricky.


Excellent, thanks.
Do you have any more information as to why please? I mean, the name does resolve as far as client tools such as dig are concerned, and shows that A and AAAA records are ok (even though they show warnings), which I thought would be enough. I’ll work on the warnings, but it would be great if I knew what Unbound does not like exactly.

Will do, thanks.


Wait a minute. You aren’t working on your own DNS implementation, are you? Or who else thought it would be a good idea to not respond to NS and SOA queries? WTF? I’ve never seen a messed-up DNS zone like that. Also, is there only a single name server listed for that domain? tells you exactly what is wrong.


It seems to set the status code of empty responses to NOTIMP, e.g. for dig CAA or dig MX. Or NS or SOA, which absolutely should exist, as you said.

I’m not surprised some resolvers are unhappy.



We’ve fixed all errors/warnings that were reported at , and yet it seems your Unbound still can’t resolve, can it? Is there any way you could tell me what kind of error it reports please?
Maybe the changes haven’t propagated yet though…



The records resolve OK for me. May be a TTL issue.

Or maybe it’s because you’re listing ::ffff: in public DNS space. If you don’t have an IPv6 address, don’t set an AAAA record. You still have only one name server for the domain.

What message do you get from LE now?


Doh, indeed. Thanks, should be fixed now.

Same as before:

acme: identifier authorization failed

$ dig @ txt
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 50647
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

;        IN      TXT

What server software exactly are you using? Why is it behaving so badly? It almost seems as if you’re trying to be too clever about using it, restricting its answers in ways you don’t understand? Or could it be you’re rolling your own entirely?

Edit: If I retry with +noedns, I still don’t get any proper answer.


Weird. it looks ok from here.


Where is the answer? Just because it’s “NOERROR” doesn’t mean it’s correct.


Why should there be an answer to that query?

In case the reason you’re mentioning that query is because of the dns-01 challenge, I should reiterate that the client (autocert), is using the tls-sni-01 challenge in my case.


Let’s Encrypt’s unbound instance uses randomized mixed-case DNS queries, which adds some spoofing resistance. Your DNS doesn’t seem to reply to these requests:

dig WiP.CaMlIsToRe.NeT A

; <<>> DiG 9.8.3-P1 <<>> WiP.CaMlIsToRe.NeT A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49802
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;WiP.CaMlIsToRe.NeT.		IN	A

;; Query time: 325 msec
;; WHEN: Thu Oct 20 00:28:58 2016
;; MSG SIZE  rcvd: 36


Thanks, done.

This is a not so random string to satisfy the 20 characters forum rule.


Ah, and now I’m finally seeing the server trying to establish the TLS-SNI connection, so it must have been able to resolve now. great!


Aaand I’ve just been able to get a cert against staging. FYI, I just had one last issue: our DNS wasn’t replying to CAA queries from Let’s Encrypt, which it now does (well, not with the proper response yet, will do in a bit).

The issue is fixed as far as I am concerned. Thanks to all.


An answer with NOERROR and no records is valid if there is such a record but of a different type. If there are no records at all, which

$ dig any

seems to confirm, the proper answer is NXDOMAIN.

Seriously, what are you doing to that DNS server to completely mess up best practices? Is there even a proper DNS server or is it homebrew code? You really shouldn’t touch DNS, that much is obvious.


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