same issue as here :
DNS resolver issues? .
(we have replaced the true domain by domain.com, of course, we are not noobs 
)
This issue is serious, we use our own DNS at OVH , and secondary DNS is at 10 000 km from it, and same issue… we tested with DNS from our registrar on another domain and SSL issuance worked immediately.
In both cases we see from logs IP from let’s encrypt succeding in reaching URLs of domain where there is the verification code…
What is your domain name ? ( and were you just trying to get the domain on this cert ? or www.domain as well ? and any other domains ? If so, please provide all ( or at least the one it failed on )
domain on which it fails : 123hosting.fr, with our own DNS being both local and distant with Canada
the issue is replicated on all domains of server using these same dns as previous domain
we have checked also both resolution of our DNS, and there is no issue
teste just now, we get :
There was a problem processing your request
Error issuing certificate for domain123hosting.frFailed to issue certificateThe Let's Encrypt HTTP challenge failed: polling pending challenge timed outwe have added a third resolver in case…
we have succeeded to issue a certificate, but not on other domains
the issue i think is truly an issue of let’s encrypt servers, this has happened in the past, and this must not happen again in future, this is a basic thing, and with all sponsors you have liek OVH you can get a redundant network of servers…
I 'm not able to decrypt/understand last URL sent. Like anyone, this is enough to say we have a correct DNS setup :
http://www.intodns.com/123hosting.fr
We have/use a normal DNS config like anyone on a cpanel server
how do you explain that it has always worked with dozens of SSL providers and yours the last 4 days ? and this issue is now on nearly whole server, it succeeds on some domains from time to time
I more thing to a network issue, if no, please provide step by step so that we can see if yoru solution is the solution ?
we get positive tests depending from where you test 
http://dnscheck.iis.se/
We suspect a network issue at DC
Please do several tests to avoid a too quick conclusion
It could well be a network issue, close to your nameservers. I got
for your first nameserver … nsa.hosting1976.fr
checking zone: The server did not respond to queries over TCP. (37.187.24.68)
checking SOA: No response was received from the server over TCP (tried 3 times). (37.187.24.68)
From your second nameserver … nsb.hosting1976.fr
checking zone: The server(s) were not responsive to queries over UDP. (198.50.146.202)
checking A: No response was received from the server over UDP (tried 8 times). (198.50.146.202)
checking NS: No response was received from the server over UDP (tried 8 times). (198.50.146.202)
Hello @yoyo699,
For me it is a network problem.
From UK:
$ dig @nsa.hosting1976.fr 123hosting.fr
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @nsa.hosting1976.fr 123hosting.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ dig @nsb.hosting1976.fr 123hosting.fr
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @nsb.hosting1976.fr 123hosting.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
From EE.UU.:
$ dig @nsa.hosting1976.fr 123hosting.fr
; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> @nsa.hosting1976.fr 123hosting.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23868
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;123hosting.fr. IN A
;; ANSWER SECTION:
123hosting.fr. 7200 IN A 5.39.54.125
;; AUTHORITY SECTION:
123hosting.fr. 7200 IN NS nsb.hosting1976.fr.
123hosting.fr. 7200 IN NS nsa.hosting1976.fr.
;; ADDITIONAL SECTION:
nsa.hosting1976.fr. 14400 IN A 37.187.24.68
nsb.hosting1976.fr. 14400 IN A 198.50.146.202
;; Query time: 82 msec
;; SERVER: 37.187.24.68#53(37.187.24.68)
;; WHEN: Mon Mar 14 18:01:58 CET 2016
;; MSG SIZE rcvd: 138
$ dig @nsb.hosting1976.fr 123hosting.fr
; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> @nsb.hosting1976.fr 123hosting.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
From Luxembourg:
$ dig @nsa.hosting1976.fr 123hosting.fr
; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> @nsa.hosting1976.fr 123hosting.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33769
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;123hosting.fr. IN A
;; ANSWER SECTION:
123hosting.fr. 7200 IN A 5.39.54.125
;; AUTHORITY SECTION:
123hosting.fr. 7200 IN NS nsb.hosting1976.fr.
123hosting.fr. 7200 IN NS nsa.hosting1976.fr.
;; ADDITIONAL SECTION:
nsa.hosting1976.fr. 14400 IN A 37.187.24.68
nsb.hosting1976.fr. 14400 IN A 198.50.146.202
;; Query time: 23 msec
;; SERVER: 37.187.24.68#53(37.187.24.68)
;; WHEN: Mon Mar 14 17:58:25 CET 2016
;; MSG SIZE rcvd: 138
$ dig @nsb.hosting1976.fr 123hosting.fr
; <<>> DiG 9.9.5-9+deb8u5-Debian <<>> @nsb.hosting1976.fr 123hosting.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60910
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;123hosting.fr. IN A
;; ANSWER SECTION:
123hosting.fr. 7200 IN A 5.39.54.125
;; AUTHORITY SECTION:
123hosting.fr. 7200 IN NS nsa.hosting1976.fr.
123hosting.fr. 7200 IN NS nsb.hosting1976.fr.
;; ADDITIONAL SECTION:
nsa.hosting1976.fr. 14400 IN A 37.187.24.68
nsb.hosting1976.fr. 14400 IN A 198.50.146.202
;; Query time: 102 msec
;; SERVER: 198.50.146.202#53(198.50.146.202)
;; WHEN: Mon Mar 14 17:58:32 CET 2016
;; MSG SIZE rcvd: 138
Also tried from Spain and France and it is erratic, sometimes resolves others don’t.
You should talk to your hosting provider.
Good luck,
sahsanu
we already talked, and it is useless. we know it is erratic, and OVH still did not discover anything…
we have no tium, and we have setup secondary DNS on another VPS in Germany at another provider to make sure one of the network will answer in term of DNS. This is a midlle term measure we were thinking of already…
let it propagate… and let se tomorrow
Having a secondary DNS provider that provides the IP may not help if the primary authoritative nameservers do not respond.
Let’s Encrypt, to ensure that they are getting the correct IP address, will always ask your authoritative namesevers (whereas your browser will typically get the IP from any nameserver that responds).
You may be better swapping and using another DNS provider. I’ve found cloudflare has very good, free DNS nameservers ( although I really don’t like they way they handle some of the SSL aspects of sites if you use their full cache system. ).
such issue is temporary, we must keep our own custom DNS, never cloudlfare in any way…
we issued successfully ssl for domain 123hosting.fr and few other domains… no error at all
issue on snd DNS :
http://www.intodns.com/123hosting.fr
Note that both "primary" and "secondary" name servers are authoritative. An outside observer cannot known which of your NS is primary or not. It just sees all NS servers as authoritative servers.
Agreed - I’m just not certain of the code within LE without checking, if 2 of the 3 authoritative servers fail to respond if it’s still happy to proceed.
For us, there is a too sensitive thing in LE way of working
Networks has recurrent issues like now, and it seems to end, things are better.
Our DNS plan has played his job at 100%, no client reported any difficulty to access his website.
We will not change anything for LE, LE should change its way, and we are not the kast one/only one to be victim of LE’s way of working
For now, we will accept how it is as it is public beta, and LE will realize itself there is an issue.
@yoyo699 I’m not sure if there is a slight miss-understanding here.
Most browsers (i.e. users ) are generally happy to get a domain name from any DNS server. Whether that is your authoritative nameservers or if they are using google, opendns or anything else.
LE needs to be 100% certain the DNS is correct, and not spoofed or anything else, hence it will always ask your authoritative nameservers for the correct information.
If there is a network issue, load issue or anything else with your authoritative nameservers it is unlikely to affect most users (since they will get a response from a different nameserver, which their browser is set up to use and has cached your IP etc.).
Since LE is asking your authoritative nameservers (and I suspect always will - as it needs to be 100% certain) then any routing / network / response issues from your authoritative nameservers will affect your ability to get certificates.
We’ve shown ( via tests from the US, UK, Luxembourg, France, Spain) that there were issues with responses from your authoritative nameservers at that time - which is where the problem lies. Because of the way DNS works this is unlikely to effect existing users ( as they will have cached the data and IP information). I do not believe in this case there was any issue with LE.
ok agreed for network issue, I’m no going to talk hard with my ISP