BIND 9.8.0 patch for DNSSEC validation in a Windows environment

Mon Apr 18 14:00:19 UTC 2011

I would like to submit the attached bind-9.8.0.patch for your consideration. I have experienced significant frustration with the implementation of DNSSEC in our Windows environment, and the patch addresses a problem that I believe will be common to many Windows users.

Windows Server 2008 R2 DNS purports to provide support for DNSSEC, the first version of Windows to do so, but there are critical problems with the implementation, even with Service Pack 1 in place. No trust anchors are configured by default, and Windows supports only the RSA/SHA-1 algorithm for DNSKEY records. This makes it impossible to configure the trust anchor for the root zone, since it uses the RSA/SHA-256 algorithm. Furthermore Windows Server 2008 R2 DNS sends all of its recursive queries with the DO and CD bits set. In other words it is claiming to be able to validate answers, even though it cannot be configured to do so. Thus far I have been unable to determine a way to make Windows DNS send its queries with the CD bit clear. For these reasons DNSSEC validation is unavailable de facto to clients using Windows Server 2008 R2 DNS servers for recursive resolution.

Our Windows Active Directory environment is, I believe, similar to many in that we are running the Windows DNS service on our domain controllers. These DNS servers are authoritative for our intranet domain with Active-Directory-integrated forward and reverse DNS zones in operation. The servers also provide recursive DNS resolution service and secure dynamic update service for all of our Windows clients. In an effort to protect the Windows DNS servers from cache poisoning, they are configured not to use the root hints and to forward recursive queries to our BIND 9.8.0 recursive resolvers.

By default these forwarded queries have the CO and CD bits set, so the BIND servers dutifully return answers even when DNSSEC validation would have failed. The ultimate purpose of DNSSEC, as I understand it, is to return a SERVFAIL response code when validation fails in order to protect clients from malicious DNS data. Under present circumstances this can only happen if the CD bit from the Windows DNS query is ignored.

Thus my patch creates a new BIND option “dnssec-always-validate yes_or_no;”. When set to “yes,” the CD bit is cleared in all received queries prior to processing them. This forces the BIND resolver to perform DNSSEC validation on all queries. When set to “no”, the default, the CD bit is left unchanged, and validation is performed, or not, according to standards. Warnings are issued if the “dnssec-enable” and “dnssec-validation” options are not also turned on.

I have tested the patch in our environment, for example against a lookup of badsign-A.test.dnssec-tools.org from a Windows client. Now with “dnssec-always-validate yes;” configured, the client receives a proper SERVFAIL response rather than the address 75.119.216.33, as it always did before. Configuring “dnssec-always-validate no;” or omitting this option allows the address to be returned. While I did the best I could to make the patch correct and complete, I am not experienced with the BIND code base, so would you please review my submission in that spirit. The patch is intended to be applied to the BIND 9.8.0 source at http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz. I have compiled and run it on an Ubuntu 10.10 amd64 system.

With the recent signing of the com gTLD, I expect that the demand for DNSSEC validation will grow. Ultimately Microsoft will probably fix this problem with their DNS service, but meanwhile I hope you will consider incorporating this patch into BIND 9.8 so that Windows users can take advantage of DNSSEC now.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School
6905 Given Road, Cincinnati, OH 45243-2898, USA
Phone +1 (513) 979-0299; Fax +1 (513) 527-7632 (UTC-4)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bind-9.8.0.patch
Type: application/octet-stream
Size: 14934 bytes
Desc: bind-9.8.0.patch
URL: <https://lists.isc.org/pipermail/bind-workers/attachments/20110418/a2cb1426/attachment.obj>