When working with DNS CNAME records and web hosting configurations, many developers encounter confusion about how the original URL appears in HTTP requests. Let's examine this scenario with concrete examples.

Consider these DNS records:

abc.example.com.    IN A    10.0.0.1
xyz.example.com.    IN CNAME abc.example.com.

When a client requests http://xyz.example.com:

1. The DNS resolver follows the CNAME chain to the A record
2. The TCP connection is established to 10.0.0.1
3. The HTTP request headers remain unchanged, including:

GET / HTTP/1.1
Host: xyz.example.com
...

Your virtual host must specifically listen for xyz.example.com:

<VirtualHost *:80>
    ServerName xyz.example.com
    ServerAlias abc.example.com
    DocumentRoot /var/www/xyz
    ...
</VirtualHost>

You can verify the behavior using:

curl -v http://xyz.example.com

This will show the request headers including the original Host header value.

• Forgetting to configure SSL certificates for both names if using HTTPS
• Assuming the server sees the resolved name (abc.example.com) instead of the original
• Missing ServerAlias directives when using wildcard certificates

This pattern is commonly used for:

• CDN configurations (cdn.example.com → vendor.cdnprovider.com)
• Regional domains (us.example.com → global.example.com)
• Service migration (old.example.com → new.example.com)

When you configure a CNAME record like xyz.example.com CNAME abc.example.com, the DNS resolution process works like this:

1. Client queries DNS for xyz.example.com
2. DNS responds with the CNAME record pointing to abc.example.com
3. Client then queries for abc.example.com's A record (10.x.x.x)
4. Connection is made to 10.x.x.x

Despite the DNS redirection, the HTTP request headers remain unchanged. When making a request to xyz.example.com:

GET / HTTP/1.1
Host: xyz.example.com
User-Agent: Mozilla/5.0
Accept: */*

The Host header will always contain the original requested domain (xyz.example.com) because CNAME operates at the DNS level, not the HTTP protocol level.

For Apache configurations, this means:

<VirtualHost *:80>
    ServerName xyz.example.com
    DocumentRoot /var/www/xyz
    # Other directives...
</VirtualHost>

<VirtualHost *:80>
    ServerName abc.example.com
    DocumentRoot /var/www/abc
    # Other directives...
</VirtualHost>

You must maintain separate VirtualHost entries for both domains, as they'll receive different Host headers.

To verify this behavior:

curl -v http://xyz.example.com
dig xyz.example.com
nslookup xyz.example.com

You'll observe that while the IP address resolves through the CNAME chain, the HTTP request maintains the original hostname.

1. Certificate Issues: SSL certificates must cover both names or use wildcards
2. Canonical URLs: Search engines may treat them as separate sites
3. Cookie Domains: Cookies set for abc.example.com won't work for xyz.example.com

The key takeaway: CNAMEs affect DNS resolution only, while HTTP headers preserve the originally requested hostname.