这篇文章是关于我们在过去几个月悄悄推出的一个新功能。上周我们开始默认为每个人启用它。它叫做CNAME扁平化，有点古怪，但是如果你使用基于云的服务，并且你讨厌有一个"www"子域，那么它非常有用和重要。要点是：现在您可以安全地使用CNAME记录，而不是指向固定IP地址的a记录，作为CloudFlare DNS中的根记录，而不会因为您违反了DNS规范而触发许多边缘情况错误情况。我知道，在问您为什么这很酷之前，以下是我们的一些客户对该功能的赞誉：

"CloudFlare的CNAME扁平化功能使我们能够轻松地为Amazon弹性负载平衡器（ELB）提供CloudFlare的DDoS和WAF保护。"纳斯达克私人市场首席技术官格雷戈里"这是一个需要解决的难题。让CloudFlare的团队来制定一个伟大的解决方案，它将作为通向几乎无限数量的其他云服务的网关。"Alex Polvi，CoreOS首席执行官"CNAME扁平化允许我们使用根域，同时仍然在多个IP地址之间保持DNS容错。"Andrew Warner，RapGenius工程总监有兴趣吗？请继续阅读，了解它的具体技术细节以及我们为什么需要构建它。DNS的不灵活性传统上，域的根记录需要指向一个IP地址（称为"地址"记录的a--）。虽然这看起来不是什么大问题，但将服务绑定到IP地址可能是非常有限的。想象一下，一个新的博客平台，WordPlumblr，启动了。WordPlumblr允许用户使用指向WordPlumblr基础设施的自定义域。Foo.com网站注册后WordPlumblr给出Foo.com网站IP地址。IP地址的供应是有限的，因此，随着时间的推移，随着越来越多的网站注册，IP地址最终会在多个客户之间共享。没有问题，因为使用虚拟主机名WordPlumblr可以为不同的域返回不同的内容，即使托管在同一个IP地址上。一切都很好直到Foo.com网站开始使用过多WordPlumblr的资源——可能是因为他们受到了攻击，或者是在奥普拉上的专题报道，或者是谁知道为什么。WordPlumblr的其他客户的性能很差，因为他们与那些不知所措的用户共享相同的资源Foo.com网站. WordPlumblr陷入了一个困难的境地：不得不去接触Foo.com网站让他们改变他们的DNS设置，或者，更困难的是，必须联系所有其他使用IP地址的客户让他们更改。祝你好运。为了胜利解决方案是CNAME。CNAME是别名。它允许一个域指向另一个域，如果遵循CNAME链，它最终将解析为A记录和IP地址。如果WordPlumblr为每个客户分发了一个唯一的CNAME，那么他们就不会有问题了。例如，WordPlumblr可能分配了cname6eqj5。wordplumblr.com网站为Foo.com网站. Foo.com网站而其他客户可能都在CNAME链的末尾，最初解析到同一个IP地址。但是，什么时候Foo.com网站开始使用太多资源WordPlumblr可能更新了CNAME并隔离了Foo.com网站从其他顾客那里。如果你熟悉编程，这就像指针的概念。当你用C编程时，为了允许内存管理的灵活性，你通常不想直接寻址内存，而是设置一个指向内存块的指针，你要在那里存储一些东西。如果操作系统需要移动内存，那么它只更新指针，指向内存块被移动到的位置。程序引用了指针，并没有一点是明智的。CNAMEs非常适合于像这样的子域网站或者博客.foo.com. 不幸的是，它们不适用于像foo.com网站本身。而且，由于一些让我有些困惑的原因，很多人沉迷于使用他们的裸域名作为他们的网站。那么为什么CNAMEs不能从根本上起作用呢？你没有根

这个问题源于DNS规范始于1987年。当时，还没有人想到网站——两年前Tim Berners Lee的开创性论文首次提出万维网的构想——更不用说像亚马逊网络服务（AWS）或Heroku这样的现代外包云服务了。因此，DNS规范规定根记录（没有任何子域的裸域）不能是CNAME。从技术上讲，根可以是CNAME，但是RFCs声明一旦一个记录有CNAME，它就不能有任何其他条目与之关联：这对于像example.com网站因为它通常会有一个MX记录（因此电子邮件会被传递）、一个NS记录（以找出哪个名称服务器处理该区域）和一个SOA记录。因为它们遵循这个规范，大多数权威的DNS服务器不允许在根目录中包括CNAME记录。在CloudFlare，我们决定让我们的用户在根目录中包含CNAME，尽管我们知道它违反了DNS规范。这在大多数情况下是有效的。不幸的是，有一些边缘案例导致了各种各样的问题。打破RFC的风险由你自己承担你永远猜不到，但最大的边缘案例与从Microsoft Exchange邮件服务器发送的电子邮件有关。域通常指定通过MX记录处理其电子邮件的服务器。问题是，在一组非常特殊的情况下，Exchange服务器可能会在根记录处获取CNAME，然后无法正确地尊重MX记录中设置的CNAME。你不能怪交换。它们是在DNS规范所规定的假设下运行的。然而，这和其他一些角落案例使我们支持但不建议在根记录中使用CNAME。直到现在。CNAME展平简介

我们需要的是在根目录下支持CNAME，但仍然遵循RFC并为根记录的任何查询返回一个IP地址。为了实现这一点，我们扩展了我们的权威DNS基础设施，在某些情况下，充当一种DNS解析程序。如果我们在那里找到一个记录，而不是直接返回一个记录。此时，我们返回和A记录相关联的IP地址。这实际上"扁平化"了CNAME链。这遵循DNS规范，对于与DNS交互的任何服务都是不可见的。在过去的几个月里，我们对它进行了广泛的测试，效果非常好，完全解决了我们之前看到的Microsoft Exchange和其他边缘案例问题。灵活、快速最大的好处是，这允许在不破坏DNS规范的情况下将CNAMEs作为根目录的灵活性。我们发现的一个辅助好处是，我们平均减少了30%的CNAME解析时间。我们缓存CNAME响应——考虑到DNS TTL，就像递归器应该做的那样——这意味着通常我们不需要遍历链就可以得到答案。当我们确实需要遍历CNAME链时，我们通常有一个比您的访问者的ISP的递归DNS服务更快、更直接的连接到任何一个权威的服务器，否则它将承担繁重的任务。

虽然我们默认只对根记录启用此项，但我们已经开始尝试更广泛地启用CNAME平坦化。我们已经开始对CloudFlare内部使用的所有CNAME进行扁平化处理。例如，如果您是通过托管合作伙伴注册的，那么您可能已经获得了CNAME链中包含的CNAME，比如cf-ssl2463-protected-。这种情况正在逐渐消失，现在将直接从您的域解析到IP地址。这使得DNS解析速度更快，也更好地掩盖了使用CloudFlare的事实。截至上周，默认情况下，CNAME展平处于启用状态。要利用它，只需在根记录中添加一个CNAME。新功能免费提供给所有使用CloudFlare DNS的用户。如果您一直在寻找一种方法，使您的根记录能够在AWS、Heroku或新的热门博客平台WordPlumblr等托管服务上运行，请不要再进一步了。而且，如果你还需要一些令人信服的东西，下面是一些来自happy beta测试人员的引述："CNAME扁平化为我们解决了电子邮件解析错误，这是非常关键的。它也使我们能够指向我们的应用托管在skyprepapp.com网站到亚马逊ELB，解决那里的电子邮件。"Arash Barkhodaee，联合创始人兼首席技术官，SkyPrep.com网站"大约6年前，我们选择在域名中删除www。虽然我知道有很多技术原因不使用这些顶级域名的网址，实际上，我不喜欢技术问题阻止我们做我们认为正确的想法。我们的客户都是精通互联网的，而www的传统已经不再需要了。所以我们放弃了它，并使用亚马逊的53号路线来平衡我们的经济咨询网负载平衡器的流量。当我们转移到CloudFlare时，我们并不打算失去Apex域，但是如果没有CNAME扁平化，我不相信这是可能的。因此，此功能非常受欢迎，并简化了向CloudFlare的迁移。"Matthew O'Riordan，首席技术官，经济咨询网"CloudFlare的CNAME扁平化解决了我们在域中看到的电子邮件解析的特定问题。当我们第一次为Junction配置DNS记录时，我们利用CloudFlare特性为zone apex设置CNAME记录。这帮助我们解决了根源--jct.com网站--到一个AWS ELB，它将流量路由到我们的web服务器并处理SSL终止。这起作用了我们