摘要

  • 1999 年的 RFC 2672 定义了 DNAME：对所有后代名字，用目标后缀替换记录所有者后缀。一条规则因此可以覆盖尚未穷举、甚至尚未出现的一组名字。
  • DNAME 不重定向所有者自身，也不构成委派。区域顶点仍需 SOA 与 NS；真正的委派仍是父区域在区域切点放置 NS 记录集；目标区域的运营者仍控制最终数据。
  • 2012 年的 RFC 6672 把运行经验写成边界：按查询合成 CNAME，以签名 DNAME 验证派生结果，禁止后代数据与规则并存，反对通配符 DNAME，限制循环，并在替换结果过长时返回 YXDOMAIN。

CNAME 与委派之间少了一种动作

RFC 1034 建立的 DNS 已有两种看似相近、实则不同的跳转。CNAME 把一个确切名字标成另一个规范名字的别名。区域切点上的 NS 记录集则告诉解析器：要继续查询这个子区域，应当去找哪些权威服务器。

前者处理单个节点的名字关系，后者重新划分管理边界。两者都不能简洁表达第三件事：保留任意后代名字左侧的标签，只把共同的右侧后缀替换掉。

假设机构从 old.example 迁往 new.example。为 www.old.example 写 CNAME，并不能照顾 mail.old.example、lab.mail.old.example 或未来才创建的名字。把 old.example 委派给另一方，又可能改变了本来不想改变的回答权。

缺口由此显现：需要一种比单点别名覆盖更广、却比区域委派含义更窄的解析指令。

一条后缀规则覆盖开放集合

RFC 2672 在 1999 年 8 月引入类型码 39 的 DNAME。若查询名字的结尾与 DNAME 所有者吻合，解析过程就以目标名字替换该后缀；匹配以完整 DNS 标签为单位，而不是按字符尾部猜测。

若 old.example 指向 new.example，查询 www.lab.old.example 会变成 www.lab.new.example。左侧的 www.lab 被保留，右侧共享后缀被替换。源区域没有复制目标数据，也没有获得控制目标数据的能力。

最初规范把网络重新编号、反向 DNS 维护和机构改名列作动机。其共同点不是证明 DNAME 后来有多普及，而是说明为何需要管理压缩：一条规则应当同时约束已知后代、未知后代和未来后代。

压缩也意味着集中。一行区域数据的失误，可能改变整棵子树的查询去向。这项机制节省的是编辑次数，并没有消除决策的影响面。

所有者留在原地

取代原规范的 RFC 6672 明确了最关键的例外：DNAME 只重定向其所有者之下的名字，不重定向所有者自身。

于是，www.old.example 可以转向新后缀，而针对 old.example 的查询仍在旧顶点回答。兼容的其他记录类型可以留在所有者处；若它是区域顶点，SOA 和 NS 仍不可缺少。

这意味着 DNAME 不能完整镜像一个区域。机构改名时，旧顶点的 MX 可能仍须单独配置。目标 Web 服务、证书或邮件系统也须明确接受旧名字。DNS 能把查询带到新名字，不能命令应用把两种身份视作同一身份。

这个例外不是功能残缺，而是语义的诚实边界。DNAME 的承诺是“后代查询按结构改写”，不是“这个域连同权威一起搬走”。

通用规则在回答中变成具体 CNAME

应用 DNAME 替换时，服务器会返回有关的 DNAME，并针对当前问题合成一个 CNAME。查询 www.lab.old.example 时，回答里可以出现从该确切名字到 www.lab.new.example 的 CNAME，尽管区域文件里从未存过这一条。

DNAME 是管理员发布的通用规则，合成 CNAME 是规则对一次查询的具体结果。这样，不直接理解 DNAME 的客户端仍可以沿熟悉的 CNAME 继续解析。递归缓存服务器也必须能够代表客户端完成合成。

运行经验改变了缓存细节。原规范让合成 CNAME 的 TTL 为零；RFC 6672 改为使用 DNAME 的 TTL，同时要求解析器兼容零值，因为旧权威实现不会在新 RFC 发布时立即消失。

修订还承认，早期设想的 DNAME 能力 EDNS 信号从未被定义。互操作不能依赖一个不存在的协商位，只能依赖普通 DNS 回答、明确算法和兼容行为。

DNSSEC 签的是规则

区域无法提前知道明天用户会查询哪个后代名字，因而无法为无限多个合成 CNAME 预先签名。DNSSEC 的做法是签署 DNAME 本身。

验证器核验 DNAME 的签名，再独立执行后缀替换，检查未签名的 CNAME 是否正是该规则的确定性结果。证明由“已认证规则 + 可复算过程”构成，而不是由服务器在线签出每一个结果。

这种结构限制了服务器的自由：左侧标签必须原样保留，所有者后缀必须按标签边界匹配，目标后缀必须来自已签名记录。服务器不能借“合成”之名随意指向第三个名字。

但证明不会自动延伸到整条链。DNAME 之后可能还有 CNAME、另一个 DNAME、未签名目标区域或错误。RFC 6604 说明，响应码与状态位应描述重定向链的终点。第一跳真实，不代表终点存在，更不代表终点运营者可信。

指路不等于委派

现行术语 RFC 9499 把 DNAME 所有者的子域称作别名，却把委派定义为：父区域在子区域起点、也就是区域切点放置 NS 记录集，从而创建独立区域。

算法上的差别很直观。NS 转介改变解析器认定的回答者。DNAME 改变解析器要问的名字；替换后的名字再沿目标命名空间已有的委派关系前进。

因此，非顶点处的 DNAME 不能与标记委派的 NS 共享同一所有者。若子区域想在自己的顶点使用 DNAME，它必须位于切点下方，作为子区域权威数据，并继续与该区域的 SOA、NS 并存。

这里有三种独立权力。源区域运营者可以发布指针。父、子区域运营者通过 NS 维持源区域委派。目标区域运营者决定替换后名字的最终数据。一个主体能把查询引向另一个主体，却不能用一条别名记录把原权威赠与对方。

规则之下的数据会被遮蔽

同一区域中，DNAME 所有者之下不得存在资源记录。服务器即使加载了这些数据，查询也会先遇到 DNAME 并转向目标，因此后代数据处于被遮蔽状态。

这使“添加一条记录”可能产生近似删除的公开效果。递归缓存还可能同时持有变更前的后代数据与变更后的 DNAME。RFC 6672 允许缓存暂时采取不同处理，最终依靠旧 TTL 过期恢复一致。

发布前必须盘点整棵子树，而不是只检查新增行。回滚也必须按分布式时间设计：从权威服务器删去 DNAME，不会撤销其他缓存尚未到期的副本。

每个所有者只能有一个 DNAME，也不能同时拥有 CNAME。协议给予一条规则广泛作用域，却不允许同一点出现相互竞争的重定向。这使控制面仍然可以被审计。

通配符会开始制造规则

普通 DNAME 是固定权威事实，针对不同查询产生不同 CNAME 结果。通配符 DNAME 则多出危险一步：通配符扩展先制造一个 DNAME 所有者，随后这个临时所有者又制造重定向规则。

RFC 4592 认为这会让不同缓存获得非确定性的规则，威胁 DNS 一致性。RFC 6672 因而反对这种配置，服务器可以警告、拒绝动态更新或拒绝加载区域。

边界说明了何种自动化可被信任：由一条固定、可定位的权威规则派生查询结果，仍可复算；若连授予重定向能力的规则本身也按查询生成，权力来源与作用域就变得模糊。

互联网允许无限多潜在问题，并不意味着它也应在回答时临时发明无限多控制规则。

循环与名字长度给便利定价

DNAME 之间可以成环，也可以与 CNAME 组成混合环。一条特殊规则甚至能把名字送回自己的匹配范围。解析器和服务器必须限制单次查询投入的资源，同时承认某些合法链可能较长。

后缀替换还可能生成超过 DNS 法定长度的名字。此时权威服务器返回 YXDOMAIN，并附上 DNAME；若区域签名，也附上相应证明。YXDOMAIN 与 NXDOMAIN 不同：它不是说原名字不存在，而是说计算出的名字无法被 DNS 表示。

NS、MX、PTR、SRV 记录中指向的主机名还必须是规范名字，查找其地址时不能依赖 CNAME 或 DNAME。负责把解析系统本身串起来的基础名字，不应藏在额外别名链后面。

这些限制划分成本归属。源管理员应避免循环和过度扩张，权威服务器应返回精确错误，解析器应阻止无限工作。管理上的简洁不能成为把无限成本推给全网的许可。

连通性从来不是权威证明

DNAME 能在过渡期间维持旧后代名字的可达性。它维持的是句法对应与查询路径，不是所有权、合同、密钥、证书、服务承诺或应用接受策略。

因此，可靠迁移要保留三类证据：谁仍控制源规则，谁控制目标数据，谁负责让服务接受旧、新身份。DNS 回答越平滑，越不能省略这些制度事实。

DNAME 的历史展示了互联网的一种克制：扩大功能，却不擦除使功能可追责的权威边界。它能把查询移动到名字树另一处，却从未获得假装整个区域也已搬迁的权力。

来源与证据边界

CNAME、区域切点与 NS 委派的原始架构见 RFC 1034：https://www.rfc-editor.org/rfc/rfc1034.html

DNAME 的 1999 年定义与早期动机见 RFC 2672：https://www.rfc-editor.org/rfc/rfc2672.html

通配符 DNAME 的非确定性问题见 RFC 4592：https://www.rfc-editor.org/rfc/rfc4592.html

重定向链终点状态的说明见 RFC 6604：https://www.rfc-editor.org/rfc/rfc6604.html

现行替换、合成、DNSSEC 与失败规则见 RFC 6672：https://www.rfc-editor.org/rfc/rfc6672.html

现行别名和委派术语见 RFC 9499：https://www.rfc-editor.org/rfc/rfc9499.html

这些材料没有给出当前全球采用率或普遍性能收益。重新编号、机构改名等是设计示例，不是普及度证据。DNAME 解析成功也不能证明源、目标具有相同所有者，应用一定接受旧名，证书有效，或行政权威已经转移。