域名服务器通信，默认走的是53端口。这个数字在DNS的世界里基本是固定的，不管是Windows Server自带的DNS服务，还是BIND、Unbound、CoreDNS这些常用软件，监听的都是53。客户端发查询请求，目标端口写53，服务器收到之后处理完再回给客户端。整个过程看起来简单，但底下分两种传输方式，UDP和TCP，用哪个取决于你在干什么。
日常上网时，你打开一个网页，浏览器背后要解析十几个域名，每个解析请求都是一个小包，问一句“example.com的IP是多少”，服务器回一句“93.184.216.34”。这种一问一答的模式用UDP最合适，不需要建立连接，发出去等回复就行，速度快，开销小。所以绝大多数DNS查询跑在UDP 53上。你电脑里配的DNS服务器地址，比如114.114.114.114或者8.8.8.8，默认就是在UDP 53上跟它们通信。
但UDP有一个天生的限制：单个数据包不能太大。传统DNS规定UDP报文最大512字节，超过这个长度就得换TCP。什么时候会超过？比如一个域名有十几个MX记录，或者返回的TXT记录很长，又或者DNSSEC签名信息塞进来，512字节就不够用了。早期遇到这种情况，DNS服务器会返回一个截断标志，告诉客户端“包太大了，你用TCP再来问一次”。客户端收到截断响应之后，重新用TCP 53发起同样的查询，这次就能拿到完整数据。所以TCP 53不是备胎，它是UDP搞不定时的正经通道。
区域传送是另一个必须用TCP的场景。主DNS服务器和从DNS服务器之间同步数据，一次要传几百上千条记录，这种批量操作只能用TCP。你用dig命令加axfr参数去拉一个域名的完整区域文件，它走的就是TCP 53。有些管理员在防火墙上只放行了UDP 53，结果从服务器同步一直失败，排查半天才发现是TCP 53被拦了。所以配防火墙的时候，53端口的UDP和TCP都要开，缺一个都可能出问题。
EDNS0扩展出来之后，情况稍微变了点。它允许UDP报文超过512字节，通过协商一个更大的缓冲区，常见的是1232字节或者4096字节。这样很多以前需要走TCP的查询，现在UDP也能扛了。但EDNS0不是所有设备都支持，老旧的防火墙和NAT设备可能会把大包直接丢掉，导致解析超时。所以实际网络里，TCP 53依然有它的位置，不是被EDNS0完全替代了。
除了53端口，这几年还冒出几个跟DNS相关的新端口。DNS over TLS，简称DoT，用的是853端口，把DNS查询塞进TLS加密通道里，防止中间人偷看或者篡改。DNS over HTTPS，简称DoH，走的是443端口，把DNS查询伪装成普通的HTTPS流量，更难被识别和拦截。这两个都是为了解决传统DNS明文传输的安全问题，但它们的端口跟传统DNS完全不一样。你在浏览器里开启“安全DNS”之后，流量就不再走53了，改走853或者443。
还有一个不太常见的mDNS，多播DNS，用在局域网里，端口也是5353，不是53。它让设备在本地网络里互相发现，比如打印机、智能音箱、AirPlay这些。mDNS跟传统的单播DNS是两套东西，不要搞混。
回到日常使用，你不需要记太多。配服务器防火墙，53的UDP和TCP都放行。排查解析问题，先确认UDP 53通不通，再看TCP 53有没有被拦。用dig或者nslookup测试的时候，加+tcp参数就能强制走TCP，看看是不是UDP那边出了问题。这些操作都很基础，但真遇到解析故障的时候，能帮你省下不少瞎猜的时间。