你在浏览器里敲下一个网址回车页面就出来了。整个过程快得像变魔术——但魔术的幕后有一场小小的协议博弈DNS到底走UDP还是TCP这个问题比大多数人以为的要复杂。答案不是非此即彼而是看情况。而这个看情况背后的逻辑恰好藏着互联网设计中最务实的智慧。默认选手UDP绝大多数时候DNS查询用的是UDP。原因不难理解。DNS查询本质上是一问一答——客户端发一个baidu.com的IP是多少服务器回一句220.181.38.148完事。这种交互模式短小、直接UDP简直是为它量身定做的。UDP不需要握手。TCP在传输数据之前得先来一轮三次握手——你准备好了吗我准备好了你呢我也准备好了。这对动辄几十字节的DNS查询来说是巨大的浪费。打个比方你只是想问路人几点了总不能先跟人家签个合同、互换名片、确认通信渠道然后再开口吧UDP就是直接问问了就走干净利落。在RFC 1035的原始设计里DNS的UDP报文被限制在512字节以内。这个数字不是随便定的——它刚好能塞进大多数网络链路的MTU而不触发IP分片既快又安全。服务器那边也轻松不需要为每个查询维护连接状态处理完就忘资源占用极低。于是一切岁月静好。直到有一天DNS的行李开始变多了。什么时候切换到TCP几种情况会逼着DNS转投TCP的怀抱。第一种响应太大UDP装不下了。随着DNSSECDNS安全扩展的普及DNS响应里塞进了数字签名、密钥记录等一堆额外信息。一个原本两三百字节的回答可能膨胀到一两千字节。虽然EDNS0机制把UDP的上限放宽到了4096字节但这只是延缓了问题没有根治。一旦响应真的超了服务器会把UDP报文截断并在报文头里置一个TCTruncation标志位。客户端收到这个标志就知道信息被砍了一半得老老实实回头用TCP重新查一遍。第二种区域传输。这是DNS服务器之间的搬运操作——主服务器把整个区域的记录同步给辅助服务器。成百上千条记录用UDP传根本不现实而且可靠性也撑不住。所以RFC规定区域传输AXFR和IXFR必须用TCP没有商量余地。第三种TCP本身的可靠性在某些场景下成了刚需。UDP不保证送达丢包了没人管。对于普通的小查询丢了重查就行代价不大。但对于大响应或者需要保证完整性的操作TCP的重传机制和有序传输就变得不可替代。各自的账本UDP的优势很直白快、轻、省资源。没有连接建立的开销查询延迟低到几乎可以忽略。DNS服务器每天处理几十亿次查询如果每次都握手服务器早就被连接状态淹没了。UDP的无状态在这里反而是优点。但UDP的短板同样明显不可靠、有大小限制、容易被伪造。丢包全靠客户端超时重传来兜底报文大小有硬上限更麻烦的是UDP没有连接验证机制攻击者可以比较容易地伪造DNS响应——这正是DNS缓存投毒攻击能得手的原因之一。TCP正好把这些问题逐个补上了可靠传输、无大小限制、连接过程提供了一定的身份验证。三次握手虽然慢但至少让伪造响应变得困难得多。代价是慢和重。建立连接要时间维护连接要内存高并发下服务器的压力陡增。如果所有DNS查询都走TCP互联网的DNS基础设施大概要重新设计一遍。不完美的平衡恰恰是工程的美感所以DNS的设计本质上是一个务实的折中日常查询用UDP追求效率和规模真正需要可靠性和完整性时切换到TCP保证正确。两种协议各司其职由一个简单的TC标志位来触发切换。这个设计已经运行了将近四十年期间互联网规模膨胀了不知多少个数量级它依然扛得住。后来者如DNS over TLS、DNS over HTTPS在协议栈上做了更多文章但底层的UDP优先、TCP兜底逻辑从未被推翻。好的工程设计往往不是追求理论上的完美而是找到那个够用且高效的平衡点。DNS协议选择了一条不设限的路——它不绑定于某一种传输方式而是让具体情况决定走哪条路。这种灵活性可能比任何单一协议的优劣都更值得记住。毕竟能随时切换思路才是真正的生存智慧。协议如此其他事大概也差不多。参考资料RFC 1035,Domain Names - Implementation and Specification, P. Mockapetris, 1987.RFC 6891,Extension Mechanisms for DNS (EDNS0), J. Damas et al., 2013.RFC 4033,DNS Security Introduction and Requirements, R. Arends et al., 2005.RFC 7766,DNS Transport over TCP - Implementation Requirements, A. Elkins et al., 2016.Paul Albitz Cricket Liu,DNS and BIND, O’Reilly Media, 5th Edition, 2006.
