由于历史原因，我们拥有5个CNAME级别的DNS域名。 有些东西外包了高可用性等，但这不是重点。 我的问题是有5个CNAMEs的DNSparsing器矫枉过正？ 我找不到任何有着超过2-3层嵌套CNAME指向不同DNS域的着名网站。
我们的CNAME跳转如下所示:(我只是以xyz为例）
www.xyz.com – > xyz.akadns.net – > xyz.worldwide.akadns.net – > xyz.cedexis.net – > xyz.msedge.net – > host1.msedge.net（最终A \ AAAAlogging）
我看到很多客户在我们的网站上抱怨DNSparsing问题，当其他网站为他们工作，虽然当我使用http://check-host.net/check-dns?host=www.xyz.comtesting我们的DNSparsing度。
似乎总是在世界范围内工作良好。 我的结论是，大部分是本地ISP提供商DNSparsing器搞砸了，当上面的一个跳跃无法解决。 nslookup在这些客户端计算机上仅在我们的网站上出现故障，而且太零星。
这种多层次的CNAME一般是不好的devise吗？
这种多层次的CNAME一般是不好的devise吗？
CNAME到CNAME链不禁止，但正如您已经体验到它不是一个非常强大的解决scheme。
每个额外的CNAME增加了parsing器的recursion深度，并且这个深度并不总是无限的。 此外，您还有创build循环或触发循环检测algorithm的风险。
要想知道您的用户名称服务器需要执行多less个查询和哪些查询，请运行DNS跟踪：
dig +trace www.example.com 或在Windows上
nslookup -debug www.example.com
HBrujin是正确的，但事实上，recursion深度比任何dig +trace都要显示的要糟糕得多。 recursion深度往往被嘲笑和过分琐碎，但是这些人忘记了你不只是解决CNAMElogging。 这是因为parsingCNAMElogging的目标需要查找path中的每个名称服务器 ，这通常比乍一看更为明显。
CNAME目标是否存在于另一个域中？ 您需要recursion到它的名称服务器中，这不仅需要NSlogging查找，还需要A(AAA)查找，其中不存在胶水。 名称服务器的名称服务器是否位于不同的顶级域名中？ 如果这些顶级域名（TLD）不共享域名服务器，则不会包含粘合logging，您还需要通过其他顶级域名（TLD）的域名服务器进行recursion。 等等。
添加到链中的每个CNAMElogging可根据需要recursion的名称服务器的数量按指数增加所需查找的数量。 这些CNAME + NS + A(AAA)logging查找链反过来可能会变得疯狂地复杂化，达到超过150个级别的高度caching。 这是recursion深度限制可能非常讨厌的地方，导致临时失败在空的caching中查找您的域，并且出于通常不明显的原因。
总之，你可以做到这一点，但谨慎行事，并认真对待这种性质的反馈。 您无法控制互联网上的recursionDNS服务器重新启动或清除的频率。
多级CNAME在实践中通常很方便。 每个redirect级别都在可能不同的pipe理区域或完全不同的组织中提供一定程度的控制。 虽然这几乎不是技术上必要的，但它可以解决组织问题。
正如其他人已经指出，这可能会造成困难，但这些可以解决：
监视所有的DNS服务器。 也许一个是故障。 监视外部服务器以及您自己的。 您可能需要向Akamai或其他供应商报告问题。
TTL应设置得足够高，以允许caching但足够低，以便您的应用程序可以快速移动stream量