Marico's space
简单说：资产规模小、变化频率低的团队，手动控制台够用了；如果租分子域名是你物业管理流程的标准环节，漏一条记录就会导致入住卡住，那才值得上配置管道。分界线不是租户数量的魔法数字，而是你能不能做到：验证意图、安全发布记录、观察传播、还能在不靠猜的情况下回滚。
这是我的决策参考：
| 场景 | 更好的起点 | 原因 |
|---|---|---|
| 几个资产，偶尔变更，一个管理员 | 手动控制台加书面检查清单 | 自动化带来的初始成本可能超过出错风险。 |
| 每周都有新租户子域名，共享一个 zone | 带审批的配置管道 | 重复操作会让配置漂移和复制粘贴错误变得昂贵。 |
| 租户自带域名 | 管道加域名验证流程 | 在修改任何记录前，所有权和授权必须明确。 |
| 混合所有权、受监管邮件或频繁迁移 | 带策略和审计存储的管道 | 单个人的控制台视图无法解释意图、历史和回滚。 |
从工作流入手，而不是从云厂商控制台入手。一个物业管理平台可能需要创建 tenant-482.example.com，指向某个入口目标，再发布一个 TXT 凭证用于验证控制权。期望状态存在租户记录里，DNS 是外部可观察的状态。一个 worker 比较两者，提交幂等变更，等待权威确认，然后记录结果。
这套额外机制不是自动就值得上的。如果一个管理员每个季度才创建两个子域名，检查清单加第二个人复核可能比上新服务更安全。当同样的操作重复、并行、且有时间敏感性的时候，自动化才值得：租约入驻、楼宇上线、区域切换、或者租户离场后的清理。
真正的阈值是运营层面的。统计一下激活失败或延迟的次数、核对记录花的时间、有多少人能安全地做变更。如果这些成本在你的故障复盘里是可见的，管道就有明确的业务价值。如果不是，先手动路径跑一个月，把数据采集清楚。
一句话可能省你一周：租户自有的 zone 和平台自有的 zone 是两个完全不同的产品。
对于平台自有 zone，团队控制着权威域名服务器，可以在内部授权后创建租户标签。管道应该拒绝租户命名空间之外的标签、强制白名单记录类型，并为每次变更附加所有者和过期时间。解除配置就变成了一次经过审查的状态转换，而不是临时起意的删除操作。
租户自有 zone 扭转了信任边界。租户控制着 zone，所以你的系统应该生成精确的指令集和验证凭证；不应该假设 API 返回成功就意味着记录在所有地方都可见。验证可以查询权威答案并检查预期值。递归解析器在记录 TTL 到期前可能仍然返回缓存数据。实际上，这意味着入驻记录需要一个状态机而不是布尔值：requested、instructions-issued、verified-authority、observed-recursively 和 expired 是本质不同的状态。客服需要看到当前处于哪个状态、上次检查是什么时候、哪个域名服务器返回了答案、以及租户在验证后是否改了值。没有这些证据，过夜的超时往往变成反复手动修改、冲突的 TXT 凭证、以及一句含糊的"DNS 生效慢"。管道应该在超过截止时间后停止重试、保留证据、给账户一个精确的下一步操作。
邮件是另一个依赖。DMARC（RFC 7489）允许域名所有者发布策略并接收汇总或取证报告。子域名上线如果改变了邮件对齐、SPF 或 DKIM，应该有一个邮件负责人的评审步骤。Web 激活和邮件投递是相关的，但不是同一个部署。
但要注意，租户自有的自动化不适用于租户无法委托授权或无法响应验证请求的场景。这类账户保留文档化的手动交接流程。当业务承诺即时入驻且控制着父 zone 时，平台自有子域名通常是更简单的边界。
核心逻辑刻意保持平淡：队列项包含幂等 key、期望记录和所有权策略。提供商适配器可以替换，但策略和审计日志是你的。这个 TypeScript 示例在任何厂商特定路由之前就停了，因为在这里发明一个 REST 路径会掩盖真正的契约。
type ZoneOwnership = "platform" | "customer"; type DnsRecord = { name: string; type: "A" | "AAAA" | "CNAME" | "TXT"; value: string; ttl: number;
}; type Change = { idempotencyKey: string; zone: string; ownership: ZoneOwnership; record: DnsRecord;
}; interface DnsAdapter { upsert(change: Change): Promise<{ changeId: string }>; authoritative(change: Change): Promise<boolean>;
} async function provisionTenant(adapter: DnsAdapter, change: Change) { if (!/^[a-z0-9-]+\.[a-z0-9.-]+$/.test(change.record.name)) { throw new Error("invalid tenant hostname"); } if (change.ownership === "customer") { throw new Error("customer-owned changes require verified delegation"); } const submitted = await adapter.upsert(change); for (let attempt = 0; attempt < 6; attempt += 1) { if (await adapter.authoritative(change)) { return { changeId: submitted.changeId, status: "authoritative" as const }; } await new Promise((resolve) => setTimeout(resolve, 2 ** attempt * 1000)); } return { changeId: submitted.changeId, status: "pending" as const };
}
队列拥有重试和去重能力。如果 worker 在提供商接受变更后超时，下一次尝试应该先查询幂等 key 或期望状态，再重新提交。记录租户标识符、zone、记录类型、变更 ID、重试次数和延迟。不要把验证凭证或租户内容放进普通应用日志。
指标应该把意图和可见性分开：请求的记录数、权威确认数、待确认数、策略检查拒绝数、最旧队列项的等待时间。只告警 HTTP 成功会漏掉用户层面的失败：租户看到主机名挂了，控制台还是绿的。
契约测试应该覆盖：规范化（尾部点和大小写）、重复的期望记录、无效标签、不支持的记录类型、以及未验证的租户委托。用假适配器测试重试和幂等性。然后在预发环境跑一个故意设置短 TTL 的 zone 和真实的递归解析器；权威成功和缓存可见性是两个独立的观测结果。
把变更部署在审批门后面。diff 应该显示旧值、新值、所有者、原因和过期时间。回滚操作是另一个期望状态变更，而不是盲目删除，因为租户可能在你原始请求之后编辑了租户自有的记录。即使最终状态没变，也要保留审计事件。
我曾经以为传播检查就是一个绿色或红色的信号。其实不是。不同解析器和 TTL 下表现不同，所以先定义用户层面的截止时间，然后分别测量权威答案和递归答案。三句话：测量尾部延迟。
自动化给不了你原本没有的授权。它不能让租户自有 zone 比 TTL 生效得更快，也不能在没有产品决策的情况下解决命名冲突。它还带来了队列、密钥、监控和值班面。这些是实打实的成本，即使 DNS 提供商按次收费。
当变更稀少、可逆、且由一个经过培训的操作员拥有时，坚持用手动控制台。当入驻是一个发布步骤、多人需要同样的护栏、或者配置漂移已经产生了客服工单时，选择配置管道。对于混合资产组合，先把平台自有的租户上管道，租户自有的域名走明确的验证流程；只有在授权和回滚契约清晰之后才合并。
租户量、域名所有权、邮件策略或故障率发生重大变化后，应该重新审视这个决策。小而可观测的管道就够了。目标是可预测的所有权和证据，不是为了自动化而自动化。