错误的DNS答案与CNAME和Alogging在同一时间

要具体解决您的问题：

• 不，这不是一个经常遇到的问题。 也就是说，中毒确实发生，但通常依靠欺骗性回复，而不是与CNAME一起生活的Alogging。 DNSSEC在devise时考虑到了中毒事件。
• 如果在这里实施了DNSSEC，那么validationparsing器是否清楚Alogging不是由您签名的。 在你自己的区域内你可以做的任何事情都不会对这个问题产生影响。

由于您缺乏额外的信息，您将不得不把这个问题与您的ISP。 定义RFC引用的最适用的标准是RFC2181，因为它与CNAME与其他数据共存的主题上的RFC1034不那么模糊。 （RFC1034皱眉，RFC2181禁止它，除非logging是DNSSEC相关的）

所有这些说，我有点怀疑问题是完全一样的，你所描述的。 对于tippspiel-bl1.unternehmen-frische.de. IN A确实是一个tippspiel-bl1.unternehmen-frische.de. IN A tippspiel-bl1.unternehmen-frische.de. IN A在www.kicktipp.de. IN A上造成碰撞www.kicktipp.de. IN A www.kicktipp.de. IN A

有自定义检查，如果你自己pipe理你的DNS服务器，你可以启用保护这些东西。 请阅读下面直接从RFC获取的要点。这只是人为错误，可以在重新加载区域configuration之前使用某些脚本或检查来阻止。

CNAMElogging

CNAMElogging不允许与任何其他数据共存。 换句话说，如果suzy.podunk.xx是sue.podunk.xx的别名，则不能为suzy.podunk.edu，Alogging，甚至TXTlogging创buildMXlogging。 特别是不要尝试像这样结合CNAME和NSlogging！

  podunk.xx. IN NS ns1 IN NS ns2 IN CNAME mary mary IN A 1.2.3.4 

这是经验不足的pipe理员经常尝试的一种明显的方式，可以让您的域名也成为主机。 但是，像BIND这样的DNS服务器会看到CNAME，并拒绝为该名称添加任何其他资源。 由于不允许其他logging与CNAME共存，所以NS条目将被忽略。

不要将CNAME与指向其他名称（如MX，CNAME，PTR和NS）的RR结合使用。 （如果你想实现无类别的in-addr委托，PTR是一个例外。）例如，这是非常不鼓励的：

  podunk.xx. IN MX mailhost mailhost IN CNAME mary mary IN A 1.2.3.4 

在第3.6.2节中的[RFC 1034]中说，不应该这样做， [RFC 974]明确指出MXlogging不应该指向由CNAME定义的别名。 这会导致访问数据时不必要的间接性，DNSparsing器和服务器需要更多的工作来获得答案。 如果你真的想这样做，你可以通过在主机文件上使用预处理器（如m4）来完成同样的任务。

此外，链接logging（如指向CNAME的CNAME）可能会使pipe理问题变得更加容易，但是已知某些解决scheme中的错误会导致无法正确检查循环。 因此，有些主机可能无法parsing这些名称。

让NSlogging指向CNAME是不好的，并且可能与当前的BIND服务器冲突。 事实上，目前的BIND实现将忽略这些logging，可能会导致一个蹩脚的代表团。 在BIND中进行了一定程度的安全检查，以防止欺骗DNS NSlogging。 另外，旧的BIND服务器据报道将陷入无限的查询循环中，试图找出别名服务器的地址，导致连续的DNS请求stream被发送。