内网 DNS 平台（2）：域名空间模型——公共、个人，以及为什么不做团队空间

背景

上一篇说了为什么要做平台。动手设计时，第一个要回答的问题不是技术选型，而是：域名空间的归属怎么划分。

这个问题之所以排在最前，是因为后面几乎所有设计都建立在它上面：权限模型、审批流程、回收策略、配额体系，全是"谁拥有哪个名字"的推论。归属划错了，后面每一层都要跟着拧巴。

两类空间，两种规则

最后定下来的模型只有两类空间：

devops.example.com          公共 zone：正式服务域名，DevOps 管理，变更走审批
{username}.user.xx          个人 zone：登录平台即自动分配，使用者自助管理

（脱敏起见，本文用 xx 代替实际使用的两字母短域名，用 example.com 代替公司真实域名。短域名的来历是下一篇的主题。）

公共 zone 承载稳定服务：payment-api.devops.example.com 这种名字要给别的系统调用，变更必须有记录、有审批。个人 zone 承载临时试验：api.zhangsan.user.xx 这种名字默认短命，到点回收。

权限矩阵很朴素：

“查询全员可见"是刻意的：DNS 本来就是共享的目录，藏起来反而阻碍自助排障。

典型用户旅程是这样的：zhangsan 用 LDAP 账号登录平台，系统自动把 zhangsan.user.xx 这个三级域划给他，他马上就能建 api.zhangsan.user.xx，全程两分钟，不需要找任何人。

这就是第一篇说的"登录即拥有域名”。但设计上真正的功夫，不在这个模型本身，而在我们没有做的那个空间上。

为什么不做团队空间

设计初稿里其实有三类空间：公共、团队、个人。直觉上团队空间就该存在——payments 团队的服务总得有个地方挂吧？

讨论中我们把它否掉了。理由是归属的生命周期：

• 个人会消失：离职是确定事件，账号一关，归属立刻清晰——个人的东西默认回收，没有歧义。
• 团队也会消失，而且消失得更难看：重组、拆分、合并、改名。payments.team.xx 里的记录，在团队拆分后归谁？新团队 A 还是 B？还是原来的负责人？DNS 记录不会因为组织架构调整而自动迁移。

也就是说，个人和团队都会"消失"，但个人的消失是干净的（人走账号封），团队的消失是糊涂的（名字还在，对应的真实主体没了）。把资源挂在一个会糊涂消失的归属上，等于提前埋下一堆没人敢删的记录。

最后的结论是二元定位写死：

个人 zone = 临时试验场（默认回收）；公共 zone = 稳定服务（走审批）。

团队有共享需求怎么办？用系统账号补：DevOps 代管的非真人账号（比如 svc-payments），它拥有一个个人 zone 的壳，但承担团队共享的实。系统账号不会离职，归属恒定；真要换主人，交接的是账号本身，不是一堆记录。

这条规则有个更普适的表述，我觉得可以用在很多资源设计上：

任何资源的归属，都要先回答一个问题：主人消失后怎么办。

公共 zone 的 owner 必填

个人 zone 的归属是天然的（域名里就带着用户名），公共 zone 没有这种红利——payment-api.devops.example.com 只有服务名，看不出是谁的。

所以公共 zone 的审批流里有一条硬规则：owner 必填，没有 owner 不予通过。没有这一条，归属追溯就是瞎的；有了这一条，“这条记录是谁的"才永远有答案。这个道理在后面的 IP 溯源篇还会以另一种形式回来。

pets vs cattle：编号机器的故事

归属模型定下来后，有一个更细的问题：个人 zone 里的名字该怎么起。这里我想讲一个很多年前的真实故事，它直接影响了这次的命名设计。

那时管理几百台物理机，机器名是连续编号：host001、host002、host003……有一天 host003 送修了，空出一个号。新机器来了，是补 003，还是往后排？

我们选择了补齐——结果送修的机器回来了，编号已经被占，它变成了 host057。那天我意识到一件事：我们一直把它当宠物管，它回来时发现自己是牲口。

连续编号是一个隐藏的承诺：名字 = 身份 = 那台具体的机器。这个承诺在"机器不可替代"的年代是成立的，但在资源可替换的时代必然被打破——云主机、容器、虚拟机，哪个都不是无可替代的。

所以这次的命名规则反着来：

• 有状态的东西才配拥有名字。你的开发机、长期维护的服务，可以有稳定名字。
• 无状态的池化资源接受编号不连续，甚至随机后缀。池子里的成员随时会被替换，名字不该承诺身份。
• 记录短命是制度设计。个人 zone 的记录默认有过期时间——不是因为存储贵，而是用制度防止"名字变宠物”：默认会消失的东西，没人会把它当成永恒身份来依赖。

顺带一提，这也是为什么我对"给临时资源起名"这件事很宽容：temp-api-3.zhangsan.user.xx 随便起，反正两周后它就不存在了。

多环境：生产用裸名

最后一个小规则。测试环境和生产环境的名字怎么区分？

做法很惯例：生产用裸名，非生产加前缀。

payment-api.devops.example.com          生产
stg-payment-api.devops.example.com      预发
test-payment-api.devops.example.com     测试

生产不加 prod. 前缀，因为生产是默认态——行业里大多数公司的惯例如此，客户端配置里出现裸名时也不用多想"这到底是哪个环境"。环境的管控不靠 DNS 子树（不给 stg. 单独开 zone 授权），靠 git 仓库的目录结构和 CODEOWNERS——这是 GitOps 篇的内容。

最后

回头看，空间模型这一层没有任何高深技术，全部是归属逻辑：谁拥有、谁审批、人走了怎么办、名字承诺什么身份。

但这些决定是整个平台的地基。后面的护栏、回收、审计、GitOps，全都是这两条规则的展开：

临时资源默认有过期时间，永久资源才需要审批。

任何资源的归属都要回答：主人消失后怎么办。