☰

名称服务器是否必须通过 TCP 来回答查询？

tag-icon • tag-icon domain-name-system nameserver
名称服务器是否必须通过 TCP 来回答查询？

我正在设置对几家大型网络主机的 DNS 服务器的监控。我的目标是通过跟踪它们的 ping 响应来比较它们的 DNS 服务器响应时间。

在此过程中，我发现 Bluehost 域名服务器不响应 ping。我尝试通过运行获取更多信息bluehost.com 上的 Pingdom DNS 检查并产生了以下错误：

名称服务器 ns1.bluehost.com (74.220.195.31) 未通过 TCP 回答查询。

名称服务器无法回答通过 TCP 发送的查询。这可能是由于名称服务器设置不正确或防火墙中的过滤配置错误造成的。一个相当常见的误解是，除非 DNS 提供区域传输，否则它们不需要 TCP - 也许名称服务器管理员没有意识到 TCP 通常是一项要求。

我想要了解以下信息：

  • 上述说法在多大程度上是正确的？
  • 名称服务器不通过 TCP 回答查询会有什么后果？

答案1

Pingdom 的诊断文本完全正确。TCP 是不是仅适用于区域传输。

DNS 服务器实现是现在“需要”（就像任何 RFC 要求的那样）支持 TCP，RFC 5966, “TCP 上的 DNS 传输 - 实施要求”。

请注意，这是对服务器软件实现的要求，它确实不是严格适用于任何服务器的操作 - 不包括操作实践。

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

ob 免责声明：我编写了该 RFC。

编辑RFC 5966 现已被取代RFC 7766

答案2

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

答案3

了解 RFC 对这个问题的看法是件好事，而且我们对此已经有了很好的权威答案，但就实际目的而言，我发现 DJBDNS 的作者 Daniel J. Bernstein 博士教授的建议非常有趣。

http://cr.yp.to/djbdns/tcp.html#why（2003年1月16日）

TCP 查询何时发送？

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

  • 您想要发布大于 512 字节的记录集。（这几乎总是一个错误。）
  • 您想要允许传出区域传输，例如到第三方服务器。
  • 在您设置 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 设置的文档可以说明其功能，则似乎它仅支持 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

答案4

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

随着签名 DNS 答案的引入，需要放宽 UPD 答案的 512 字节限制。EDNS0 提供了更长的 UDP 响应机制。不允许通过 TCP 进行 DNS 很可能会破坏安全的 DNS 实施。

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

有一个新的RFC596现在需要 TCP 才能实现完整的 DNS 实现。这针对的是实现者。这些文档并没有特别针对运营商，但警告说不允许 TCP 可能会导致许多故障情况。它详细说明了如果不支持 DNS over TCP 可能导致的各种故障。

曾有讨论使用 TCP 来防止 DNS 放大攻击。TCP 本身存在拒绝服务风险，但分发难度更大。

相关内容