Closed olliephillips closed 5 years ago
At the expense of the blacklist you are right, but it is easy to settle through the support. It is important that the site is not in these blacklists host-tracker.com/InstantCheck/Create?type=DNSBL Because of them it is very difficult to get out.
It won't work and it can abuse from lets-encrypt.
Servers of lets encrypt have IPv6 access (i have check domains with ipv6 only) to internet and if domain has IPv6 address - they will check it by IPv6 (it is default OS behaviour).
It mean if domain has bad IPv6 record - it will reject from lets-encrypt server and no reason to send request for it.
Have some reason for send domains with bad IPv4 and good IPv6, but it can work with luck only and domain will work bad in real life (with most traffic in ipv4) - some later server can check domains from few points with both protocol and it will fail.
Ok, thanks for the explanation. We'll just have to ensure domain configuration instructions include removing AAAA records if they exist. No big deal. Thanks again.
Odd case of certificate not being requested on a single domain.
Looking at the log error messages and the DNS of the domain, suspect the issue is that while IPv4 records exist and point correctly to the server, IPv6 records also exist but do not point to the server. Presumably these were defaults configured by the registrar to some default shared hosting. Lets-proxy "appears" to add the domain to bad list, on the basis that one of these DNS checks does not resolve.
I am correct? My inference is that if we remove the IPv6 records, we'll get a certificate issued. I hope to test when we can get access to their DNS.
Would a better behaviour be that if one IPv* format resolved correctly, then the domain is ok, for certificate request and is not added to the bad list.
Admittedly, we are running v0.15.0 on this particular server, so maybe this is picked up in a later release?