DNS port 是多少？53 端口 TCP/UDP 区别与排查方法

更新于 2026-10-30 · suyungo.buzz

简答：DNS 的传统端口是 53，UDP 53 用于大多数普通查询，TCP 53用于截断后的重试、较大响应和区域传送。配置防火墙时通常应同时考虑 UDP 53 与 TCP 53；如果使用 DoT，默认是 TCP 853，DoH 通常通过 HTTPS 443，mDNS 则使用 UDP 5353。

定义：DNS port 是 DNS 客户端或服务器收发解析请求所使用的网络端口，传统单播 DNS 默认使用 UDP 53 和 TCP 53。

先看结论：DNS 端口与协议速查表

如果你正在配置服务器、防火墙、云安全组或网络工具，最短判断是：传统 DNS 不要只放行 UDP 53，通常还应允许 TCP 53；客户端发出的源端口一般是随机高位端口，DNS 服务器的目标端口才是 53。IANA 将 53/TCP 和 53/UDP 注册为 Domain Name Server 服务。IANA 端口注册表。iana.org

协议或用途	常见端口	传输方式	主要用途	配置时注意
传统单播 DNS	53	UDP	大多数普通名称查询	通常优先使用，开销较低
传统单播 DNS	53	TCP	较大响应、截断重试、区域传送	不要因平时 UDP 可用就关闭
DNS over TLS（DoT）	853	TCP	通过 TLS 加密的 DNS	默认不应把明文 DNS 发到 853
DNS over HTTPS（DoH）	443	TCP/TLS/HTTP，或 HTTP/3	把 DNS 查询封装在 HTTPS 中	不能仅靠开放 53 判断是否可用
DNS over QUIC（DoQ）	853	UDP/QUIC	通过 QUIC 传输加密 DNS	与普通 UDP 53 不是同一种流量
Multicast DNS（mDNS）	5353	UDP 多播	局域网设备发现和 .local 名称	不等同于公网单播 DNS

DoT 默认使用 TCP 853，DoQ 默认使用 UDP 853；DoH 则建立在 HTTPS 之上，常见入口是 443。mDNS 使用 UDP 5353，并面向局域网多播地址，不应与普通 DNS 53 混为一谈。相关定义可查阅 RFC 7858、RFC 8484、RFC 9250 和 RFC 6762。rfc-editor.org

DNS 使用 TCP 还是 UDP？为什么两者都需要

普通 DNS 查询通常先使用 UDP 53，因为 UDP 不需要建立连接，报文开销较小。若响应超过当前 UDP 传输条件，服务器可能返回截断标志，客户端再通过 TCP 53 重新查询。Windows Server 文档也说明，DNS 查询通常从随机高位源端口发往服务器的 53 端口，响应则从服务器的 53 端口返回客户端的高位端口。Microsoft Learn：Network Ports Used by DNS。learn.microsoft.com

TCP 53 不只是“UDP 失败后的备用端口”。DNS 区域传送 AXFR 一直使用 TCP；IXFR 等同步场景也需要可靠、有序的传输。RFC 7766 要求完整的 DNS 实现同时支持 UDP 和 TCP，并指出 DNSSEC、IPv6 等场景可能增加较大响应出现的机会。RFC 7766：DNS Transport over TCP。rfc-editor.org

只开放 UDP 53：简单查询可能正常，但大响应、区域传送或必须改用 TCP 的请求可能超时。
只开放 TCP 53：部分客户端仍会先发 UDP 查询，因此可能表现为解析慢、重试或完全失败。
同时开放 UDP/TCP 53：更符合传统 DNS 服务器和递归解析器的常见要求，但仍应限制来源、关闭不必要的递归功能。

服务器、防火墙和客户端端口应该怎么配

先区分三个概念：服务器监听端口、客户端目标端口、客户端源端口。传统 DNS 服务器通常监听 UDP 53 和 TCP 53；客户端向服务器的目标端口是 53，但客户端自己的源端口一般由系统临时分配，通常是高位随机端口。不要把“客户端使用了随机源端口”误解成 DNS 服务器需要监听所有高位端口。

服务器或云防火墙

递归解析服务器：按实际服务范围允许 UDP 53 和 TCP 53；如果只服务内网，应限制来源网段，不要默认对整个公网开放递归查询。
权威 DNS 服务器：公网权威解析通常需要接收 UDP 53 和 TCP 53；具体 ACL、区域传送来源和主从关系应按 DNS 软件配置。
DoT 服务：确认客户端与服务器约定的是 TCP 853，并检查证书、服务器名称和 TLS 握手。
DoH 服务：按具体服务监听的 HTTPS 地址和端口配置，不能仅凭“这是 DNS”就放行 53。
局域网设备发现：若问题涉及打印机、局域网主机名或 .local，检查 UDP 5353、多播范围和网卡防火墙，而不是只测试 53。

端口登记本身不等于流量合法。IANA 明确提示，注册端口不代表流经该端口的流量一定属于登记服务，因此防火墙规则还应结合来源、目标、应用和日志判断。IANA Service Name and Port Number Registry。iana.org

用命令测试 DNS port 是否可达

测试时建议先用一个明确的 DNS 服务器地址替换 DNS_SERVER，例如企业内部解析器或你已获授权使用的公共解析器。不要把含账号、订阅链接或内部域名的完整命令输出直接发到公开平台。

Windows：先查解析，再测 TCP 53

测试普通 DNS：nslookup example.com DNS_SERVER。预期能看到服务器地址和解析结果；若提示超时，继续测端口和防火墙。
测试 TCP 53：Test-NetConnection DNS_SERVER -Port 53。若 TcpTestSucceeded 为 True，表示 TCP 连接层可达，但不代表 DNS 查询逻辑一定正确。
测试 DoT：Test-NetConnection DNS_SERVER -Port 853。这只验证 TCP 853 可建立，不能替代证书和 TLS 名称校验。
失败回退：如果 UDP 查询正常但 TCP 53 失败，检查服务器 TCP 监听、防火墙入站规则、云安全组和中间设备策略。

Linux 或 macOS：用 dig 与 nc 分层判断

普通查询：dig @DNS_SERVER example.com。观察是否返回 status: NOERROR、是否有 ANSWER，以及响应是否带有截断标记。
强制 TCP 查询：dig +tcp @DNS_SERVER example.com。普通查询成功而强制 TCP 失败，通常指向 TCP 53 路径、监听或防火墙问题。
测试 TCP 端口：nc -vz -w 3 DNS_SERVER 53。显示 succeeded 只能说明 TCP 端口可连接，不能证明 DNS 协议响应正确。
测试 UDP：nc -vzu -w 3 DNS_SERVER 53。UDP 没有像 TCP 那样的连接建立过程，因此该结果只能作为辅助证据，最好结合 dig 或抓包确认。
失败回退：若 dig +tcp 失败，先检查本机路由和防火墙，再从同一网段另一台主机重复测试，以区分客户端问题和服务器问题。

DNS 解析失败时，按症状排查端口、DNS 和 MTU

不要看到“网页打不开”就直接修改 DNS。先判断失败发生在哪一层：域名是否解析、解析器端口是否可达、返回地址是否可用、还是后续连接被阻断。

现象	优先检查	下一步
`nslookup` 超时	DNS 服务器地址、UDP 53、路由和本机防火墙	换同网段客户端测试，再执行 `dig +tcp`
普通查询成功，TCP 查询失败	TCP 53 监听、云防火墙和中间设备	确认服务器没有只配置 UDP
返回截断或响应不完整	TCP 53、EDNS、路径 MTU 和 DNSSEC 响应大小	用 `dig +tcp` 对照测试，必要时抓包
DoT 连接失败	TCP 853、证书名称、系统时间和 TLS 配置	不要把 853 当作明文 DNS 53 使用
局域网 .local 无法解析	UDP 5353、多播地址、网卡和本地防火墙	不要只测试单播 DNS 53
只有某个客户端失败	本机代理、TUN、VPN、DNS 劫持或本地服务占用	暂时停用一个网络组件后复测

如果使用网络工具或客户端后出现“连接成功但域名打不开”，可先回到系统 DNS，分别测试 UDP 53、TCP 53 和应用实际使用的加密 DNS 端口。若修改 MTU 后问题变化，记录修改前后的结果并保留回退值；不要把单一设备上的 MTU 数字当成所有网络的统一标准。

53 端口被占用：如何确认是不是 systemd-resolved

Linux 主机上，如果本地解析器服务监听了回环地址的 53 端口，另一个 DNS 服务可能无法绑定同一地址和端口。先确认监听者，再决定停用、改监听地址，还是让新服务转发到本地解析器。

查看 53 端口监听：sudo ss -lntup | grep ':53'。重点记录监听地址、协议、进程名和 PID。
查看 systemd-resolved 状态：systemctl status systemd-resolved。
查看本机解析状态：resolvectl status。确认当前上游 DNS、网卡和 DNS 作用域。
确认进程详情：sudo lsof -nP -iTCP:53 -iUDP:53。
回退路径：不要直接删除 /etc/resolv.conf。先备份现有文件和服务配置，再按发行版文档调整 resolved、NetworkManager 或目标 DNS 软件的监听方式。

如果监听只绑定在 127.0.0.53 或其他回环地址，它与公网网卡上的 53 端口是否冲突，要结合具体绑定地址判断；不能仅凭“看到 53 端口”就认定所有网卡都被占用。

安全检查：开放 DNS 端口前先确认服务边界

开放 UDP/TCP 53 会让服务暴露在网络上，配置前应明确它是本地缓存、内网递归、权威解析还是转发器。尤其不要因为测试方便就对公网开放不受限制的递归查询。测试完成后，删除临时放行规则，并检查日志中是否出现异常来源、重复失败或不符合预期的查询类型。

对于 DoT、DoH 和 DoQ，端口不同不等于自动安全：还要核对服务端身份、证书或客户端配置，确认查询确实走了目标协议。DoH 是通过 HTTPS 传输 DNS 查询，RFC 8484 明确其实现建立在 IP、TCP、TLS 和 HTTP 之上，因此单纯测试 UDP 53 不能证明 DoH 可用。RFC 8484。rfc-editor.org

常见问题

DNS 默认端口是多少？

传统单播 DNS 默认使用 53 端口，并同时登记了 UDP 53 和 TCP 53。普通查询多使用 UDP，但服务器和防火墙通常不应忽略 TCP 53。

DNS 只开放 UDP 53 可以吗？

不建议作为通用 DNS 配置。普通查询可能暂时正常，但较大响应、截断重试和区域传送可能需要 TCP 53。应结合服务器类型、客户端行为和防火墙日志确认。

DNS 的 TCP 53 端口主要做什么？

TCP 53 可用于较大 DNS 响应、UDP 响应被截断后的重试，以及 AXFR 等区域传送。RFC 7766 要求完整 DNS 实现支持 UDP 和 TCP。

DoT、DoH 和 DoQ 分别使用什么端口？

DoT 默认使用 TCP 853；DoQ 默认使用 UDP 853；DoH 通过 HTTPS 传输，常见是 443。实际服务也可能约定其他端口，应以服务端配置和协议文档为准。

客户端 DNS 源端口也是 53 吗？

通常不是。客户端一般使用系统分配的临时高位源端口，向 DNS 服务器的目标端口 53 发起请求；服务器响应从源端口 53 返回客户端临时端口。

为什么 ping DNS 服务器成功，但 DNS 解析仍然失败？

ping 主要测试 ICMP，不等于 UDP 53、TCP 53 或加密 DNS 端口可用。应使用 nslookup、dig、Test-NetConnection 或抓包分别测试 DNS 协议路径。

UDP 5353 是普通 DNS 端口吗？

不是。UDP 5353 主要用于 Multicast DNS，也就是 mDNS，常见于局域网设备发现和 .local 名称解析；它与普通单播 DNS 53 的地址范围和工作方式不同。