域名解析是业务系统的入口，DNS记录变更如果没有严格的流程约束，很容易因为手误、权限过大或信息不同步造成线上事故。把DNS变更纳入工单系统后，每一次新增、修改、删除解析记录都需要经过申请、审批、执行和审计环节，运维团队可以随时追踪变更来源和执行结果。本文从工单字段设计、审批策略、API对接和回滚审计四个角度，介绍一套可以落地的DNS变更流程。
一、DNS变更工单的字段与状态设计
工单系统承载DNS变更，首先要解决的是信息结构问题。一个合格的DNS变更工单至少需要记录域名、记录类型、主机记录、记录值、TTL、变更原因、申请人、所属业务和回滚快照等字段。记录类型通常包括A、AAAA、CNAME、MX、TXT、SRV等，不同记录类型需要校验规则不同。例如A记录的值必须是合法IPv4地址，CNAME记录不能与MX、NS等记录冲突。在创建工单时，系统可以通过正则表达式或DNS解析库完成第一层校验，减少审批环节中的无效信息。
状态设计是工单流转的核心。建议采用草稿、待审批、审批通过、待执行、执行中、执行成功、执行失败、已回滚、已关闭等状态。草稿状态允许申请人随时编辑；提交后进入待审批状态，锁定关键字段；审批通过后进入待执行状态，由执行人确认执行窗口；执行中的工单不允许重复触发；执行成功或失败后进入终态。如果执行失败并触发回滚，状态应标记为已回滚，而不是简单关闭，方便后续复盘。
CREATE TABLE dns_change_ticket (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
ticket_no VARCHAR(32) NOT NULL UNIQUE,
domain_name VARCHAR(255) NOT NULL,
record_type VARCHAR(20) NOT NULL,
host_record VARCHAR(255) NOT NULL,
record_value VARCHAR(500) NOT NULL,
ttl INT DEFAULT 600,
change_action VARCHAR(10) NOT NULL,
applicant VARCHAR(64) NOT NULL,
approver VARCHAR(64),
executor VARCHAR(64),
status VARCHAR(20) NOT NULL DEFAULT 'DRAFT',
rollback_snapshot TEXT,
failure_reason TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
executed_at DATETIME NULL
);
上面的表结构可以作为自研工单系统的基础模型。change_action字段区分新增、修改、删除三种操作，rollback_snapshot用于保存变更前的记录内容。工单创建时自动生成唯一编号，便于在审批记录和操作日志中关联。对于使用Jira、ServiceNow等通用平台的情况，可以通过自定义字段和状态机插件实现类似结构，没有必要完全自研数据库。
二、审批流程与权限隔离策略
DNS变更直接关系到域名解析结果，审批策略需要根据域名环境区分。生产域名的A记录、CNAME记录变更建议至少两个人审批，其中一人必须是网络管理员或值班经理；测试环境域名可以放宽到开发负责人审批。审批人不能是申请人本人，执行人也不能同时是最终审批人，这样可以在流程上实现基本的权限隔离。对于删除记录操作，无论环境如何都应该要求更高等级的审批，因为删除动作一旦丢失原始配置，恢复成本比修改更高。
工单系统可以内置审批规则引擎，根据域名后缀、记录类型、变更动作和申请人的组织架构自动匹配审批人。例如，凡是涉及公司主域名的变更，强制走网络团队审批；凡是包含内网解析的变更，需要安全团队会签。审批通过前，工单系统应锁定记录值、主机记录等关键字段，防止申请人在审批途中偷偷修改。拒绝的工单必须填写拒绝原因，申请人可以复制原工单重新提交，避免重复创建造成信息碎片。
approval_rules:
production:
min_approvers: 2
required_roles:
- network_admin
- duty_manager
forbid_self_approval: true
delete_record_extra_approver: security_admin
staging:
min_approvers: 1
required_roles:
- developer_lead
forbid_self_approval: true
test:
min_approvers: 1
required_roles:
- developer
权限隔离除了体现在审批节点上，还要落实到DNS服务商的API密钥管理。工单系统不应允许普通用户直接调用DNS控制台，而应该通过系统内置的服务账号与DNS服务商通信。服务账号的权限只保留单域名或单记录集的写权限，并且禁止删除整个域名。密码、Token等敏感信息统一存放在配置中心或密钥管理服务中，执行日志只记录密钥ID，不记录明文Token。
三、DNS服务商API对接与执行自动化
审批通过后的执行环节可以通过调用DNS服务商API自动完成。常见的DNS服务商都提供REST API，例如阿里云DNS、腾讯云DNSPod、Cloudflare等。工单系统在待执行状态下，由执行人点击执行按钮触发API调用，也可以配置定时任务在变更窗口自动执行。无论哪种方式，API调用必须设计成幂等操作，避免网络超时重试时重复创建或修改记录。
调用API前需要先通过工单系统查询当前记录是否存在，并拉取变更前快照。修改操作一般需要记录ID，新增操作则需要检查同名记录是否已经存在。如果工单申请的是新增记录，但接口发现已有同名同类型记录，应直接终止执行并提示冲突；如果申请的是删除记录，但记录不存在，可以视为已成功，或者让执行人确认是否关闭工单。下面是一个对接通用DNS API的Python示例，执行修改记录操作并获取返回状态。
import requests
def update_dns_record(record_id, record_type, value, ttl=600):
url = "https://dnsapi.ippipp.com/Record.Modify"
payload = {
"login_token": "SERVICE_ACCOUNT_TOKEN",
"format": "json",
"domain": "ippipp.com",
"record_id": record_id,
"sub_domain": "www",
"record_type": record_type,
"record_line": "默认",
"value": value,
"ttl": ttl
}
resp = requests.post(url, data=payload, timeout=10)
result = resp.json()
if result.get("status", {}).get("code") != "1":
raise RuntimeError("DNS更新失败: %s" % result)
return result
执行自动化还需要考虑变更窗口。DNS记录修改通常在业务低峰期进行，工单系统可以在执行前检查当前时间是否在预设窗口内，如果不在窗口内则拒绝执行，强制执行人走特批流程。执行完成后，系统应调用DNS服务商查询接口验证最终生效值，而不仅仅依赖API返回的成功标记。由于DNS存在TTL缓存，验证时要区分服务商侧的配置已经修改和本地递归解析是否已经更新。
四、失败回滚与全程审计追踪
DNS变更执行失败后，必须有能力快速回滚到变更前状态。工单在审批通过前应自动保存变更前快照，内容包括原记录ID、原记录值、原TTL、原线路等。执行失败时，系统根据快照自动调用API恢复，如果回滚也失败，则立即通知运维人员手工介入。回滚操作本身也应该记录在工单日志中，并生成新的状态变化。很多团队只关注正向变更，却忽略了回滚脚本的可用性，建议定期做故障演练，验证快照记录是否完整、API回滚链路是否可达。
import json
def rollback_dns_change(ticket):
snapshot = json.loads(ticket.rollback_snapshot)
if not snapshot:
raise ValueError("缺少回滚快照，无法自动恢复")
client = get_dns_client(ticket.domain_name)
if snapshot.get("exists"):
client.upsert_record(
domain=ticket.domain_name,
host=snapshot["host_record"],
record_type=snapshot["record_type"],
value=snapshot["record_value"],
ttl=snapshot["ttl"]
)
else:
client.delete_record(
domain=ticket.domain_name,
record_id=snapshot["record_id"]
)
ticket.mark_rolled_back()
ticket.add_comment("已自动回滚至变更前状态")
审计追踪是工单系统相比口头变更最大的优势。每一次状态流转、审批意见、API请求参数、返回结果、执行人、时间戳都应该记录在案。对于合规要求较高的企业，还可以把工单记录同步到独立的日志平台或对象存储中，满足长期留存和搜索需求。审计日志中不应包含完整Token或密码，敏感字段需要脱敏。通过定期审查DNS变更工单，团队能够发现高频变更、高危操作和流程漏洞，持续优化变更管理。
工单系统不是银弹，真正落地还需要配合DNS服务商的权限策略和组织管理规范。建议从低风险测试域名开始试点，逐步扩展到生产域名；先实现记录修改和删除的审批流，再完善自动执行和回滚。流程稳定运行一段时间后，可以基于工单数据统计变更成功率、平均审批时长和回滚率，为后续自动化运维提供数据基础。