It’s a common theme to accumulate legacy Web domains over time through services since deprecated or migrated. It also was common practice to create a new domain per service, e.g., a company example Org would by a another domain service.com for one service of theirs, instead of providing it through a subdomain service.expample.org on their main domain.

In order to fight phishing among other things one goal is reduce the number of domains users (and admins in company networks) need to treat as “trustworthy”. In addition, reducing the number of such domains can ease the rollout of technical anti-phishing measures such as HTTP/S, STS, … . As such, the current trend is to use subdomains or paths on the main domain instead.

When migrating, old domains should remain under the ownership of the company and refer to the new pages. Generally, this can be implemented using DNS with DNS CNAME and A/AAAA Records or HTTP with HTTP Forwarding.

Problems with HTTP Forwarding

One possibility is to keep maintaining old servers on their own IPs and reconfigure their web server installations to request the browser to redirect to the new website. The downside is the burden of needing to keep said servers up-to-date, pay the technical costs and ensure valid SSL-certificates for all old domains.

If done different however, the stated goal of moving everything to a subdomain of the main domain can lead to reduced effort.

DNS Forwarding: Naïve Approach

Instead of using HTTP-Forwarding, a DNS CNAME record for the old domain can refer to the IP of the new server. This may be example.org when the new site is hosted under example.org/service or service.example.org if it’s hosted through a subdomain:

Now users can navigate to service.com but requests will actually go to service.example.org.

DNS Forwarding: Problems and Solutions

However this is not without problems, albeit solveable ones:

1. It’s possible that the server yet only reachable under service.example.org isn’t configured to handle requests under the host service.com, too.
2. It may be desirable to re-write the URL in a user-visible way.
3. If the service is supposed to be available under the path example.org/service instead of a subdomain, a plain CNAME referer would not be enough since this would refer to the domain example.org only.
4. Finally, the SSL certificate is probably only valid for example.org and not service.com

The simplest solution is to host a Reverse Proxy listening on a server and answering to example.org , service.com and/or service.example.org with a SSL certificate for all those domains or one per each. Depending on the Host header of the original request, the request will be served directly (e.g., if the request already was conforming to the current infrastructure address) or forwarded using the same HTTP referrer mentioned earlier. As such, a request to service.com would be answered by the server with a HTTP forward to e.g., service.example.org which would then trigger another, otherwise identical, request by the browser to that domain (although both domains actually point to the same server).

Summary

By aggregating legacy domains to one single host we can massively reduce maintenance burden and cost — and also the number of irrelevant findings pertaining legacy infrastructure.