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:
Detail: No valid IP addresses found for php72.webehostin.com
But, I can ping it just fine from my PC and my servers…
Pinging php72.webehostin.com [184.108.40.206] 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.
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
;; 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 220.127.116.11
----- 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 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.