一句话回答你的第一个问题，“是”。

为了回答第二个问题，最佳实践问题通常是非常主观的，并不适合Stack Exchange格式。 经验法则是应该有一个答案，而且这个答案应该是正确的答案，而不是你想要从中得到的一堆意见。

也就是说，对于你正在做的事有两个重要的警告，而且它们足够重要，以至于我认为值得采取一些措施。

知道DNSSEC实际上是在保护您。

在validationstubparsing器在OS供应商实现中变得更为普遍之前，设置了AD （authentication数据）位的回复数据包基本上是这样说的：

“我信任这个数据，所以你也可以信任这个数据！如果你信任我， 我们之间的networking 。

仔细阅读。 如果您的目标是“[避免]必须在内部实现这些function”，请确保您了解从DNSSEC获得的内容。 大多数人不会。 这意味着您对远程recursionDNS服务器的攻击更具弹性，但您仍完全接受针对您的基础架构的中毒攻击 。 当然，有人专门针对你的可能性要低得多，但假设你不是唯一的目标，也不是你有多less损失，以及有人对此感兴趣。

如果您和执行validation的recursion服务器之间的networkingpath不通过Internet，则这些风险将大大降低。 这是相互排斥的外包，虽然stream量本身实际上被encryption害羞。

附注：如果您有兴趣利用OpenDNS，OpenDNS确实会实施dnscrypt ，但是要走这条路线，您必须确定在执行和支持它的过程中的复杂程度，而不是仅仅执行您自己的DNSSECvalidation，是值得的：福利比例。

你得到你所付出的。

这是商业IT环境的通用规则。 这也不足为奇，也适用于此。 如果您将外部依赖性引入您的networking基础架构，那么当该服务closures时会发生什么？ 你的补救path是什么？ 谁来赔偿损失？ 如果这个服务是从别人的angular度来看的，但是这个服务是以一种狭隘的方式打破，只会影响到你的环境，那么你能指望这个远程方认真对待你的意见并执行修复（SLA）的速度有多快？

如果您要创build这种依赖关系，请确保您以某种方式支付服务费用。 你总是放弃一些东西，通过添加一个外部的依赖关系到你的networking，而不需要订阅某种东西，而不这样做的select是衡量你的赌注的可能性。

全面披露

我是美国MSO的DNS运营商。 也就是说，像我这样的人根据这个build议并不真正从你那里得到经济上的好处。 从您的ISP的DNS群集中迁移出去，对我们所pipe理的东西的负载要less一些。

configurationDNS根提示，可以减less您的pipe理，并提高外部DNS查询的可用性

对于间隔查询DNS转发器工作正常