平台工程 on 出租窝

内网 DNS 平台（10）：边界——一个 DNS 平台该做什么、不该做什么

Sun, 09 Aug 2026 00:00:00 +0800

背景

系列写到这里，功能基本都讲过了。收官篇想讨论一个贯穿始终的问题：边界——一个 DNS 平台该做什么，更关键的是，不该做什么。

这个问题不是哲学题。我见过 DNS 平台做到后来变成 API 网关的团队：先是"顺手"加了反向代理，然后加了负载均衡策略，然后有人提需求要 WAF——最后团队一半精力在维护流量路径上的组件，DNS 本身反而没人深耕，两边都没做好。边界失守的代价不是功能变多，是主业稀释。

先看全景，再逐层划界。

六层框架总图

整个平台可以用六个层面描述，前几篇各自讲了其中一两层：

数据面 权威 DNS（PowerDNS）+ 递归转发
控制面 管理控制台（自助建改删）+ API
集成面 GitOps（公共 zone 记录即代码）+ 工单审批
观测面 审计日志 + 查询统计 + 治理报表
安全面 LDAP 认证 + 护栏 + 证书策略
可靠性面 git 备份 + 重建预案 + HA roadmap

六层的关系是：数据面是存在理由，控制面和集成面是两条变更通道，观测面让治理成为可能，安全面和可靠性面是底座。任何新需求进来，先问它属于哪一层——不属于任何一层的，就是越界。

七层的三层深度模型

最难划的边界在"七层"（HTTP/应用层）。用户的真实需求长这样：“我建了域名，能不能顺手把路由也配好？"——听起来无比合理，做进去却步步惊心。我把它拆成三个深度：

Level 1：做七层的"知情者”。 七层信号参与 DNS 决策：健康检查发现后端挂了，驱动 DNS 把记录摘除；证书系统用 DNS-01 验证。这个深度在边界内——DNS 平台只是消费信号、改变自己的应答，不碰流量。

Level 2：做七层的"指挥者"。 建域名的同时，平台去调 ingress/LB 的 API，把对应路由开好。注意平台做的不是自己实现转发，而是编排别人的接口。这个深度是"一站式体验"的真正来源——用户感觉平台什么都能办，实际上平台只是替他敲了隔壁系统的门。这条 Golden Path 我支持，但每个集成都要单独评审。

Level 3：做七层的"执行者"，禁区。 自建反向代理、负载均衡、WAF——一旦跨进流量路径，平台就从"DNS 平台"变成了"又一个流量管理平台"，开头那个失败故事就是这么发生的。

内网 DNS 平台（9）：竞品分析——市面上的产品都怎么做

Sat, 08 Aug 2026 00:00:00 +0800

背景

设计过程中我有一个坚持：不闭门造车。平台的每个模块，市面上都有做得最好的产品，先看清它们怎么做、为什么这么做，再决定自己采用什么、参考什么、不碰什么。

这一篇按模块过一遍竞品。分析的方法论不是"选哪个产品"，而是回答三个问题：这个模块谁做得最好？学什么？为什么不直接用？

总表

模块	竞品/参照	学什么	为什么不直接用
权威 DNS	PowerDNS / BIND / CoreDNS	PowerDNS 的 API 与后端灵活性	—（直接采用）
管理 UI	PowerDNS-Admin	开箱即用 + LDAP	配额/空间隔离要二开
toC 域名商	DNSPod / Cloudflare / name.com	view 智能解析的概念	功能止于解析，无治理面
商业 DDI	Infoblox / BlueCat	DDI 一体，IPAM 是护城河	重型商业套件，自助体验差
智能解析/GSLB	F5 GTM / NS1	功能天花板：pool/健康监控/就近调度	商业硬件；但边界设计值得学
云 DNS	Route53 / Azure Private DNS	私有 zone + 转发的产品形态	云绑定，自建内网不适用
GitOps 工具	dnscontrol / OctoDNS	记录即代码 + plan/apply	评估后决定集成深度
IPAM	NetBox / phpIPAM	数据模型与 API	IP 级太重，我们只要段级
私有 CA	step-ca / Vault PKI	step-ca 的轻量 ACME	—（选型推荐）
门户层	Backstage	“门户做广度，平台做深度”	未来方向，不在本平台边界

下面挑几个最有启发的展开。

内网 DNS 平台（8）：可靠性——从 MVP 单机到 HA 的演进

Fri, 07 Aug 2026 00:00:00 +0800

背景

聊到可靠性，先把态度说清楚：HA 当然想要。DNS 是基础设施的基础设施，它挂了，所有依赖名字的系统都会跟着抖。但 MVP 阶段的现实是：权威 DNS 只有一台机器，团队的精力只够把一件事做对。

所以这个阶段的可靠性策略不是"做 HA"，而是两句话：先保证单机可用，再保证备份可靠——HA 是 roadmap，不是放弃。

这一篇讲单机阶段怎么把可靠性做到位，用三个著名事故当警示，最后给出 HA 的演进路径和触发条件。

单机阶段的可靠性三件套

第一件：git repo 就是版本化备份。 这是 GitOps 设计的副产品，也是我最喜欢的一笔。公共 zone 的权威数据源本来就是 git 仓库（GitOps 篇会展开），个人 zone 则有一个导出器，每天把所有记录快照导出到另一个 git 仓库。两边合在一起意味着：整个 DNS 平台的全部状态，都有完整的版本历史。

由此得到一个极低的重建成本：装一台 PowerDNS + git sync 一次，平台就回来了。 不需要备份软件，不需要恢复演练的复杂流程，git clone 就是恢复。

第二件：递归缓存是天然的故障保护网。 权威 DNS 挂掉后，公司递归 DNS 里还缓存着 TTL 期内的所有记录——大部分服务在缓存过期前毫无感知。TTL 300 秒意味着你有至少五分钟的"隐形缓冲"，而实际感知往往更久（热点记录会被持续刷新）。这不是不修的理由，但它是单机现实的减压阀。

第三件：依赖降级预案。 平台登录依赖 LDAP，LDAP 挂了怎么办？留一个本地 admin 账号兜底，只在 LDAP 故障时启用。DNS 挂了平台还能查（直连权威），平台挂了 DNS 不受影响（数据面和管理面分离）——每一层都问过自己"上一层挂了我会怎样"。

三个事故

单机策略定下来后，我专门重读了三个著名事故的复盘，确认自己的取舍站得住，也知道未来 HA 要解决什么。

2016 年 Dyn 被 DDoS。Mirai 僵尸网络打瘫了 Dyn——一家大型 DNS 托管商。后果是 Twitter、Netflix、GitHub 等一批把 DNS 全部托管在 Dyn 的公司集体受影响。这个事故的教训朴素到残酷：你的应用做得再好，DNS 全押在一家，就是单点。 事后行业流行的做法是用两家 DNS 提供商互为备份。对应到我的设计：内网权威虽然是单机，但"递归缓存 + 备份重建"是另一种形式的减压和恢复，HA 阶段则必须考虑第二节点。

内网 DNS 平台（7）：治理与运营——护栏、僵尸与纠偏

Thu, 06 Aug 2026 00:00:00 +0800

背景

第一篇说过"带护栏的自助"。这一篇把护栏和上线后的运营治理写完整：哪些限制该有、哪些限制该砍、记录死了怎么办、记录"活着但不该活"怎么办。

先把治理哲学放在最前面，因为它决定了后面每一条具体规则的形状：

防误填，不防有意——别把人想得太坏。

内网治理的边界是防止误操作，不是防恶意。真要防恶意，一个想绕过平台的人有一百种方法（比如在自己电脑上跑个 dnsmasq，把自己的子域委托出去），平台根本拦不住；而为了拦这一百种方法加的层层校验，会把九十九个正常用户的自助体验全部拖垮。治理的每一刀，都应该砍在"无心之失"上，而不是砍在"假想敌"上。

护栏四件套

初稿的护栏有六条，定稿时砍成了四条。先看留下的：

记录类型白名单 + 禁 NS/SOA。个人空间只允许 A、AAAA、CNAME、TXT、SRV。NS 和 SOA 禁掉——允许用户在个人子域里再开委托，等于让他把平台的责任边界撕开一道口子（委托出去的子域解析完全脱离平台控制，失效了平台还不知道，这在安全上叫 dangling delegation）。
配额。每个个人 zone 的记录数有上限（比如 50 条）。防的是脚本失控和"把个人 zone 当正式服务注册中心用"。
TTL 上下限。默认 300 秒，允许 60~3600。TTL 太短刷权威，太长变更不生效——而用户总是倾向于"我的记录最重要，TTL 给最长"，所以需要制度兜底。
前端提示防呆。建记录时实时校验格式、提示冲突、给默认值。大多数误填在输入框阶段就能拦下来，这是成本最低的护栏。

砍掉的是命名黑名单（不许起某些名字）和记录值强校验（比如强制校验 A 记录的 IP 是否在某段）。砍的理由：个人子域里起什么名字，危害不出自己的圈；值校验误伤面大（合法场景太多），而且防不了有意绕过。这两条都属于"防有意"的投入，按治理哲学砍掉。

治理的两个对象：僵尸，和活着但不该活的

上线后真正要处理的记录有两类，它们的治理动作完全不同。

第一类：僵尸（死的）。长期无查询、无更新、owner 账号已失效的记录。动作是标准三段式：提醒（邮件/IM 通知 owner）→ 冻结（暂停解析，看有没有人喊）→ 回收（删除）。冻结期是关键设计——直接删除的回收会制造事故，先冻结观察的回收几乎不会。

第二类：违规使用（活着但不该活的）。这类是我后来才意识到的：个人 zone 的记录指向生产网段的 IP、流量模式像个正式服务——用户把"试验场"当成了"免费的生产入口"。

对这类记录，治理动作不是删除，而是引导迁移：联系 owner，协助他把服务迁到公共 zone 走正式审批。原因有两层：一是它活着、有真实流量，删了就是生产事故；二是它的存在恰恰说明公共 zone 的流程可能有卡点（是不是审批太慢了？），治理应该顺手修复流程，而不只是消灭症状。

这条规则把"个人 zone = 试验场"从口号变成了可执行的判定：试验场的记录，流量画像应该是稀疏的、临时的；不像试验的，就该去它该去的地方。

还有一个对称的豁免规则：活跃豁免。有持续查询流量的记录自动续期，治理不打扰使用者。回收的矛只对僵尸，活跃的记录永远不用担心被误伤——这是用户敢用平台的前提。

TTL 与递归缓存的调试坑

运营期最高频的"平台 bug 报告"，其实都不是平台的 bug：用户改了记录，dig 公司递归查到的还是旧值——递归缓存还没过期。

这类问题的解法是三件套：TTL 默认小（300s 是体验和缓存效率的平衡点）、文档里写明"调试请 dig @权威IP 直连权威"、平台前端提示"变更最长 N 分钟生效"。把预期管理做在前面，工单量能少一半。

内网 DNS 平台（6）：IP 溯源与元数据——一次自我纠偏

Wed, 05 Aug 2026 00:00:00 +0800

背景

这一篇是系列里写法最特殊的一篇：它不是"问题→方案"的直线叙事，而是我在设计过程中两次推翻自己的记录。第一次推翻发生在 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 的职能？

内网 DNS 平台（5）：IPAM——企业 DNS 的另一半

Tue, 04 Aug 2026 00:00:00 +0800

背景

平台跑起来之后，我意识到一个一直存在但被忽略的事实：DNS 记录里的 IP 是个裸值——它不知道该不该被用、有没有被回收、之前是谁在用。给"名字→IP"的映射建了平台，但"IP 本身"的账，还记在一本 Excel 上。

这一篇讲 IPAM（IP 地址管理）：为什么它是企业 DNS 的另一半，以及我为什么最后只做了一半的它。

三个事故

先说没有 IPAM 的代价，三个都真实见过：

流量串号。服务下线了，DNS 记录没删；IP 被回收，又分给了另一台机器。B 团队的调用还指着旧域名，流量直接打到了 C 的机器上。排查时两边都觉得委屈：调用方说"我走的是域名啊"，被打的机器说"我根本不认识这个服务"。

反向查人两小时。安全设备告警：某内网 IP 有异常外连。这个 IP 是谁的？翻 Excel（三个月没更新）、问群（没人认领）、查 CMDB（没有这台机器）。两小时后发现是某台临时测试机，主人早就休假了。

幽灵网段。要扩容，问"10.42.0.0/24 还有多少可用？“没人知道。段里注册的、实际在用的、早就不在但没删的，三个数字对不上，最后只能拍脑袋再申请一段。

三个事故的共同根源：IP 的分配、使用、回收没有账本，或者账本和现实早就脱节了。

IPAM 的数据模型

教科书式的 IPAM 有两个核心对象。

网段树。网段按层级组织：10.0.0.0/8 下面分地域/机房/用途。层级本身就是信息——权限可以继承（这个段归网络团队管），统计可以上卷（这个机房的利用率是多少）。

IP 状态机。每个 IP 有状态：available（可用）→ allocated（已分配）→ reserved（保留）→ deprecated（弃用冻结）→ 回到 available。特别说一下 deprecated 这个状态：删服务时 IP 不是立刻回收，而是冻结一段时间——防止"刚删就被分给别人"的串号事故。冻结期是对人性（或者说对缓存、对陈旧配置）的尊重。

与 DNS 的四个联动

IPAM 单独存在没有意义，它的价值全在和 DNS 的联动上：

建 A 记录时校验占坑：用户建 api.xx → 10.42.3.17，平台检查这个 IP 在 IPAM 里的状态——不是 allocated 或者不属于任何已知段，就提示确认。
自动生成 PTR：A 记录建好的同时，反向记录自动落好，不用人维护两份。
删记录时冻结回收：删除 A 记录，IP 进入 deprecated 冻结期，过了期限才回 available。
三路对账：这是灵魂，单独讲。

没有扫描对账的 IPAM，只是好看的 Excel

IPAM 最大的失败模式是台账和现实脱节——人登记的时候是真的，三个月后一半是假的。防脱节只有一个办法：对账，而且必须是三方互对：

内网 DNS 平台（4）：内网 HTTPS 突围——证书问题的系统解法

Mon, 03 Aug 2026 00:00:00 +0800

背景

短域和正式域都建好之后，用户的第一批反馈里很快出现一类：浏览器打开 https://api.zhangsan.user.xx，证书报错。

这是内网私有域名的宿命问题：公共 CA 不可能给你签证书。这一篇把这个问题从原理到解法讲清楚——它是个支线话题，但坑的密度超出我预期，值得一篇。

公共 CA 的两道墙

“用 Let’s Encrypt 签一个不就行了？"——不行，而且不行有两层原因，一层比一层硬。

第一层：技术墙。申请证书时 CA 要验证你拥有这个域名。即使是 DNS-01 验证（在 TXT 记录里放 challenge），也要求 CA 从公网能查到这条 TXT。而 xx 是私有 TLD，公网上根本不存在——CA 的解析器查不到，验证无从谈起。

第二层：政策墙，更硬。CA/Browser Forum 从 2015 年起就禁止公共 CA 为 Internal Name（内网名称、私有 TLD、IP 地址）签发证书。这是合规红线，写在全球 CA 的基线要求（Baseline Requirements）里——就算某个 CA 技术上能验证，它也不敢签，签了会被浏览器踢出信任库。

两层墙的结论一致：私有域名的证书，公共 CA 这条路是死的。

自救：自建 ACME CA

墙堵死了正门，但 ACME 给了我一个启发：它是开放协议，不是 Let’s Encrypt 的专利。既然协议公开，就可以在内网自建一个 ACME CA——我用的是 smallstep 的 step-ca。

step-ca 部署很轻，而且 ACME 客户端生态零改造：certbot、acme.sh、Traefik、Caddy 全都天然支持自定义 ACME 目录，把目录指向内网 step-ca 就能自动签发。签发这个问题，一晚上就解决了。

内网 DNS 平台（3）：给内网域名起名字——短域、.internal 与递归转发

Sun, 02 Aug 2026 00:00:00 +0800

背景

上一篇的空间模型里出现了两类域名：正式的 devops.example.com，和两字母的个人短域。这一篇讲这个短域是怎么来的、风险评估怎么做，以及让全公司能解析它时踩过的坑。

（脱敏起见，下文用 xx 代替实际使用的两字母短域，example.com 代替公司真实域名。）

一个真实的需求：域名太长

设计之初，域名方案顺理成章：服务用 devops.example.com 的子域。但把它给"人"用的时候，问题立刻出现——公司真实域名有十好几个字符，个人空间的全名会变成：

api.zhangsan.user.devops.example.com

这条名字打完手都酸了。个人空间的核心场景是临时联调、随手起名，名字长到这个程度，自助体验就死了。

内网的一个自由度：自定义顶级域

内网有一个公网没有的自由度：可以自己发明顶级域。

公网里你只能从注册商买域名；内网的解析完全在自己的权威 DNS 手里，你想让 xx 成为顶级域，它就能成为顶级域。解析不出外网——但内网名字本来就不需要出外网。

于是给个人空间申请了一个两字母短域 xx。个人名字立刻清爽了：

api.zhangsan.user.xx

这不是替换 devops.example.com，是并列的另一条轨：稳定服务走正式域名，临时试验走短域。双轨各有各的规则，上一篇已经写过。

插曲：私有 TLD 的沟通成本

短域要在全公司生效，需要管理员在公司的递归 DNS 上加一条转发。沟通时出了个小插曲：管理员第一反应是"你要用 xx 替换 devops 域名？"——替换没有意义，他无法理解这个需求。

解释清楚"不是替换，是并列的另一个域"之后，事情立刻就办了。这个插曲给我提了个醒：私有 TLD 对很多网络管理员来说是个陌生概念。他们的经验里域名都是买来的、有注册商的，“自己发明一个顶级域"听起来像违规操作。后来我把解释话术固定下来：内网解析归自己管，这个域只在公司网络里存在，出了公司就查不到——就这三句。

风险评估：撞名怎么办

自定义 TLD 不是免费的，最大的风险是冲突：万一哪天 ICANN 把 xx 分配成真实的公网 TLD，内网和外网就有两个 xx，内外解析会打架。

评估的过程比结果有意思：

两字母 TLD 在现行规则下只可能是国家代码域（ccTLD），通用顶级域（gTLD）要求至少三个字母；
而 ccTLD 来自 ISO 3166 国家代码表，我们用的两字母组合恰好不在表里；
所以冲突风险从"现实风险"降为"理论风险”——理论上 ISO 可以给新国家分配这个代码，但这个概率和"公司网络撞名"相比可以忽略。

真实剩下的风险只有一个：多 VPN 撞名。如果合作方的内网也用了同一个短域，员工同时拨两个 VPN 时会解析错乱。这是自定义 TLD 的通病，防不住，只能记着。

风险对冲：让短域承载的东西本来就该死

评估完我又想了一层：为什么敢用一个有理论风险的域？

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

Sat, 01 Aug 2026 00:00:00 +0800

背景

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

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

两类空间，两种规则

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

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

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

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

权限矩阵很朴素：

操作	公共 zone	自己的个人 zone	别人的个人 zone
查询	所有人	所有人	所有人
建/改/删	审批后由同步流程执行	本人自助	不可
审批	DevOps	不需要	—

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

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

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

为什么不做团队空间

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

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

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

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

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

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

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

Fri, 31 Jul 2026 00:00:00 +0800

背景

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

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

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

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

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

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

五个日常痛点

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

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

这些痛点单独看都是小事。但它们叠加起来的效果很明显：名字这件事在内网里不可靠。因为不可靠，大家就绕开它——配置里写 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 这类解析服务）卖的是域名资产加解析服务：注册、续费、解析、防攻击，功能到解析为止。这是合理的，因为它的客户不拥有网络——域名指向的服务器在哪里、归谁管、谁在用，厂商既不知道也不需要知道。

DNS不只是A记录：从Homelab到企业平台的一些思考

Thu, 23 Jul 2026 00:00:00 +0800

背景

我最早对 DNS 产生兴趣，不是因为 A 记录，而是因为 MX 记录。

刚开始做邮件工程师时，我对域名、主机名和记录之间的对应关系非常敏感。MX 指向的是邮件主机名，不是一个可以随便填写的 IP；邮件主机还要有正确的 A/AAAA 和 PTR；发送时的 EHLO、反向解析以及 SPF、DKIM、DMARC 又共同影响着身份判断和投递结果。一个看起来不起眼的主机名不一致，就可能让邮件进入垃圾箱，甚至直接被拒收。

那段经历让我第一次意识到：DNS 并不只是“域名解析到 IP”的电话簿。它同时参与了服务定位、身份表达、信任建立和系统边界的划分。域名怎么分层、主机名怎么命名、正向和反向是否一致，这些都属于系统设计的一部分。

2019 年写《家用DNS选择》时，我又从邮件系统回到了 Homelab：家里 DHCP 分配的 IP 总在变化，希望找一个轻量、支持 API、方便迁移的 DNS 服务。那时最直接的需求仍然是给变化的地址一个稳定名称，但继续往下折腾后会发现，A 记录只是 DNS 最基础的一种玩法。

DNS 还能描述服务端口和优先级、发布少量资源元数据、引导 Agent 找到平台入口、约束证书签发，并成为自动化和安全审计的一部分。这些能力不只适用于 Homelab：小公司需要低成本的服务发现和资产归属，大公司则需要域名委派、权限、审计、高可用和安全治理。规模不同，组件和管理方式会变，但底层原则是通用的。

这篇文章不是某个 DNS 产品的部署手册，也不是一个项目实施计划，而是我对 DNS 在基础设施和平台系统中还能承担哪些职责的一次整理：

DNS 负责回答“去哪里、怎么连接、由谁管理”；平台 API 负责实时状态、完整配置、权限和复杂业务逻辑。

或者说得更简单一点：DNS 是目录，不是数据库；是路标，不是目的地。

我理解的 DNS 设计原则

名称是稳定契约，地址只是实现细节

IP、机房、集群和容器都会变化，但调用方不应该跟着基础设施不断修改配置。一个稳定的服务名称应当成为客户端与平台之间的契约，再由 A、AAAA 或 CNAME 把它映射到当前实现。

域名层级应该表达稳定边界

域名结构适合表达环境、项目、服务等相对稳定的维度，例如 api.test.project.example.com。团队名称和负责人经常变化，更适合放在 TXT 或服务目录中，而不是永久编码进域名。好的域名规划应该支持委派，让不同团队能够管理自己的命名空间，而不必共享整个根域的修改权限。

正向和反向解析是一套完整身份

邮件系统让我对 PTR 特别敏感，但这个原则并不局限于邮件。A/AAAA 回答“这个名字在哪里”，PTR 回答“这个地址是谁”。两者一致时，日志、审计、资产核对和故障排查都会清晰很多。

主机名应该成为物理资产的稳定索引

以前管理几百台物理服务器时，一个很实用的原则是：日常运维使用主机名，不直接使用 IP。