networking - 如何克服根域CNAME限制？

Question

我们为客户托管许多 Web 应用程序。很明显，他们希望使用自己的域来引用这些应用程序，通常他们希望任何输入 http://www.customer1.example 或 http://customer1 的用户.example 转到他们的网络应用程序。

我们面临的情况是，我们需要在不久的将来能够灵活地更改IP地址。我们不想依赖客户对其域进行 A 记录更改。因此，我们认为使用 CNAME 记录可行，但我们发现 CNAME 记录不适用于根域。

基本上:

customer1.example IN CNAME customer1.mycompanydomain.example //this is invalid as the RFC
www.customer1.example IN CNAME customer1.mycompanydomain.example //this is valid and will work

我们希望能够更改 customer1.mycompanydomain.example 的 IP 地址或 A 记录，并且我们的客户将遵循我们可以控制的此记录。

在我们的 DNS 中，它看起来像:

customer1.mycompanydomain.example IN A 192.0.2.1

有什么想法吗？

Answer 1

这个问题仍然经常出现的原因是，正如您所提到的，在某个地方，有人认为重要的人写道，RFC 规定前面没有子域的域名无效。然而，如果您仔细阅读 RFC，您会发现这并不完全是它所说的。事实上，RFC 1912状态:

Don't go overboard with CNAMEs. Use them when renaming hosts, but plan to get rid of them (and inform your users).

某些 DNS 主机提供了一种使用自定义记录类型在区域顶端(根域级别，对于裸域名)获取类似 CNAME 的功能的方法。此类记录包括，例如:

• DNSimple 的 ALIAS
• DNS 中的 ANAME 变得简单
• easyDNS 上的 ANAME
• CloudFlare 的 CNAME

对于每个提供商，设置都是相似的:将您的顶级域的 ALIAS 或 ANAME 条目指向 example.domain.com，就像使用 CNAME 记录一样。 根据 DNS 提供商的不同，空值或 @ 名称值可标识区域顶点。

别名或 ANAME 或@ example.domain.com。

如果您的 DNS 提供商不支持此类记录类型，并且您无法切换到支持的记录类型，则您将需要使用子域重定向，这并不难，具体取决于所需的协议(protocol)或服务器软件去做这件事。

我强烈不同意它仅由“业余管理员”或此类想法完成的说法。这是一个简单的“名称及其服务需要做什么？”处理，然后调整您的 DNS 配置以满足这些愿望；如果您的主要服务是网络和电子邮件，我看不出有任何有效的理由说明为什么永久删除 CNAME 会出现问题。毕竟，谁会更喜欢 @subdomain.domain.org 而不是 @domain.org 呢？如果您已经设置了协议(protocol)本身，谁还需要“www”？假设使用根域名无效是不合逻辑的。