When trying to obtain a Let’s Encrypt certificate for domain edisongalicia.es I get the following error in my logs:
Error creating new registration :: empty DNS response
My server is debian 7 with apache 2.2.22 and I using ruby acme-client.
If I execute the command “dig edisongalicia.es +short” I get “185.42.104.196” which is the correct IP of my server and if I execute “dig edisongalicia.es aaaa +short” I get nothing.
I work for a Hosting company and we received a DDoS attack against our DNS servers that makes them to be down for an hour, but actually they work fine.
That error message seems to come from the code to validate the email address associated with your account, not anything related to the website you’re trying to issue a certificate for.
Make sure the email address is correct and its DNS is working, i guess.
It’s possible to change an account’s email address, but i don’t know if that client implements it. At worst, you can just create a new account.
After reading this thread I thought the error being displayed wasn’t as helpful as it could be for identifying the root cause. I opened a PR on Boulder (https://github.com/letsencrypt/boulder/pull/2812) to improve the error message.
Do you think if the error had said “empty DNS response validating email domain - no MX/A records” it would have been easier for you to figure out initially?
Hi @cpu, thank you for your reply,
I work as a Backend developer por CDmon, a Hosting company in Barcelona, and it would be so helpful if the error had said “empty DNS response validating email domain - no MX/A records”.
I didn’t understand anythink the day I had the error, because I used the dig command and the domain that I asked the certificate for resolved an IP address.
In my case, and probably the case of any Hosting company, we used the mail that the client used to register to our company, but thats mails can disapear and are not changed in our platform.
Thank you again!
Great! I'm glad to hear this will make things less confusing. The change has been deployed to staging and I expect production will be fixed tomorrow (22/06/17) with the scheduled Boulder deploy.
Thanks again for raising the thread initially so we could solve the problem!