Invisible CNAME record (to letsencrypt.vdeck.eigdyn.com) prevents adding a TXT record for acme challenge

I ran the following command:
sudo certbot certonly --manual -d *.<domain-name>.com -d <domain-name>.com --agree-tos --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory

I update the TXT file but get an error that my challenge failed since the TXT file is not there but they found two more TXT records. Upon investigation, I can see that the txt records come from .letsencrypt.vdeck.eigdyn.com. There is a CNAME from _acme-challenge.<domain-name>.com to <domain-name>.letsencrypt.vdeck.eigdyn.com so that is how these txt records are obtained. Having the CNAMe record also probably overrides any attempt to add txt record for _acme-challenge.

But the issue is that I went to my iPage DNS settings and I don't see any such CNAME record. My only guess is that it was from some previous SSL certificaation through iPage but I'm not sure why I wouldn't see any CNAME records on iPage even if it was. has anybody encountered a similar issue?

If you have a CNAME you cannot have any other record on the same fqdn.

You have to investigate where the cname comes from, why is it there, and go from that.

If you don't see it, it's probably your DNS hosting/registrar's fault.

6 Likes

THank you for your reply. This is what I suspect too - that iPage/Domain.com is doing something on their end that is causing this.

I've spent countless hours trying to get them to look into it and they keep telling me "propogation takes 48 hours" even when they make no changes. So it feels I have to resort to some other means here. Is there a way to reset the "invisible" cname settings? Like can i move domain providers or reset somehow?

1 Like

I suspect they don't understand what you mean, ask them to kindly escalate to their second level support and that the problem is a CNAME record that cannot be delete regardless of propagation time.

They are most likely using their own "invisible" CNAME for _acme-challenge so that they can use it to validate certificates via Let's Encrypt etc themselves. Cloudflare also do this for some settings and you may be able to disable it if there is some option for automatic SSL on the domain that you can switch off.

3 Likes

Hello,
I have been struggling with the same thing with domain.com trying to renew my certs, I did find a setting in the "Summary" page for the domain and label "LetsEncrypt Free SSL", I have turned that on. Waiting to see what that does. Will let you know hopefully soon.

I ended up moving to cloudfare. Put all my dns settings on cloudfare, moved nameservers to the ones cloudfare suggested while still having the domain on domain.com. And this fixed the issue rather than waiting for domain.com to figure out the issue (their response time and customer service was extremely frustrating).

3 Likes

Totally agree, I am looking into transferring the domain to some other registrar. But in the meantime, toggling that setting finally exposed that CNAME record, so I deleted it. Now I am waiting for change to propagate.......going on 45 minutes now.

LE doesn't need to wait for TTL expirations - it doesn't rely on any "generic public DNS system".
As long as all the authoritative systems are on the same SOA version and it contains the change you requested, then you should be good to proceed.

3 Likes

Don't disagree, however when I dig or nslookup for txt directly to ns1.domain.com or ns2.domain.com. I still get the CNAME record.

Are those two servers authoritative for your DNS doman/zone?

You could test as much as you like with staging environment.
Just add:
--dry-run

2 Likes

yeah, the SOA record lists those two servers. dry run failed cause of the failed challenges, its still hanging up on that CNAME record. But thanks for the --dry-run tip, was not aware of that!

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.