I am hosting my nginx server @ scaleway.com and I have a internal and external IP address. The external IP address is correct edited with an A record and is responding. Ports 80 and 443 are open with firewalld. What I am doing wrong and how I can fix this?
Please help me.
Attached you find the error:
Type: connection
Detail: DNS problem: SERVFAIL looking up A for domain.tld.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
In the past, we have seen problems with hosts that reply to all-lowercase domain name queries, but not to mixed lower-upper case queries of the domain name. LE uses mixed case queries for better security. Can you check whether this is OK with you?
Your DNS looks fine, however I can’t reach your site. I get a connection refused on both http and https. Are you sure there isn’t a firewall blocking access ?
Aha, I found it: You are not serving A DNS record for www.git.bin-bash.net. Please add a new DNS record or a CNAME regarding the www subdomain. Results from Mxtoolbox:
That's a really, really great article -- but not about this particular random mixed case strategy. It doesn't mention case at all, in fact. RFC 4343 is probably a more informative reference here, and it doesn't seem to agree with the strategy.
Specifically, indirect labels are legitimate, and do not provide case preservation on output. Moreover, implementations in general are not required to provide case preservation on input, at all. It therefore seems to me that this strategy provides more breakage than protection.
Ah, thanks, very appropriate, and very informative indeed. It's the question section that can be relied on (ubiquitously, if not by requirement). I retract my prior conclusion.
Final question, with apologies for the threadjack: Does LE ensure the validity of this check by implementing its own resolver library?