内网 DNS 平台（1）：一个域名等了两天

背景

上一篇《DNS不只是A记录》写了我对 DNS 职责的理解：它是基础设施的目录和平台的引导层，是路标而不是目的地。那一篇讲的是 DNS 能做什么，这一篇讲的是我为什么决定把它做成一个平台。

动机来自一次很小的不愉快。

有一次联调，需要给一个内部服务加一条域名记录。事情本身只有一行：

api.test.project.devops.example.com. 300 IN A 10.42.3.17

但这一行记录从提出到生效，走了接近两天：先找到负责 DNS 的人，对方手头有别的事，隔天才处理；处理时敲错了一个字符，又隔了半天才发现解析不对。两天里，服务本身是就绪的，测试环境是就绪的，唯一没有就绪的是一行文本。

这种经历几乎每个有内网的公司都有，只是频率和痛感不同。它让我开始认真盘点：内网 DNS 的日常，到底痛在哪里。

五个日常痛点

盘下来的结果并不新鲜，但很系统：

1. 申请流程长。想要一个域名，要找人手动加记录。等待时间取决于对方忙不忙，不取决于事情急不急。
2. 互访靠报 IP。临时联调时互相访问，靠嘴上说"我连你机器，你 IP 多少"。IP 难记、会变、写不进配置文件，更不能写进代码。
3. 临时域名泛滥。一次性、测试用的域名被加进正式 zone，用完没人删。时间一长，没人说得清哪些记录还活着。
4. 归属不清。一条记录是谁加的、给什么用的，无从查证。出问题时只能顺着 IP 猜，或者干脆不敢动它。
5. 权限粗放。管理权集中在少数人手里：要么能改所有记录，要么什么都改不了。没有"各人管各人空间"的粒度。

这些痛点单独看都是小事。但它们叠加起来的效果很明显：名字这件事在内网里不可靠。因为不可靠，大家就绕开它——配置里写 IP，文档里写 IP，口头报 IP。而绕开名字，等于放弃了 DNS 最基本的价值：名称是稳定契约，地址只是实现细节。

这不是缺工具，是缺平台

面对这些痛点，最自然的反应是找个工具：装一个 DNS 管理面板，或者干脆用 hosts 文件加 Excel 台账顶着。这些我都试过，也都能缓解一时，但有一个共同的问题：它们只解决"记录怎么写"，不解决"流程怎么走"。

手工加记录慢，不是因为管理员打字慢，而是因为每一次变更都要经过同一个人；临时域名泛滥，不是因为大家没有责任心，而是因为没有任何机制提醒回收；归属不清，不是因为没人记录，而是因为记录这件事不在变更发生的现场。

也就是说，痛点不在记录层，在治理层。这是"加个工具"和"做个平台"的分界线。

平台工程（Platform Engineering）这几年有几个被反复验证过的思路，恰好对应这些治理问题：

Self-service with guardrails（带护栏的自助）。解决申请流程长的正确姿势不是加人手，而是让使用者在护栏内自助：开发测试可以在自己的空间里随便建记录，但不能碰别人的空间，不能建危险的记录类型，数量有上限，到期要回收。自助是效率来源，护栏是不出事的保证，两者缺一不可。

Platform as a Product（平台是产品）。平台不是交付完就结束的项目，它面对的是内部用户，体验差、不好用，用户就会绕开——就像当年绕开域名写 IP 一样。建好没人用，是平台工程最大的失败模式，不是技术不行。

Thinnest Viable Platform（最小可行平台）。平台很容易膨胀：既然做了域名，要不要顺手做负载均衡、做证书、做发布？答案是要克制。平台只负责把一件事做透，其余的能力通过编排别人的接口获得，而不是自己实现。这个边界问题很重要，后面会专门用一篇来讲。

为什么 toC 的答案不适用

研究现有产品时，一个明显的分界是：面向消费者的 DNS 产品和面向企业的 DNS 平台，解决的几乎是两个问题。

toC 的域名产品（注册商和 DNSPod 这类解析服务）卖的是域名资产加解析服务：注册、续费、解析、防攻击，功能到解析为止。这是合理的，因为它的客户不拥有网络——域名指向的服务器在哪里、归谁管、谁在用，厂商既不知道也不需要知道。

企业内网完全不同。你拥有整个网络：每台主机的地址、每个服务的归属、每条记录的生命周期，都是可以也应该被管理的对象。所以企业要建的不是"解析服务"，而是命名基础设施加治理体系：谁能建什么名字、记录归谁、什么时候回收、变更怎么审计，这些才是核心功能，解析反而只是底座。

这个判断直接决定了产品形态：不是买（toC 产品没有治理面），也不全是造（权威解析有成熟开源实现），而是在成熟组件之上，把命名、归属、生命周期和审计这层治理逻辑做出来。

这个系列要展开什么

从"理解 DNS"到"建成平台"，中间是一连串具体的取舍。这个系列会把这些取舍逐个展开：

1. 域名空间模型：公共、个人，以及为什么不做团队空间
2. 短域名的诱惑与风险：一场关于命名权的讨论
3. 证书突围：内网域名的 HTTPS 之路
4. IPAM 轻实践：段级台账与两级反查
5. 溯源元数据：每条记录都应该知道"是谁、为什么"
6. 治理与回收：防误填，不防有意
7. 可靠性演进：从单机备份到高可用
8. 开源竞品分析：天花板在哪里
9. 边界：一个 DNS 平台该做什么、不该做什么

每一篇的结构都一样：问题是什么，考虑过哪些选项，为什么这样选。它们讨论的是同一个六层框架的不同侧面——数据面（权威与递归）、控制面（管理入口）、集成面（GitOps 与工单）、观测面（审计）、安全面（认证与防护）、可靠性面（备份与高可用）。

最后

回头看那两天的等待，真正让我下定决心的不是"慢"，而是慢背后的结构：名字的注册、变更和回收，没有一处是自动的；而只要是人肉的，就一定是慢的、忘的、查不清的。

DNS 是基础设施里少有的"改一行文本就能影响全局"的东西。这样一层能力，值得被当作平台认真对待，而不是散落在某台服务器的配置文件里，靠某个人的记忆维护。

平台不是把工具装起来，而是把治理做出来。