域名服务器必须通过TCP回答查询吗？

我正在设置监视多个大型Web主机的DNS服务器的过程。我的目标是通过跟踪其对ping的响应来比较其dns服务器的响应时间。

在此过程中，我发现Bluehost名称服务器不响应ping。我试图通过在bluehost.com上运行Pingdom DNS Check来获取更多信息，它产生了以下错误：

名称服务器ns1.bluehost.com（74.220.195.31）无法通过TCP回答查询。

名称服务器无法回答通过TCP发送的查询。这可能是由于名称服务器设置不正确或防火墙中过滤配置不正确所致。一个非常普遍的误解是，除非DNS提供区域传输，否则DNS不需要TCP-也许名称服务器管理员并不知道TCP通常是必需的。

我想知道以下内容：

• 以上说法在多大程度上是正确的？
• 域名服务器不通过TCP回答查询的含义是什么？

Pingdom的诊断文本完全正确。TCP是不是只为区域传送。

现在，根据RFC 5966 “通过TCP进行DNS传输-实施要求”，DNS服务器实现是 “必需的”（在任何RFC需要任何东西的情况下）以支持TCP 。

请注意，这是在服务器上的软件实现的要求，它并没有严格地适用于任何服务器的操作-操作实践不是盖的。

也就是说，如果您的特定DNS服务器未配置为支持TCP，或者被阻止，则长期影响将是无法正确支持DNSSEC。同样，任何其他导致响应超过512字节的DNS数据也可能被阻止。

ob免责声明：我写了RFC。

编辑 RFC 5966现在已由RFC 7766取代

它应该支持TCP和UDP-TCP用于大于512字节的响应（这将包括区域传输）（根据我已经阅读的内容。无论如何，我通常为运行的NS启用TCP和UDP ...）

很高兴知道RFC在这个问题上怎么说，而且我们已经有了一个很好的权威答案，但是出于实际的目的，我发现DJBDNS的作者Daniel J. Bernstein教授的建议非常有趣。

http://cr.yp.to/djbdns/tcp.html#why（2003-01-16）

什么时候发送TCP查询？

如果您处于以下情况之一，则需要配置DNS服务器以回答TCP查询：

• 您要发布大于512字节的记录集。（这几乎总是一个错误。）
• 您要允许传出区域传输，例如到第三方服务器的传输。
• 在设置TCP服务之前，父服务器将拒绝将名称委托给您。

如果您不在任何一种情况下，则无需提供TCP服务，也不应进行设置。TCP上的DNS比UDP上的DNS慢得多，并且在本质上更容易受到拒绝服务攻击。（这也适用于BIND。）

请注意，他省略了对DNSSEC的明确提及；原因是，根据DJB的说法，DNSSEC属于“总是错误”类别。有关更多详细信息，请参见https://cr.yp.to/djbdns/forgery.html。DJB有一个替代标准，称为DNSCurve — http://dnscurve.org/，该标准已被某些提供商（如OpenDNS）独立采用。感兴趣的：https : //security.stackexchange.com/questions/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption。

请注意，如果以上有关DJBDNS设置的文档表明其功能，则表明它仅支持TCP的AXFR。由于许多提供商仍在使用DJBDNS，因此如果不付出额外的努力，他们不太可能支持TCP上的DNS。

PS请注意，事实上，DJB确实在实践他的讲道。他自己的服务器（1）确实运行DNSCurve（2），但未正确应答TCP。只有+notcp会成功（默认）：

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

，而a +tcp则会失败（显然会显示不同的错误消息，具体取决于选择了哪个服务器）：

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

TCP仅是必需的，并且通常仅在需要长响应时才使用。可能会有负面影响。区域传输是通过TCP完成的，因为它们很大，并且需要可靠。不允许来自不受信任的服务器的TCP是确保仅给出较小答案的一种方法。

随着签名DNS答案的引入，要求放松对UPD答案的512字节限制。EDNS0提供了更长的UDP响应机制。无法通过TCP允许DNS很有可能破坏安全的DNS实施。

完全有可能运行仅向Internet开放UDP端口53的DNS服务器。需要对DNS对等方进行TCP访问，但这只是一小部分主机。

有一个更新的RFC596，现在需要TCP才能实现完整的DNS。这是针对实施者的。这些文档没有专门针对运算符，但警告说不允许TCP会导致多种故障情况。它详细说明了如果不支持基于TCP的DNS，则会导致多种故障。

已经讨论了使用TCP来防止DNS放大攻击。TCP有其自身的拒绝服务风险，但是分发更加困难。