DNS 端口指南：端口 53 上的名称解析

当客户端需要访问某个域时，它会向解析器请求 A、AAAA、CNAME、MX、TXT、NS 或 SRV 等记录。解析器可以从缓存中进行应答，或者通过根、TLD 和权威服务器遍历 DNS 层次结构，直到找到记录。

大多数客户端查询使用 UDP 端口 53，因为请求和响应都很小。当响应太大、发生截断、DNSSEC 增加响应大小或服务器执行区域传输和其他需要可靠流的操作时，DNS 可以切换到 TCP。

UDP 53 是日常 DNS 解析的常用路径。阻止它通常会破坏正常的查找。对于完整的 DNS 部署，TCP 53 不是可选的：它支持大型答案、从截断的 UDP 响应中回退、DNSSEC 大量响应以及授权服务器之间的区域传输。

允许 UDP 53 但阻止 TCP 53 的防火墙规则可能会造成难以诊断的间歇性故障。小记录可能有效，而较大的 DNSSEC、TXT 或邮件相关响应会失败。

权威 DNS 服务器发布您控制的域的记录。当它为公共区域提供服务时，它应该可以通过互联网访问，但它应该只对这些区域进行权威回答，并且不应该提供开放递归。

递归解析器为客户端执行查找。公共递归解析器必须针对该角色进行设计和保护。内部解析器通常应仅对受信任的网络、VPN 客户端或特定应用程序环境进行应答。

向互联网开放端口 53，以供托管公共区域的权威 DNS 服务器使用。 UDP 和 TCP 都应该考虑。如果服务器仅用于内部，则限制对需要名称解析的网络的访问。

不要将递归解析器暴露给整个互联网，除非您有意操作具有速率限制、滥用监控和容量规划功能的公共解析器。开放解析器通常被滥用于反射和放大攻击。

在允许端口 53 之前，请确定服务器是否为权威、递归、转发、缓存或水平分割。确认哪些客户端应该使用它、它服务于哪些区域、是否启用递归以及区域传输是否仅限于授权的辅助服务器。

端口检查器可以确认端口 53 是否可达，但 DNS 正确性需要协议级测试。使用 dig、nslookup、drill 或解析程序日志来验证记录答案、递归策略、TCP 回退、DNSSEC 行为和响应时间。

在 Windows Server 上，DNS 服务器角色可以为 Active Directory 集成区域、内部记录和转发规则提供服务。仔细限制递归和区域传输，尤其是在服务器具有任何公共接口的情况下。

在 Linux 上，常见的 DNS 服务器包括 BIND、Unbound、PowerDNS、Knot DNS、CoreDNS 和 dnsmasq。配置 UDP 和 TCP 53 的侦听接口、递归策略、允许的客户端、权威区域、日志记录和防火墙规则。

在云平台上，托管 DNS 对于公共权威区域来说通常更安全，因为提供商负责处理选播、扩展和基线 DDoS 恢复能力。自托管 DNS 仍然需要冗余实例、监控和明确的网络策略。

从外部端口检查 UDP 或 TCP 53 开始，具体取决于您需要验证的内容。然后针对目标解析器运行 dig @server example.com A、dig @server example.com AAAA 或 nslookup 以确认真实的 DNS 答案。

使用 dig +tcp @server example.com TXT 或其他大型响应显式测试 TCP。对于权威服务器，从网络外部查询记录并验证递归是否被拒绝。对于递归解析器，从允许和不允许的源网络进行查询。

如果端口 53 关闭，DNS 服务可能会停止、侦听错误的接口、被主机防火墙阻止或受到云安全组的限制。如果 UDP 看起来不可靠，但 TCP 有效，请检查 MTU、分段、响应大小、EDNS 设置和 DNSSEC 相关行为。

如果端口打开但查找失败，请检查区域数据、委派、粘合记录、SOA 和 NS 记录、递归策略、转发器、DNSSEC 验证、缓存状态和日志。 DNS 故障通常来自策略或区域配置，而不是原始端口可达性。

不要意外运行打开的递归解析器。限制对受信任客户端的递归，限制对已知辅助服务器的区域传输，保持 DNS 软件修补，并监控查询率、NXDOMAIN 峰值、SERVFAIL 峰值和异常源网络。

对于公共权威 DNS，请使用冗余服务器、适当的 DNSSEC、足够短的 TTL 以实现操作灵活性，并明确区域更改的所有权。对于内部 DNS，请保护水平分割记录，因为它们通常会泄露基础设施名称和私有拓扑。