Closed (fixed)
Project:
Provision
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
30 Jan 2009 at 18:04 UTC
Updated:
3 Jan 2014 at 00:07 UTC
Jump to comment: Most recent
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.
Comments
Comment #1
MichaelCole commentedHi, 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 :-)
Comment #2
acDisabled site should work as it does now, domain should resolve and then be redirected to aegir page
Deleted site should delete vhost file IMO
Comment #3
anarcat commentedAgreed.
Comment #4
anarcat commentedComment #5
anarcat commentedThe 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
Comment #7
Anonymous (not verified) commentedComment #8
anarcat commentedNote that the "allowed list of TLDs" should probably be dynamic and compared against lists like http://data.iana.org/TLD/tlds-alpha-by-domain.txt. libidn can parse those files properly http://www.gnu.org/software/libidn/manual/html_node/TLD-Functions.html There's an IDN extension for PHP: http://ca.php.net/manual/en/intro.intl.php
We should allow the admin to override those settings however.
http://whois.iana.org/ (and directly through whois.iana.org on port 43) can tell you where to find the whois server for a TLD, so that we can tell if we're the registered NS for a domain. See also http://en.wikipedia.org/wiki/WHOIS#Determining_the_WHOIS_server_for_a_do...
Comment #9
adrian commentedjust so you know. you can now use drush_get_option('site_ip_addresses', array(), 'site') to fetch the ip addresses associated with the site.
It's indexed by server alias name, so you can see which server gave the site which IP.
Comment #10
adrian commentedit's working correctly in dev-dns now for 'install', 'delete' and 'verify'
verify is now called after every clone/restore/migrate command, so i think this should handle all the cases.
Comment #11
anarcat commentedI'm going to close this now as the DNS branch has all we need for now. We are still missing some pieces for migrate and TLD detection, but that can be done later. I just want to have the pleasure to close this old issue now: we now create and delete records properly when creating and deleting sites. :)