It produced this output: Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for dev.ccss.cz
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/dev.ccss.cz.conf produced an unexpected error: Failed authorization procedure. dev.ccss.cz (http-01): urn:acme:error:dns :: DNS problem: query timed out looking up A for dev.ccss.cz. Skipping.
My web server is (include version): Apache httpd 2.4
The operating system my web server runs on is (include version): Debian 8
I can login to a root shell on my machine (yes or no, or I don’t know): yes
It seems there may be some GEO blocking at work…
Or it is being allowed now…
I think #1:https://letsdebug.net/dev.ccss.cz/12306
Because I can reach the challenge folder.
All other folders return 403 error.
wget dev.ccss.cz/.well-known/acme-challenge/1234
–2018-12-17 07:46:04-- http://dev.ccss.cz/.well-known/acme-challenge/1234
Resolving dev.ccss.cz (dev.ccss.cz)… 88.86.113.241
Connecting to dev.ccss.cz (dev.ccss.cz)|88.86.113.241|:80… connected.
HTTP request sent, awaiting response… 404 Not Found
2018-12-17 07:46:05 ERROR 404: Not Found.
wget https://dev.ccss.cz/.well-known/acme-challenge/1234 --no-check-certificate
–2018-12-17 07:46:21-- https://dev.ccss.cz/.well-known/acme-challenge/1234
Resolving dev.ccss.cz (dev.ccss.cz)… 88.86.113.241
Connecting to dev.ccss.cz (dev.ccss.cz)|88.86.113.241|:443… connected.
WARNING: cannot verify dev.ccss.cz’s certificate, issued by ‘CN=Let’s Encrypt Authority X3,O=Let’s Encrypt,C=US’:
Unable to locally verify the issuer’s authority.
HTTP request sent, awaiting response… 404 Not Found
2018-12-17 07:46:21 ERROR 404: Not Found.
I think that although most recursive resolvers (such as 1.1.1.1 and 8.8.8.8) resolve the domain okay, Let's Encrypt's (which is also letsdebug's) resolver is going into a weird caps-for-id fallback mode (not sure why, since the one alive resolver is 0x20-compatible), which requires more than one to be responsive.
Since only one resolver is alive, the entire thing times out.
Unbound sometimes (always?) does that when servers (or the first server it tries?) are down, since it's impossible to tell the difference between "times out because it drops capitalized queries" and "times out because it's actually down" without additional probing.
I dunno if it's intentional behavior, a bug, or intentional behavior that the developers might change if presented with a good argument.
Resolution is always a race against the clock, and delaying caps fallback until after more regular-timeout fallback could solve this case but lead to more failures overall. Or just an unmaintainable tangle of code.
.