|AITech Solutions Home Site Map Services Contact Us Website & Servers|
|Article Topic: Aliasing and redirection,|
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 Apache Back 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