背景
系列写到这里，功能基本都讲过了。收官篇想讨论一个贯穿始终的问题：边界——一个 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 应答还是 HTTP 响应？
- 它调别人的 API，还是进了流量路径？
- 它挂了，影响的是解析还是流量？
三问里任何一问偏向后者，就是越界。还有一个更锋利的版本，适合在评审会上直接问出来：
“这个功能必须操作 DNS 数据才能完成吗？”——一句话挡住大部分职责蔓延。
顺带澄清一个容易混淆的概念：GSLB（全局负载均衡）不算越界。GSLB 的本质是"根据健康状态和拓扑，回不同的 DNS 答案"——它只出 DNS 应答，不转发流量，是 Level 1 的加强版。F5 的产品线分法（GTM 只应答、LTM 才碰流量）印证的就是这条线。
GitOps 双轨：两条变更通道的边界
平台内部的边界同样重要。变更通道有两条，各自的领土必须划清：
个人 zone：用户 → 控制台 UI → API → 权威 DNS
公共 zone：开发者 → git PR → CI 校验/审批 → 同步器 → API → 权威 DNS
公共 zone 走 git 的理由：PR 就是审批流、git log 就是审计、revert 就是回滚——审批、审计、回滚三件事，git 全部免费赠送，比自研一套审批系统便宜得多。仓库按 zone 分文件，YAML 声明记录，owner 字段必填（CI 卡死，落地归属规则），purpose 投影成 TXT（落地元数据规则）：
# zones/devops.example.com/payment.yaml
records:
- name: payment-api
type: A
value: 10.42.3.17
ttl: 300
owner: payments-team # 必填，CI 校验
purpose: 支付网关联调 # 投影为 TXT
双轨的硬规则只有一条：公共 zone 在控制台 UI 里只读。没有这一条，UI 和 git 都能改同一份数据，互相覆盖，两边都不再可信。规则只有一条，但必须零例外。
双轨还有个可爱的副产品，可靠性篇已经用过：git 仓库就是 zone 数据的版本化备份——单点阶段的重建成本因此低到"装 PowerDNS + git sync 一次"。
动态解析与控制台的分工
还有一个更轻的通道值得一提：nip.io 式的动态解析——10.42.3.17.dynamic.example.com 直接解析出内嵌的 IP，零注册零登录。
它和控制台的关系是 gist 和 repo 的关系：临时到"我就是想让别人连我机器试试"的场景，动态解析连登录都省了；需要归属、需要生命周期、需要别人记得住的，走控制台注册。两者不冲突，服务的便利度层级不同。判断标准还是那条：需要持久和归属的，必须进平台；纯临时的，别强迫用户走流程。
Roadmap 的依赖标注法
收尾说一个方法论。评审 roadmap 时，最容易吵的是"某某功能优先级低"。我的做法是换种标注：不是低优先级，是前置条件未满足。
例子是 Consul 集成。服务发现谁都想要，但 Roblox 2021 年 73 小时宕机的复盘就摆在眼前——根因正是 Consul 集群在特定负载下的性能崩溃，而一个依赖它的 DNS 委托会把故障传导给全公司解析。在我还没有把 Consul 的性能边界摸透之前，“Consul 集成"这个条目的状态不是"P3”，而是"blocked by: Consul 运维深度"。
这个标注法的价值：它把"不想做"和"不能做"分开，前者是取舍，后者是纪律。前置条件满足时，条目自动激活，不需要重新争论。
终局：门户层
最后描绘一下边界之内的终局形态。用户要的"一站式"是真实需求，但它不该由 DNS 平台来实现——一站式是门户的职责，不是平台的职责：
门户层（统一入口 / 编排 / Golden Path）
├── DNS 平台（命名、解析、治理）
├── 七层平台（网关、路由、证书）—— 未来建设
└── ……其他专业平台
门户做广度（统一体验、串联流程），平台做深度（各自的领域做透）。DNS 平台和未来的七层平台是门户下平行的专业平台，互相通过 API 编排，谁也不吞并谁。Backstage 是这种形态的代表，F5 用 GTM/LTM 两条产品线讲了二十年的也是这个道理。
而 DNS 平台自己的天花板，我在竞品篇定过：对齐 F5 GTM 的能力集，到此为止。
最后
这个系列从"一个域名等了两天"开始，到这里收尾。十篇下来，技术方案其实都不复杂，真正反复出现的是同一件事：克制。
平台工程做了这些年，我越来越确信一件事：能力是可以加的，边界退了很难收回来。一个平台最大的风险不是功能不够，而是在"顺手做掉"的一次次妥协里，变成另一个面目模糊的系统。
克制比能力重要。
DNS 平台做到最后，守住的是一句话：它回答"去哪里、怎么连接、由谁管理"，剩下的，交给别人。