NOTIFY 与主从同步
主服务器改完区域后会立刻用 NOTIFY 通知从服务器「来拉新数据」，比等区域信息里的刷新时间到期快得多。从服务器收到通知后比较序列号，发现自己持有的更旧就发起区域传送拉取新内容。整套机制的关键前提是序列号必须严格递增：用日期格式便于人工管理与识别，但绝对不能回退，回退会被从服务器直接忽略。
基本信息
| 通知方向 | 主服务器发往从服务器 |
|---|---|
| 触发时机 | 区域内容变更后立即发出 |
| 从端动作 | 比较序列号，必要时发起传送 |
| 关键字段 | SOA 记录里的序列号 |
| 序列号要求 | 只增不减，用日期格式便于管理 |
| 兜底机制 | 通知失败时按刷新周期轮询对比 |
SOA 常见字段
| 字段 | 含义 | 调优关注点 |
|---|---|---|
| serial | 版本号，每次改动递增 | 回退会被从端忽略 |
| refresh | 从端多久主动检查一次 | 配太长会让故障发现滞后 |
| retry | 拉取失败后的重试间隔 | 与刷新周期配套调整 |
| expire | 多久联系不上主端就判定区域过期 | 过长会持续提供旧数据 |
| minimum | 负缓存相关的最小生存时间 | 影响解析失败的缓存时长 |
观察序列号与同步
观察序列号与同步
dig @ns1.example.com example.com SOA +short # 主服务器序列号
dig @ns2.example.com example.com SOA +short # 从服务器序列号，应当一致
dig example.com SOA +short | awk '{print $3}' # 序列号是第三个字段
dig @ns2.example.com example.com NOTIFY # 手工触发通知（需授权）典型使用场景
- 变更后确认生效：分别查询主从服务器，核对序列号是否一致
- 同步故障排查：确认通知是否送达、传送端口是否放行
- 参数调优：在发现速度与查询开销之间取平衡
- 迁移演练：确认新权威能正确接收通知并完成同步
- 审计：检查是否存在序列号长期不变却仍有内容变更的情况
序列号回退是主从同步里最隐蔽的一类故障：主服务器上改动看起来已经生效，从服务器却一直提供旧数据，且不会有明显报错。用日期加序号的格式不仅便于人工识别，也能在跨团队协作时避免有人手工写入一个更小的值。