0

We have "go links" where I work, such as http://go.mycompany.com/foo which redirects to an arbitrary location. It's powered by a simple Python app on Google App Engine that keeps a mapping of keyword => url.

I'm working on making them work "unqualified" so go/foo takes you to the same place. Our DHCP server gives us search domains including "mycompany.com" so just "go" does resolve to an IP and it should all just work.

Except, that DNS entry points at Cloudfront which we use primarily to upgrade HTTP to HTTPS. When using the full domain, Host: HTTP header comes through as go.mycompany.com and everything is fine. When using just "go" the Host: header comes through as simply "go". Even though traffic routes at the TCP level, Cloudfront doesn't know what to do with it.

The fix should be as simple as adding "go" to the CNAMES of the given CloudFront distribution, such that it looks like:

Alternate Domain Names (CNAMEs)

go.mycompany.com
go

However, that box in the UI won't accept bare word domains. Any trick to work around?

jpsimons
  • 103
  • 3

2 Answers2

2

There is no workaround for this, and as Michael Hampton correctly points out, it's a bad practice anyway.

But with regard to why, specifically, this isn't possible with CloudFront, the reason is at least in part that the alternate domain name values for CloudFront are in a global namespace. No two CloudFront distributions can have the same value in their alternate domain name settings. If I have a CloudFront distro with example.com as an alternate domain name, nobody else can configure that same name in their distribution until I delete it from mine. So, if it were allowed, only one distribution anywhere in the whole of CloudFront could respond to requests with the Host header set to "go" or some other short value, and of course such a site could not have a cert from a public CA, since no CA would be authorized to issue such a cert.

Michael - sqlbot
  • 22,984
  • Good answer. Didn't realize they had to be unique. Taking a different approach: Putting a reverse proxy in front of CloudFront that "upgrades" a bareword host header to an assumed FQDN. 20 lines of NodeJS. – jpsimons Aug 08 '18 at 02:33
  • There's no technical reason they need to be unique though, if IP address 1.1.1.1 wants to accept a.com, b.com and c.com, and 2.2.2.2 also wants to accept and serve different content to a.com, b.com and c.com, regardless of how traffic got there (because it couldn't get both places via public DNS), there's no problem. Just a constraint of AWS I guess. – jpsimons Aug 08 '18 at 02:37
  • Correct. CloudFront doesn't notice which address accepted the incoming request. It's only interested in the SNI and the Host header. A reverse proxy "in front of" CloudFront is a possibility, except that you then lose the geographic diversity of CloudFront, since the browser needs to connect to the proxy instead of directly to the edge location. CloudFront uses DNS magic to return a set of IP addressed that are at an edge that is close to the viewer doing the DNS lookup, so if you and I look up a given distro, we're likely to get different IPs in response. – Michael - sqlbot Aug 08 '18 at 10:28
1

For CNAMEs? No. You can use Route53 as your zone host and use Alias records though, but any DNS host that you use that's worth anything will not allow Apex CNAME records. From the Cloudfront docs linked above:

If you're using Route 53 as your DNS service, you can create an alias resource record set, which has two advantages over CNAME records. You can create an alias resource record set for a domain name at the top node (example.com). In addition, when you use an alias resource record set, you don't pay for Route 53 queries.

Wesley
  • 32,840