And a new challenger has entered the game! What info do you have for me Certbot Engineer?
The DNS spy service apparently expects a registered domain name (or it will strip www.), not a FQDN.
https://dnsspy.io/scan/translate.google.com
I’m pretty sure that the DNS records for translate.google.com are OK, but there is no NS record at that level.
That would be the ideal scenario.
And then any future changes would have to be done on both (independent) systems.
Like say you added an IRC chat server at “irc.pioneerdm.com” that entry would not automatically get entered into the other system. it must be done manually (now twice).
OK, so then the (network) DNS break is much larger than just GoDaddy.
That still doesn’t discount the prognosis.
But the unboundtest.com test was able to resolve the ip address and the nameserver correctly. So doesnt that imply that the issue may be more local than orignally thought instead of wider spread?
Even if the problem is just one IP can’t see one other IP.
You are affected by that and are at the mercy of the network.
Until IP#1 can see IP#2 (or IP#3), you will not get a cert.
I say introduce IP#4 (and even IP#5) and add it so that should IP#2 (and IP#3) continue to fail, you are not 100% down from that point of view - nor any future points of view.
Remove the Single Points Of Failure - they will inevitably fail and let you down.
I think you're just misinterpreting what DNS Spy tests. It appears that it just doesn't properly test any non-www subdomain of any domain:
Schoen, starting from about the 2nd message, can you offer any solutions or suggestions as to what I might try?
stevenzhuRegular2h
Hi,
What’s the software you use to apply the certificate?
Thank you
dennis21302h
I’m not 100% sure. The site is hosted internally, it’s run through Mamp Pro with Apache. A previous developer installed the cert that has worked without issue for the last few months. Today people started receiving the “Your connection is not private” error. After some digging I found the LetsEncrypt software on my server. It’s just an executable that runs the Lets Encrypt Windows Simple program. From there I can see that there is a cert on LetsEncrypt, but attempting a renewal tells me that No DNS Pointers Found.
What I can’t figure out is the tie between Mamp and Letsencrypt. Within Mamp itself there are no setting selected for SSL Security. There is a listener for port 80 and 443, but neither of them have SSL Enabled. So I can’t tell if there is something else in windows that I need to be looking at to determine how the SSL Cert is actually installed.
I’m going to email the owner of the host account and get a full list of DNS Records for our Domain Name. Who should i use as a back up Name Server provider?
Ok, removing all references to DNS SPY, we are still left in this situation:
Does anyone else have a (different) immediate solution to this situation?
Could you try a different Let's Encrypt client? We haven't seen the actual underlying error message from the certificate authority here, so we don't know for sure whether the certificate authority thinks that the problem is DNS-related (or indeed whether a certificate was even requested at all). A different client application might offer a more specific and more useful error message.
I get this on my unrelated DNS system:
sftp.pioneerdm.com NS69.DOMAINCONTROL.COM
Server: NS69.DOMAINCONTROL.COM
Addresses: 2607:f208:206::2d
216.69.185.45
*** NS69.DOMAINCONTROL.COM can't find sftp.pioneerdm.com: No response from server
sftp.pioneerdm.com NS70.DOMAINCONTROL.COM
Server: NS70.DOMAINCONTROL.COM
Addresses: 2607:f208:302::2d
208.109.255.45
*** NS70.DOMAINCONTROL.COM can't find sftp.pioneerdm.com: No response from server
The responses are immediate - not a timeout issue.
I see “Truncated, retrying in TCP mode”; which client are you using to do that lookup?
using windows nslookup
maybe it is a UDP/TCP thing…
one single record lookup should not require TCP and forcing TCP may be violating the RFC…
2.5 hours later and we still have no solution…
https://letsdebug.net/pioneerdm.com
to recap what I consider when trying to eliminate Single Points Of Failure as related to DNS:
(in these cases more is always better)
- number of DNS providers
- number of datacenters
- number of AS numbers used
- number of TLD used by name servers
- name servers accessibility via IPv4, IPv6
If you only have one DNS provider, who services your DNS form only one datacenter, that uses only one AS number, and whose name servers all end with the same TLD, and only use IPv4, then you should expect, and/or already be accustomed to, DNS outages.
At which point your only hope is to increase the TTL time and hope for mercy from the Internet caching systems.
I just tried requesting a certificate for this name from another machine and I saw a successful connection from Let’s Encrypt to the real sftp.pioneerdm.com, which of course didn’t have the challenge set up and gave a (correct) challenge validation failure. I don’t believe that there’s an underlying DNS error causing this problem and I believe that trying with a different client will produce a more useful error message.
DNS redundancy is great for site reliability, but I think it’s a red herring with respect to this issuance failure.
To put this another way, the actual production Let’s Encrypt CA accepted the current DNS configuration enough to make an HTTP request to sftp.pioneerdm.com to attempt to validate an HTTP-01 challenge. That’s much further than it would have gotten if it believed there was a DNS error.
It wouldn’t be the first red head I’ve fallen for - lol
I think he’s a 9-5 guy, so we may not hear anything until Monday morning…
By then, who knows, it just might magically work without him making any changes at all.
Yay! The tiny Internet elves will have saved the day!
Thanks everyone for the help. I was able to resolve the issue this morning.
I ended up using the ZeroSSL Client. It had more options to troubleshoot than the LetsEncrypt Client did. Firing up with ZeroSSL Cient showed that DNS was fine and entering my csr and key files as parameters got me quickly renewed.
Renewal was just the first part as I then had to figure out how to get the newly renewed cert into the MAMP Pro system.