FW: w2000 DNSSEC compliance?
nguyenj at ncr.disa.mil
Tue Mar 7 13:00:59 UTC 2000
I have read some messages related to MS. Came across this email, I
forwarded just for information.
> -----Original Message-----
> From: Stuart Kwan [mailto:skwan at EXCHANGE.MICROSOFT.COM]
> Sent: Monday, February 28, 2000 10:04 PM
> To: NTBUGTRAQ at listserv.ntbugtraq.com
> Subject: Re: w2000 DNSSEC compliance?
> Hi Dan,
> When RFC 2137 "Secure Domain Name System Dynamic Update" was written, it
> based on the then-current DNSSEC spec, RFC 2065 "Domain Name Security
> Extensions". RFC 2535, a re-write of DNSSEC based on implementation and
> deployment experience, obsoletes RFC 2065. A side-effect of the
> of RFC 2065 is the invalidation of RFC 2137. RFC 2137 is not safe for
> Upshot: there is no IETF standard for DNS secure dynamic update.
> Two years ago we had to make a call on whether or not we should implement
> DNSSEC (RFC 2065) in Windows 2000. DNSSEC - which is a public key
> infrastructure unto itself - is very complex. In our judgment, at the
> it was not ready for implementation and deployment. It followed that RFC
> 2137 was also not ready for implementation and deployment.
> Still, we needed a solution for secure dynamic update. As it happened,
> DNSIND working group in the IETF had already recognized that DNSSEC was
> appropriate in all situations, and that there was a demand for a
> (shared secret) alternative. Two complementary Internet-Drafts were
> published to satisfy this requirement: "Secret Key Transaction
> Authentication for DNS (TSIG)", and "Secret Key Establishment for DNS
> TSIG and TKEY alone do not solve the key distribution problem inherent in
> any secret key system. However, both mechanisms allow for extension,
> permitted us to publish a third complementary draft, "GSS Algorithm for
> (GSS-TSIG)". The GSS-API mechanism enables us to use integrated Windows
> security to solve the key distribution problem, and ensure our customers
> will have no additional key management burden associated with secure
> The GSS-TSIG draft has been available since November of 1997. Microsoft
> would be happy to assist any vendors who wish to develop an independent,
> interoperable implementation. We have already demonstrated
> interoperability between Windows 2000 and other GSS/Kerberos
> (see below for more information).
> The DNSEXT working group (a consolidation of the DNSIND and DNSSEC working
> groups) is currently working on an Internet-Draft to replace RFC 2137.
> draft, called "Simple Secure Domain Name System (DNS) Dynamic Update",
> separates the authentication of an update from the later DNSSEC
> authentication of the data. The draft acknowledges the TSIG/TKEY method
> a way to authenticate updates. When TSIG, TKEY, GSS-TSIG, and Simple
> Dynamic Update reach standard status, there will be an IETF standard for
> secure dynamic update.
> Microsoft is continuing to evaluate the viability of and demand for
> DNSSEC/public key-based security for DNS.
> - Stuart
> The DNSEXT working group home page:
> RFC 2065: http://www.ietf.org/rfc/rfc2065.txt?number=2065
> RFC 2137: http://www.ietf.org/rfc/rfc2065.txt?number=2137
> RFC 2535: http://www.ietf.org/rfc/rfc2065.txt?number=2535
> "Secret Key Transaction Authentication for DNS (TSIG)":
> "Secret Key Establishment for DNS (TKEY RR)":
> "GSS Algorithm for TSIG (GSS-TSIG)":
> White paper on Kerberos interoperability:
> Press release on Kerberos interoperability:
> "Simple Secure Domain Name System (DNS) Dynamic Update":
> -----Original Message-----
> From: Dan Stromberg [mailto:strombrg at NIS.ACS.UCI.EDU]
> Sent: Thursday, February 24, 2000 10:55 AM
> To: NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM
> Subject: w2000 DNSSEC compliance?
> It appears that Windows 2000 requires DDNS for active directory. This
> is not an entirely unreasonable thing.
> It appears that DDNS is not secure without either RFC 2137 (DNSSEC for
> DDNS: http://www.isi.edu/in-notes/rfc2137.txt), or microsoft's
> now-proprietary version of DNSSEC which was based on a now-orphaned IETF
> draft. This is not good.
> Naturally, Microsoft, as with any other vendor, should be expected to
> implement the RFC. This is what interoperability and good faith are all
> about in the computer industry. This has obvious security implications
> - if you can't interoperate with the products of other vendors without
> weakening security because of microsoft's race to get w2000 to market
> (or cavalier attitude toward interoperability?), that's a big problem.
> It is in microsoft's power to fix this.
> Anyway, has anyone heard any rumors as to Microsoft's plans for
> implementing RFC 2137 properly?
> For more information, see
> This looks like a pretty good paper on the subject, but the paper fails
> to acknowledge that one option is to simply not use active directory
> until microsoft fully implements RFC 2137.
> Delivery co-sponsored by Trend Micro, Inc.:
> ScanMail for Microsoft Exchange
> * Stops viruses from spreading through Exchange Servers.
> * Eliminates viruses from email in real time, even unknown macro viruses
> * Filters spam (unsolicited junk email).
> * Sends customized virus warning messages to specific parties and admins
> * Remote installation and management via web or ScanMail's Windows GUI
More information about the bind-workers