You cannot remove the domain because it is still configured for HTTP use error

[martin MHC]

I have two servers, one runs on a CentOS 6.1 system, this is an older server and I am migrating accounts across to a newer server on CentOS 7.6 .

Up to today, my process has been:

1) Transfer account;
2) Update DNS wth name registers
3) Set a email forward from the account email to a server email address
**24 hours later
3) suspend the old account
**24 hours later
4) Delete the old server DNS records. Account remains.
**12 hours later
5) Email forward all redirected emails from the server email address to the accont email address, now on the new server.

BUT -- I am now told today by the DNS system on WHM:

You cannot remove the domain “<domain.co.uk>” because it is still configured for HTTP use on the “<domain>” account. In order to remove the domain, perform any of the following actions:

• Change the domain with the “Modify an Account” interface.
• Remove the the account “<domain>” with the “Terminate Accounts” interface.

This is new and causes me some issues:

1) I can not give a new FQDN for the account. The account remains as a short term recent backup only. The data should remain accessible in the account but not online.

2) I do not yet want to terminate the account until I have confirmation from the client that the transfer has been problem free.


I have been transferring ~50 accounts without issue and now all of a sudden (with the 78.0.21 update it appears) I am unable to delete the DNS.

Explanation as to why I need to delete the DNS:

So that the server admin email can forward the caught emails successfully off-server to the updated DNS pointing to the new server, so that clients can recieve emails caugh during the DNS update propergation.

How do I resume this process?

 

[martin MHC]

CPanel made the change in cPanel 78 so DNS zones can't be removed that are linked to active domains. CPanel made this change because the cPanel system expects the DNS zone to exist, even if it's not being used.

One method to work around this problem with the emails would be to change the mail routing inside the cPanel >> Email >> Email Routing interface so the mail Routing is set to "Remote Mail Exchanger" so it is forced to be sent to a remote destination instead of trying to delivery it locally for this account.

 

[cPanelMichael]

One method to work around this problem with the emails would be to change the mail routing inside the cPanel >> Email >> Email Routing interface so the mail Routing is set to "Remote Mail Exchanger" so it is forced to be sent to a remote destination instead of trying to delivery it locally for this account.

Hi @martin MHC,

Can you verify if this workaround addresses the issue in your first post?

Thank you.

 

[martin MHC]

Hi @cPanelMichael - Yes, this work around appeared to work correctly. Thanks.

 

[microeuropa]

Hi Michael,

This change on cPanel is problematic, consider this:

We have clients that control their own DNS and only use our servers as hosting for the website.
They personalize the MX or whatever record they need in their own DNS servers, what we used to do is
to delete the zone from our server and they only pointed the domain to the server IP.

Without this option, the zone always exist in our DNS clusters, so, even if we remove all the records
from the zone, it will always be handled by our name server instead of the remote one... this is causing
lot of malfunctions in the system.

Cheers,
Hugo Ferreira

 

[cPanelMichael]

Without this option, the zone always exist in our DNS clusters, so, even if we remove all the records
from the zone, it will always be handled by our name server instead of the remote one... this is causing
lot of malfunctions in the system.

Hello Hugo,

The DNS zones in the /var/named/ directory are required, even when the local name server is disabled or isn't utilized for a domain. The zones are needed for certain features (e.g. Transfer Tool, SPF or DKIM record creation). I recommend adding feedback to the following feature request if you'd like to see a change to the existing functionality:

Auto-detection and deletion or suspension of non-authoritative DNS zone files

Until such a feature is implemented, can you share the specific issues this is leading to so we can help you with workarounds? Note the workaround here is applicable for email routing.

Thank you.

 

[microeuropa]

Hello @cPanelMichael,

Regarding this:

Hello Hugo,
Until such a feature is implemented, can you share the specific issues this is leading to so we can help you with workarounds? Note the workaround here is applicable for email routing.

The main problem is the DNS zone is created in our cluster, so everytime we try to deliver mail to this domain it fails.
This happens even with E-mail routing set to remote. The issue is that the other servers in the cluster resolve to the one that has
the website and has an invalid configuration. The workaround was to see what were the records defined in the remote DNS server
and replicate manually in the server that has the website hosted. Of course this is a recipe to disaster, since if in the remote server something changes we will break the workaround.

Cheers,
Hugo Ferreira

 

[cPanelMichael]

Hello Hugo,

Could you open a support ticket so we can take a closer look and see your specific scenario happening on a live server? You can post the ticket number here once it's opened and we'll update this thread with it's outcome.

Thank you.

 

[michellered]

I read the thread and it helps me a lot! Thanks for the very accommodating support here.