DigitalPlat FreeDomain 域名运维入门：基础设施台账与变更管理实践

可靠运维始于两件事：一份反映当前真实状态的基础设施台账，以及一套受控的变更流程。在 DigitalPlat FreeDomain 的体系里，域名注册（Dashboard）、权威 DNS、网站托管、邮件与监控往往分属不同系统，任何一个环节"说不清谁在管"，都会让一次简单的 DNS 修改变成一次事故。读完本篇，你将掌握如何为域名建立私有台账、执行变更前检查与变更后验证（含可复制的 dig/curl 命令），以及如何在团队中分离资源角色，让域名在人员变动与设备丢失后依然可恢复。

为什么域名运维要先建"台账"

DigitalPlat FreeDomain 的产品边界决定了台账的必要性：注册控制层（DigitalPlat Dashboard）只负责域名状态、到期时间、委托给外部的权威 NS 主机名等注册级信息，而 A、CNAME、MX、TXT 等记录都在外部权威 DNS 服务商那里维护。这一边界在 产品边界说明 中有完整描述：DigitalPlat 记录域名委托到哪些外部 NS，但不提供外部 DNS 的记录编辑器。

这意味着同一个域名天然横跨多个账户体系——注册账户管状态与续费，外部 DNS 账户管 zone 记录，服务器账户管网站，证书自动化和监控系统又各有归属。因此文档给出的核心原则是：

账户界面与服务能力会变化，台账必须基于当前观察到的状态维护，而不是依赖过期的截图。

台账不是给人看的摆设，而是变更管理的前置条件：变更前要定位每个受影响服务的归属人，变更后要知道去哪里验证，恢复时要知道从哪里重建。

六个控制域：逐项确认"谁在管"

在建立台账前，先逐一记录以下六个控制域各自在哪里管理：

控制域	管理什么	典型载体（以 DigitalPlat FreeDomain 为例）
注册账户（Registration account）	域名状态、续费、委托的 nameservers	DigitalPlat Dashboard 的 Domain List 与域名详情页
外部权威 DNS 账户	Zone 内全部记录	你自选的 DNS 服务商控制台
服务器/托管账户	网站本体	自有服务器或托管平台
证书自动化	TLS 证书的签发与续期	服务器或托管系统上的自动化工具
邮件系统	邮箱与发信配置	邮件服务商或自建邮件栈
监控系统	对外检查与告警	任意外部探测或自建监控

其中注册账户一栏值得特别强调：Domain List 证明的是注册账户内的状态，它不能证明外部 DNS 记录存在（详见 Dashboard 导览）。这正是台账要同时覆盖六个域而非只记注册信息的原因。

建立私有域名台账

为每个维护中的域名保留一份私有台账，建议至少包含以下字段：

字段	用途
Domain（域名）	精确的注册名
Project owner（项目负责人）	对内容与续费负责的人
Account owner（账户所有人）	实际控制注册账户的人或组织
Authoritative DNS（权威 DNS）	Nameserver 主机名与 DNS 账户的所有人
Web host（Web 托管）	服务器或部署的所有人
Renewal date（续费日期）	日历截止日与各级提醒日期
Certificate（证书）	覆盖的主机名与续期方式
Email use（邮件用途）	该域名是否收发邮件
Recovery contact（恢复联系人）	内部升级/应急联系人

几个实操要点：

• Renewal date 必须以注册界面当前显示值为准。续费窗口、费用、宽限行为都可能变化，不同后缀的规则不可互相套用，具体以 状态与续费章节 和 续费与到期章节 的流程为准（90/60/30/7 天多级提醒均指派到具体负责人）。
• Authoritative DNS 一栏要同时写 NS 主机名和 DNS 账户所有人。NS 值可以从 Dashboard 或 dig NS 获得，但账户所有权只能靠人来确认——这是迁移 nameservers 时能否快速回滚的关键（见 安全迁移 Nameservers）。
• 安全红线：不要把密码、会话 Cookie、API 密钥或证书私钥写进台账。 台账记录的是"哪里管、谁来管、何时到期"，而不是凭据本身。备份与恢复章节 中的 "DNS 和域名恢复包" 也遵循同一原则：可打印的恢复材料中不得包含原始密码与 API token；密钥应存放在密码管理器或密钥管理系统中，台账里只记录存放位置。

变更前检查：五步固定流程

任何会改变域名行为的动作（修改 NS、调整记录、更换托管、改注册信息）之前，按顺序执行：

1. 检查注册通知与域名状态——登录注册界面（DigitalPlat Dashboard 即注册状态的权威来源），阅读当前公告，确认域名仍处于预期状态。公告可能改变"安全的下一步"，哪怕旧教程描述的是另一套流程。
2. 导出或记录现有 DNS 记录——完整快照当前 zone。注意 dig ANY 不是可靠的 zone 导出手段，应使用 DNS 服务商支持的导出功能或管理界面逐项记录，覆盖 A/AAAA、CNAME、MX、TXT（含 SPF 与验证记录）、DKIM selector、DMARC、CAA、SRV 以及委托子域的 NS 记录。
3. 记录当前 nameservers 与 TTL 值——TTL 决定变更传播的时间尺度，也是回滚时间窗的估算依据。
4. 确认每个受影响服务的归属人——这一步直接依赖前面建立的台账；如果某个服务查无归属人，说明台账有缺口，应补全后再变更。
5. 定义回滚值与决策点——明确"改回什么值"以及"出现什么信号就决定回滚"，避免出问题时临场判断。

这套流程与 Nameservers 迁移 的"先建新区、再换委托、两边都保留"策略是同一逻辑：变更前快照 + 可回滚性，是 DNS 类变更不出大事故的底线。

变更后验证：三条最小命令集

变更提交后，不要只盯着控制台显示成功，必须从公网视角验证。最小验证集如下：

dig NS example.dpdns.org
dig A example.dpdns.org
curl -I https://example.dpdns.org

• dig NS 验证注册级委托是否已生效（新 NS 是否已被父层接受）；
• dig A 验证外部权威 DNS 是否返回预期地址记录；
• curl -I 验证端到端链路（TCP、TLS、HTTP）是否正常工作。

当变更涉及邮件或特定应用时，追加对应的专项检查，例如 dig MX example.dpdns.org、dig TXT _dmarc.example.dpdns.org，以及对 API 端点的探测。验证视角应与 监控与事件响应 中的"用户路径"一致：DNS 解析 → TCP 连接 → TLS 校验 → HTTP 返回预期状态 → 页面包含预期标识。注意旧委托的答案可能仍被缓存，即使 Dashboard 已显示新 NS，也不要立即删除旧 zone（这一约束在 nameserver 迁移章节有专门说明）。

分离角色：让域名活过人员变动

对组织而言，应避免让某一个个人账户不加记录地同时拥有注册、DNS、托管、证书和邮件五类资源。单点私有所有权意味着：人员离职、设备丢失或账户被盗时，整条服务链同时失联。

实操上建议：

• 把"账户所有权"与"日常操作权"分开：台账中的 Account owner 是恢复责任主体，日常变更可由受控的授权管理员执行；
• 记录访问所有权与恢复流程——包括恢复邮箱所有人、批准的管理员名单、恢复码存放位置、续费责任人与事件联系人（详见 账户与 API 安全 的恢复计划清单）；
• 人员变动时执行交接动作：转移或变更账户归属（如平台支持）、轮换密码与 API key、撤销旧会话、转移文档与续费所有权（与 注册数据与隐私 中的离岗检查一致）；
• 主动放弃域名前，执行 offboarding 清单：清理敏感服务与过期记录、迁移邮件与恢复账户、从登录恢复、OAuth 回调、包元数据、白名单中移除该域名——被放弃的域名可能随后被他人注册。

本篇要点回顾

• 域名的可靠运维 = 当前状态台账 + 受控变更流程，二者缺一不可；
• 台账覆盖六个控制域（注册、外部 DNS、托管、证书、邮件、监控），字段含域名、双负责人、NS 与 TTL、续费/提醒日期、证书主机名、邮件用途、恢复联系人；
• 台账是"索引"而非"凭据库"：密码、Cookie、API 密钥、私钥一律不落台账；
• 变更前五步（查状态 → 快照记录 → 记 NS/TTL → 定位归属人 → 定义回滚点）+ 变更后 dig NS / dig A / curl -I 最小验证集，构成可复制的变更纪律；
• 组织场景下分离账户所有权与操作权，并预写恢复流程，是域名对抗人员与设备风险的根本手段。

完成本篇后，建议按 教程目录 继续阅读续费与到期（5.2）、Nameservers 迁移（5.3）等章节，把台账与变更纪律应用到具体的高风险操作中。