权威区运维要点

权威侧出的错，会被全世界的解析器各自缓存一份，回滚比出错慢得多。下面这些都是实践中反复踩到的点。

最后修订 2026-10-05 · 约 5 分钟读完

区文件#

$ORIGIN example.com.
$TTL 3600
@        IN  SOA   ns1 hostmaster 2026100501 7200 3600 1209600 3600
@        IN  NS    ns1
@        IN  NS    ns2.example.net.
ns1      IN  A     192.0.2.53
@        IN  A     192.0.2.10
www      IN  CNAME @
mail     IN  A     192.0.2.25
@        IN  MX    10 mail

• @ 代表当前的 $ORIGIN，也就是区顶点。
• 不带末尾点的名字是相对名字，会自动接上 $ORIGIN。把 ns2.example.net 漏写末尾的点，它就变成了 ns2.example.net.example.com.——这是区文件里最经典的错误。
• $TTL 设置之后记录的默认 TTL；单条记录可以自己写 TTL 覆盖它。
• 改完先用工具检查语法和逻辑（BIND 的 named-checkzone、Knot 的 kzonecheck），再加载。

SOA 计时与序列号#

四个计时值控制辅服务器的行为，取值没有统一标准，下面是思路而不是唯一答案：

• REFRESH：辅服务器多久检查一次序列号。用了 NOTIFY 后它只是兜底，几小时即可。
• RETRY：检查失败后多久重试，应当比 REFRESH 短。
• EXPIRE：多久联系不上主服务器就停止回答。设得太短，主服务器的一次长时间故障会让辅服务器也跟着停；常见是一到几周。
• MINIMUM：否定缓存时间（RFC 2308）。几十分钟到几小时较常见；太长会让新增记录迟迟不可见。

序列号按 RFC 1982 的序列号算术比较，32 位、会回绕。每次修改必须增大；不小心把序列号改得太大，不能直接改小，要按规则分两步“绕回去”，或者在辅服务器上强制重新传送。

委派与胶水#

• 注册商处填写的 NS，就是父区（顶级域）里的委派记录。它必须和你区里顶点上的 NS 一致。
• 名字服务器落在本区内时（如 ns1.example.com），要在注册商处登记它的地址，即胶水记录。
• 失效委派（lame delegation）：被列为 NS 的服务器其实不为这个区提供权威应答——服务器下线了、换托管时没撤、或者配置里漏了区。解析器碰到它会超时重试，表现为解析变慢、偶尔失败。
• 至少两台权威服务器，最好在不同网络、不同地点，甚至不同供应商。

主辅同步#

典型流程：主服务器上的区更新后，向各辅服务器发 NOTIFY（RFC 1996）；辅服务器收到后查询 SOA，发现序列号变大，就发起区传送——优先用增量传送 IXFR（RFC 1995），不支持或差异太大时用完整传送 AXFR（RFC 5936）。

• 用 TSIG 保护（RFC 8945）：主辅之间共享密钥，对 NOTIFY 和区传送签名。仅凭 IP 地址做访问控制，挡不住伪造源地址的请求。
• 考虑加密：区传送默认是明文，任何途经的人都能拿到整个区。RFC 9103 定义了基于 TLS 的区传送（XoT），DoQ 也支持区传送。
• 隐藏主服务器：主服务器不列在 NS 里，只对辅服务器开放，减少暴露面。
• 不要对公网开放 AXFR。它会把整个区的内容（包括你不想公开的子域名）交给任何人。

TTL 策略#

TTL 是可用性、变更速度和查询量之间的取舍：

• 稳定的记录（NS、MX、长期不变的地址）：几小时到一天，减少查询量，也让解析器在你的服务器出问题时多撑一会儿。
• 需要快速切换的记录（故障切换、负载调度）：几十秒到几分钟。太短的 TTL 会被部分解析器抬高，实际效果未必如设定。
• 计划内的变更：提前至少一个旧 TTL 的时间把 TTL 调低，变更完成并确认无误后再调回去。

需要换算 TTL，可以用排错页的换算工具。

邮件相关#

一个能正常收发邮件的域，通常至少要有：MX、SPF（TXT）、DKIM 公钥（TXT）、DMARC 策略（TXT），以及发信 IP 的反向解析。只发不收的域可以设空 MX（RFC 7505）；完全不用于邮件的域，可以发布 v=spf1 -all 和 p=reject 的 DMARC 策略，减少被冒用。写法见资源记录页。

证书相关#

• CAA：限定可以为你签发证书的机构，见资源记录页。
• ACME DNS-01（RFC 8555）：在 _acme-challenge.域名 放一条 TXT 证明控制权。在 ACME 里，通配符证书只能用这种方式验证。自动化时给 API 密钥最小权限，最好只能改这一个名字。
• DANE/TLSA（RFC 6698）：在签名区里发布证书或公钥的指纹，让客户端不依赖证书机构就能验证。目前主要用在邮件服务器之间（SMTP），浏览器不支持。

多供应商与迁移#

同时使用两家托管商可以避免单一供应商故障，但要保证两边数据一致。启用 DNSSEC 的情况下更复杂：两家各自签名时，DNSKEY 集合必须包含双方的密钥，父区要同时有双方的 DS，RFC 8901 描述了几种可行的模型。

迁移托管商时的稳妥顺序：在新托管商处建好完全相同的区 → 逐条比对 → 若有 DNSSEC，先处理 DS → 在注册商处更换 NS → 等旧 NS 的 TTL（父区里通常是一到两天）过去 → 再关闭旧托管商的区。

变更前的检查清单#

1. 相关记录的 TTL 已提前调低，并已等待过旧 TTL。
2. 区文件通过语法检查，序列号已增大。
3. 所有权威服务器都加载了新版本（逐台查询 SOA 确认序列号）。
4. 签名区：新数据已签名，RRSIG 有效期正常，DS 未受影响。
5. 从外部网络用 dig +trace 和几家公共解析器分别确认。
6. 记下变更前的数据，准备好回滚方法。