先证明 53 端口能出去
「解析全部超时」时，第一个要回答的问题不是「DNS 服务器坏了吗」，而是「53 端口能不能出去」。测试要分两条路径：UDP 53 是常规查询通道，TCP 53 用于应答过大时的回退，两者都要验。分清楚之后结论就很明确——UDP 与 TCP 都不通是网络或策略问题，只有 TCP 不通是防火墙只放行了 UDP，两者都通但解析失败才是 DNS 服务本身的问题。
基本信息
| 适用平台 | Linux（dig、nc、bash 内建 /dev/tcp） |
|---|---|
| 协议依据 | RFC 1035：DNS 使用 53 端口，UDP 为主、TCP 用于大响应与区域传送 |
| 测试手段 | dig +time=2 +tries=1、dig +tcp、nc -zvu、bash 的 /dev/tcp 探测 |
| 常见策略 | 企业网只允许内网 DNS 出 53，直连公共 DNS 被静默丢弃 |
| 判读顺序 | 先测端口可达性，再测解析功能 |
典型使用场景
- 解析整体失败：先区分端口不可达与 DNS 服务异常
- UDP 正常但大响应失败：验证 TCP 53 是否被拦截
- 新环境上线前验证：确认出向 53 策略符合预期
- 排查容器环境解析：确认容器内到 DNS 服务器的 53 可达
- 与安全团队核对策略：明确哪些网段允许直连外部 DNS
端口级测试
端口级测试
dig +time=2 +tries=1 @223.5.5.5 example.com # UDP 查询（默认）
dig +tcp +time=2 +tries=1 @223.5.5.5 example.com # 强制 TCP 53
# 测内网 DNS（更贴近真实使用路径）
dig +time=2 +tries=1 @10.0.0.53 example.com
# TCP 端口探测：bash 内建方式最可靠
timeout 3 bash -c 'cat < /dev/null > /dev/tcp/223.5.5.5/53' && echo TCP53-OK || echo TCP53-FAIL
# nc 的 UDP 结果参考价值有限，仅作辅助
timeout 3 nc -zvu 223.5.5.5 53结果组合与结论
| UDP 53 | TCP 53 | 结论与方向 |
|---|---|---|
| 通 | 通 | 端口路径正常，问题在 DNS 服务或上游转发 |
| 通 | 不通 | 只放行了 UDP，大响应场景会失败，需放行 TCP 53 |
| 不通 | 不通 | 网络或策略整体阻断，先查安全策略与路由 |
| 不通 | 通 | 少见：可能 UDP 被单独丢弃，需查中间设备策略 |
| 超时但指定公共 DNS 通 | 内网 DNS 有问题 | 检查内网 DNS 服务状态与监听地址 |
企业网常见策略是只允许内网 DNS 出 53，直连公共 DNS 的流量被静默丢弃；此时 dig 指向公共 DNS 超时是策略使然，不代表故障。
对比出结论：同一台机器分别测内网 DNS 与公共 DNS，一侧通一侧不通，基本可以直接指向安全策略而不是服务故障。