DNS是TCP还是UDP：DMIT自建解析为何小记录能查、长答案却超时

小记录能查到，带签名或较长记录却超时，换一台更贵的VPS也可能原样复现。自建DNS只放行UDP的53端口，会把需要转到TCP的查询挡在另一条路径上。采购DMIT候选实例前，应先用同一域名、同一记录类型拆开验证UDP响应、截断标志与TCP返回，再谈线路和资源；单次ping延迟无法替这些交付结果作证。

先把“小包能通”的验收拆开

百度本次实际返回了“DNS是TCP还是UDP”“dns端口号53是UDP还是TCP”等建议，必应也出现相同方向的问题。对部署者而言，答案直接影响防火墙、监听地址和故障定位。RFC 7766要求通用DNS实现同时支持UDP和TCP；TCP并非只服务于区域传送。该文档还指出，网络层阻断TCP可能造成解析失败或应用层超时。查询成功一次，只证明那一次请求经过的路径能工作。

传统DNS在不使用EDNS时，UDP报文大小存在512字节边界。响应需要超过边界时，服务器通常将其截断并设置TC标志，客户端据此改用TCP查询。EDNS可以让请求方声明更大的UDP接收能力，却没有取消TCP需求，也没有替网络保证大报文一定抵达。要验的是客户端是否得到完整答案，而不是某个端口曾经返回过数据。

同一套自建服务可以分别从授权的外部测试机和服务本机发起检查。记录查询目标、记录类型、响应大小、TC标志、耗时与返回码；不能拿查询A记录的结果与查询DNSKEY的结果直接当作网络对照。前者短、后者可能长，差异本身就会改变传输选择。应使用自己控制的测试域，避免对第三方公共服务器施压。

图中的双路径只是传输选择示意。真正的TCP回退由DNS实现与报文状态决定，不对应两根物理网线，更不意味着购买双线路就自动具备容错。对于权威DNS，应从外部检查入站的UDP与TCP；对于递归解析器，还应查出站到上游的两种传输，以及响应返回时的状态规则。两种角色的测试目标不同，不能只给出一张“53端口已开”的截图结项。

用三组结果区分监听、策略与大包问题

第一组在服务器本机查询实际监听地址，并强制使用TCP。若本机也失败，先看进程是否监听TCP套接字、是否只绑定回环地址、服务配置和错误日志是否一致。此时换公网线路没有直接依据。本机成功、外部失败，则把云侧安全策略、宿主防火墙、地址绑定与运营商路径列为候选原因，逐层查证，不能直接归罪于商家。

第二组从同一外部测试机，针对同一个受控记录分别发起普通查询与强制TCP查询。使用dig时可以用+tcp明确选择TCP；观察UDP截断时可用+ignore阻止工具自动回退，以免默认自动行为掩盖中间步骤。命令选项只用于诊断，不应把禁止回退带入生产客户端配置。还应先核对本机dig版本和帮助输出，保存实际执行参数，不能照抄其他版本的显示格式。

第三组使用能稳定产生较长答案的测试记录，改变EDNS声明的大小，比较不同大小下的返回。RFC 6891说明，声明值应当是请求方真正能够接收的范围，过大的选择可能触发IP分片；单个分片丢失或防火墙配置问题，都可能让答案无法收全。提高EDNS值可以减少截断机会，也可能把故障移到分片交付环节。没有报文与路径证据时，不应把某个固定值宣传成所有网络的最佳值。

对于准备在DMIT上自管DNS的读者，本文含推广入口：查看DMIT服务器入口，核对双传输放行与自管权限。入口取自本轮渠道通网站17实时广告记录；官网直访超时，跳转到商家后遇到访问限制，因此本稿不列当前套餐价格、库存或退款承诺。渠道描述中的网络卖点，也不能证明某个订单已经通过上述DNS测试。

不要把连接建立成功当作查询完成

TCP握手成功只说明连接建立，后续仍需核对DNS消息是否完整接收、长度边界是否处理正确、查询与应答能否对应。RFC 7766允许连接复用及流水线处理，响应顺序可能与发出顺序不同。应用若按到达顺序机械配对，会把软件错误表现成偶发解析异常。采购验收应保留完整事务结果，而非只保留连通性工具的绿色提示。

高峰下的长尾等待也需要另算。短测试每次新建连接，得到的握手开销与生产中的连接复用不一致；反过来，长期保持很多空闲连接，又会占用连接状态与文件描述符。应分别测冷连接、复用连接和空闲后再用的行为，并记录中间设备是否回收连接。没有实际测试，本稿不能给DMIT任何实例承诺每秒查询量或持续并发上限。

把查询量换成采购预算，条件要写在数字旁边

一个可复算的演练情景是：峰值每秒2000次查询，其中5%进入TCP路径，平均占用0.2秒。在到达平稳、每次占用独立且不考虑空闲连接保留的简化前提下，TCP路径速率为每秒100次，平均在途请求约20个。这个结果来自速率乘停留时间，20是在途请求估算，不能直接当作20条连接的配置上限。流水线、复用、空闲保留及峰值突发都会改变连接数。

若平均占用增加到1秒，同样假设下平均在途请求变成100个。此时加CPU是否有效，取决于等待发生在本机计算、上游解析还是网络重传。将响应时间压低的目标，应与拒绝率、完整答案率一起验；只提高连接上限，可能让更多请求同时等待，并未提高完成速度。以上数字为预算演算，不是商家性能测试。

带宽也要分层核算。假设每秒100个TCP答案、每个DNS负载平均4096字节，则单方向答案负载约为每秒409600字节，即3.2768Mbps，未包含查询、IP与TCP头部、握手、重传和其他业务。套餐端口足以容纳这个平均负载，仍不能证明丢包条件下的尾延迟合格。月底总流量、峰值端口和连接状态是三份不同预算，询价时应分别问清。

继续比较配置前，可通过推广入口进入DMIT方案页，确认流量计费、控制台与测试条件。下单前要求商家明确：入站和出站TCP/UDP的53端口是否受限，是否允许预期用途，自管权限涵盖哪些策略，遭遇异常流量时怎样处置，测试失败能否退款以及期限从何时计算。这些问题没有得到书面答案，就不应把广告描述转换成采购保证。

旧版维护结束后，迁移交付要重新留下证据

本次检索到ISC在2026年6月10日发布的BIND 9.18维护终止说明，原文把当年6月维护版本列为最后一次，并建议迁向9.20。这是已经公布的维护节点，不能写成11月刚发生的新故障，也不证明某家主机正在使用旧版。它提醒自管服务的采购者：服务器交付与DNS软件维护由谁负责，必须在合同或工单中说清。

更换软件或迁往新实例后，应重新跑完整答案、TCP回退、连接复用与访问控制测试。上游版本停止维护，也不自动等同于发行版软件包没有安全补丁；需要核对发行版维护公告和已安装包来源。仅凭版本号要求重装，可能错判维护状态；仅凭服务进程仍在运行，亦无法证明维护责任已落实。

适合自管方案的是能够管理防火墙、监控并处理异常流量的团队，并且已经拿到用途许可与故障恢复入口。只想获得托管解析结果、无人维护安全更新的团队，应把托管DNS服务纳入比较，不能把低价VPS视为完整替代。无论选择哪条路线，都应明确递归访问范围，避免把测试时临时开放的递归权限留给整个互联网。

交付单最终应留下受控域名的两种传输记录、长答案测试和故障接手人，以及真实套餐的费用、权限与用途答复。若这些检查通过后，峰值完整答案率仍随CPU饱和而下降，才有依据比较更高规格；若问题停留在TCP被拦或软件配置，升级预算应先用来完成配置与维护交付。

资料来源

IETF：DNS通过TCP传输的实现要求

IETF：EDNS报文大小与分片边界

ISC BIND手册：dig查询与传输选项

ISC：BIND 9.18维护终止与升级说明，2026年6月10日