DNS SOA 的 MNAME、RNAME、SERIAL、REFRESH、RETRY、EXPIRE 和 MINIMUM 有什么区别?
DNS SOA 的 MNAME、RNAME、SERIAL、REFRESH、RETRY、EXPIRE 和 MINIMUM 有什么区别?
一个 SOA 记录示例
example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. (
2026082601 ; SERIAL
3600 ; REFRESH
600 ; RETRY
1209600 ; EXPIRE
300 ; MINIMUM
)
这里 3600 是 SOA 资源记录自身的 TTL,不属于括号内七个 RDATA 字段。末尾 300 才是 MINIMUM。这两个值共同影响现代 DNS 的负缓存 TTL,但含义并不相同。
快速对照
`MNAME` 是区域数据源,不是 NS 列表
RFC 1035 将 MNAME 定义为该区域原始或主数据来源的名称服务器域名。它用于表达区域维护关系,不代表该服务器必然是查询时唯一、最近或优先使用的权威服务器。
区域的公开权威服务器集合由区域顶点和父区委派中的 NS 记录表达。一个区域可以拥有多个 NS,但 SOA 只有一个 MNAME 字段。不要用 MNAME 替代 NS 记录,也不要假定递归解析器会因为它出现在 SOA 中就优先向它发送普通查询。
`MNAME` 与 Primary/Secondary 角色
传统资料常称其为 master,现代运维更常使用 primary。辅助服务器会依据自身配置从一个或多个源获取区域,实际传送拓扑可能比单个 SOA 字段复杂。
因此,MNAME 应指向一个语义合理、可解析的服务器名称,但不能仅凭它判断全部区域传送路径。托管 DNS 平台也可能抽象内部 primary,公开 SOA 值未必等同用户能直接连接的管理端点。
`MNAME` 必须是域名而不是 IP
SOA 字段编码要求域名。应写 ns1.example.net.,而不是 192.0.2.53。区域文件中的末尾点表示绝对域名;若漏掉,权威服务器可能按当前 $ORIGIN 拼接,得到意外名称。
修改前应使用区域编译或检查工具验证最终展开结果,并从权威响应中读取实际 SOA,而不是只看模板源文件。
`RNAME` 是邮箱的 DNS 名称表示
RNAME 表示负责该区域人员的邮箱,但它使用 DNS 域名语法编码。通常第一个未转义的点替代邮箱中的 @:
hostmaster.example.com. -> [email protected]
不能直接写 [email protected],因为 @ 在主区域文件中还有特殊含义。自动化系统应把它作为 DNS 名称字段处理,而不是任意文本。
邮箱本地部分包含点时需要转义
如果邮箱是 [email protected],对应 RNAME 通常写成:
dns\.ops.example.com.
第一个未转义点才代表 @。忽略转义会被解释成 [email protected]。不同界面可能要求用户填写真实邮箱后由平台编码,也可能要求直接输入 RNAME 形式,提交前必须确认产品契约。
`RNAME` 不控制邮件投递路由
RNAME 只是联系信息,不是 MX 记录,也不会建立邮箱或确保邮件可达。域名对应邮件系统仍由实际邮件配置决定。
它也不应包含个人敏感邮箱。使用可持续维护的角色地址,例如 hostmaster 或 dns-ops,并确保有人接收告警,比填一个不会查看的占位值更有意义。
`SERIAL` 是32位序列号
RFC 1035 把 SERIAL 定义为原始区域副本的32位无符号版本号,区域传送保留该值。辅助服务器比较自己持有的序列号与来源服务器的序列号,以决定是否需要更新。
每次权威区域内容发生需要传播的变更,都应使新序列号在 DNS 序列号算术中“更大”。如果内容变了但 serial 未推进,辅助服务器可能合理地认为没有新版本。
日期格式只是运维约定
YYYYMMDDnn(如 2026082601)便于人读,但协议并不要求日期格式。递增整数、Unix 时间的受限变体或平台内部计数都可以,只要遵守32位序列号比较规则。
日期格式每天通常只留两位变更计数。如果同一天超过99次,或错误设置到未来日期,简单“改成今天”可能造成数值倒退。必须按序列号算术规划修复。
SERIAL 不能只按普通整数比较
RFC 1982 为 DNS 定义序列号算术。序列号空间是 0 到 4294967295,到达上界后可以环绕。一个数在十进制上更小,仍可能在序列空间中被视为更新版本。
比较的核心边界是半个序列空间,即 2^31。相差恰好半个空间时,排序结果未定义;一次或一系列增量也不应在相关 EXPIRE 周期内跨越不安全范围。不要用普通 SQL 大小比较替代实现的 RFC 1982 比较函数。
为什么直接降低 SERIAL 很危险
若 primary 从较高 serial 改成普通数值更低的 serial,部分 secondary 可能把新版本视为旧版本而拒绝传送。缓存和不同步副本会让修复更复杂。
安全处理需要盘点所有权威服务器当前 serial,制定符合 RFC 1982 的推进步骤,并逐台验证跟随情况。若托管平台管理 serial,应使用平台支持的恢复流程,不要在导入区域时任意覆盖。
`REFRESH` 是正常检查间隔
REFRESH 表示辅助服务器在正常情况下经过多少秒后检查区域是否需要刷新。它不是记录缓存 TTL,也不要求每到时间就完成一次完整 AXFR。
典型流程是 secondary 查询 SOA serial;如果 primary 版本更新,再尝试 IXFR 或 AXFR。DNS NOTIFY 可以促使辅助服务器更快检查,但不会消除 refresh 计时器作为最终保障的价值。
`RETRY` 是失败后的重试间隔
当 refresh 尝试失败时,secondary 等待 RETRY 秒再试。通常 retry 小于 refresh,因为服务器已经知道正常维护动作失败,需要更积极地恢复。
设置过短可能在 primary、网络或认证故障时制造查询与传送风暴;设置过长则延长不同步时间。它只控制区域维护重试,不控制客户端普通 DNS 查询重试。
`REFRESH` 与 `RETRY` 的状态不同
REFRESH 面向健康状态下的定期检查,RETRY 面向一次刷新失败后的恢复。两者不是“首次等待”和“第二次等待”的通用 DNS 超时设置。
例如 refresh 为3600秒、retry为600秒,正常时大约每小时检查;若检查失败,则大约每10分钟重试,直到成功或达到过期条件。实际实现可能加入抖动,减少大量服务器同时请求。
`EXPIRE` 是旧副本的权威寿命上限
EXPIRE 指定 secondary 在无法成功刷新区域后,还能继续把旧副本作为权威数据服务多久。超过该上限,服务器不应继续权威回答这份过期区域。
它不是“所有 DNS 记录在缓存中消失的时间”,也不是域名注册到期日。它保护用户免受无限期陈旧的权威副本影响,但过短会使短暂维护故障演变成整个区域在辅助服务器上不可用。
EXPIRE 应明显大于维护间隔
若 expire 小于或接近 refresh 加若干 retry 周期,短暂网络故障就可能耗尽余量。RFC 2182 关于辅助 DNS 的运维建议强调设计多个可靠服务器与合理维护参数,而不是依赖单点。
规划时应考虑最长可接受故障窗口、节假日响应、primary 灾难恢复时间和服务器间网络隔离。所有 secondary 都从同一故障域取数,会削弱冗余价值。
`MINIMUM` 的旧语义已经更新
RFC 1035 最初把 MINIMUM 描述为区域资源记录的最小 TTL 下限。后来实践中该字段被赋予多个相互冲突的含义,包括默认 TTL 和负缓存 TTL。
RFC 2308 明确废弃“所有 RR 的最小 TTL”语义,并将现代含义确定为负响应使用的 TTL。今天不能仅因为 SOA.MINIMUM 是300,就断言区域内任何 A、AAAA 或 MX 记录至少缓存300秒。
普通记录默认 TTL 使用 `$TTL`
主区域文件中没有显式 TTL 的记录,应从 $TTL 指令获得默认值,而不是借用 SOA.MINIMUM。区域传送后,每条记录都有明确 TTL,接收方无法再区分它原先是显式填写还是继承默认值。
托管平台可能通过界面默认值生成每条记录的 TTL,但概念仍相同:普通正响应 TTL 与 SOA.MINIMUM 的负缓存作用应分开管理。
负缓存 TTL 取两个值的较小者
RFC 2308 规定,权威服务器返回 NXDOMAIN 或 NODATA 时,应在 Authority Section 携带区域 SOA,以便解析器缓存负结果。负缓存 TTL 来自 SOA.MINIMUM 与 SOA 记录自身 TTL 的较小者。
因此,上例中 SOA TTL为3600、MINIMUM为300,协议给出的负缓存 TTL 上限是300秒。若反过来 SOA TTL为120、MINIMUM为300,则取120秒,而不是300秒。
NXDOMAIN 与 NODATA 的缓存键不同
NXDOMAIN 表示名称不存在,负缓存通常关联查询名称和类;NODATA 表示名称存在但没有所问类型,缓存还需要区分查询类型。
SOA 提供缓存时间,不会把两种响应变成同一种语义。排查“新加记录仍查不到”时,要确认此前缓存的是名称不存在还是某种类型不存在,并观察返回 SOA TTL 的倒计时。
修改 MINIMUM 不会清除现有缓存
递归解析器已经缓存的负响应会按当时取得的 TTL 继续倒计时。现在把 MINIMUM 调低,不能远程撤销世界各地已有缓存。
计划新增此前不存在的名称时,可在变更前至少一个旧负缓存周期降低相关值,等待旧策略自然失效,再实施记录变更。即便如此,各解析器仍可能设置自己的缓存上限或下限。
SOA 自身 TTL 与 MINIMUM 必须同时检查
执行 dig SOA example.com 可看到 SOA 记录自身 TTL 和 RDATA 内的 MINIMUM。只抄最后一个数字会漏掉较小值规则,只看回答行 TTL 又会漏掉字段语义。
检查负响应时,更直接的方法是查询一个确认不存在的随机名称,观察 Authority Section 中 SOA 的剩余 TTL,并区分权威直接回答与递归缓存回答。
区域传送与普通解析是两条路径
SERIAL、REFRESH、RETRY、EXPIRE 主要服务 primary/secondary 区域维护;MINIMUM 主要影响递归解析器对负答案的缓存。它们都在 SOA 中,但消费者和故障表现不同。
辅助服务器没更新,应检查 serial、NOTIFY、SOA 查询、AXFR/IXFR、传送 ACL 和 TSIG;用户仍看到 NXDOMAIN,则应检查递归缓存时间。不要用清客户端缓存去修复 secondary serial,也不要用提高 serial 期待清除外部递归缓存。
一套权威侧验证流程
1. 分别向每台公开权威服务器直接查询 SOA,记录 AA 位、MNAME 和 SERIAL。
2. 确认所有服务器 serial 按预期一致,或处于可解释的短暂传播阶段。
3. 查看 primary 到 secondary 的 NOTIFY、SOA 检查与 IXFR/AXFR 日志。
4. 核验区域传送 ACL、TSIG、TCP 53、防火墙和时钟状态。
5. 计算从上次成功刷新到 EXPIRE 的剩余安全窗口。
6. 使用区域检查工具验证 RNAME 转义、绝对域名和计时器单位。
一套负缓存验证流程
1. 生成区域内确定不存在且不重复的查询名称。
2. 直接询问权威服务器,确认 NXDOMAIN 或 NODATA 与 Authority Section 的 SOA。
3. 记录 SOA 自身 TTL、MINIMUM 和两者较小值。
4. 再询问递归解析器,观察负答案 TTL 是否递减。
5. 新增记录后,在旧负缓存窗口内预期部分解析器仍返回旧结果。
6. 不要连续高频随机查询,以免制造无意义流量或污染测试数据。
常见误区
MNAME 是唯一权威 DNS
错误。公开权威集合由 NS 与委派表达,MNAME 主要标识区域数据的原始或主来源。
RNAME 可以直接填写带 `@` 的邮箱
错误。它采用 DNS 名称编码,第一个未转义点代表 @,邮箱本地部分的点需要转义。
SERIAL 数值更大就永远更新
错误。它是32位环绕序列号,必须按 RFC 1982 比较,半个序列空间附近还存在未定义边界。
MINIMUM 是所有记录的最低 TTL
这是已废弃的旧语义。现代标准用它参与确定负缓存 TTL,普通记录默认 TTL 应由 $TTL 或显式值提供。
EXPIRE 到期会删除递归缓存
错误。EXPIRE 控制 secondary 是否继续把旧区域当作权威数据,与递归缓存中单条记录的 TTL 是不同机制。
FAQ
1. SOA 为什么只能有一条?
SOA 标识区域权威起点并提供一组统一维护参数。一个区域顶点使用一条 SOA;多个权威服务器通过 NS 记录表达。
2. 修改记录后必须增加 SERIAL 吗?
对依赖传统区域传送传播的区域,必须让 serial 成为更新版本。托管平台可能代为维护,但仍应验证公开权威 serial 是否推进。
3. YYYYMMDDnn 是标准强制格式吗?
不是,只是常见运维约定。协议要求的是符合 RFC 1982 的32位序列号行为。
4. NOTIFY 是否让 REFRESH 没用了?
没有。NOTIFY 加速变更发现,REFRESH 仍为通知丢失或不可用时提供周期性检查保障。
5. RETRY 应该比 REFRESH 大吗?
通常小于 REFRESH,以便刷新失败后更快恢复;具体值要兼顾恢复速度与故障期间的请求压力。
6. MINIMUM 为300是否保证 NXDOMAIN缓存300秒?
不保证。标准取 MINIMUM 与 SOA 自身 TTL 的较小者,递归实现还可能施加自己的上限或策略。
7. 为什么新记录已在权威服务器上,用户仍收到NXDOMAIN?
用户所用递归解析器可能仍持有添加记录前的负缓存。观察其 SOA TTL 倒计时并等待旧条目失效。
8. 如何判断是区域传送故障还是缓存故障?
直接逐台查询权威服务器的 serial 和目标记录。权威之间不一致指向传送问题;权威一致而递归仍旧,则更像缓存传播问题。
参考来源
1. RFC 1035:Domain Names — Implementation and Specification(SOA字段基础定义)
https://www.rfc-editor.org/rfc/rfc1035.html
2. RFC 1982:Serial Number Arithmetic(DNS序列号环绕与比较)
https://www.rfc-editor.org/rfc/rfc1982.html
3. RFC 2182:Selection and Operation of Secondary DNS Servers
https://www.rfc-editor.org/rfc/rfc2182.html
4. RFC 2308:Negative Caching of DNS Queries(MINIMUM现代语义与负缓存TTL)
https://www.rfc-editor.org/rfc/rfc2308.html
5. RFC 8499:DNS Terminology(SOA及相关术语更新)
https://www.rfc-editor.org/rfc/rfc8499.html
6. RFC 9520:Negative Caching of DNS Resolution Failures
https://www.rfc-editor.org/rfc/rfc9520.html