DNS zone records are left when a guest system is deleted

After deleting a guest system if you go to Webmin > Servers > BIND DNS Server and click on master zone where guest records are added it is still there.

Status: 
Active

Comments

Do you see any error message about DNS updates when you deleted to VM?

No any error messages, however DNS records are still left intact.

It's odd that this only happens during VM deletion - if you create a new test VM, does a record for it get added to the DNS domain?

Yes, it does. I tested this on a clean CentOS 7.x based Cloudmin system. I created my first guest system and its record had been successfully added to master DNS zone. However when I deleted the guest system its DNS record was still there.

Is there anything unusual about the DNS zone? Like for example is it a sub-domain of another zone, or an unusual name like internal ?

Nothing unusual except that it is a newly created master zone. Usually Cloudmin suggests to dd all DNS records for the new guest systems to default zone called something like cloudmin.something.tld, so I usually delete this default master zone and create a new one 'hostname.host.tld' and configure Cloudmin to add DNS records there. Anyway, Cloudmin should be able to remove DNS records for guest system regardless of which master zone is used, shouldn't it?

Unfortunately not - Cloudmin doesn't look in all the DNS zones for the VM's record, only the cloudmin.host.tld zone.

Unfortunately not - Cloudmin doesn't look in all the DNS zones for the VM's record, only the cloudmin.host.tld zone.

I see now. But will this be fixed as it sounds quite logical for Cloudmin users to be able to properly use created by their own master zones?

Are you creating a separate DNS zone for each VM, or just using a single zone that is different from the one Cloudmin creates by default?

Single new master zone with real hostname of the system.

Ok .. and I assume you selected this master zone on the KVM Hosts Systems -> your-host page?

Ok .. and I assume you selected this master zone on the KVM Hosts Systems -> your-host page?

Of course I did, otherwise DNS entries wouldn't be written there in the first place.

I'm not sure what could be going on here, sorry - on all our test systems, DNS record creation and deletion works fine.

I have a similar problem.

I'm upgrading one complete Virtualmin server to a brand new Virtualmin server running on CentOS 7. I thought I would do a trial run, so I used Virtualmin > Server Configuration >Transfer Virtual Server and the VS transferred successfully. As I wasn't actually ready to make the transfer live, I deleted the newly created VS using Virtualmin > Disable and Delete > Delete Server and the VS apparently deleted successfully. So, again by way of test, I went back to the Virtualmin source server and tried Transfer Server again. The system went through all its steps happily until the very end where it said that the transfer failed because the DNS records already existed. The exact wording is:

'Checking for errors in backup .. .. no errors found Starting restore.. Extracting backup archive files .. .. done Re-creating virtual server xyz.com .. .. a clash was detected : The DNS domain xyz.com is already hosted by your DNS server Restore failed! '

Oh well I thought. That's easy. I'll just repeat the exercise but click on the Overwrite radio button in the transfer setup page and that should sort the problem out, however the same error message appears.

This is what I have tried so far:

  1. Creating the domain's VS manually on the destination and then deleting it in the hope that will delete the DNS record at the same time.

  2. Setting the 'Overwrite' radio button on the source server before initiating the transfer.

  3. Rebooting both source and destination servers

  4. Repeated attempts at the Transfer - one in about four report that they have completed successfully on the source server, but then when I go to the destination, the VS is simply not listed.

We're running v6.01 gpl on the destination and v6.01 gpl-3 on the source in case it makes any difference and both are fully patched up to date. There is nothing unusual about the domain itself - it is not a subdomain and it has no subdomains either.

All input most welcome!