Sure but I have a theory on why this happens that is related to the Akamai CDN and the way my server is setup.
I’m running dehydrated from my Linux load balancer in a VM environment, now the networking. It’s handled so basicly all incoming/outgoing traffic is through GRE tunnel in a remote datacenter to avoid having to pay for a static IP (have a custom daemon to manage the connection) and also DDoS mitigation. however I currently just have the DNS proxied to home router which runs it’s own DNS resolver, but you see the Akamai CDN IP is actually at my home ISP, and I suspect that they are rate limiting connections from people who aren’t their customers.
; <<>> DiG 9.11.0-P2 <<>> cert.stg-int-x1.letsencrypt.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10229
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cert.stg-int-x1.letsencrypt.org. IN A
;; ANSWER SECTION:
cert.stg-int-x1.letsencrypt.org. 600 IN CNAME cert.stg-int-x1.letsencrypt.org.edgesuite.net.
cert.stg-int-x1.letsencrypt.org.edgesuite.net. 21600 IN CNAME a1759.dscd.akamai.net.
a1759.dscd.akamai.net. 20 IN A 209.121.139.177
a1759.dscd.akamai.net. 20 IN A 209.121.139.178
;; Query time: 407 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Mar 04 00:14:36 PST 2017
;; MSG SIZE rcvd: 183
jtl-macbookpro-ethernet:~ jtl$ geoip 209.121.139.177
Resolving IP: 209.121.139.177
{
"ip": "209.121.139.177",
"hostname": "No Hostname",
"city": "Cambridge",
"region": "Massachusetts",
"country": "US",
"loc": "42.3626,-71.0843",
"org": "AS852 TELUS Communications Inc.",
"postal": "02142"
}
But if we try a different DNS server
jtl-macbookpro-ethernet:~ jtl$ dig @4.2.2.1 cert.stg-int-x1.letsencrypt.org
; <<>> DiG 9.11.0-P2 <<>> @4.2.2.1 cert.stg-int-x1.letsencrypt.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46386
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;cert.stg-int-x1.letsencrypt.org. IN A
;; ANSWER SECTION:
cert.stg-int-x1.letsencrypt.org. 600 IN CNAME cert.stg-int-x1.letsencrypt.org.edgesuite.net.
cert.stg-int-x1.letsencrypt.org.edgesuite.net. 21600 IN CNAME a1759.dscd.akamai.net.
a1759.dscd.akamai.net. 20 IN A 23.215.102.82
a1759.dscd.akamai.net. 20 IN A 23.215.102.88
;; Query time: 341 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Sat Mar 04 00:20:26 PST 2017
;; MSG SIZE rcvd: 183
jtl-macbookpro-ethernet:~ jtl$ geoip 23.215.102.82
Resolving IP: 23.215.102.82
{
"ip": "23.215.102.82",
"hostname": "a23-215-102-82.deploy.static.akamaitechnologies.com",
"city": "Cambridge",
"region": "Massachusetts",
"country": "US",
"loc": "42.3626,-71.0843",
"org": "AS20940 Akamai International B.V.",
"postal": "02142"
}
So It’s an interesting erratum involving Akamai’s CDN and not really related to LetsEncrypt service.
OK you wanted to see curl -vvv with this issue in action?
root@lb-lan:~# curl -vvv 'http://cert.stg-int-x1.letsencrypt.org/ ' |/dev/null
bash: /dev/null: Permission denied
* Hostname was NOT found in DNS cache
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 209.121.139.177...
* Connected to cert.stg-int-x1.letsencrypt.org (209.121.139.177) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: cert.stg-int-x1.letsencrypt.org
> Accept: */*
>
0 0 0 0 0 0 0 0 --:--:-- 0:00:12 --:--:-- 0
At which point it just stalls, curl eventually errors with exit code 56.
I will try using other DNS for my load balancer not died to my main home ISP which should solve it, but thought I’d document this for the rare edge case.
Thanks
