当我的一个 Windows 2008 R2 实例指向 BIND 9 作为转发器时，我注意到了 BIND 9 的一个奇怪问题。具体来说，当在 BIND 中启用 DNSSEC 时，某些域名在特定情况下无法解析。当切换到公共 DNS 服务器（如 Google 的 8.8.8.8）时，这些问题会自动解决。
进一步观察发现，当在 Windows 2008 R2 DNS 服务器中打开 EDNS（默认，接受 DNSSEC 响应）时，当向 BIND 返回 NODATA（即，0 个答案，状态代码为 NOERROR）时，解析偶尔会失败，并出现 SERVFAIL。
例如，在指向 BIND 作为转发器的 Windows 2008 R2 DNS 服务器中查找时，mx2.comcast.com 类型的 SRV 将会失败，但 bat.comcast.com 类型的 SRV 却可以正常工作。
使用 dig 在本地进行查询，我得到以下结果：
mx2.comcast.com SRV - 本地 BIND 查询
; <<>> DiG 9.9.2-P1 <<>> @127.0.0.1 mx2.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42484
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mx2.comcast.com. IN SRV
;; AUTHORITY SECTION:
mx2.comcast.com. 3600 IN RRSIG NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. pmOHJX7dSNuFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRwjPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=
mx2.comcast.com. 3600 IN NSEC mx3.comcast.com. A RRSIG NSEC
comcast.com. 3600 IN SOA dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com. 3600 IN RRSIG SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
相同的查询，但使用 Google 的 DNS 服务器进行：
; <<>> DiG 9.9.2-P1 <<>> @8.8.8.8 mx2.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3537
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;mx2.comcast.com. IN SRV
;; AUTHORITY SECTION:
comcast.com. 1800 IN SOA dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com. 1800 IN RRSIG SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
mx2.comcast.com. 3600 IN NSEC mx3.comcast.com. A RRSIG NSEC
mx2.comcast.com. 3600 IN RRSIG NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. pmOHJX7dSNuFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRwjPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=
当使用 Windows 并将 BIND 服务器用作转发器时：
; <<>> DiG 9.9.3-P1 <<>> mx2.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57054
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com. IN SRV
并使用 Google 的 DNS 作为转发器：
; <<>> DiG 9.9.3-P1 <<>> mx2.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56582
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com. IN SRV
;; AUTHORITY SECTION:
comcast.com. 900 IN SOA dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
现在，尝试使用 bat.comcast.com：
; <<>> DiG 9.9.2-P1 <<>> @127.0.0.1 bat.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2383
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bat.comcast.com. IN SRV
;; AUTHORITY SECTION:
comcast.com. 1603 IN SOA dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com. 1603 IN RRSIG SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
awrelaypool02.comcast.com. 1603 IN RRSIG NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. U87nbvAj7j7pAk4kigqMyVy8XDeHqRP9756PTQsucrRTEchtScfBKWLl Eo7cWJc4Vcsfept+ixg0IiAxpwHATqwNTmq/giAeglFfeFmMHlXrhdOl Bl5myReo1gSXlpm0+bvinOFRek/MUlYGLvDAq17noJag2k1oXrvhaNBo qWo=
awrelaypool02.comcast.com. 1603 IN NSEC www.bat.comcast.com. A RRSIG NSEC
以及谷歌的解析器：
; <<>> DiG 9.9.2-P1 <<>> @8.8.8.8 bat.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28253
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;bat.comcast.com. IN SRV
;; AUTHORITY SECTION:
comcast.com. 1800 IN SOA dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com. 1800 IN RRSIG SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
awrelaypool02.comcast.com. 3600 IN NSEC www.bat.comcast.com. A RRSIG NSEC
awrelaypool02.comcast.com. 3600 IN RRSIG NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. U87nbvAj7j7pAk4kigqMyVy8XDeHqRP9756PTQsucrRTEchtScfBKWLl Eo7cWJc4Vcsfept+ixg0IiAxpwHATqwNTmq/giAeglFfeFmMHlXrhdOl Bl5myReo1gSXlpm0+bvinOFRek/MUlYGLvDAq17noJag2k1oXrvhaNBo qWo=
再次使用 Windows（BIND 解析器）：
; <<>> DiG 9.9.3-P1 <<>> bat.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11140
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;bat.comcast.com. IN SRV
;; AUTHORITY SECTION:
comcast.com. 900 IN SOA dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
再次使用 Windows（Google Resolver）：
; <<>> DiG 9.9.3-P1 <<>> bat.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;bat.comcast.com. IN SRV
;; AUTHORITY SECTION:
comcast.com. 900 IN SOA dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
从这些结果来看，Windows 解析 mx2.comcast.com 失败，但解析 bat.comcast.com 成功，从 Windows 报告的错误代码 (SERVFAIL) 来看，最初可能看起来是 DNSSEC 验证失败，但事实并非如此，因为所有查询响应都设置了“ad”（已验证）位。也就是说，BIND 似乎有一种有趣的倾向，即篡改授权部分 RR 出现的顺序。查看 mx2.comcast.com 的 Google 查询，我们可以看到授权部分按以下顺序出现（这也是授权服务器的响应方式）：
- 面向服务架构
- RRSIG-SOA
- 神经外科学会
- RRSIG-NSEC
而 BIND 按以下顺序返回响应：
- RRSIG-NSEC
- 神经外科学会
- 面向服务架构
- RRSIG-SOA
对于 bat.comcast.com，Google 按以下顺序响应：
- 面向服务架构
- RRSIG-SOA
- 神经外科学会
- RRSIG-NSEC
BIND 按以下顺序响应：
- 面向服务架构
- RRSIG-SOA
- RRSIG-NSEC
- 神经外科学会
鉴于第一个查询在 Windows 中失败，而第二个查询却运行正常，显然 Windows 2008 R2 要求在没有答案且返回代码 = NOERROR 时首先出现 SOA 记录。（请注意，如果远程服务器返回 NXDOMAIN，则这些 RR 的顺序似乎并不重要，Windows 将相应地将 NXDOMAIN 返回给客户端）。
查看 BIND 文档，看看是否有任何配置选项可以控制这些 RR 的排序，但无济于事。以下是我尝试过的：
rfc2308-type1 yes;
minimal-responses yes;
rrset-order {order fixed;};
我也尝试将本地 BIND 版本从 9.9.2-P1 升级到 9.9.3-P1，但行为似乎没有改变。
最后，理论上我可以禁用 Windows 2008 R2 中的 EDNS 支持作为一种解决方法并使这些查询正常工作（因为禁用 EDNS 也会抑制 DNSSEC 的 DO 标志，从而省略响应中的 RRSIG 和 NSEC RR），但我宁愿让 EDNS 保持开启状态以提高其在 UDP 上的效率。
有人知道我在这里遗漏了什么，或者遇到了类似的情况吗？
任何评论都将不胜感激！
答案1
您是否能够验证您的假设，即记录的顺序导致 MSDNS 返回SERVFAIL？（从您在问题中所展示的内容来看，这是合理的，但我不清楚是否排除了其他可能性。）
另外，MSDNS 端是否有与该故障相关的任何记录？
我不知道绑定选项这将适用于在这种情况下如何对//RRSIG记录进行排序。NSECSOA
在您提到的设置中，rrset-order是唯一会影响排序的设置，但据我所知，它适用于具有多个A记录的响应等场景，以及如何对这些记录进行排序，而不是这样。
fixed无论哪种方式，默认情况下都不支持该值：
在此版本的 BIND 9 中，rrset-order 语句默认不支持“固定”排序。可以在编译时通过在“configure”命令行上指定“--enable-fixed-rrset”来启用固定排序。
在我看来，如果顺序是导致您遇到问题的原因，那么 MSDNS 或 BIND 存在错误。
很明显，BIND 改变了其响应中记录的顺序，但为什么这会成为一个问题并不明显（至少对我来说）。