We run a custom PHP script to install and renew certificates, using the Let’s Encrypt API.
Today was impossible to get the certificate for the domain “edwinchambilla.com”, we get the next message:
{"identifier":{"type":"dns","value":"edwinchambilla.com"},"status":"invalid","expires":"2019-01-05T16:03:04Z","challenges":[{"type":"tls-alpn-01","status":"invalid","uri":"https:\/\/acme-v01.api.letsencrypt.org\/acme\/challenge\/G9k2UgXpjccnj-TwjwL2BPDdj1VsTv9vDgWXNUlDOV8\/10848253459","token":"7vr1dp25wBnN4PF7jjOb0m3LZG4jay7bHt7e7vKGfts"},{"type":"dns-01","status":"invalid","uri":"https:\/\/acme-v01.api.letsencrypt.org\/acme\/challenge\/G9k2UgXpjccnj-TwjwL2BPDdj1VsTv9vDgWXNUlDOV8\/10848253462","token":"lNR_XyXN43Y7Dvj8QvYhY47Qhvk5cw8AyxLRohIvHTs"},{"type":"http-01","status":"invalid","error":{"type":"urn:acme:error:dns","detail":"DNS problem: query timed out looking up A for edwinchambilla.com","status":400},"uri":"https:\/\/acme-v01.api.letsencrypt.org\/acme\/challenge\/G9k2UgXpjccnj-TwjwL2BPDdj1VsTv9vDgWXNUlDOV8\/10848253467","token":"JIP7Ku_TTkOxRtfC6S5DrD9hFxCcZuJMbrB4ZssDLwU","validationRecord":[{"url":"http:\/\/edwinchambilla.com\/.well-known\/acme-challenge\/JIP7Ku_TTkOxRtfC6S5DrD9hFxCcZuJMbrB4ZssDLwU","hostname":"edwinchambilla.com","port":"80"}]}],"combinations":[[0],[2],[1]]}
This seems to be a geographically restricted problem.
From the west coast (California), I can reproduce the timeout. (And you can too, since unboundtest.com is hosted in CA).
When I run the exact same DNS test (using the same software, though you can try at letsdebug.net) from the east coast (New York), it is fine.
I’ve made a packet capture of a failed lookup attempt from CA (DigitalOcean SF2) available, which shows a whole bunch of unanswered queries that lead to timeout:
The large number of queries to your nameservers is caused by the nameservers’ lack of support for 0x20 mixed case randomization (https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00), which causes the resolver to go into “caps-for-id fallback mode”, where it needs to send a large volume of queries to verify the responses.
Additionally, I observed that after my failed test, your nameservers were completely dropping all DNS traffic from my host (which did work initially), but ICMP echo continued to work. That’s pretty suggestive of rate limiting or firewall behavior.
The other aspect of this is that ns1.dondominio.com/ns2.dondominio.com are anycasted hosts.
So, to summarize, it would seem to be that the NY anycasted nameservers for this domain are responding well to Let’s Encrypt’s queries, whereas the CA anycasted ones are not.
Since this can be reproduced with relative ease, I would probably send the packet capture to your host/NOC and ask them to look into why the traffic is dropping.
I had this problem as well. I found the DNS test tool at http://dnsviz.net/ very useful.
It ended up being the way my DNS was configured. I was hosting my own using SimpleDNS software. The solution was to enable “;EDNS0. EDNS0 payload size” on the DNS server, allowing it to send and receive larger packets over UDP.