First DNS offline, second available - letsencrypt fail


#1

Hey,

I use the dns service from twodns.de which offer the domain ‘dyndns.de’ currently the first DNS server is offline but the second is available. (https://intodns.com/dynvpn.de) Unfortunately certbot ( version 0.21.1-1~bpo9+1 Debian) can not resolve the domain names to A-records. Some of the requested domains however get resolved but it is not predictable. Multiple calls of certbot didn’t work well, because the a-records are not cached. Therefore I run into the rate-limit.

Any solution available?


#2

Could you please fill in the questions you were presented with when you opened this topic? Those are really important for us to be able to help:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):


#3

My domain is: koelner.dynvpn.de

I ran this command:
certbot certonly --standalone -n --agree-tos --preferred-challenges http --expand -d koelner.dynvpn.de -d cloud.koelner.dynvpn.de -d gateway.koelner.dynvpn.de --pre-hook ‘systemctl stop nginx.service’ --post-hook ‘systemctl start nginx.service’

It produced this output:
differs: but mainly:
The following errors were reported by the server:

Domain: gateway.koelner.dynvpn.de
Type: unknownHost
Detail: No valid IP addresses found for gateway.koelner.dynvpn.de

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that
domain contain(s) the right IP address.
2018-04-05 17:01:25,090:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: cloud.koelner.dynvpn.de
Type: connection
Detail: DNS problem: query timed out looking up CAA for koelner.dynvpn.de

My web server is (include version):
nginx version: nginx/1.13.3

The operating system my web server runs on is (include version): Debian 9

My hosting provider, if applicable, is: —

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no


#4

I believe the DNS resolution from the CA side is going to choose one of the authoritative DNS servers randomly and timeout if it doesn’t respond, rather than failing over to another DNS server. In that case you’d need to wait until the other authoritative server is back up or get them to remove it as authoritative.


#5

Thanks, not really the solution I searched for. Is there a reason not to check the second dns server?


#6

In general Let’s Encrypt is very cautious about treating failures as final and requiring certificate applicants to fix their infrastructure. You can also see this in many other DNS-related areas like enforcement of DNSSEC, enforcement of CAA, and treating other kinds of DNS server errors as fatal.

Overall the reason for this is that applicants are being asked to do something to prove their control over the domain for security purposes. Attackers who want to issue fake certificates might do various things to try to falsify the proof, so we don’t want to give people a lot of flexibility or leeway in what we say constitutes valid proof. This is very much not Postel’s “be liberal in what you accept” because it’s forming a basis for making a public certification to the whole Internet that the applicant really controlled the domain name, which any Relying Party is then invited to rely upon.


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.