DNS query timed out

Help
1

I tried the following command:

./letsencrypt-auto certonly --standalone --email me@example.com -d www.amshome.uk

(except I did use a real email address).

But it failed like this:

Failed authorization procedure. www.amshome.uk (http-01): urn:acme:error:connection :: The server could not connect to the client for DV :: DNS query timed out

I can get the DNS to resolve just fine, so I'm a bit stuck.

Are the Let's Encrypt servers getting slammed, or something, or is this a problem on my end?

Any help appreciated.

2

It seams to be a temporary problem at Let’s Encrypt.
I also can resolve the domain without problems.

Maybe try it several minutes later.

1 Like
3

Thanks.

I have tried this several times last night, just after the public beta opened, and again today. I did once get a different error (can’t remember what), but I wasn’t sure if that was failing sooner, or later. I’ll just keep trying every day or two, I suppose.

4

Can you run the command again with following parameter
and post the output (e.G. via Pastbin)?

-text -vv

Perhaps there are some more informations.

5

I just reproduced the other error:

Failed authorization procedure. www.amshome.uk (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client for DV :: Server failure at resolver

Still not sure whether that's progress, or not?

6

Log output: pastebin

7

Hmm, seems it is really a internal problem with the resolver of LE.
They cache dns data for 24 hours.

There is also a known problem with some TLDs: https://github.com/letsencrypt/letsencrypt/issues/1610

2 Likes
8

Yes, that bug looks the same. I also use DNSPod.

I suppose I need to wait for that bug to get fixed. :frowning:

Thanks for you help.

1 Like
9

You are welcome :wink:

I’m sorry that we could not solve the problem

10

I’m has been submit a ticket to DNSPod and ask for support, and they said it’s an server-side error by Let’s Encrypt, any idea?

11

When it is really a server-side problem at Let’s Encrypt then
you must wait until the developers fixed the problem.

The problem is already known and reported to the boulder team (server-side ca software).

1 Like
12

I could reproduce the timeout on my server with nslookup.

The error occurs when you initially try to resolve the domain.
Then my nslookup ran also into a timeout (2 sec, timeout for LE server).
When i try it a 2nd time on my server it resolve in time.

I think the expiration time of 10 seconds from DNSPod is may a problem.

Could you try to rerun the command and then directly after the result again ?
Or did you tried this already ?
Or you could try to increase the TTL of the Record.

1 Like
13

Got another problem: let’s encrypt server return 500 response for my request:

Error: urn:acme:error:serverInternal :: The server experienced an internal error :: Error creating new registration

14

Is this a reproducible problem ?
This is generic error from LE server.

15

YES, I had met this problem for two of my friend’s domains (both hosting by DNSPod, the DNS hosting provider in China), but my domains are fine, hosting by Route53.

16

Have a look at the last post on github.

1 Like
17

A 10 second expiry time on DNS entries is sure to cause problems, especially if a service needs to check an entry a few times during a process which takes a few seconds and the caching provider honours the expiry set by the server. It also causes additional load on the servers due to more frequent lookups.

2 Likes
18

Additionaly to the problem with 10sec there are some nameserver that are not responding

19

I found that I also had a 10 second TTL on my www subdomain. That’s odd, because all the other settings had 600 second TTLs.

Anyway, I changed it yesterday, but letsencrypt still fails today.

Judging by the comments in the GitHub bug, using DNS hosted in China is a problem for everybody. I had no idea DNSPod even was in China, I just used them because DynDNS stopped being free.

Anyway, my IP address changes so rarely it might as well be static, so I might just switch back to GoDaddy and risk it (the address is bound to change while I’m travelling).

20

DNSPod is in China and there’s a 10 second expiry? :o
That would enable the Chinese government (and other parties) to listen on the traffic and derive what domains are being requested with less worries about DNS caching servers ruining that opportunity.