我正在build立一个监控几个大型networking主机的DNS服务器的过程。 我的目标是通过跟踪他们对ping的响应来比较他们的DNS服务器响应时间。
在这个过程中，我发现Bluehost域名服务器不响应ping。 我试图通过在bluehost.com上运行Pingdom DNS Check来获取更多信息，并产生以下错误：
名称服务器ns1.bluehost.com（74.220.195.31）不通过TCP回答查询。
名称服务器无法回答通过TCP发送的查询。 这可能是由于名称服务器没有正确设置，或者是由于防火墙中的filter设置错误导致的。 这是一个相当普遍的误解，DNS不需要TCP，除非它们提供区域传输 – 也许名称服务器pipe理员不知道TCP通常是一个需求。
我想知道以下几点：
来自Pingdom的诊断文本是完全正确的。 TCP不仅仅是区域传输。
根据RFC 5966 “通过TCP进行DNS传输 – 实施要求”，DNS服务器实现现在是“必需的”（就像任何RFC要求的一样）来支持TCP。
请注意，这是服务器软件实现的一个要求，它不严格适用于任何服务器的操作 – 操作实践不包括在内。
也就是说，如果您的特定DNS服务器未configuration为支持TCP，或者被阻止，则长期效应将无法正确支持DNSSEC。 同样，可能会阻止导致响应超过512字节的任何其他DNS数据。
ob免责声明：我写了RFC。
编辑 RFC 5966现已被RFC 7766取代
它应该支持TCP和UDP – TCP响应大小> 512字节（这将包括区域传输）（根据我读过的东西，无论如何，我通常启用TCP和UDP的NS我运行…）
我们很高兴知道RFC在这个问题上的说法，我们已经有了一个很好的权威答案，但是从实际的angular度来看，DJBDNS的作者Daniel J. Bernstein博士的build议非常有趣。
http://cr.yp.to/djbdns/tcp.html#why（2003-01-16 ）
TCP查询何时发送？
如果遇到以下情况之一，则需要configurationDNS服务器以回答TCP查询：
- 你想发布大于512字节的logging集。 （这几乎总是一个错误。）
- 您希望允许传出区域传输，例如到第三方服务器。
- 父服务器拒绝委派一个名字给你，直到你设置TCP服务。
如果你没有遇到这种情况，你不需要提供TCP服务，你不应该设置它。 DNS-over-TCP比DNS-over-UDP慢得多，并且本质上更容易遭受拒绝服务攻击。 （这也适用于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设置的上述文档是其function的任何指示，它似乎只支持TCP的AXFR。 由于许多提供商仍然使用DJBDNS，因此他们不可能在没有额外努力的情况下支持DNS over TCP。
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
，而一个+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实施。
运行只有UDP端口53的DNS服务器是完全可以运行的。 TCP对DNS对等体的访问是必需的，但是这是一个主机列表。
有一个较新的RFC596现在需要TCP完整的DNS实现。 这是针对执行者。 这些文件明确没有针对运营商，但警告不允许TCP可能导致一些故障情况。 它详细介绍了如果不支持基于TCP的DNS，可能导致的各种故障。
已经讨论过使用TCP来防止DNS放大攻击。 技术合作计划有其自身的拒绝服务风险，但分配比较困难。