Archive note: originally published November 12, 2007, and kept for the record rather than revised. Two claims below need correcting. An alias does not improve security, and it does not provide high availability by itself. It is a stable client-facing name: a load balancer, cluster, or DNS failover system still has to route traffic to a healthy resource. Treat authentication, network policy, and least privilege as the security controls, and the alias as the thing that keeps a migration or failover from becoming a client rollout.
What are they?
An alias is simply a placeholder name for a specific service that points to the actual resource on the back-end. The end-user or client will see only the alias, never the back-end. The most common form of this is used heavily in DNS where a browser is requesting services from a web server using www.example.com but the actual server itself is rarely called www.
Why use aliases?
The purpose of using aliases for services is three-fold.
- Portability. If you tie your users or clients to a machine name, that machine name has to remain viable at all times and your services are tied to that inextricably. If the server goes down, there’s no easy way to recover without either getting the server back online or changing the name of another server to the original server name. Using aliases prevents being tied to a specific machine. If a server goes down, the appropriate alias is adjusted (either manually or preferably automatically) and the services are redirected to the live resource.
- High-Availability. The use of aliases allows multiple resources to serve a single service - load balancing and clustering, for instance. In this scenario, if one resource goes offline, the service remains viable because one or more other machines are tied to the alias and are providing services.
- Security. The use of aliases provides a security shield by way of hiding the actual physical server(s) on the back-end.
How do you use them?
Every service that you want to use aliases on are a bit different, but the extra work getting them setup is worth the trouble.
For websites, web services, sql, mail, ftp and many others, the procedure is relatively painless. In its simplest form, assign a DNS A-record (e.g. www) to an IP pointing to the server providing the service. Setup the server to listen on that address for that alias. Load balancing and clustering is beyond the scope of this, but is easily doable.
For file servers, the easiest way to do this is using Distributed File System (DFS) over Active Directory (AD). Again, in its simplest form, a share is created in DFS that point to one or more back-end file servers.
2026 addendum. Nearly twenty years on, the indirection is still doing the same job and still hiding the same failures. Point three has a cost I ran into in 2026: when a reverse proxy in front of a container kept accepting connections for a backend that had died, the shield that hides the back-end also hid the outage, and the affected applications looked slow instead of broken.