Thanks @griffin
Hopefully @_az can shed some light on this as I am in the dark and apparently our web hosting provider is as well as to why its broken. Whatever the issue is it seems to be preventing them from renewing certs on our behalf which is a problem.
Keep in mind that Let's Encrypt and Let's Debug (to the best of my knowledge) aren't intertwined. The only relationship I am aware of between them is the engineers themselves and that which they are/were involved. I just wanted to clarify to prevent any confusion. There have been secondary validation errors with the Let's Encrypt CA the past few days that I believe are unrelated to what's going on with Let's Debug.
Fortunately, _az has already taken time out of his schedule to look into things and action is being taken. I love this community! 
I'm keeping my eye out, so please report anything you may find related. Domain names and circumstances help.
Update:
Per _az, the related issues with Let's Debug should be gone right now. 
As wonderful as that might be...
How will that fix/change the outcome of the LE issue(s)?
That is the concern now.
I don't think they're related, but at least we got our tool back. Last I heard from James they're addressing the LE issue, but progress has been made.
OK, that is good news 
But is there still an issue with LE and the whole CAA/etc. DNS problems of late?
James exact words as of 16h ago: Getting there! I wouldn’t say it’s fully solved yet.
Here it is the output of the unbound recursion that ends in SERVFAIL:
https://unboundtest.com/m/CAA/agit-global.com/Q2LE6QW6
Unfortunately, I am not able to interpret its output, may be someone else?
You have access to the #lounge, so you can check here for more info on the LD side of things. Just a heads-up. 
Has anyone looked at the warning on this page for that domain?:
Oh wait... I think already brought that up (twice) before!
post #10
post #15
It's getting late, Rudy. 
What my grammer chekcer is of a gain? - LOL
@griffin is there a post somewhere regarding any changes being made?
I understand that they may not be intertwined but when a company we uses informs me there is something wrong with our DNS because letsdebug reports there is and they use letsencrypt to generate certs it leaves me in a bad spot. I have to prove that my DNS is not the issue for a service that I don't even use to a company that doesn't seem to know how letsdebug or letsencrypt validate whether they can generate a cert or not. Hoping someone can shed some light on all of this so I have better understanding of how this process works.
Were you able to prove anything?
Which DNS service provider are you using?
@rg305 Yeah man, hence the reason why I am here.
Other than proving that I have valid resolvable A/AAAA records for the domains the provider is complaining about what else is there to prove? We host our own DNS and don't use any managed DNS service provider.
You started the whole "proving" thing - LOL
I can look into this more if you can provide the FQDN that is having "difficulty".
@rg305 Not sure what is so funny about this? Like I said I am here to learn more about how this website verifies whether it can generate a cert or not for a specific domain as the documentation seems to be lacking.
I'll message you directly.
Wow, I am so impressed with all the responses. What a community!
I have an update from the client's IT provider who is controlling the nameserver. They are saying that their server does not support the CAA method. I am no DNS expert but what confuses me is that LE used to verify the cert for the domain where it was hosted previously, when the only difference was where the A-Record was pointing.
Also when I tried the command again this morning, I received a slightly different error:
Challenge failed for domain shop.agit-global.com
http-01 challenge for shop.agit-global.com
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: shop.agit-global.com
Type: dns
Detail: During secondary validation: No valid IP addresses found
for shop.agit-global.com
and from the log:
{
"identifier": {
"type": "dns",
"value": "shop.agit-global.com"
},
"status": "invalid",
"expires": "2020-10-14T15:07:08Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:dns",
"detail": "During secondary validation: No valid IP addresses found for shop.agit-global.com",
"status": 400
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/7731535808/_Ecz3g",
"token": "JVaNhRyA5tqVZcMt1eDHPB9COzarFZw5esrW56Lv3dE",
"validationRecord": [
{
"url": "http://shop.agit-global.com/.well-known/acme-challenge/JVaNhRyA5tqVZcMt1eDHPB9COzarFZw5esrW56Lv3dE",
"hostname": "shop.agit-global.com",
"port": "80",
"addressesResolved": [
"54.176.144.117"
],
"addressUsed": "54.176.144.117"
}
]
}
]
}
Sorry for the delay. Late night and I just checked my messages. Looks like I may be late to the party from what I've read. You and @rg305 may have taken the conversation private, so I don't know what's there, but I did update a message further up at a point last night with news from _az that the issue with Let's Debug should be mitigated. I probably should have made a new post so it would have been more evident. Try it out and let us know what you experience.
As for the process of how Let's Encrypt goes about verifications, there might be details about the super specifics explained somewhere, but I'm not exactly sure. I do know that Let's Encrypt uses the Boulder CA, which is open source, so I suppose the answers are there, just maybe not in the most digestible form.
I gathered some documentation that you potentially might find helpful:
This is still part of the secondary validation failure that has been seen a lot the past week. I know that Let's Encrypt is working on it. I believe it is just a different flavor of the error you originally saw.
I can confirm that my dig was readily able to find a valid IP address for shop.agit-global.com. It appears that Let's Debug still reports SERVFAILs though. 
You can clearly see in your own log that the primary address validation succeeded, so it's for sure not an issue specifically with your DNS.
OK, thanks for clarifying. I will just keep trying once a day to get the cert issued.
