整理BIND 9配置：把琐碎的子域合并为一个zone
内容提要
作者将BIND 9中5个由DHCP动态更新的子域zone合并进sjc.example.net，以简化DNSSEC密钥、委派和配置维护。流程包括冻结、导出、过滤SOA/NS/DS等记录、合并、修改named.conf与dhcpd配置及解冻。因父zone残留旧NS/DS导致解析失败，清理后恢复。合并后6个zone减为1个，代价是故障影响范围和DHCP授权范围变大。
延伸解读
合并zone的收益与代价
合并后，6个zone、6组CSK（18个密钥文件）和5组父子DS委派缩减为1个zone、1组CSK，验证链少了一层，目录和配置也更清爽。但代价是更新、签名和传送都集中到一个zone，重新加载或恢复时影响范围更大。作者认为家庭设备少，分开维护的麻烦更多，因此接受这一取舍。
残留NS/DS为何导致解析失败
合并时只过滤了子域导出文件中的记录，父zone里原有的委派NS和DS被原样带入。NS使ut.sjc等名字仍被视为委派点，父zone返回referral而非权威答案；DS则建立指向旧子zone的DNSSEC信任链，旧DNSKEY撤销后验证接不上。清理这些NS/DS后，名字成为父zone普通记录，delv显示fully validated。
DHCP更新授权的宽严选择
作者在sjc.example.net的update-policy中使用zonesub ANY，让原dhcpd-key继续更新整个zone，包括下级名字。这并非合并zone的必然代价：仍可用subdomain规则把授权限制到iot.sjc等名字，并只允许A、AAAA、TXT、DHCID等实际需要的类型。dhcpd.conf中的子域zone声明也需合并为父zone，否则更新会被拒绝。
切换顺序与缓存窗口
操作中漏删父zone委派记录，造成一小段解析失败。作者建议先确认辅服务器已加载合并后的父zone，再撤销旧zone；同时注意递归解析器缓存中的旧NS、DS和DNSKEY不会立即消失。要缩短失败窗口，应提前降低相关TTL，等旧TTL过期再切换，仅改权威端不能保证缓存立刻跟上。
Q&A
为什么要把多个子域zone合并成一个？
每个子域zone都需要独立的DNSSEC密钥（每个zone一套CSK，产生多个密钥文件），父zone要维护多组NS和DS记录，密钥轮换时易因缓存导致SERVFAIL，named.conf和辅DNS配置重复。合并后6个zone减为1个，密钥和委派记录大幅减少，维护更简单。
合并zone的具体操作步骤是什么？
1) 用rndc freeze冻结相关zone；2) 用named-compilezone导出各zone为full格式；3) 过滤掉SOA、NS、DNSKEY等记录后拼接，并递增SOA serial；4) 修改named.conf删除子zone块，在父zone的update-policy中用zonesub授权DHCP密钥，并调整dhcpd.conf中的zone声明；5) 执行rndc reconfig和rndc thaw解冻。
合并后DHCP动态更新如何继续工作？
在父zone sjc.example.net的update-policy中使用grant dhcpd-key zonesub ANY，使原TSIG密钥可更新整个zone（包括下级名字）。DHCP服务器端需将原来针对各子域的zone声明合并为一个指向父zone的声明，或依赖nsupdate自动识别zone。
合并后解析失败的原因是什么？
父zone中残留了原委派子域的NS和DS记录。NS使父zone仍返回指向旧子域的referral，而非权威答案；DS建立了指向已撤销子域的DNSSEC信任链，导致验证失败。需在父zone中删除这些NS和DS记录并递增serial。
合并zone有哪些代价或风险？
更新、签名和传送集中到一个zone，重新加载或恢复时影响范围更大；使用zonesub ANY授权使DHCP密钥权限覆盖整个父zone，范围过宽（可改用subdomain规则限制）。此外，递归解析器缓存旧记录可能导致短暂解析失败。
如何避免合并过程中出现解析中断？
操作前降低相关记录的TTL，等旧TTL过期后再切换；确保先让辅服务器加载合并后的父zone，再撤销旧zone；彻底清理父zone中的旧NS和DS记录；并接受缓存可能导致短暂失败，或提前规划缩短窗口。
