背景
这一篇是系列里写法最特殊的一篇：它不是"问题→方案"的直线叙事，而是我在设计过程中两次推翻自己的记录。第一次推翻发生在 PTR 上，第二次发生在 TXT 上。两次纠偏的结论都不算惊艳，但思辨过程比结论更有价值——所以我尽量把当时的推理还原出来。
第一版设计：PTR 找人
最初的设计里，IP 反向溯源有两条路：PTR 记录（协议层）和段台账（数据层）。我对 PTR 寄予厚望：拿到一个陌生 IP，dig -x 一下就出名字，从名字就能找到人。
这个想法在个人空间确实成立：
10.42.3.17 → api.zhangsan.user.xx → owner 显然是 zhangsan
第一次纠偏：PTR 不找人
写到一半我自己停住了：这是个人 zone 的命名红利，不是 PTR 的能力。
把场景换到公共 zone：
10.42.3.17 → payment-api.devops.example.com → 这是谁的？
payment-api 只是个服务名，不包含任何人。PTR 能告诉你"这是什么"，但对"这是谁的"一无所知。我之前把命名规范（个人 zone 带用户名）产生的可追溯性，错误地记在了 PTR 头上。
修正后的分工：
- PTR 解决"这是什么"：协议刚需（SMTP、Kerberos 都依赖正反一致）+ 日志可读性（日志里
payment-api.devops.example.com 比 10.42.3.17 好读十倍）+ 自动生成成本近零（平台建 A 记录时顺手落 PTR）。 - 归属追溯的本体是台账：公共 zone 审批时 owner 必填，追溯走平台查询，不走 DNS 协议。
两个结论都很朴素，但顺序很重要：台账登记才是正菜，PTR 是协议甜点。因果不能倒置。
第二次思辨：DNS 当半个 CMDB？
纠偏完 PTR，我又动了另一个念头：既然 DNS 到处都能查、协议标准化，能不能把元数据直接放进 TXT 记录，让 DNS 承担半个 CMDB 的职能？
这个想法有正当的先例：SPF 和 DKIM 用 TXT 发布邮件策略，ACME 用 TXT 做证书验证，SRV 记录发布服务端点——DNS 早就是一个合法的声明式数据存储。我在总纲篇里也写过 _meta TXT 的玩法。
但认真推演后，CMDB 的"半个"卡在三处：
- CMDB 的核心是反查聚合。“列出 payments 团队的所有服务"是 CMDB 的日常查询；DNS 是精确的键值查询，没有"列出所有 owner=payments 的记录"这种操作。
- 无 schema。TXT 是自由文本，
owner=zhangsan 和 Owner: zhangsan 和 负责人=张三 都是合法值，没有校验，没有约束，数据质量随时间腐烂。 - 全员可见 + 缓存语义。TXT 里的内容对所有能查 DNS 的人可见，且会被各级缓存——敏感信息和频繁变化的信息都不适合进去。
落地：台账是档案，TXT 是名片
两次思辨的最终落地是一个分层架构：
台账（平台数据库） = 档案：权威源，支持反查聚合，可含敏感信息，权限受控
TXT 记录（DNS 投影） = 名片：只读，简短，非敏感，机器免登录可读
实现上这个架构几乎是白送的：平台本来就有投影引擎（数据库 → DNS 记录），在投影 A/PTR 的同时，把 owner、purpose、environment 这几个字段多投影一份 TXT 就行：
_meta.payment-api.devops.example.com. 300 IN TXT "owner=payments-team"
_meta.payment-api.devops.example.com. 300 IN TXT "purpose=支付网关联调"
_meta.payment-api.devops.example.com. 300 IN TXT "environment=prod"
什么信息放名片、什么放档案，我给自己定了一个判断标准：
| 信息的性质 | 放哪 |
|---|
| 需要反查聚合（“列出某团队所有服务”） | 档案 |
| 有敏感性（负责人手机、成本、漏洞信息） | 档案 |
| 机器要免登录读取（Agent 启动时发现归属） | 名片 |
| 高频变化（状态、版本、负载） | 都不放，放监控系统 |
一句话版本：
DNS TXT 是 CMDB 的只读名片投影，不是本体。
最后
这篇的两个结论：
PTR 解决"这是什么”，不解决"这是谁的"——命名规范带来的可追溯性，不能记在协议头上。
元数据的权威源必须是可反查、可授权、可演化的系统（台账）；DNS 只拿一份只读投影。
写下来之后我还想多说一句关于"自我纠偏"本身。设计讨论里被打脸不是坏事——第一版"PTR 找人"如果没被质疑，上线后就会在公共 zone 场景失效，那时改的就是系统而不是文档了。结论被质疑，质疑让设计更精确，这是整个系列里我最想保留的工作方式。
下一篇转向运营视角：平台上线后，护栏、僵尸记录和违规使用怎么管。