No valid IP addresses found for... DNS A record exists and works

Hi All,

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.

# dig @8.8.8.8 php72.webehostin.com NS

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.4 <<>> @8.8.8.8 php72.webehostin.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45338
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;php72.webehostin.com.          IN      NS

;; AUTHORITY SECTION:
webehostin.com.         59      IN      SOA     ns3.webehostin.com. your.email.here.webehostin.com. 159 1300 180 84000 60

;; Query time: 31 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 15 13:46:30 2018
;; MSG SIZE  rcvd: 94

…also, there are dnssec errors

Edit: I said it had dnssec errors but it is not true, my bad.

http://dnsviz.net/d/php72.webehostin.com/dnssec/

http://dnssec-debugger.verisignlabs.com/php72.webehostin.com

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.

Still, that shouldn’t necessarily/always stop it from working. :confused:

Might be a mess in your opinion, but the entries I actually use do work, so why is Let’s Encrypt saying otherwise?

Pretty sure Let’s Encrypt isn’t parsing email addresses from the DNS response either…

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.

It’s weird, I can’t resolve that hostname with https://unboundtest.com/, but can resolve it with my own resolvers. :confused:

I can’t tell, but it appears that https://unboundtest.com is working, so why isn’t Let’s Encrypt?

Sorry but it is not working:

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).
[...]

Oh, OK. Guess I can’t even figure out the output of the utility. Looks like it failed to unpack a message whatever that means.

There’s something wrong with Let’s Encrypt DNS lookup then because I can assure you that php72.webehostin.com works as it should on a normal system.

Ok, I guess I’ll file a bug at GitHub. Still not working for me today either.

Looks like cpu on GitHub locked the issue without any explanation. Great technical support for a clearly flawed system.

Still have no idea what I need to do to “fix” a non-issue so I can use Let’s Encrypt.

https://github.com/certbot/certbot/issues/5433

Hi @own3mall,

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.

I don't get it. :confounded:

Edit:

@own3mall:

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.

Untested hypothesis:

The Boulder / unboundtest / miekg/dns DNS query implementation limits responses to 512 bytes, and fails when a long authority section is truncated.

Is that plausible?

I’m not sure how to test it.

Actually I am sure how to test it, but it would take a couple minutes to set up.

1 Like

Nah, that's just the SOA record. That second URL-like thing is actually the e-mail address of the zonemaster.

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…

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=3431

Why is Let’s Encrypt using unbound? What advantage do you get from using this… great… system?

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.

Supporting evidence:

I'm not a Go programmer though.

And I haven't looked at Boulder's implementation.

@jsha Thoughts?

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.