摘要

  • 截至 2026 年 8 月 5 日，IETF Datatracker 的 Ray Bellis 人物页列出十份 RFC，包括 2026 年 7 月发布的 RFC 10029；当时没有列出活跃 Internet-Draft。这是公开文件与署名索引，不是个人独占发明或普遍部署证明。[1]
  • Bellis 署名的 RFC 5966 在 2016 年被五位作者共同完成的 RFC 7766 取代。后者要求完整的通用 DNS 实现支持 TCP，并把 TCP 视为可正常选择的传输方式，而不只是 UDP 失败后的特殊补救。[3] [4]
  • RFC 7828 与 RFC 8490 为长连接增加了可表达的空闲时间、会话建立、成功、失败、超时与关闭状态。标准定义双方如何沟通，服务器仍根据本地资源决定容量和限制。[5] [6]
  • RFC 8906 指出，不回应本身就是运营问题。丢包、过滤、不支持的功能、限速和错误实现可能让客户端看到同样的空白等待；在非攻击环境中，明确协议回应能减少猜测。[7]
  • RFC 9619 明确普通 DNS 查询通常只有一个主要问题；RFC 10029 在此基础上使用 EDNS 请求额外记录类型，并说明哪些类型已完整处理、哪些需要单独重试。它是 2026 年 7 月发布的 Proposed Standard（IETF“提议标准”状态），不能写成已广泛采用。[8] [9]

一个名字背后有多条独立运行的链路

DNS 是 Domain Name System，也就是域名系统。它把人能读懂的名称连接到应用可使用的数据。浏览器可能询问 A 记录来获得 IPv4 地址，询问 AAAA 记录来获得 IPv6 地址，也可能需要 HTTPS 等记录来准备连接。

应用通常把问题交给解析器。解析器是负责寻找答案的软件或服务；递归解析器会沿着域名委派逐步查询，直到找到负责该区域的权威服务器。这里的“权威”只表示服务器发布某个 DNS 区域的正式数据，并不代表它管理其他网络。缓存则会在有效期内保存结果，减少重复查询。

真实路径上还可能有家庭网关里的 DNS 代理、防火墙、负载均衡器、地址转换设备和不同运营商的网络。域名运营者维护委派与权威数据，递归服务决定怎样重试，设备厂商实现协议，应用决定用户最多等待多久。这些责任没有集中在一处。

当消息表达清楚时，分散运行并不会妨碍协作。“名称不存在”表示服务器理解了问题，但没有对应名称；“未实现”表示操作不受支持；响应里的截断标志说明当前消息没有容纳全部内容，客户端可以换用能承载更大响应的方式。

沉默则没有语义。解析器不知道该继续等、重新发送、改问另一台服务器、移除扩展，还是切换传输方式。每一种选择都可能合理，但连续尝试会消耗应用的时间预算。即使最后成功，第一次失败的原因也可能从记录中消失。

Bellis 参与的多份文件持续处理的正是这条边界：让一方更明确地告诉另一方自己理解了什么、完成了什么、拒绝了什么，以及还可以尝试什么。这类共同规则是协调记录，不是中央控制。服务器的容量、过滤策略和运行选择仍由各自运营者掌握。

TCP 从“特殊情况”走进完整 DNS 能力

DNS 常见的两种传输方式是 UDP 和 TCP。UDP 不先建立持久连接，适合小型、快速的问答；TCP 先建立连接，维护连接状态，并能可靠承载较大的数据。代价是服务器需要分配套接字、内存、队列和处理时间。

入门材料常把 DNS 简化成“平时用 UDP，响应太大或传送区域数据时才用 TCP”。这句话描述了部分历史习惯，却容易让团队把 TCP 当作可有可无的备用项。随着 DNSSEC 这种为 DNS 数据提供签名验证的机制让响应变大、网络分片并不总是可靠，这条备用路径一旦未经测试，就会变成真实故障点。

2010 年 8 月发布的 RFC 5966 把 R. Bellis 列为作者，规定了 DNS 通过 TCP 传输的实现要求。[3] 这份文件后来被取代。2016 年 3 月，John Dickinson、Sara Dickinson、Ray Bellis、Allison Mankin 与 Duane Wessels 五位作者共同完成 RFC 7766，并使 RFC 5966 失效。[4]

RFC 7766 要求完整的通用 DNS 实现同时支持 UDP 与 TCP。解析器可以因为本地运营考虑直接选择 TCP，不必先经历一次 UDP 失败；如果已有合适的 TCP 连接，文件还建议复用。[4]

对普通用户而言，影响可能出现在完全看不到 DNS 的地方。权威数据和网络路径都正确，但中间防火墙只放行 UDP，并把 TCP 静默丢弃。小查询仍会成功，较大响应却进入长时间等待。此时一句“DNS 服务器能回答”并不能说明整条服务路径合格。

RFC 的文字不证明所有产品都已照做。它提供可检验的共同要求：用同一名称与类型分别测试 UDP 和 TCP，观察连接是否建立、响应是否完整、连接能否复用，以及失败时究竟收到明确拒绝还是只等到超时。

RFC 5966 被 RFC 7766 取代也很重要。旧文件没有被神化成永远不变的答案，而是把责任交给更新的多人文件。Bellis 出现在两个阶段，能够证明持续参与，不能把 TCP 或 DNS 传输写成他的私有设计。

DNS 代理可能转发了数据，却改变了含义

DNS 代理接收本地客户端的问题，再转发给其他解析服务。家庭路由器和企业局域网常见这种设计。客户端以为自己在直接询问 DNS 服务，实际还有一层程序负责复制字段、处理大小、保留错误码和支持传输切换。

2009 年发布的 RFC 5625 把 Bellis 列为作者，为 DNS 代理实现提供指导。[2] 这份文件不能证明每台网关都符合要求，但说明了为什么“只是转发”也需要严格测试。

一台代理可能顺利处理最普通的 A 记录，却在大响应、未知类型、EDNS 选项或 TCP 出现时出错。EDNS 是给 DNS 增加可协商能力和额外选项的机制，并不替换主要问题。如果代理删除自己不认识的信息，或者把应当返回的错误变成沉默，客户端可能误以为权威服务器出了问题。

因此，兼容性测试不能只换几个域名。它需要比较普通 DNS 与 EDNS、UDP 与 TCP、已知类型与未知类型、小响应与截断响应。设备暂时不支持新功能并不等于整个系统失效，前提是这种“不支持”能够被看见，并触发有边界的替代路径。

Bellis 在这里可被准确描述为公开指导文件的作者。设备怎样实现、运营者怎样配置、具体产品是否合格，都不在来源能证明的范围内。

长连接首先是一项资源决定

TCP 连接可以复用，避免每个 DNS 问题都重新建立连接。但只要连接保持，服务器就需要保存状态。关闭太快会失去复用收益；永远不关则可能在高负载或攻击下耗尽资源。

RFC 7828 由 Paul Wouters、Joe Abley、Sara Dickinson 和 Ray Bellis 共同完成，定义 edns-tcp-keepalive 选项。[5] 客户端可以表达希望保留连接，服务器则返回适合本地情况的空闲时间。资源不足时，服务器可以给出零，要求客户端在完成待处理请求后关闭。

零并不必然是故障。它可能是一条明确的容量信号：服务器现在不愿继续保留空闲连接。客户端可以根据这条信号行动，运营团队也能把它与无说明断开分开统计。

标准没有为全球所有服务器规定同一个时长。小型权威服务、大型递归服务和遭受攻击的节点面对完全不同的压力。文件定义字段与含义，实际资源策略仍留给掌握服务器的人。

RFC 7828 还提到 anycast 路由变化可能打断长连接。Anycast 是多个地点发布同一地址、由路由把用户带到其中一个地点的方式。如果路径中途改变，已有会话未必还能抵达同一台服务器。中间设备也可能对 EDNS 选项或消息大小处理不当。[5]

所以，监控不能只问“当前有多少连接”。更有用的记录包括建立耗时、复用次数、空闲时长、关闭方、关闭原因、仍在等待的请求和各 anycast 站点差异。标准信号不能增加内存，却能让资源决定更可见。

DSO 把连接、会话和关闭分开记录

TCP 已经连接，不代表双方已经同意更高层的会话操作。RFC 8490 定义 DNS Stateful Operations，简称 DSO，也就是 DNS 带状态操作，用于持久连接上的会话功能。[6]

这份文件有六位作者，其中包括 Bellis。它区分连接建立、DSO 会话请求、成功、失败、超时、已建立运行与关闭，并定义保持连接、建议延后重试和隐私填充等操作。每次请求有一个主要操作，响应码表明成功或失败。

这套状态避免把“套接字还开着”误当成“会话已经可用”。客户端可能只是连上了 TCP，正在请求 DSO 会话；服务器可以明确拒绝，也可能没有及时回应。两种情况都不是成功，但后续处理不同。

Timeout 通常译作超时，指系统等到预设期限后停止等待。超时只表明没有在时限内收到所需结果，本身不揭示根因。在 DSO 会话建立中，它至少指出故障发生在哪一步，并要求客户端终止连接；根据情况，客户端之后可以不使用 DSO 重新连接。[6]

如果收到非零响应码，说明 DSO 会话请求失败，但普通 DNS 仍可以在已连接、无 DSO 会话的状态中继续。这个事实比笼统的“DNS 断了”更适合排查和交接。

RFC 8490 没有提供部署规模，也不能保证会话长期可用。网络仍会丢失，服务器仍有容量边界，中间设备仍可能干扰。它的作用是让更多运行阶段拥有共同名称。

不回应会把不同故障压成同一种现象

2020 年 9 月发布的 RFC 8906 由 Mark Andrews 和 Ray Bellis 共同完成，直接讨论 DNS 服务器“无法沟通”的常见运营问题。[7]

一条格式正确的请求没有回应，可能因为数据包丢失、EDNS 选项被过滤、服务器限速、未知操作处理错误或实现缺陷。客户端看不到服务器的动机，只能看到计时器继续前进。

RFC 8906 主张，在非攻击条件下，名称服务器应当回应格式正确的请求。文件列出未知类型、标志、操作码和 TCP 查询应得到的明确结果，同时承认服务器遭受攻击时可能需要丢弃数据包或限制响应。[7]

这个例外保留了运营者的本地安全决定。共同标准并不要求服务器无限消耗资源。问题在于，如果日常不支持也一律用沉默表示，合法客户端就无法区分防护措施与实现错误。

Fallback 是首选方法不可用时采取的替代路径。解析器发出 EDNS 请求后等不到回应，可能移除 EDNS 再问一次。最终页面也许能打开，但 DNSSEC 验证或新扩展可能因此无法使用。用户被保护了，兼容性缺口却藏在“最后成功”之后。

RFC 8906 还把回应问题连接到委派维护。上级区域的 NS 记录指定负责下级区域的服务器，下级区域自身也发布 NS 记录。文件建议父区运营者检查两边是否一致。[7] 过期委派可能继续把查询送往已经不再负责的服务器。

明确错误能够保护客户端有限的重试时间。格式错误、“未实现”、普通否定回应和清晰的 TCP 拒绝都不是理想答案，但它们缩小了判断范围。沉默则把猜测成本分摊给每个客户端。

一个主要问题可以带上额外类型

DNS 消息里的 QDCOUNT 字段用于记录问题数量。早期报文格式看起来容许多个问题，但不同实现没有形成可靠的一致处理方式。Ray Bellis 与 Joe Abley 共同完成、2024 年发布的 RFC 9619 明确：普通 DNS 查询通常有一个问题。[8]

现代应用却经常需要同一名称的多类数据。准备连接时，客户端可能同时需要 A、AAAA 和 HTTPS。如果每种类型都单独查询，就会增加往返与服务器处理次数。

Bellis 署名的 RFC 10029 在 2026 年 7 月以 Proposed Standard 发布，定义 DNS Multiple QTYPEs。[9] 它保留一个主要问题，通过 EDNS 选项列出希望同时得到的额外记录类型。服务器在响应选项中说明哪些额外类型已完整处理。

即使整体响应被截断，符合规范的服务器也要针对有效请求返回这个选项。某个类型没有完整回答，就不能被列为完成。客户端无需猜测，可以再为剩余类型发送独立查询。

这条独立查询路径就是兼容性后备。如果服务器不支持扩展、返回格式错误或只处理部分类型，主要问题的答案仍可能被使用，未完成部分回到普通查询。新能力没有把旧服务器排除在 DNS 之外。

合并也有成本。一条请求可能要求更多服务器工作并产生更大响应，增加 DNS 放大攻击风险。因此 RFC 要求实现提供运营者可配置的限制，具体数值取决于环境。[9]

这份文件刚刚发布，不能用规范存在来代替部署证据。接下来真正值得观察的是支持比例、哪些类型常被省略、独立查询发生多少、响应大小如何变化，以及服务端增加了多少工作。

公开记录展示的是接力，不是个人所有权

在查询日期，Datatracker 为 Bellis 列出十份 RFC。[1] 这个数字只应作为人物页当时的文件索引使用，不能扩展成完整履历或影响力排名。

署名形式不断变化。RFC 5625 和 RFC 5966 把 Bellis 列为作者；RFC 7766、7828、8490、8906 与 9619 都有多位作者；RFC 10029 再次列 Bellis 为作者，同时仍是 IETF 共识流程形成的公开规范。[2] [3] [4] [5] [6] [7] [8] [9]

文件之间存在清晰接力。RFC 7766 取代 RFC 5966；RFC 8490 为持久连接增加会话状态；RFC 10029 以 RFC 9619 的单一主要问题规则为基础。任何工程师都可以查阅、比较、实现或质疑这些文本。

来源因此支持一个有限而准确的结论：Bellis 多次参与 DNS 公开规范的编写。来源不支持他单独发明 DNS over TCP、EDNS、DSO、DNS 代理或 Multiple QTYPEs，也不支持关于其私人动机、当前任职或特定部署成效的推断。

真正可以延续的是公开记录。作者会变化，旧文件会被更新，运行软件会暴露新的问题。规范负责留下共同描述，实际代码与网络负责证明描述是否成立。

最终结果仍要回到运行中的系统

发布 RFC 不会自动更新老旧网关，不会打开防火墙的 TCP，也不会为服务器增加连接内存。它同样无法保证 anycast 路由不变，或保证解析器把每次后备尝试都报告出来。

新机制还会带来新选择。DSO 增加需要保护和监测的会话状态。Multiple QTYPEs 可能减少多次往返，也可能增加单次工作量。服务器限制保护容量，却会留下未完成类型。Fallback 保护用户，却可能在只看最终成功率时掩盖低支持度。

因此，书面要求是测试目标，不是运行结果。响应码是收到的证据，不是低延迟保证。超时是状态，不是根因。新 Proposed Standard 是公开协调起点，不是部署完成证明。

DNS 连续性最终取决于现实层：权威数据是否准确，委派是否一致，UDP 与 TCP 是否都可用，错误是否明确，连接限制是否可观察，替代路径是否经过测试。维护共同记录的机构帮助协调这些信息，但不会替服务器运行，也不会替运营者承担本地决策。

Bellis 的公开工作贯穿着一个朴素问题：当一方不理解、没有完成、受资源限制或需要关闭一项 DNS 操作时，另一方能否收到可用于下一步的事实，而不是只在沉默中耗尽等待时间？这些文件没有消灭所有故障，却让更多故障不再长得完全一样。

来源

  1. IETF Datatracker，Ray Bellis 人物页。
  2. RFC Editor，RFC 5625：DNS Proxy Implementation Guidelines。
  3. RFC Editor，RFC 5966：DNS Transport over TCP — Implementation Requirements。
  4. RFC Editor，RFC 7766：DNS Transport over TCP — Implementation Requirements。
  5. RFC Editor，RFC 7828：The edns-tcp-keepalive EDNS0 Option。
  6. RFC Editor，RFC 8490：DNS Stateful Operations。
  7. RFC Editor，RFC 8906：A Common Operational Problem in DNS Servers: Failure to Communicate。
  8. IETF Datatracker，RFC 9619：In the DNS, QDCOUNT Is (Usually) One。
  9. IETF Datatracker，RFC 10029：DNS Multiple QTYPEs。