分离大脑（Split-Brain）架构下Bind9 DNS子域启用DNSSEC的实现需求及信任链构建咨询

问题描述 #

我目前维护着一套复杂的分离大脑（Split-Brain）DNS环境，现在想为整个体系部署DNSSEC以支持SSHFP（SSHFP必须依赖DNSSEC才能生效）。不过我对具体的实现细节，尤其是完整信任链的搭建逻辑不太清楚，希望能得到针对性的帮助：

• 主域example.com由域名注册商托管，已经在注册商处启用了DNSSEC
• 多个子域部署在内部网络中：外部访问时需要解析到我的公网IP，内部访问时则需要解析到私有IP
• 内部网络的核心域是domain.example.com，注册商那边的domain.example.com A记录指向我的公网IP
• 内网中有一台仅对内服务的Bind9 DNS服务器，作为内部托管域的权威解析器——比如zabbix.domain.example.com，内部解析到内网Web代理的私有IP，外部则解析到公网IP

实现方案与信任链构建指南 #

首先明确核心逻辑：你的主域example.com已经通过注册商完成了DNSSEC部署，所以整个信任链的根锚是注册商配置的DS记录（关联主域的KSK密钥）。接下来要做的就是让内部子域的DNSSEC与主域的信任链完成衔接，同时适配Split-Brain的解析差异。

1. 为内部Bind9托管的子域启用DNSSEC

第一步是在内部Bind9服务器上，为需要保护的内部子域（比如domain.example.com及其下属子域）配置DNSSEC签名：

• 生成密钥对：使用Bind自带的dnssec-keygen工具生成子域的密钥签名密钥（KSK）和区域签名密钥（ZSK）：

  # 生成KSK（采用RSASHA256算法，密钥长度2048位，适合长期使用）
  dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -K /var/lib/bind/keys/ domain.example.com
  # 生成ZSK（算法同KSK，密钥长度1024位，用于日常区域签名，可定期轮换）
  dnssec-keygen -a RSASHA256 -b 1024 -n ZONE -K /var/lib/bind/keys/ domain.example.com
  

• 配置Bind区域签名：编辑内部子域的区域配置文件（比如/etc/bind/named.conf.local），添加DNSSEC相关指令：

  zone "domain.example.com" {
      type master;
      file "/var/lib/bind/zones/domain.example.com.db";
      # 使用Bind默认的DNSSEC策略自动管理签名（推荐）
      dnssec-policy default;
      # 如果需要手动管理密钥，可替换为以下指令：
      # key-directory "/var/lib/bind/keys/";
      # auto-dnssec maintain;
      # inline-signing yes;
  };
  

• 重载Bind配置生效：执行命令让Bind重新加载配置并开始签名区域：

  rndc reload domain.example.com
  

2. 衔接主域与内部子域的信任链

因为主域example.com的DNSSEC由注册商托管，你需要在主域中添加DS记录，将内部子域的KSK公钥纳入主域的信任体系：

• 导出子域DS记录：使用dnssec-dsfromkey工具，基于生成的KSK密钥文件（文件名类似Kdomain.example.com.+008+xxxxxx.key）生成DS记录：

  dnssec-dsfromkey -f /var/lib/bind/keys/Kdomain.example.com.+008+xxxxxx.key
  

• 在注册商后台添加DS记录：登录域名注册商的DNS管理界面，在example.com的DNS记录中新增一条类型为DS的记录，主机名填写domain.example.com，记录值为上述工具输出的内容。
  这一步是信任链的关键：它告诉全球DNS系统，domain.example.com的DNSSEC密钥是受example.com信任的，无论外部还是内部解析，都能通过主域的信任链完成对内部子域签名的验证。

3. 适配Split-Brain架构的解析差异

要保证内外解析都能正常通过DNSSEC验证，需要做以下适配：

• 内部客户端配置：确保所有内网设备的DNS服务器指向内部Bind9，这样它们会直接从内部权威服务器获取签名后的私有IP记录，并且通过主域的DS记录验证信任链的完整性。
• 外部解析配置：注册商那边的domain.example.com A记录已经指向公网IP，如果外部需要解析内部子域的公网IP（比如zabbix.domain.example.com），需要在注册商的DNS中添加这些记录，并且确保这些外部记录也被签名——如果注册商支持自动DNSSEC签名，只要主域已启用，子域记录会自动被签名；如果需要手动处理，需将外部子域的密钥信息提交给注册商。
  如果外部不需要解析内部子域的具体记录，仅需domain.example.com的公网IP，那么只要保证注册商处的domain.example.com DS记录存在即可，外部客户端访问时会通过主域的信任链验证domain.example.com的DNSSEC信息。

4. 验证DNSSEC信任链有效性

完成配置后，通过以下方式验证整个体系是否正常：

• 内部验证：在内网客户端使用dig工具查询内部子域的DNSSEC记录：

  dig +dnssec zabbix.domain.example.com A
  

  检查输出中是否包含RRSIG（签名记录），同时使用dig +cdflag domain.example.com DS确认DS记录能被正确获取。
• 外部验证：在公网环境使用dig +dnssec domain.example.com DS验证主域到子域的信任链是否完整，也可以用dnssec-verify工具检查区域文件的签名有效性。

关键注意事项 #

• 密钥生命周期管理：定期轮换ZSK（建议每3-6个月），KSK则每年轮换一次；内部Bind9的密钥文件要严格控制权限（仅允许Bind进程读取），避免泄露。
• 时间同步：Bind服务器和所有客户端的系统时间必须保持同步（可通过NTP服务实现），因为DNSSEC签名有有效期，时间偏差过大可能导致验证失败。
• 区域一致性：如果内部子域有多个主/从DNS服务器，要确保所有服务器的DNSSEC配置一致，签名记录同步正常，避免出现解析不一致或验证失败的情况。

备注：内容来源于stack exchange，提问作者surfrock66