Using a CNAME or ServerAlias for domain and subdomain aliasing

When managing domains it is desired and often necessasary to make the same web site content available under
multiple domains or between the domain and a subdomain.
For example:
www.apache-serveralias-tips.com and
apache-serveralias-tips.com
or
dns-cname-tips and
www.dns-cname-tips.com
In the DNS zone file both can be acheived using a CNAME or canonical (preferred) name record. (AKA C record)
In an Apache HTTP server this can be achieved using a ServerAlias directive in httpd.conf or other included files
such as vhost.conf used in virtual host configurations (But also needs the corresponding DNS CNAME or A record).
Both methods provide the same result to someone using a browser. They use either name and they are directed
to the same content on the same server in the same document root. So life is good right?
Not necessasarily.
Using just these methods alone will result in content duplication on multiple URLs. This could lead to undesireable
results. You could end up with inbound links to one or the other domain version which may be confusing to your users.
You could also end up hurting your performance in search engines.
In the following sections I will explain CNAMES and ServerAlias, what they do and why additional methods for proper
redirection need to be used.

Example One: CNAME pointing of a subdomain
In DNS a CNAME record provides a method of associating two URLs together where one is the cannonical version
and the other is an alias. Consider this somewhat simplified analysis of the DNS protocol transactions.

In this case the domain mydnstips.com (Defined in the $ORIGIN directive)
Is set to IP Address via the A resource record to 10.1.1.200 (@ being the shortcut for $ORIGIN)
The www alias points via the CNAME resource record to the canonical or preferred URL mydnstips.com.
Let's walk through this. In your browser you enter www.mydnstips.com. The DNS server configured as above
responds informing the requestor that to find the IP adddress another DNS lookup needs to be made to
the URL mydnstips.com. Your browser\Local DNS does so and the DNS server now responds with 10.1.1.200.
As you see, The CNAME does not provide any HTTP response or even redirection. It just tells the requestor
to resubmit the DNS lookup with another URL to get it's answer.
Another server down the line is needed in addition to provide the HTTP redirection code of 301, 302, etc...
In our example the request will need to be handled at the server with the IP address 10.1.1.200 or another
server further down in case of a proxy or load balancer. This might be at your hosting provider or your own server.
Example Two: CNAME pointing the domain alias to a redirection server
Registrars that manage the DNS often provide HTTP servers of their own just for the purpose of redirection.
Consider this simplified analysis using a typical modification to the above example:

In this case the when the www.mydnstips.com is to be found, instead of a lookup for mydnstips.com the the DNS server
will request the browser\Local DNS do a second NS lookup on the URL mydnstips.redirectserver.com.
Now the browser\Local DNS will make a second DNS lookup will be made to resolve that URL's IP address. That IP
address will be sent back to the browser and now a HTTP GET will be made to the Registrars HTTP redirect server.
Finaly a HTTP response will be then sent back to the browser with a 301 (or 302) HTTP code indicating the browser
now perform a third DNS lookup for mydnstips.com.
The DNS server now responds with the 10.1.1.200 and a second GET will be submitted by the browser using that
address and the mydnstips.com hostname.
Wow, 3 DNS Lookups and 2 HTTP GETs, what a vicious circle just to get the hostname resolved!
That is one reason you would prefer the HTTP redirection to be done locally on your hosting server.
It is more efficient and as you see the CNAME by itself does NOT provide proper HTTP redirection but causes
one or two additional DNS lookups.

The Apache ServerAlias directive is typically used with named virtual hosts. The URL(s) specified will then be
considered the same or an alias of the URL defined in the ServerName directive. This does not send a HTTP 301
(or 302) redirect response header but directs the request internally thus it is transparent to a browser or bot.
For example:
<VirtualHost 10.1.2.3:80>
ServerName example.com
ServerAlias www.example.com prodinside.example.com>
[Other directives in this virtual host container]
</VirtualHost>
What happens here - When requests are made to www.example.com or prodinside.example.com they will,
by the server, be directed internally to example.com.
This is useful when you have a server and the requestor on the same private network or subnetwork where
there is a NAT for the server on the firewall to the public ip address. In this case an internal user could point
his browser to prodinside.example.com and reach the server (assuming intranet DNS is set accordingly) via the
internal address.
Using the www.example.com to alias the domain to the canonical domain is indeed a proper way to insure in a virtual
server environment the correct association is made to the desired virtual host.
While this works fine from a browser standpoint, The problem is that requests for www.example.com that originate
from the internet will not be aware that the actual domain hosted is example.com.
This causes a domain canonicalization issue where the real domain version is indeterminate. This is a concern because
search engines typically consider the www and non www versions different web sites and may consider the content
duplicated. Also, you may wind up with inbound links to either site resulting loss of focus to the preferred domain
which will then divide any "credit" for these links given by search engines.
To resolve this issue a proper 301 (or rarely a 302) HTTP redirect needs to be done in addition to the ServerAlias
directive.

What this all means is that the best way to properly associate two different domains versions from a DNS standpoint
is to provide the correct Resource Record in the appropriate DNS Zone and follow through with a proper HTTP
301 or 302 redirection at the final point of URL resolution.
Although a CNAME can be used and works from a browser standpoint, without any HTTP redirect it will result in
duplicate content available at multiple URLs.
In regard to the ServerAlias directive, After the proper DNS configuration is made, HTTP level redirection also
needs to be done to insure the preferred domain canonicalization is realized.
See our comprehensive and popular article for detailed information on how to do HTTP URL redirection on ApacheBack to the top

If you found this page useful, consider linking to it.
Just copy (mark then ctrl-c) and past into your website.
This is how this link will look: URL Alias and redirection

One other thing. If you found this article on CNAME, ServerAlias and redirection useful (or not) and have comments, criticisms, or suggestions please feel free to drop us a note using our Contact form