manage DNS records properly when creating/restoring/verifying/disabling/deleting sites
anarcat - January 30, 2009 - 18:04
| Project: | Provision |
| Version: | HEAD |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | aegir-0.4, dns |
Jump to:
Description
I disabled and deleted test.example3.com and the DNS record was not removed.
I think it should be removed or at least commented out when disabling the site.
#1
Hi, for my application of this module, I wouldn't want the DNS deleted when disabling the site. Especially if it was a billing problem.
I'd like the DNS to remain active, but with a note saying "Please pay your bill."
For me, it would be appropriate to delete the DNS record when deleting the site.
Better to have an extra unused DNS record than to few :-)
#2
Disabled site should work as it does now, domain should resolve and then be redirected to aegir page
Deleted site should delete vhost file IMO
#3
Agreed.
#4
#5
The DNS code was completely reshuffled, so this is far from working now. We are focused on getting zonefile management right, without site interference, at this point, so the hooks are just not present anymore, or broken.
The general way this is going to work is this. The frontend will first check if the site can be created, based on ownership of the zones (or create a zonefile if it doesn't exist), this is part of #366415: zones should be associated with dns servers and clients. The dns backend will have task.provision.inc command files that will hook into the various install/delete/etc tasks. It will add the proper records in the zonefiles and, if necessary, bump the serial number and so on. That serial and the modified records will be returned to the frontend, which will then fire hooks to update the database with the relevant information.
Here's what should happen in every task case:
Install: a A record is created in the zonefile. Heuristics should define what the zone should actually be. Right now, there's some code to guess based on the "reserved TLDs" that define what the TLDs are. If the site created is foo.TLD, for example, then the zonefile is foo.TLD. If it's bar.foo.TLD, the zonefile is still foo.TLD. Basically, the algorithm should be something like this. Say the site is named "foo.bar.quux":
1. does the zone "foo.bar.quux" already exists?
2. if yes:
2.1. is the zone part of the "reserved TLDs"?
2.1.1. if yes, edit the zone file with the previous part added back (if there's no part to add back, refuse the domain)
2.1.2. if not, edit that zonefile
3. if not, strip the first element from the zone and return to step 1
A few examples:
* foo.example.com would mean example.com, because .com is a 'reserved TLD' and foo.example.com is not a known zonefile
* example.co.uk would mean example.co.uk because .co.uk is a 'reserved TLD'
* bar.foo.example.com would mean example.com, because .com is a 'reserved TLD' and foo.example.com is not a known zonefile
* bar.thing.com would mean bar.thing.com because the zonefile bar.thing.com has been created before (say)
Disable: do not touch the DNS records.
Delete: remove the record. We need to figure out when to completely delete the zonefile, maybe if it's the last record apart from NS?
Backup: shouldn't touch DNS.
Verify: recreate the DNS record, see install
Restore: see Verify
Migrate: change the DNS pointer if the server changes
Clone: same as install, basically