如何克服根域CNAME限制？

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

我们面临的情况是,我们需要具备在不久的将来更改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

我们希望能够更改IP地址customer1.mycompanydomain.example或A记录,我们的客户将遵循我们控制的记录.

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

customer1.mycompanydomain.example IN A 192.0.2.1

有任何想法吗？

1> 小智..：

---

这个问题经常出现的原因是因为,正如你所提到的,在某个地方某个人被认为是重要的人写道,RFC声明在他们面前没有子域名的域名是无效的.但是,如果您仔细阅读RFC,您会发现这并不是它所说的.实际上,RFC 1912声明:

不要过分使用CNAME.重命名主机时使用它们,但计划摆脱它们(并通知您的用户).

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

ALIAS在DNSimple

在DNS轻松实现的ANAME

easyDNS上的ANAME

CloudFlare的CNAME

对于每个提供商,设置类似:将您的顶点域的ALIAS或ANAME条目指向example.domain.com,就像使用CNAME记录一样.根据DNS提供程序,空或@Name值标识区域顶点.

ALIAS或ANAME或@ example.domain.com.

如果您的DNS提供程序不支持这样的记录类型,并且您无法切换到那样做,那么您将需要使用子域重定向,这并不难,具体取决于需要执行此操作的协议或服务器软件.

我强烈不同意只有"业余管理员"或此类想法才能完成的声明.这很简单"名称及其服务需要做什么？" 处理,然后调整您的DNS配置以满足这些愿望; 如果您的主要服务是网络和电子邮件,我没有看到任何有效的原因,为什么放弃CNAME为好 - 这将是有问题的.毕竟,谁更喜欢@ subdomain.domain.org而不是@ domain.org？如果您已经设置了协议本身,谁需要"www"？假设使用根域名无效是不合逻辑的.

---

我完全同意.想要从"裸体"域名托管网站是一件很常见的事情.它使用较少的字符,它看起来更好等.网址自己的协议标识符(www)是网址的残留部分,如果首先是必要的(它不是).

---

ANAME很不错,或者你可以将301全部非www到www.通过免费301重定向服务http://198.251.86.133

2> 小智..：

---

CNAME的根记录在技术上不是针对RFC的,但确实有限制意味着它是一种不推荐的做法.

通常,您的根记录将有多个条目.比方说,3为您的名称服务器,然后一个为IP地址.

每个RFC:

如果节点上存在CNAME RR,则不应存在其他数据;

并且根据IETF的"常见DNS操作和配置错误"文档:

这通常是由经验不足的管理员尝试的,这是允许您的域名也是主机的明显方式.但是,像BIND这样的DNS服务器将看到CNAME并拒绝为该名称添加任何其他资源.由于不允许其他记录与CNAME共存,因此将忽略NS条目.因此,podunk.xx域中的所有主机也会被忽略!

参考文献:

http://tools.ietf.org/html/rfc1912"2.4 CNAME记录"部分

http://www.faqs.org/rfcs/rfc1034.html第3.6.2节.别名和规范名称'

---

但为什么没有其他记录可以与CNAME共存.这只是RFC作者添加的限制还是有技术原因？如果没有技术原因,那么可以轻松地提出扩展RFC.