> Perhaps someone who has a Windows 2008 R2 domain can go ahead and confirm > this, but so far the only way I can see to mitigate this issue is either:
> 1. Disable EDNS on Windows 2008 R2 (which essentially disables the ability to > accept DNSSEC based responses) or 2. Disable DNSSEC support in BIND9 with > dnssec-enable no; (setting dnssec-validation no; has no effect) One additional comment on this: When I first set up a DNSSEC-enabled BIND 9 resolver and used it as a forwarder from Windows Server 2008 R2 DNS, I found that Windows DNS would return answers for known-bad queries, thus defeating the entire purpose of using a DNSSEC-enabled forwarder. DNSSEC-Tools maintains a test zone with various problematic records. See http://dnssec-tools.org/testzone/index.html. "dig badsign-A.test.dnssec-tools.org" issued to the BIND9 resolver returns a SERVFAIL response, as you would expect with an invalid RRSIG. The same query, however, issued to the domain controller returned the answer 75.119.216.33. This turned out to be happening because Windows DNS was actually sending its query as "dig badsign-A.test.dnssec-tools.org +dnssec +cdflag", in other words telling BIND not to perform DNSSEC validation. Based on a Microsoft tech support case that I opened, the only way to fix this was to turn off EDNS ("dnscmd /config /EnableEDnsProbes 0"). It turned out not to be possible to enable DNSSEC validation on the Windows domain controller itself, because the mechanism for entering the DNS root trust anchor was also broken. What response do you get from your domain controller with "dig badsign-A.test.dnssec-tools.org"? This also seems to have been fixed in Windows Server 2012. Thanks. Jeff. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
