Currently, if the domain has a wildcard DNS configured and pointing to the server's IP, any not defined in Aegir subdomain will be served by default vhost, while it could be useful to redirect it to the main domain, until it is defined/used on any site.

This may cause issues when there is already aliases redirect enabled in the front-end, so it may require also some tweaks in the Hostmaster and not only in the vhost templates in Provision.

Comments

anarcat’s picture

anarcat CreditAttribution: anarcat commented

The way this works in Apache right now is that there's a default Vhost that gives a 404:


ServerName default
Redirect 404 /

It is the default only because it is included before the others. I think nginx should follow a similar policy.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

In Nginx version we use by default the standard Nginx directory with the index file "It works!" as a root for the default vhost, so it is basically the same (almost) result as in the Apache version. However, we received some requests recently to add support for wildcard subdomain vhosts and it is perfectly doable in Nginx.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Title: Add support for wildcard subdomains entry in the Nginx vhosts » Wildcard subdomain support

Okay, then I misinterpreted what we meant here.

I understand now that you mean having a domain or alias like *.example.com be a wildcard for the domain, is that correct?

There are some twists to this, most importantly the symlinks in sites/, but it's perfectly doable and something I would support.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Almost. The symlinks in the sites directory will not be an issue, since the idea is to *redirect* all not defined subdomains to the main domain and not to add the ability to create a SEO-spam-like wildcard in the vhosts. So we probably need to add an extra server block in the config template, so it will work as a catch-all for *.example.com just before the standard server block, with configuration as usual. I will submit some patches for review, when I will have it tested enough.

Robin Millette’s picture

Robin Millette CreditAttribution: Robin Millette commented

In my case, I am using the subdomain module have 1000 subdomains, one for every group on the site. Currently, I have a huge list of site aliases, all leading to different groups - much like different sites as far as the content and themes go anyway. Having the wildcard redirect them all to the main site would defeat the purpose, at least for my case.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

@Robin Millette

The wildcard should never conflict with any defined aliases and you can't use any alias if it is not added in Aegir, no Drupal module will help you with this, so I don't see how is it related. Am I missing something maybe?

Robin Millette’s picture

Robin Millette CreditAttribution: Robin Millette commented

I have a main site at example.com using organic groups. http://drupal.org/project/subdomain lets you map subdomains to groups. Given the groups "A" and "B", subdomains a.example.com and b.example.com are also accessible, leading to their group content.

With 1000 subdomains, that's a lot of aliases to create. I would like to add *.example.com (in the aegir alias list or with a checkmark) and NOT have those subdomains all (http) redirected to the main site at example.com but each living at its own subdomain.

My problem is not www.example.com vs example.com - where an http redirect is always a good idea.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Then we need it as an option - wildcard with redirect and wildcard without redirect. There is already related issue in the hostmaster queue, so it could share some code probably, anyway - #815190: Allow for both redirects and aliases

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Active » Needs review

Note that there is a start in #1859478: Don't allow site domain names to be IP addresses, with a fix to the _hosting_valid_fqdn regex - is there anything else necessary here?

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Version: 6.x-1.1 » 6.x-2.x-dev

This should be in 2.x, not 1.x.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Yep, we have added this wildcard support in Nginx and it works as expected by @Robin Millette - you just enter *.example.com instead of 1000 separate aliases. Not sure if this kind of wildcard is supported in Apache - if yes, then it is easy.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Cool, nice to hear. Was changing that regex the only thing necessary for this support to work in nginx?

From what I understand, Apache also supports wildcard vhosts the same way, so this should be fairly transparent.

I do feel we will need to check for host ownership - for example what happens if clientA takes the example.com domain and clientB takes the *.example.com - who wins www.example.com? How do you handle this now?

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Needs review » Needs work

I meant to mark this as needs work, we still need a patch.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Yes, it was just a matter of changing the regex to allow *. at the beginning.

If there is no vhost with www.example.com alias, then owner of *.example.com wins it, obviously, but if you have enabled by default "Generate www.domain.com alias automatically" and "Generate domain.com alias automatically" at admin/hosting/aliases, so both www and non-www versions are always created, then owner of *.example.com can't take over www.example.com, because wildcards are processed last - see http://wiki.nginx.org/NginxHttpCoreModule#server_name

We handle this by always enabling automatic aliases by default.

However, hmm.. now I think we should allow this only in aliases, and not as a main site name, because even if it doesn't work (site install fails anyway) it shouldn't be allowed. This makes things a bit more complicated, so not sure if this would be worth the effort.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

So I guess my question is: what policy do we want in the frontend by default? Should we let clientA steal www.example.com or (say) secure.example.com from clientB that has *.example.com?

Maybe that's already a problem - if clientB has just example.com, probably that clientA can already steal foo.example.com... Maybe I'm stumbling upon a problem that's already present...

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Sure, that problem already exists as we don't control it at all, so anyone on the same instance can use not-yet-created sub-domain alias in someone's else domain.

We would need to introduce something like strict *.domain ownership associated with client probably, but since domains can have several sub-levels and various extensions with various levels, it can be tricky, because, well, what if someone will add an alias like *.com.au? In fact, we already allow also too broad names like com.au, so it is already a problem, and adding wildcards may open a Pandora's box.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Assigned: Unassigned » anarcat

I'm going to work on this now. From what I understood, I believe the only thing that is necessary is to fix the regular expressions, so I will do that. It seems, however, that we can only have wildcards in aliases and not in the primary domain name, at least I had issues with doing that. So I will create two regex functions since, anyways, the fqdn check is used for servers and we don't want wildcards there.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Needs work » Fixed

pushed a fix to the frontend in 2.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.