The public comments period has officially ended for the NTIA's consideration of requiring domain name servers within the Internet's root zone to, at long last, encrypt their communications. Could there really be any opposition?

For well over a decade, the Internet has had available to it a security measure called DNSSEC, that would enable DNS hosts to request that communications between each other be encrypted, using public key cryptography. That way, all DNS messages could be traced back to a verifiable source, conceivably thwarting any possibility of a cache poisoning nightmare on the order of the one that security research Dan Kaminsky warned about last summer.

As with all major upgrades to a platform infrastructure, the big problem is rolling out changes in a way that's downwardly compatible with the older system. With a security upgrade, that's a problem because in any situation where security is an option, admins may choose the easiest system to control, and malicious users will always exploit the insecure option.

But last month, Microsoft revealed it planned to support DNSSEC with its next versions of Windows, including Windows 7. That could be a major boost for the long-standing security option's chances of being integrated into the infrastructure of the Internet, now that the National Telecommunications and Information Administration is considering public comments with respect to a proposal to implement DNSSEC at the root zone of the Internet.

"Over the years, a number of vulnerabilities have been identified in the DNS protocol that threaten the accuracy and integrity of the DNS data and undermine the trustworthiness of the system," reads an NTIA statement last month. "In particular, due to technical advances, vulnerabilities in the existing DNS have recently become easier to exploit. Malicious parties may use these vulnerabilities to distribute false DNS information, and to improperly re-direct Internet users. DNSSEC was developed to mitigate these vulnerabilities. Accordingly, the Department is exploring the deployment of DNSSEC at the top level of the DNS hierarchy, known as the root zone."

DNSSEC is not a particularly complex system. If you understand public key cryptography, you know that an unshared private key is used to encrypt communications between entities, but a public key that is a mathematical function of the private one, can decrypt them. The fact that it decrypts them serves as proof that the holder of the private key must have authored the communication, so the public key is shared with everyone. DNSSEC enables a DNS host to request a public key from a DNS server -- something the typical DNS server does not provide.

Conceivably, DNSSEC's biggest potential boon has been its ability to harden the security of IPsec, the encryption of all IP packets between server and client...which typically takes place after their DNS names have been resolved. Microsoft has supported IPsec for some time, and has embraced it with the latest Windows Server 2008. But for IP hosts to make use of it, they have to use some makeshift protocol for exchanging their public keys with each other -- a process that, frankly, looks a little obvious to anyone who happens to be sniffing for such transactions. If DNSSEC were in place, those public keys would be returned by the DNS servers instead, enabling hosts to use IPsec with one another without the unsightly social miscues.

For the last several years, reticence to the idea of deploying DNSSEC has centered around two problems, one being that it's virtually impossible to employ a security standard for the Internet all at once. Assuming that a fallback mode must be supported in the meantime, suppose one DNS host requests a public key, and the server can't respond because it hasn't been upgraded? How should the host handle this sort of failure? Ignoring it, believe it or not, and requesting the domain name data in the clear has been considered as an option.

Another objection is that DNSSEC doesn't actually specify how the root servers themselves will be secured. If you build a fortress with an obviously insecure back door, you're essentially painting a red target on yourself.

In an effort to address these concerns, Microsoft's engineers have worked out a way to merge group policy -- the mechanism already in place for setting rules for how clients behave in a widely deployed network -- with DNSSEC. In a similar fashion to how Active Directory currently works, policies can designate which domain names in a network are only resolvable through DNSSEC, and which subdomains within that domain may be exceptions. This way, there's no obvious fumbling around between DNS hosts over what a public key is and whether one is available.

"The Name Resolution Policy Table (or NRPT for short) is a table of settings and configuration which defines the DNS client's behavior when sending out queries and tells it what to do when receiving responses," wrote Microsoft's DNS program manager, Shyam Seshadri, in a blog post last week. "The NRPT contains settings that pertain to DNSSEC as well as another new Windows 7 technology known as DirectAccess."

When the entire IP session is already completely encrypted and secured, the need to tunnel beneath existing protocols to establish and secure a virtual private network (VPN) completely disappears. At WinHEC 2008 earlier this month, Microsoft premiered this disappearance as DirectAccess, as a future component of Windows Server 2008 R2 and Windows 7, and Microsoft's complete replacement for the VPN.

"DirectAccess in Windows 7 and Windows Server 2008 R2 enhances the productivity of mobile workers by connecting them seamlessly and more securely to their corporate network any time they have Internet access -- without the need to VPN," reads a recent Microsoft marketing page entitled "Windows 7 for the Enterprise." "When IT enables DirectAccess, the whole corporate network file shares, intranet Web sites, and line-of-business applications can remain accessible wherever you have an Internet connection."

If DNSSEC is widely deployed next year both at the very front end of the Internet -- in users' DNS clients on Windows 7 -- and at the very back end infrastructure, there's a good chance that the historical causes for objections to the protocol could be rendered moot.