TL;DR - I'd suggest doing away with the current ServerAlias setup for domain aliases in favor of creating their own VirtualHost containers.
I kind of butted heads with cPanel on this - although I didn't really press the matter that much, because I gave up hope of them ever listening. It has to do with utilizing ServerAlias's for parked or alias'd domains and how that relates to the increase SSL and Let's Encrypt movement.
This pertains to how DirectAdmin (and cPanel) so parked/alias/pointer domains. (In the old Alabanza era, these were called pointers. cPanel initially used the term parked domain, but have lately switched to Alias. Alabanza never had addon domains. And cPanel initially did not either)
I see where DirectAdmin differentiates between a domain alias (parked domain) and a pointer (what I would refer to as a redirect - since it just 301's to the source domain). DirectAdmin also has just "Domains" which would appear to be mostly equivalent to cPanel's addon domains. The basic difference between these 3 are as follows:
A domain alias essentially just adds that domain name to the ServerAlias portion of Apache (I would assume the same is true for any web server you use - but I can only speak to Apache right now), i.e.:
A pointer (or 301 redirect) create a new VirtualHost container, that just redirects to the source domain
A Domain - or addon domain, creates a new VirtualHost container with a new DocumentRoot
This is all fine and good until you start issuing secure certificates every where. It becomes much, much more difficult to keep certificates all lined up when you deal with Apache ServerAlias's like this. This set up worked fine a few years ago until SSL and Let's Encrypt started becoming common place every where. Consider the scenario:
What if sourcedomain1.com purchases a secure certificate? Now aliasdomain1.com cannot be accessed securely, because as an Alias, it gets grouped in with sourcedomain1.com. The secure certificate is valid only for sourcedomain1.com and www.sourcedomain1.com. Now going to aliasdomain1.com securely will create a CN mismatch error.
I would propose that every domain added to an account should get it's own VirtualHost container. So for aliasdomain1.com the entire setup would look like:
This way a purchased secure certificate can still be made for sourecdomain1.com and a Let's Encrypt certificate can still be installed for aliasdomain1.com.
Or if it's easier, make aliasdomain1.com's VirtualHost container look like a regular addon domain:
And create a symlink for /home/%user%/domains/aliasdomain1.com -> /home/%user%/domains/sourcedomain1.com
Another area where this can be problematic - if an account has a setup with 10 domain aliases... then all 10 of those domain aliases have to be included on the Let's Encrypt or other SSL certificate in order for all of the domain names to function properly under SSL. What happens if one of those domain names expires, isn't renewed, and the certificate comes up for renewal? The certificate has to be renewed without that domain name. What happens if that domain name is then renewed?
If the individual decides to create an 11th or 12th domain alias, then all of the domain names again have to be revalidated and a new secure certificate has to be issued for all of the domain names.
By separating all of these into their own VirtualHost... each domain name can be handled independently of the others. If the Let's Encrypt certificate for sourcedomain1.com still has 45 days remaining on it and the user wants to park aliasdomain11.com on top of sourcedomain1.com... then a new Let's Encrypt certificate can be issued for aliasdomain11.com that is good for 90 days while sourcedomain1.com's certificate still has just 45 days left on it.
The ServerAlias directive just was not a directive that was written to envision a time when secure certificates would be free and the demand so prevalent. I don't have an issue with the www subdomain being included in the ServerAlias like this - since those two hostnames are commonly tied together. But adding "parked" or "alias" domains using this method just seems like a recipe for disaster that can be better avoided by utilizing multiple VirtualHost containers.
Or is there a specific reason why you would want to minimize the number of VirtualHost entries? I'm sure there are memory savings with using ServerAlias's instead of VirtualHost containers - but does that really factor in here? Might be more common if you only have 640K of memory to work with, but most servers do not run into memory issues.
At any rate, I thought it was worthy of a discussion.
For me personally, I will probably add CMD_DOMAIN_POINTER to the never_commands to prevent end-users from being able to create Aliases in this manner. They will still be able to create Domains (addon domains) and if they want one of those domains to show the same content as a specific source domain - I'll just symlink the addon domain's DocumentRoot to the source domain's DocumentRoot. But I'm open to listening to discussion on this.
I kind of butted heads with cPanel on this - although I didn't really press the matter that much, because I gave up hope of them ever listening. It has to do with utilizing ServerAlias's for parked or alias'd domains and how that relates to the increase SSL and Let's Encrypt movement.
This pertains to how DirectAdmin (and cPanel) so parked/alias/pointer domains. (In the old Alabanza era, these were called pointers. cPanel initially used the term parked domain, but have lately switched to Alias. Alabanza never had addon domains. And cPanel initially did not either)
I see where DirectAdmin differentiates between a domain alias (parked domain) and a pointer (what I would refer to as a redirect - since it just 301's to the source domain). DirectAdmin also has just "Domains" which would appear to be mostly equivalent to cPanel's addon domains. The basic difference between these 3 are as follows:
A domain alias essentially just adds that domain name to the ServerAlias portion of Apache (I would assume the same is true for any web server you use - but I can only speak to Apache right now), i.e.:
Code:
<VirtualHost XX.XX.XX.XX:80>
ServerName sourecdomain1.com
ServerAlias www.sourecdomain1.com sourecdomain1.com aliasdomain1.com www.aliasdomain1.com
DocumentRoot /home/%user%/domains/sourcedomain1.com/public_html
...
</VirtualHost>A pointer (or 301 redirect) create a new VirtualHost container, that just redirects to the source domain
Code:
<VirtualHost XX.XX.XX.XX:80>
ServerName pointer1.com
ServerAlias www.pointer1.com
Redirect 301 / http://www.sourcedomain1.com/
</VirtualHost>A Domain - or addon domain, creates a new VirtualHost container with a new DocumentRoot
Code:
<VirtualHost XX.XX.XX.XX:80>
ServerName domain2.com
ServerAlias www.domain2.com domain2.com
DocumentRoot /home/%user%/domains/domain2.com/public_html
...
</VirtualHost>This is all fine and good until you start issuing secure certificates every where. It becomes much, much more difficult to keep certificates all lined up when you deal with Apache ServerAlias's like this. This set up worked fine a few years ago until SSL and Let's Encrypt started becoming common place every where. Consider the scenario:
What if sourcedomain1.com purchases a secure certificate? Now aliasdomain1.com cannot be accessed securely, because as an Alias, it gets grouped in with sourcedomain1.com. The secure certificate is valid only for sourcedomain1.com and www.sourcedomain1.com. Now going to aliasdomain1.com securely will create a CN mismatch error.
I would propose that every domain added to an account should get it's own VirtualHost container. So for aliasdomain1.com the entire setup would look like:
Code:
<VirtualHost XX.XX.XX.XX:80>
ServerName sourecdomain1.com
ServerAlias www.sourecdomain1.com sourecdomain1.com
DocumentRoot /home/%user%/domains/sourcedomain1.com/public_html
...
</VirtualHost>
<VirtualHost XX.XX.XX.XX:80>
ServerName aliasdomain1.com
ServerAlias www.aliasdomain1.com aliasdomain1.com
DocumentRoot /home/%user%/domains/sourcedomain1.com/public_html
...
</VirtualHost>This way a purchased secure certificate can still be made for sourecdomain1.com and a Let's Encrypt certificate can still be installed for aliasdomain1.com.
Or if it's easier, make aliasdomain1.com's VirtualHost container look like a regular addon domain:
Code:
<VirtualHost XX.XX.XX.XX:80>
ServerName aliasdomain1.com
ServerAlias aliasdomain1.com www.aliasdomain1.com
DocumentRoot /home/%user%/domains/aliasdomain1.com/public_html
...
</VirtualHost>And create a symlink for /home/%user%/domains/aliasdomain1.com -> /home/%user%/domains/sourcedomain1.com
Another area where this can be problematic - if an account has a setup with 10 domain aliases... then all 10 of those domain aliases have to be included on the Let's Encrypt or other SSL certificate in order for all of the domain names to function properly under SSL. What happens if one of those domain names expires, isn't renewed, and the certificate comes up for renewal? The certificate has to be renewed without that domain name. What happens if that domain name is then renewed?
If the individual decides to create an 11th or 12th domain alias, then all of the domain names again have to be revalidated and a new secure certificate has to be issued for all of the domain names.
By separating all of these into their own VirtualHost... each domain name can be handled independently of the others. If the Let's Encrypt certificate for sourcedomain1.com still has 45 days remaining on it and the user wants to park aliasdomain11.com on top of sourcedomain1.com... then a new Let's Encrypt certificate can be issued for aliasdomain11.com that is good for 90 days while sourcedomain1.com's certificate still has just 45 days left on it.
The ServerAlias directive just was not a directive that was written to envision a time when secure certificates would be free and the demand so prevalent. I don't have an issue with the www subdomain being included in the ServerAlias like this - since those two hostnames are commonly tied together. But adding "parked" or "alias" domains using this method just seems like a recipe for disaster that can be better avoided by utilizing multiple VirtualHost containers.
Or is there a specific reason why you would want to minimize the number of VirtualHost entries? I'm sure there are memory savings with using ServerAlias's instead of VirtualHost containers - but does that really factor in here? Might be more common if you only have 640K of memory to work with, but most servers do not run into memory issues.
At any rate, I thought it was worthy of a discussion.
For me personally, I will probably add CMD_DOMAIN_POINTER to the never_commands to prevent end-users from being able to create Aliases in this manner. They will still be able to create Domains (addon domains) and if they want one of those domains to show the same content as a specific source domain - I'll just symlink the addon domain's DocumentRoot to the source domain's DocumentRoot. But I'm open to listening to discussion on this.
