我工作的地方有“前往链接”，例如http://go.mycompany.com/foo重定向到任意位置。它由 Google App Engine 上的一个简单的 Python 应用程序提供支持，该应用程序保存了 keyword => url 的映射。
我正在努力让它们以“无限制”的方式工作，这样 go/foo 就可以带你到同一个地方。我们的 DHCP 服务器为我们提供搜索域，包括“mycompany.com”，因此只需“go”即可解析 IP，一切应该都可以正常工作。
除此之外，DNS入口指向Cloudfront，我们主要使用它来将HTTP升级到HTTPS。当使用完整域名时，Host:HTTP标头以go.mycompany.com的形式通过，一切正常。当只使用“go”时，Host：标头以简单的“go”形式通过。即使流量在TCP级别路由，Cloudfront也不知道如何处理它。
修复应该很简单，只需将“go”添加到给定 CloudFront 分发的 CNAMES 中，如下所示：
备用域名 (CNAME)
go.mycompany.com
go
但是，UI 中的框不接受裸字域名。有什么技巧可以解决吗？
答案1
对此没有解决方法，而且正如 Michael Hampton 正确指出的那样，这是一种糟糕的做法。
但至于为什么具体来说，CloudFront 无法做到这一点，原因至少部分在于 CloudFront 的备用域名值位于全局命名空间中。没有两个 CloudFront 发行版的备用域名设置值可以相同。如果我有一个 CloudFront 发行版，并且使用备用域名example.com，那么其他人都无法在其发行版中配置相同的名称，除非我从我的发行版中删除它。因此，如果它是允许，整个 CloudFront 中任何地方只有一个分布可以响应将Host标头设置为“go”或其他短值的请求，当然这样的站点不能拥有来自公共 CA 的证书，因为没有 CA 被授权颁发这样的证书。
答案2
对于 CNAME？不。您可以使用 Route53 作为区域主机并使用别名记录，但您使用的任何有价值的 DNS 主机都不会允许 Apex CNAME 记录。来自上面链接的 Cloudfront 文档：
如果您使用 Route 53 作为 DNS 服务，则可以创建别名资源记录集，与 CNAME 记录相比，它有两个优点。您可以在顶级节点 (example.com) 为域名创建别名资源记录集。此外，当您使用别名资源记录集时，您无需为 Route 53 查询付费。