问具有多个CNAME

EN

这种多层次的CNAME总体上是个糟糕的设计吗？

CNAME到CNAME链是不被禁止，但正如您已经体验到的那样，它不是一个非常健壮的解决方案。

每增加一次CNAME，就会增加解析器的递归深度，而且这个深度并不总是无限的。此外，您还面临创建循环或触发循环检测算法的风险。

要了解您的用户名服务器需要执行多少次查询以及需要执行哪些查询，请运行DNS跟踪：

dig +trace www.example.com 

或在Windows上

nslookup -debug www.example.com

HBrujin是正确的，但实际上递归深度比dig +trace将要展示的任何东西都要糟糕得多。递归深度是经常被嘲笑和过分琐碎的东西，但是那些人忘记了，你不仅仅是在解析5条CNAME记录。这是因为解析CNAME记录的目标会导致需要查找路径中的每个名称服务器，这通常比乍看上去要明显得多。

CNAME目标是否存在于另一个域中？您需要递归到它的名称服务器中，这不仅需要NS记录查找，而且需要不存在胶水的A(AAA)查找。这些名称服务器的名称服务器是否生活在不同的顶级域中？如果那些TLD不共享名称服务器，那么胶水记录很可能不会包括在内，而且您还必须通过其他TLD的名称服务器进行递归。诸若此类。

添加到链中的每个CNAME记录都可以成倍地增加所需的查找数量，这取决于需要递归的名称服务器的数量。这些CNAME+NS+A(AAA)记录查找链反过来会变得异常复杂，在emtpy缓存中的深度超过150个级别。在这种情况下，递归深度限制可能会变得非常糟糕，从而导致在空缓存上查找域的临时失败，而且原因通常不是立即就能显现出来的。

总之，你可以这样做，但要谨慎行事，认真对待这种性质的反馈。您无法控制internet上递归DNS服务器重新启动或清除的频率。

多层次的CNAMEs在实践中往往很方便.每个级别的重定向都在可能不同的管理区域或完全不同的组织中提供一个级别的控制。虽然这在技术上并不都是必要的，但它可以解决组织问题。

正如其他人所指出的，这可能会造成困难，但这些问题可以解决：

• 监视所有DNS服务器。也许其中一个故障了。监视外部服务器以及您自己的服务器。您可能需要向Akamai或其他供应商报告问题。
• 应该将TTL**S*设置得足够高，以便允许缓存，但设置得足够低，以便您能够为应用程序快速转移通信量。