摘要

  • RFC 3123 定义 APL 资源记录，用一个有序序列承载 IPv4、IPv6 前缀与否定位；空列表、多条 RR、未知地址族和 ! 的实际含义，必须由应用另行说明。
  • 格式正确、甚至经过 DNSSEC 或 TSIG 保护的 APL，只能证明某份表示被发布或某次消息被认证；它不能证明前缀控制权、决策授权、ACL 已安装、规则已命中或服务成功。

DNS 得到的是容器，不是命令

到 2001 年，DNS 早已不只是把主机名换成地址的电话簿。RFC 1034 与 RFC 1035 建立的 Resource Record 模型能够携带邮件路由、权威服务器和其他基础设施信息。RFC 1101 曾描述如何公布组织网络；一些旧版 BIND 还从 TXT 里的地址范围获取一种很弱的区域数据访问限制。

这些做法容易把两个问题粘在一起：前缀怎样表达，读取它的软件又该做什么。2001 年 6 月以 Experimental 发布的 RFC 3123 拆开了它们。它为 APL 分配 DNS 类型 42。每个元素包含地址族、前缀长度、N 位、地址部分长度以及有效地址字节。地址族 1 和 2 分别是 IPv4 与 IPv6，同一条记录可以混合两者。

规范却没有给列表一个通用目的。它明确说，APL 只定义框架，不定义前缀列表的特定含义。公布组织地址范围、描述无类别反向区域、为访问控制提供材料，都只是可能场景，需要独立的应用规范。示例不等于应用标准，更不证明真实部署存在。

因此，DNS 名称、类型和载荷可以说明“在哪里读到什么表示”，不能自动说明“谁有权让谁照此行动”。记录不是主体，目录也不会因为分发了一条声明就获得执行权。

感叹号首先只是被保存的语法

区域文件中，APL 元素可以带 !，线格式用 N 位保留它。读者很容易把它直接翻成“拒绝”“排除”或“未经授权”。RFC 3123 拒绝替应用做这个决定，要求应用规范写明否定元素的精确语义。

空列表同样如此。空 RDATA 合法，并表示一张空表；但空表是“谁都不允许”“不作限制”“没有意见”还是“继承其他规则”，记录本身不回答。一个 RRset 可以包含多条 APL，它们怎样组合也留给应用。

地址族扩展没有靠猜测解决。应用必须写出预期地址族，并规定遇到其他或尚未定义的地址族时如何处理。忽略一个元素、拒绝整条记录、保留给未来读者，是三种不同决策。解析器认识字段，只证明它能读，不证明它有权选。

这是一种最小共同层的纪律：共享格式只承载参与者可以本地验证的事实，未来策略继续留在采用它的系统里。标点符号不应偷偷变成跨组织命令。

顺序与重复不是可随手清理的噪声

RFC 3123 特意禁止服务器和解析器“优化”列表。相同元素可以重复，不能合并；元素必须保持原顺序，不能重排，也不能聚合。只有先假定这是一组无序数学集合，这些限制才显得浪费。规范没有做这个假定，因为未来应用可能让顺序表达优先级，也可能让重复承载意义。

中间层的责任因此很窄：忠实转运，而不是自作聪明。若它把两个相邻前缀合成一个，或删除第二次出现的项目，就可能改变一条自己从未获权解释的策略。

在字节层面，规范又要求一种确定性规范化：地址部分末尾不携带前缀信息的零字节必须省略。等价的 IPv4 或 IPv6 前缀因而只有一种线表示，这对当时引用的 DNSSEC canonicalization 很重要。

但规范化只解决“签名和比较哪些字节”，不解决“签过的内容要求什么动作”。确定表示与政策后果属于两个层次。

安全机制能保护声明，不能补齐授权

安全章节说，若没有所引用的 DNSSEC 或 TSIG 技术，从 DNS 得到的信息应视为不安全。它也警告：发布前缀可能泄露网络拓扑，而从 APL 构造访问控制列表可能损害安全。

DNSSEC 能帮助验证签名 DNS 数据的来源与完整性；TSIG 能在已配置的参与方之间认证 DNS 消息或事务。这些属性很重要，因为篡改列表会改变依赖方看到的材料。但认证不是授权。它们不判断区域管理员是否有权命令一台防火墙，也不证明应用取到了最新版本、编译成功、安装到正确接口，或数据包真正经过了那个执行点。

完整链条需要分别留证：查询的 owner name 与时间、精确 RRset、验证状态、应用规范及版本、本地采用配置、编译后的策略、执行点确认、所附着接口，以及后续流量观察。若从第一步直接跳到最后一步，就是把分发记录虚构成控制行为。

DNS 的委派、缓存和普及度让它成为经济的发布渠道；但声明被分布，不等于决策权也被分布。区域管理员发布字节，消费系统的运营者仍然决定是否采用。

类型 42 不是部署数量

RFC 中的例子很生动：组织地址范围、无类别反向区域、AXFR 传送限制、多播空间。它们使用示例域名解释语法。文档同时明确说明，这些例子没有规定任何应用，也不暗示某种 APL 应用现在存在或未来一定出现。

Experimental 身份也不是现场试验回执，它只记录 2001 年的文档类别。后来的 RFC 3597 说明软件如何搬运未知 DNS RR 类型，有助于理解扩展兼容性，却不证明 APL 被采用、被忽略或取得成功。RFC 4034 进一步规定 DNSSEC 资源记录与 canonical 处理，也没有给 APL 增加统一策略语义。

因此，可核验的历史必须停在设计证据上：RFC 3123 建立了一个紧凑、可扩展、保留地址族、顺序、重复和否定位的容器。要讲部署、故障或成效，还需要具体实现、区域数据或测量记录。

真正的贡献是把边界留下来

APL 的共同层只解决跨系统交换同一表示。应用另行定义名字约定、空列表、多 RR、地址族与否定；运营者另行决定是否采用；策略系统另行安装；数据包随后才可能遇到规则。

这种分离不保证正确结果，却让错误可以归因。记录可能真实但已经过期；应用规范可能正确但本地配置错误；ACL 可能成功安装却挂在错误接口；执行点可能返回成功，而流量走了另一条路径。

同一个前缀字符串可能出现在 DNS、应用模型、编译策略与流量日志中。文字相同，不代表它们是同一个事实；它们的时间、主体与证据权限不同。

RFC 3123 没有让 DNS 统治网络。它让 DNS 精确携带前缀材料，同时承认真正的决定必须在记录之外被证明。

来源

  1. https://www.rfc-editor.org/rfc/rfc3123.txt
  2. https://www.rfc-editor.org/info/rfc3123
  3. https://datatracker.ietf.org/doc/rfc3123/
  4. https://www.rfc-editor.org/rfc/rfc1034.txt
  5. https://www.rfc-editor.org/rfc/rfc1035.txt
  6. https://www.rfc-editor.org/rfc/rfc1101.txt
  7. https://www.rfc-editor.org/rfc/rfc2317.txt
  8. https://www.rfc-editor.org/rfc/rfc2535.txt
  9. https://www.rfc-editor.org/rfc/rfc2845.txt
  10. https://www.rfc-editor.org/rfc/rfc2874.txt
  11. https://www.rfc-editor.org/rfc/rfc3597.txt
  12. https://www.rfc-editor.org/rfc/rfc4034.txt