So this one is hairy, but please bear with me.

The way SSL works right now is that it assigns IP to certificates. That's a good idea: it takes from the pool of IPs in the server and allocates. It's kind of crude in the way it does it (or maybe I just don't understand how tracking is done). (It would also be good to allow for manually assigning IPs, but that's beside the point here.)

The problem is the way DNS works right now is that it blindly creates as many A records as necessary to point to all those IPs. So the A record created for www.example.com will point to ALL the IPs in that list (round-robin). This may work for non-ssl (because of NameVirtualHost *:80) but not for SSL. So when we create that record (install.provision.inc, create_host()) we need to check if we're dealing with a funky SSL server or not. If we are, we need to create an A record to the *first* IP *or* the IP of the site.

Maybe that's already the way it works, but seeing SSL got me worried here. Needs testing and fixing before release.

Comments

adrian’s picture

this should work fine during install / verify, because the site is bootstrapped and we can determine the IP address to use. (hind: the site_ip_addresses is very very very fscking important).

the zone editor command has no such luck because it's not actually being run on a site, but instead being run 'in the aether' so to speak.
the zone editor has no http service even available to tell it which ip addresses it is using.

anarcat’s picture

Status: Active » Postponed (maintainer needs more info)

So this basically "should work" and just needs testing, let's not block here either.

anarcat’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

This indeed seems to work as designed, according to the (inactive) zonefiles generated here.