AutoSSL DCV: CNAME entries from comodoca

[WaldoPepper]

I just reviewed my DNS zones and noticed that there are more than 30 CNAME entries from comodoca. I thought each time AutoSSL ran the DCV through DNS the old CNAME would be deleted.

Is this a misunderstanding, a misconfiguration or just a bug? Is it safe to clear all record types referring to comodoca.com?

TIA. Sam.

 

[cPanelLauren]

The old CNAME should be removed, is there anything in the cPanel error logs indicating anything in relation to this?

 

[PeteS]

Can I get some docs on this record?

I found a domain with 15 (three sets of 5, for cpcalendars, webmail, cpanel, cpcontacts, and webdisk). I checked some other DNS zones and they have none. All domains have autoSSL.

 

[cPRex]

@PeteS - these would all be related to AutoSSL checks, and are safe to remove. They likely look something like this:

_7e3a11259b8306275bef9b1e59b150e1.testing 300 IN CNAME 6be5e17b5ac27acaae876259dfaeb409.7493a8970fa5d32a2644f719c00fd4ec.comodoca.com.

 

[PeteS]

@PeteS - these would all be related to AutoSSL checks, and are safe to remove. They likely look something like this:

_7e3a11259b8306275bef9b1e59b150e1.testing 300 IN CNAME 6be5e17b5ac27acaae876259dfaeb409.7493a8970fa5d32a2644f719c00fd4ec.comodoca.com.

Thank you. Do you know what causes/how to prevent these?

 

[cPRex]

In theory, these should get removed after the SSL verification process is complete. If that isn't happening, can you submit a ticket to our team so we can check your particular system?

 

[PeteS]

In theory, these should get removed after the SSL verification process is complete. If that isn't happening, can you submit a ticket to our team so we can check your particular system?

Thanks.

#grep -l "comodoca.com" /var/named/*.db tells me there are only three other domain zone files with a CNAME like this, and they each have just one, not many. I will monitor for it and reach back here if it is ongoing.

 

[Metro2]

I just found this thread because I've noticed the same thing happening on several cPanel accounts recently as well. I just deleted 8 of these comodoca CNAME entries from an account. When I come across another one I'll likely leave the CNAME records in place and submit a ticket.

 

[thowden]

Hi

The Comodo SSL issues have been occurring for some time.

I am sure (99.9%) it relates to the failing DNS resolution items as discussed (at length) in this thread

AutoSSL Error DCV with Remote Mail Exchanger

Hi All I have had this annoying me for a while now, but this afternoon it all got too much. This is trying to renew AutoSSL - edited to protect the innocent:: 4:10:19 PM AutoSSL’s configured provider is “cPanel (powered by Sectigo)”. This AutoSSL provider does not poll for certificate...

forums.cpanel.net

It can be summarised as " The Cpanel server assumes 100% ownership of the domain, for the purpose of AutoSSL. If you modify the DNS at all then you will break AutoSSL, and find the residue in these failed entries." Can I prove that ? Not really, but given the issues with AutoSSL and non-Cpanel IP DNS locations, it is the most likely cause.

All domains I have sampled on my servers that have all Cpanel default settings (ie standard account) work ok with no Comodo artefacts.

All domains I have sampled with modified DNS entries, for silly things like pointing mail to Office365, will get the CNAME entries that are not cleaned up.

My expectation is that the DNS Zone includes an A record(s) that is(are) not on the localhost, then SSL configuration errors. An example client I am looking at is hosted elsewhere for everything except a website. We have 30 failed Comodo CNAME records in that DNS.

We can "just delete them" which is just "another task" to be monitored and managed. PITA.

 

[PeteS]

I will monitor for it and reach back here if it is ongoing.

I am sure (99.9%) it relates to the failing DNS resolution items as discussed (at length) in this thread

AutoSSL Error DCV with Remote Mail Exchanger

Hi All I have had this annoying me for a while now, but this afternoon it all got too much. This is trying to renew AutoSSL - edited to protect the innocent:: 4:10:19 PM AutoSSL’s configured provider is “cPanel (powered by Sectigo)”. This AutoSSL provider does not poll for certificate...

forums.cpanel.net

@cPRex It would be interesting to know if @thowden is correct. Can you confirm?

Regardless... they are still occurring for me.

Can we get a fix so this doesn't become just one more annoying task? (If it IS the above, light more fire under those dealing with the options you said may be coming in the other thread about cert renewal issues.

 

[cPRex]

If there are DNS entires that don't resolve, that is defintely going to be an issue. You should remove any lingering comodoca entries from the DNS zones to ensure this doesn't happen.

As far as a "fix" - are you looking for a tool that strips those automagically?

 

[thowden]

Hi

Point of clarification re @cPRex "If there are DNS entires that don't resolve "

My point was DNS Entries that do not resolve "to the localhost" i.e. they do resolve, but to somewhere other than the localhost.

Rather than stripping automatically, perhaps not having them created in the first place would be a better goal.

 

[cPRex]

I'm not sure I understand - can you provide an example of the DNS entries that shouldn't be created? We don't just create random DNS entries for fun, so there must be some logic as to why they exist.

 

[PeteS]

Hi

Point of clarification re @cPRex "If there are DNS entires that don't resolve "

My point was DNS Entries that do not resolve "to the localhost" i.e. they do resolve, but to somewhere other than the localhost.

Rather than stripping automatically, perhaps not having them created in the first place would be a better goal.

In my case, it's not related to remote mail services for the domain (as referenced in the other thread you linked). It appears to just be temporary records that AutoSSL is no removing, as I understand it.

 

[PeteS]

If there are DNS entires that don't resolve, that is defintely going to be an issue. You should remove any lingering comodoca entries from the DNS zones to ensure this doesn't happen.

As far as a "fix" - are you looking for a tool that strips those automagically?

The issue for me is not related to unresolved DNS entries. When I last posted here about this I found several domains with them, but today I only see two. Is it possible that AutoSSL is cleaning them later on subsequent runs? That's what appears to have happened - I didn't remove any since my last post here. Also, these two are only showing in the domain on one server (but not any others that are in the DNS cluster), so maybe it's a latent syncing issue?

I'm going to manually clean those two today and see what happens next...

Re: "automagially" (I love that "word" and use it often)
I meant a fix for AutoSSL not cleaning up after itself (if that's the case). But a cleanup script isn't a bad idea, as a tool for those with potentially 1000s of these records to remove.

 

[thowden]

Hi

Sorry @cPRex for the confusion.

I'm not sure I understand - can you provide an example of the DNS entries that shouldn't be created? We don't just create random DNS entries for fun, so there must be some logic as to why they exist.

My poor selection of words. I was referring to the orphaned comodoca.com entries. Rather than 'not created' I should have said 'not left behind in the event of an error'. Automatically removing the orphaned records in some way is preferable to having them bloating the DNS files.

 

[cPRex]

AutoSSL *should* be cleaning up the DNS files. I may be misremembering, but I feel like there was a period when that didn't happen, causing the older comodoca ones to linger longer than they should have.

Thanks for that clarification, @thowden - I completely agree.

Are you both running cPanel version 106 and still seeing the older entries in the zones?

 

[thowden]

All my servers are latest but any remaining comodoca entries are artefacts that I have failed to clean up.

I swapped to Lets Encrypt on my production servers to resolve all the issues I was having.

 

[cPRex]

Let's Encrypt is the way to go, for sure.

If you have a situation where you think https://support.cpanel.net/hc/en-us...are-does-not-resolve-to-any-IP-AutoSSL-errors doesn't apply, could you make a ticket so we could check that out?

 

[PeteS]

AutoSSL *should* be cleaning up the DNS files. I may be misremembering, but I feel like there was a period when that didn't happen, causing the older comodoca ones to linger longer than they should have.
....

Are you both running cPanel version 106 and still seeing the older entries in the zones?

Sorry, my memory was flawed... In checking back, I DID remove the comodoca records, and since then there are no new ones in WHM. So I *think* that has stopped happening. (v106)

--what follows is a little off-topic, but it's related and I add it here for any quick response you might have--

The two I records I mentioned above are odd... they ARE in the named/*.db file (on just one server in the DNS cluster (the others are fine), but they don't show in WHM DNS Zone Manager. They are both for subdomains that no longer exist (and I assume that's why WHM ignores them?). Am I correct that I can remove them from the one .db file, and don't have to advance the date, nor resync the cluster?

Also, two other things:
1- I found a CAA record for one domain on the same server. It's for the account's main domain.
Flags: 0
Tag: issue
Value: comodoca.com
I question it since no other .db file on any server contain such a record. Why is it only in one place? Should it be removed?
2- I found a TXT record in some accounts that I wonder about:
_cpanel-dcv-test-record.example.com. 300 TXT _cpanel-dcv-test-record=X8CyKI1eQ5EeUzeegSUNr...
It's in about 1/2 of the accounts in all servers in the DNS cluster. It soesn't seem to be only new or old accounts. Any thoughts on this one?

I suspect the one server is sometimes not syncing for some reason, and sometimes one or more servers in the cluster report "Could not communicate with remote API server." temporarily for one or both the DNS servers. AFAIK or can tell they are all configured correctly, and DNSing is fine. I'm going to go back through them and douvble check everything.