摘要

  • RFC 1279 试图在 X.500 中表示域名，却明确区分域名与组织、邮箱与人员。因为对象不同，跨树连接不能使用把两者当作同一对象的 alias。
  • AssociatedDomain 与 AssociatedName 从两个方向保存关联。域名侧应尽量保持简洁，通过指针取得组织信息，而不是复制；一个域名也可能对应多个组织，反之亦然。
  • DNS 记录可以在域名服务器与 DSA 之间转移，但写入目录时必须保持非 DNS 属性不变。转移、写入、保留、建立指针、查询、身份判断与实际行动各自需要证据。

相似的名字不代表相同的对象

1991 年 11 月发布的 RFC 1279 是 Experimental 文献，题为 X.500 and Domains。它设想把 DNS 的域名层级映射进 X.500 Directory Information Tree，让目录工具能够查询域名、邮箱、管理者及相关网络信息，并测试 X.500 是否有一天能承担部分 DNS 管理工作。

但文献没有把远景当成现状。最初阶段更可能继续由 Domain Databases 掌握原始数据，再上传到 X.500。附录先列出用户工具、zone transfer、关联修补、分布式 DSA 与 DNS 模拟服务等试验步骤，最后才设想把部分 DNS 层级交给 DIT 管理。

这条时间线把计划、传输、权威变更与部署结果分开。详细的组件清单不是运行回执，能写出最终阶段也不代表已经到达最终阶段。

在 DNS 形状的分支里，每级域名成为一个 DomainComponent。邮箱的 local part 也可以作为特殊的域组件继续向下延伸。另一边则是组织结构：大学、部门、人员或角色拥有各自的目录条目。

同一个机构名称可能同时出现在两边，但两条记录表示的事物不同。UCL.AC.UK 是域名空间中的位置，University College London 则是组织条目。S.Kille@... 是邮箱标识，不等于目录里的某个人。

RFC 1279 因此拒绝使用 alias 连接这两棵树。Alias 适合表达同一对象的另一个名字；这里需要表达的是两个对象之间的关系。如果把关系写成别名，查询工具就可能在没有证据的情况下允许相互替换。

指针的价值在于保留它跨越的边界

文献选择两个有方向的属性。组织条目可以用 AssociatedDomain 指向相关域名；域名条目可以用 AssociatedName 指向组织树中的条目。

两个方向回答的不是同一个问题。从组织出发，相关域名是什么？从域名出发，应到哪个组织条目读取更丰富的信息？把两条陈述分别保存，还能看见反向关联缺失，而不是由界面悄悄补出一个对称关系。

RFC 1279 也明确提醒，一对一只是最简单的例子。一个域名可能关联多个组织，一个组织也可能拥有多个域名。关联指针不是唯一性证明，更不是法律所有权证书。

因此，域名指向某组织并不能自动证明该组织控制所有相关服务；邮箱条目指向某人也不是身份认证；一条 DNS 记录与组织相邻，更不能说明组织已授权某次操作。目录保存的是带方向的关联陈述，不是读者希望得到的全部结论。

真正可审计的关系至少要保留谓词、方向、来源与时间。删掉这些限定后，图数据库很容易把“靠近”升级成“拥有”，再把“拥有”升级成“有权”。

不复制，才能知道谁负责修正

RFC 1279 允许域名真正拥有的信息保存在域名条目中。DNS 记录和域名特有的管理信息当然可以留在这一侧。但如果组织树已经有相应资料，文献主张域名条目保持相对简洁，通过指针取得组织资料，不应重复复制。

这不是单纯节约空间。两份副本意味着两个写入者、两个更新时间和一次无法自动解决的冲突。

假设域名条目复制了组织记录中的管理员电话。人员变更后，组织侧更新，域名侧遗漏。两串电话号码在格式上都正确，搜索结果也可能任意展示其中一条。更糟的是，同一旧值若被复制到多个域名，看上去像多项证据，实际都来自一次过期陈述。

指针让责任保持清晰。组织条目负责自己的描述性属性，域名条目负责说明关联。查询界面可以把两边组合给读者看，但组合视图不能倒过来改写事实来源。

修正也因此更安全。关联错误时只改关联，不必重写组织；联系人变化时只改组织来源，不必追查所有曾经复制过它的域名。系统既保留对象，也保留读者为何到达该对象的路径。

携带 TTL 字段，不等于复制 DNS 的时间行为

RFC 1279 提议以文本形式把 DNS resource records 存进 DIT。域名必须写全，每条记录必须带 TTL；使用一个可扩展的 DNSRecord 属性，可以避免每出现一种新 RR 都修改目录定义。

文献要求这些 DNS 信息与原系统保持等价，以便在 DNS 与 X.500 之间移动。但它同时明说：OSI Directory 不尝试模拟 DNS caching 或 TTL handling。主条目假定通过 zone transfer 或等价机制维护，之后才在试验范围内视为权威数据。

字段里有一个 TTL 数字，与缓存时钟正在倒数，是两种不同记录。RFC 1035 把 TTL 定义为资源记录可被缓存、而无需再次询问来源的时间。权威 zone 数据、cache 数据、refresh 状态与 expiry 各自有不同运行语义。把一行文本复制进 X.500，不会自动复制整套时间状态。

调查时必须补齐链条：哪一个 DNS 来源提供记录？哪一次 zone 版本或 transfer 携带它？传输是否完成？DSA 何时接受写入？后来是否刷新？哪一次查询把它交给读者？单独一个 TTL 字段无法回答这些问题。

如果复制值活得比来源观测更久，问题尤其明显。数字仍在，并不表示把它当作当前事实的依据仍有效。语法可能比权威窗口寿命更长。

同步工具只拥有自己搬运的记录族

RFC 1279 的附录提出双向 zone-transfer tool，在 DNS Server 与 DSA 之间传递信息。它加了一条极具体的限制：向 DSA 写入时，所有非 DNS record 属性必须保持不变。

这句话划定了控制面。工具能更新自己搬运的 DNS 记录，却不能因为这些记录与管理员、电话、组织描述或关联指针住在同一条目中，就取得修改邻近属性的权力。

连接到 DSA 不等于传输完成；传输完成不等于全部记录通过检查；DNS 写入成功也不能证明非 DNS 属性没有改变，除非保存前后状态；后续查询成功更不等于用户采取了行动。

可靠证据应拆成来源 zone 状态、传输请求、收到的集合、接受的写入、被保护的非 DNS 状态、关联指针、查询响应以及下游行动。一个笼统的“已同步”标志，会把 RFC 1279 最想保护的边界重新藏起来。

试验路线不是部署证明

附录列出了七类工具：用户工具、程序库、zone transfer、关联修补、DNS 管理、邮箱下载和 DNS 模拟服务。初期试验可以把允许 zone transfer 的大量 DNS 空间复制进一台 DSA，再添加关联指针，供参与者浏览。之后才会测试分布式 DSA 和性能，最后才考虑在 DIT 中管理部分 DNS 层级。

这些都是待验证步骤。RFC 1279 没有证明全部组件已经建成、反向指针完整、数据持续新鲜、读者信任结果，或 DNS 已被取代。Experimental 身份不是装饰，它规定了报道可以说到哪里。

RFC 1309 后来解释了更广的 X.500 背景：条目以属性描述对象，各组织可在分布式目录中用自己的 DSA 掌握本地资料。这能说明 RFC 1279 为什么重视对象边界，却不能替 RFC 1279 提供不存在的部署结果。

安全边界同样有限。RFC 1279 说它没有直接处理 security issues，只认为 X.500 的能力可能带来更安全的访问与管理。可能性不是认证证据。指针和 DNS 副本都没有为背后的人员、组织或运营者签发身份证明。

来源与证据边界

RFC 1279 支撑域名表示、拒绝 alias、双向关联、不复制、DNS 记录转移边界及分阶段试验。RFC 1274 确认相关域对象类与关联属性。RFC 1035 仅用于 DNS 的 TTL 与 zone 运行背景。RFC 1309 仅用于 X.500 条目和分布式本地管理背景。

这些文献证明历史定义与拟议控制，不证明具体部署、当前目录内容、法律所有权、认证身份、完成的传输、新鲜值、成功查询、安全结果或用户行动。