摘要

  • RFC 830 提议把名字服务分成两段：域名服务只把层级名字解析到目的端 DNS/AIP 的地址，随后由应用接口进程实时协商传输与应用能力。
  • 源端从最右侧标签开始轮询；中间域只保存直属子域映射，内部数据库格式可以各自不同，缓存也由实现者自行决定。
  • RFC 882 与 RFC 883 选择了另一条共同边界：资源类型、协议类别、权威区、转介、缓存与刷新进入标准分布式数据库。记录因此可复用，却仍不是运行能力的证明。

最右边先决定去哪里问

RFC 819 把域描述为名字分配与翻译责任的辖区，而不是网络拓扑的同义词。每个父域只需保证直属孩子的简单名字唯一；完整名字把这些层级连接到共同根。一个组织可以保留内部命名习惯，只在边界上提供可被外部理解的绝对名字。

RFC 830 在这棵树上设计了 SINS，也就是 System for Internet Name Service。请求交给源端的 Application Interface Process，简称 AIP。名字包含本地部分与一串从具体到一般的域标签。真正做域解析时，本地部分暂时被拿开，DNS 从最右侧的顶级域开始。

源端 DNS 是这次解析的轮询中心。它先把最右标签变成顶级域 DNS 的地址，再询问下一层。中间 DNS 只需要知道自己的直属子域由哪个 DNS 表示。它可以返回下一站地址，也可以代为转发一次，但不能继续成为另一个长期轮询中心。

这条限制把状态与责任留在源端。一次解析可能经过多个管理边界，却不要求每个中间节点保存整个旅程。父域负责自己的孩子；源端负责追问；目的域负责最后呈现自身。

解析终点只是域的接待处

在 RFC 830 中，成功解析一个域所得的结果，是与目的端域关联的 DNS 地址。端点域还运行 AIP，通常与 DNS 位于同一处。这个地址让源端找到可以继续交谈的接待处，却不一定是目标应用的地址。

应用地址有时可以由固定约定推导。例如众所周知的 TCP 端口把服务与端口永久绑定。但 RFC 830 不愿把所有变化都冻结在名字数据库里。端点可以通过实时协商说明自己支持 TCP 还是 UDP、SMTP 还是另一种邮件协议、NIFTP 还是 FTP。

因此，“这个域在哪里”与“这个域现在能为本次请求做什么”属于两种证据。前者来自层级映射，后者来自目的端进程的现场答复。把它们压成一个绿色查询，会丢掉错误发生的位置，也会把域管理权误写成应用决定权。

谈判可以改变协议而不改变目的

RFC 830 的例子让源端请求 TCP/NIFTP/RFT，也就是用 NIFTP 做远程文件传输。目的端没有 NIFTP，却有 FTP。只要源端也支持 FTP，两个 AIP 就能找到共同方案。

这里改变的是实现方式，不是用户目的。名字没有错，目的域也没有错；双方只是在应用协议上不相容。目的端返回可用替代项后，源端仍可以接受或拒绝。协商提供选择，不替代本地决策。

肯定答复可以同时给出多个地址。RFC 830 认为多结果更好，因为多宿主端点可以让源端选择。在 TCP 示例里，一个地址项包含 IP 地址、协议号与端口号。它是下一步连接所需的候选坐标。

多个坐标并不等于多个等价承诺。路径、可达性、拥塞、策略与进程状态仍可能不同。返回两个地址只证明目的 AIP 报告了两个选择；只有随后的连接与应用行为才能说明哪个选择实际工作。

活答复也没有携带全部权力

现场谈判比静态条目更接近当前状态，却不会自动验证身份、许可或容量。AIP 说自己提供 FTP，不代表任何来访者都有权使用。它返回一个端口，不代表传输必然建立。传输建立，也不代表文件操作会被接受。

整条链至少有四个独立事实：层级中存在这个域；源端抵达代表该域的 DNS/AIP；双方找到共同能力；应用交易完成。后一个失败不能随意否定前一个，前一个成功也不能替后一个背书。

这种区分与责任有关。父域的委派权止于名字层级。目的域的发布权止于它声明的数据或能力。授权属于应用与运营者。结果属于真正执行的系统。名字服务不因位于开头就获得后面各层的主权。

共同数据库很薄，共同对话却很细

RFC 830 给应用/AIP、AIP/DNS 与 AIP/AIP 设计了统一命令结构。条目可以表示名字、服务、地址与说明。失败答复可以返回未能解析的那一段名字，并附上解释。短请求通常建议使用 UDP，以避免为一次小查询建立 TCP 连接。

反过来，持久数据库可以保持本地。端点 DNS 只保存顶级域映射；中间 DNS 只保存直属子域映射。各组内容彼此分离，更新可以在责任域内完成。文档甚至认为无需统一数据库内部格式。

缓存也没有被列为 SINS 的标准功能。RFC 830 知道每次交易都重新走完整层级会很低效，因此预期实现者会复用结果，但把具体做法留给本地。共同规范更小了，代价是缓存寿命、过期与来源界线缺少统一语义。

这是一种清晰但并不轻松的取舍：把互操作所需的现场语言写得很细，把存储与记忆留给实现者。每个端点域则必须运行懂得应用能力的 AIP，承担实时依赖与共享服务词汇的成本。

从 HOSTS.TXT 迁移并没有预先决定答案

RFC 881 处理的是部署困局。域式名字先加入并行的 HOSTS.TXT，待软件准备好后再替换旧表。以后，解析器可以替换原来的查表函数，使应用无需知道地址来自文件还是服务器。中心表最终只保留顶级域服务器入口。

这条迁移路线解决了集中表无法继续扩展的问题，却没有必然要求把应用协商放在哪一层。RFC 830 选择端点实时谈判。RFC 882 与 RFC 883 则把更多通用信息做成可查询的分布式数据库。

在新设计里，一个域名对应一组资源信息。查询同时携带资源类型，必要时还有协议类别。名字服务器持有权威区与转介；解析器追逐答案并缓存外部数据。权威数据来自区与主数据，缓存数据来自过去查询，并按超时规则失效。

应用与本地解析器之间不需要全球统一的网络协议。过程调用或操作系统接口就够了。共同层转而统一解析器与服务器之间的消息、资源记录、区维护、转介与刷新。

后来的 DNS 选择了声明式共同层

RFC 1034 回顾早期历史时，把 RFC 830 列在多种层级命名提案之中；它另行指出，RFC 882 与 RFC 883 的分布式数据库与通用资源设计经过实践后演变成后来的 DNS。RFC 830 因此不是换了名字的现代 DNS，而是一条在共同边界上不同的分支。

类型化记录能被复制、缓存、审核，也能服务未知的未来应用。它不要求每个域运行一位理解所有协议的通用谈判者。这个选择扩大了互操作，也让解析成本更可控。

但记录仍是声明。权威答复证明相关区发布了什么；缓存答复证明解析器在有效期规则内保留了什么。两者都不能单独证明进程正在监听、客户端兼容、访问获准或交易成功。

RFC 830 留下的不是一项应当复活的通用协议，而是一把判断尺：发现位置、声明能力、实时协商、授权与执行结果必须各自留下证据。共同层越成功，就越要防止它替后续层作决定。

来源