主域启用DNSSEC后，如何排除Azure DNS托管的子域？

• domain.com 在服务商X处注册
• sub.domain.com 托管于Azure DNS

我们已经为sub.domain.com添加了指向正确Azure DNS服务器的NS记录，host.sub.domain.com解析正常。此前在服务商Y处为主域domain.com启用DNSSEC时一切正常，现在希望在服务商X处为主域启用DNSSEC，但启用后sub.domain.com相关资源出现服务器故障。经推断，原因是Azure DNS暂不支持DNSSEC（该功能至少自2019年就已列入规划，但目前暂无明确上线时间）。

请问是否可以在主域启用DNSSEC的同时，排除sub.domain.com区域？

DNSSEC启用后的错误信息 #

Google DNS查询host.sub.domain.com返回的错误： #

{
  ....
  "Comment": "Resolution failure. Please check https://intodns.com/host.sub.domain.com",
  "extended_dns_errors": [
    {
      "info_code": 22,
      "extra_text": "At delegation domain.com for sub.domain.com/ds"
    }
  ]
  ....
}

递归DNS解析结果（正常）： #

dig +trace host.sub.domain.com @8.8.8.8
 
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +trace host.sub.domain.com @8.8.8.8
;; global options: +cmd
.                       87203   IN      NS      m.root-servers.net.
.                       87203   IN      NS      f.root-servers.net.
.                       87203   IN      NS      i.root-servers.net.
.                       87203   IN      NS      l.root-servers.net.
.                       87203   IN      NS      d.root-servers.net.
.                       87203   IN      NS      a.root-servers.net.
.                       87203   IN      NS      g.root-servers.net.
.                       87203   IN      NS      e.root-servers.net.
.                       87203   IN      NS      h.root-servers.net.
.                       87203   IN      NS      c.root-servers.net.
.                       87203   IN      NS      j.root-servers.net.
.                       87203   IN      NS      k.root-servers.net.
.                       87203   IN      NS      b.root-servers.net.
.                       87203   IN      RRSIG   NS 8 0 518400 20240228050000 20240215040000 30903 . eiIbJzFD74pJwP/o0r1Z91AhBFQfEYaO6rOOCaQIH4Vo/zwF+grKyPEa wi2eiU8GEEdZOsfbCNkQIch8+0ue2fABl7qeMH196uNAWVaxL2QDRr2I untt6fq3xLhfWT8EYOfEDTG3wdnu/udVq9R4IjKn73juDcqP0g3gSDAr psZe3sQIcG3u9pgiVQrPjy0Ibxd2G2vbobjHIRBbrx7ZYQkbFGGSTaM1 QDHMYR91Uj2+RvtZPbVz19K0D5W2J6kBkN7Dq+ANIE9qKHYheRybv+p3 Df0HOqhNlkjGNXTUCicOUql+xbpgOVk+RqA3b7kxC2jqQC+ZK1e2OvSD FXcvCw==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 40 ms
 
nl.                     172800  IN      NS      ns1.dns.nl.
nl.                     172800  IN      NS      ns3.dns.nl.
nl.                     172800  IN      NS      ns4.dns.nl.
nl.                     86400   IN      DS      17153 13 2 C5DFDDC91E7532562A35F3C2CD30823894BE08F20101F1ABF45C8AB9 739F3F49
nl.                     86400   IN      RRSIG   DS 8 1 86400 20240228050000 20240215040000 30903 . iHVs9zBiHfjJy2IUtacqyo3bY6cn9ammq1QusJXj9ykT19XIzu5hYqLl /snI1LbTwhIyJZyfft3cAm3YiBS+3IXZCSoFem89OdeKH7dRQtrPk5vW Cn1a5Id16XrUemi0zhpf+OVMa/IqAOTvz1ZVG6ShQ2jz94SSyBxb1rjf sqdviL7Pua0L7oEixtz0tbqVjIfhh5gHSSmWe04D9X3ZLGHM2kPDqKDG +wIcemN9QfejeFBEXKWlr8aSH9jLnSbpxq4rR8kMDjNpPQ38MDKQzM3/ q6tvdPQKuSkSwBes45K7/g2GlJh8sqIhDZC7QOaErAJo70CjdZtN9O53 cXsHoA==
;; Received 607 bytes from 192.36.148.17#53(i.root-servers.net) in 229 ms
 
domain.com.              3600    IN      NS      ns4.sectigoweb.com.
domain.com.              3600    IN      NS      ns1.sectigoweb.com.
domain.com.              3600    IN      NS      ns2.sectigoweb.com.
domain.com.              3600    IN      NS      ns3.sectigoweb.com.
domain.com.              3600    IN      DS      10559 8 2 13E775DCB89F3146F2CCB2B2C3F6D0739C22937A555BDFE8D8713880 1A495E79
domain.com.              3600    IN      RRSIG   DS 13 2 3600 20240228150444 20240214120731 15365 nl. 6poz7TNNCk7WIkc8J/lCZr9GkFuF/vLaXO6oOY98vShefKePCGlEe4mh cOQykjJVMWiAPJTWAPOjtrgxE6Hg8A==
;; Received 291 bytes from 194.0.25.24#53(ns3.dns.nl) in 30 ms
 
sub.domain.com.           600     IN      NS      ns1-09.azure-dns.com.
sub.domain.com.           600     IN      NS      ns2-09.azure-dns.net.
sub.domain.com.           600     IN      NS      ns3-09.azure-dns.org.
sub.domain.com.           600     IN      NS      ns4-09.azure-dns.info.
host.sub.domain.com.  300     IN      NSEC    \000.host.sub.domain.com. NS RRSIG NSEC
domain.com.              300     IN      RRSIG   SOA 8 2 3600 20240514134541 20240214134541 23593 domain.com. JgbTRDbxJ6Jmylr64SU7/9ga1mC0w3ajf7E98rr0V8UI2/fLOAXDje/5 oCJwqpiIy8tAwi8IyB7EQQKQdYRBkyhXGcDQpDTz+JkWwxvILV4zZpa8 j8dxote+P5s4k2FO4wercV5zYxPPyiJ/b865UI83Z0P9M5qmwcvtVl/2 /Tw=
host.sub.domain.com.  300     IN      RRSIG   NSEC 8 5 300 20240514134541 20240214134541 23593 domain.com. qh4EhKb5gGcmqiLlaXEUx0YLWeXiYDsPLEz6osxCPCE0XmDF/wv1lth5 68UWG5/mymglhF/l07GggnRJdgJS0CRNtvN5zLScS1kCRYbCF2YJC8wE LOL/3aJVeupocfsWeLnG+KFsukwTSx8sxgxmiwO/KOAX0NnbOvzux3Jn s5Y=
;; Received 570 bytes from 162.159.27.4#53(ns4.sectigoweb.com) in 40 ms
 
host.sub.domain.com.  3600    IN      A       40.50.60.70
;; Received 66 bytes from 204.14.183.7#53(ns3-09.azure-dns.org) in 30 ms

可以在主域启用DNSSEC的同时，不对sub.domain.com区域启用DNSSEC，核心操作是不要在主域domain.com中为sub.domain.com添加DS记录。

DNSSEC的信任链依赖DS记录传递：主域启用DNSSEC后，严格的递归服务器会默认期望所有被委托的子域都有对应的DS记录来验证其DNS响应。如果子域不支持DNSSEC，只要主域不为其配置DS记录，递归服务器就不会尝试验证该子域的数据，从而避免解析失败。

从你提供的dig +trace结果来看，当前主域DNS服务器返回了host.sub.domain.com的NSEC记录，这说明主域的DNSSEC配置中包含了对sub.domain.com区域的否定授权（NSEC用于证明域名不存在或无特定类型记录），导致Google DNS这类严格验证服务器判定sub.domain.com的DNS数据无效，返回解析失败。

具体解决步骤：

1. 在服务商X的主域DNS配置中，确保未为sub.domain.com添加任何DS记录。
2. 检查主域的NSEC/NSEC3生成规则，调整区域签名范围，仅签名主域自身的记录，避免将sub.domain.com的委托包含在否定授权记录中。部分服务商支持配置“豁免”特定子域的DNSSEC验证，可直接利用该功能。
3. 重新签名主域区域，确保新签名中不再包含与sub.domain.com相关的否定授权记录。

完成以上操作后，支持DNSSEC的递归服务器会跳过对sub.domain.com区域的验证，直接使用Azure DNS返回的未签名数据，同时主域的DNSSEC依然保持有效。

内容的提问来源于Stack Exchange，提问作者Haruka Shitou