A Domain by Any Other Name: CNAMES, Wildcard Records and Another Level of Indirection
This is post 3 in the 5-part series The Right Tools for the Job: Re-Hosting DigitalGov Search to a Dynamic Infrastructure Environment.
“All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections.” – David Wheeler
The simplest of our four requirements was to allow customers to choose whether to use the search.usa.gov domain for their search results page, or create a “masked” domain name such as search.someagency.gov. While only about 1/4 of customer agencies use them, half of our search traffic comes through masked domains.
In our previous infrastructure, the customer would create a CNAME in their own DNS zone to point search.someagency.gov to the edge servers for search.usa.gov, and we had to register the customer’s domain mask with our DNS provider. All our customers used the same CNAME: search.usa.gov.old-cdn-waf-provider.net
We knew that we wanted to avoid a “Big Bang” migration event in which all of our customers were suddenly pointed to the new AWS hosting infrastructure, so we asked our CNAME customers to point their agency-specific hostnames to customer-specific CNAMEs. This would allow us to shift traffic around on a customer-by-customer basis – both to the new infrastructure, but also back to the old infrastructure if the need arose:
$ORIGIN someagency.gov.
search IN CNAME someagency.sites.infr.search.usa.gov
Once a fair number of our customers had these CNAMEs in place, we were able to switch them over to our new AWS infrastructure one-at-a-time rather than switching everyone at once:
$ORIGIN sites.infr.search.usa.gov.
earlyadopteragency IN CNAME aws.search.usa.gov
anotherearlyadopteragency IN CNAME aws.search.usa.gov
notchangingnowagency IN CNAME old-infra.search.usa.gov
The snippet above is a bit of a simplification, however. We used wildcard DNS records at first to direct the majority of our customers to our previous hosting provider, and then later to our AWS-hosted site:
Before:
$ORIGIN sites.infr.search.usa.gov.
earlyadopteragency IN CNAME aws.search.usa.gov
anotherdaringagency IN CNAME aws.search.usa.gov
; All customers above will go to the new infrastructure
* IN CNAME old-infra.search.usa.gov
Later:
$ORIGIN sites.infr.search.usa.gov.
* IN CNAME aws.search.usa.gov
; All customers below will go to the old infrastructure
notchangingnowagency IN CNAME old-infra.search.usa.gov
Finally:
$ORIGIN sites.infr.search.usa.gov.
; Everyone goes to the new infrastructure
* IN CNAME aws.search.usa.gov
At any step in this process, we were always able to go back to our zone file and add a customer-specific CNAME to direct traffic as needed for that customer, but eventually the DNS migration came to an end and we were left with just the single wildcard record *.sites.infr.search.usa.gov pointing to our AWS infrastructure.
Read more of this 5-part series:
