I can’t seem to get a certificate for one of my domains php72.webehostin.com. The error log shows the following:
2018-01-15 18:28:06,702:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:
Domain: php72.webehostin.com
Type: unknownHost
Detail: No valid IP addresses found for php72.webehostin.com
But, I can ping it just fine from my PC and my servers…
C:\Windows\System32>ping php72.webehostin.com
Pinging php72.webehostin.com [173.243.124.109] with 32 bytes of data:
Any idea why this is happening? The DNS record is setup and valid unless I’m mistaken…
This is only a hunch, but your nameservers look strange here, note the “your.email.here.webehostin.com” nameserver. This looks like it might have something to do with it, but I’m definitely not sure on that one.
And domain webehostin.com has 3 ns records announced on top level domain but these servers announce there are 31 ns servers for the domain and most of them refuse to answer… a complete mess.
Seems you have a lot of work to fix your DNS issues.
It is a mess and it is an objetive opinion. Anyway, it is your domain.
Check this page https://unboundtest.com/ it uses the same dns resolver and very close conf as Let's Encrypt does, if you can get an A record for your domain you will get your certificate.
Query results for A php72.webehostin.com
----- Unbound logs -----
Jan 15 19:21:25 unbound[24978:0] notice: init module 0: validator
Jan 15 19:21:25 unbound[24978:0] notice: init module 1: iterator
Jan 15 19:21:25 unbound[24978:0] info: start of service (unbound 1.6.7).
Jan 15 19:21:26 unbound[24978:0] info: 127.0.0.1 php72.webehostin.com. A IN
Jan 15 19:21:26 unbound[24978:0] info: resolving php72.webehostin.com. A IN
Jan 15 19:21:26 unbound[24978:0] info: priming . IN NS
Jan 15 19:21:26 unbound[24978:0] info: response for . NS IN
Jan 15 19:21:26 unbound[24978:0] info: reply from <.> 2001:7fd::1#53
[...]
Jan 15 19:21:26 unbound[24978:0] info: query response was ANSWER
Jan 15 19:21:26 unbound[24978:0] info: validated DNSKEY com. DNSKEY IN
Jan 15 19:21:26 unbound[24978:0] info: NSEC3s for the referral proved no DS.
Jan 15 19:21:26 unbound[24978:0] info: Verified that unsigned response is INSECURE
Error running query: dns: failed to unpack truncated message
You should see the A record for your domain in top of that results page, something like:
Query results for A letsencrypt.org
Response:
;; opcode: QUERY, status: NOERROR, id: 13053
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;letsencrypt.org. IN A
;; ANSWER SECTION:
letsencrypt.org. 30 IN A 23.74.143.201
----- Unbound logs -----
Jan 15 19:24:20 unbound[24987:0] notice: init module 0: validator
Jan 15 19:24:20 unbound[24987:0] notice: init module 1: iterator
Jan 15 19:24:20 unbound[24987:0] info: start of service (unbound 1.6.7).
[...]
Whether the DNS works properly in a browser isn’t a good test for whether it will work with Let’s Encrypt, because Let’s Encrypt verifies the correctness of DNS records in detail much more stringently than browsers do. We’ve had many cases before where sites worked fine in browsers but had various DNS configuration glitches that interfered with issuing certificates.
A common example (which isn’t necessarily related to your case) is DNSSEC misconfigurations and mismatches. Browsers don’t necessarily enforce DNSSEC checks at all—but Let’s Encrypt does. So someone with a DNSSEC configuration problem might well be able to browse to the site yet still not get a certificate.
I was trying to find a good analogy for this difference, and I’ve found one that I kind of like but that’s obviously not totally exact. This is that an immigration agent at a border checkpoint is likely to apply more scrutiny to your identity documents than a bouncer in a nightclub or a convenience store clerk does. Therefore, the fact that a convenience store clerk accepted an ID for purposes of tobacco sales or something doesn’t guarantee that a border agent will accept the same document. Indeed, they’re likely to disagree about whether the document should be rejected if it’s expired recently.
Similarly, Let’s Encrypt is trying to perform a validation in order to vouch for the correctness of something to the general public, and so its interpretation of the technical details is much more stringent than a browser’s might be.
Do you have tech support available from the hosting provider? They would probably be in a position to fix the DNS configuration problems once they’ve understood the details.
I setup the DNS configuration, so I have the access, but I don’t know what’s broken because as far as I know, it’s not broken based on how I set it up.
It is unusual to have a DNS query return 31 authority and 31 additional records. But it's only ~1.1 KiB of data, which is less than many ordinary signed responses.
It's also problematic that some of the nameservers don't work, but that shouldn't particularly break resolution.
It's not a Certbot issue. It's either a Boulder issue (or more generally an issue with Unbound or Let's Encrypt's infrastructure), or an issue with your setup.
It is definitely partly broken: Some of the nameservers return REFUSED. But DNS resolvers are normally forgiving, so that shouldn't cause things to fail (often).
I could clean it up as mentioned since most of those name servers aren’t used anymore (guess deleting those entries will fix this problem… maybe?), but as many have mentioned here, I shouldn’t HAVE to, and that’s kind of my point.
If unbound limits the response to 512 bytes, that’s a problem. Still sounds like their system is flawed, as it should support more than that. It would be nice if unbound would output a helpful error message stating that it expects the total record to be under 512 bytes if that is the case.
I’m probably going to be the most hated person on the internet when this is all over… unless I am totally wrong…
My hypothesis isn't that anything is wrong with Unbound.
Its default configuration is to enable EDNS with a typical buffer size of 4096 bytes. It also of course falls back to TCP when it receives truncated messages.
My unconfirmed hypothesis is that Boulder and unboundtest's usage of the miekg/dns Go library as a stub resolver uses a buffer size of 512 bytes and throws an error when it receives a truncated response.
It's a great, free software recursive DNS server. And in my opinion some of the other popular servers wouldn't have been good choices in 2015, though they're probably fine now.