DNS 端口 53：选择正确的传输测试

模块 1｜端口号只是端点的一部分

传统 DNS 在 UDP 和 TCP 上都使用 53 端口。传输协议是端点的一部分：允许 UDP 53 端口并不等于允许 TCP 53 端口。一条有用的故障记录应写明目标、传输协议、端口以及实际提出的 DNS 问题。

不要因为一次较小的查询经常使用 UDP，就假设 DNS 只使用 UDP。DNS over TCP 是正常运行中受支持的一部分，并不是可以始终阻断而不会产生后果的可选功能。

模块 2｜比较常见的传输方式

服务配置可能不同，因此应使用运营方记录的端点。表格描述的是常见传输方式，并不是适用于所有环境的防火墙策略。使用加密 DNS 的浏览器，解析路径可能与普通命令行查询不同。

模块 3｜理解 TCP 为什么重要

解析器可以使用 TCP 进行 DNS 交换，包括 UDP 响应无法承载所需结果的情况。因此，在允许 UDP 的同时阻断 TCP，可能只在特定响应或条件下产生故障。

一次很小的 A 记录查询可能成功，而另一条查询失败。这不能证明整个 DNS 路径是健康的。在修改权威记录来弥补传输问题之前，应与网络运营方检查实际响应和传输行为。

模块 4｜了解基础连接测试能证明什么

Test-NetConnection -ComputerName 1.1.1.1 -Port 53

在 Windows PowerShell 中，这个示例会在网络策略允许时测试到所述公共端点的 TCP 连接。它不会发送等效的 UDP DNS 查询，也不会验证 DNS 应答是否正确。

因此，TCP 连接成功不能证明应用的 UDP 查询有效。连接失败可能反映出策略要求使用组织指定的解析器。应将连通性测试与实际查询区分开，并且只使用经过批准的目标。

模块 5｜处理传输方式不匹配

在一个示例网络中，基础地址查询成功，但需要 TCP 交换的查询失败。管理员发现预期的解析器可以通过 UDP 53 到达，但对应的 TCP 路径被拒绝。修复方式是为授权服务审查并更正策略，而不是关闭防火墙。

更改后，从受影响的客户端重新运行原来失败的查询和一条普通查询。记录协议、目标、结果和时间。不要仅因为通用端口扫描器报告端口开放，就宣布问题已经解决。

模块 6｜分别看待客户端和服务器暴露面

发起查询的客户端不需要变成面向公网的递归 DNS 服务。经过授权的网络规则应定义清楚方向和目标。不要把向互联网开放不受限制的入站递归当作排障捷径。

对于私有或受管理的网络，应询问负责的管理员当前适用的解析器和加密 DNS 策略。允许所有外部解析器可能破坏内部名称解析行为，或违反预期的安全控制。

模块 7｜常见问题

HTTPS 端口 443 上的流量能证明正在使用 DNS over HTTPS 吗？不能。大多数 HTTPS 流量与 DNS 无关。应检查应用配置的解析器和实际服务契约。

我可以通过在线查询判断网络吗？在线工具从自己的服务器运行。它提供的是公共对比，不能测试本地防火墙规则或你的 DNS 传输。

模块 8｜利用结果缩小故障范围

回到 慢 DNS 指南或 DNS 服务器无响应指南，补充更清楚的传输方式和受影响范围记录。使用 Arcvenza NSLookup检查公共应答，同时让网络运营方验证本地路径。最终事件记录中应把这两项观察分开。

技术参考

RFC 1035：DNS 记录 · RFC 7766：DNS over TCP · RFC 7858：DNS over TLS