Meet Paul Mockapetris. He may not be an industry celebrity like Bill Gates, Michael Dell, Richard Stallman, Eric Raymond, or Linus Torvalds, but he should be. Mockapetris was a key figure in the development of the Domain Name System, the Internet protocol that maps domain names like zdnet.com to IP addresses like 206.16.6.208. Without a protocol like DNS, people, software, and computers would be cast adrift in a sea of incomprehensible and changing numbers. Although others were involved with the development of the DNS, Mockapetris wrote the protocol, and for this contribution he was recently awarded the prestigious IEEE Internet Award.

Today, Mockapetris is the chairman and chief scientist at Nominum, a solution provider offering industrial strength DNS and DHCP management solutions. But, when he's not running Nominum, he's thinking about how to combat what he says is the Internet's number one growth industry and the source of ills: identity theft. "Most of our problems," says Mockapetris, "whether spam or hactivism, like what happened to Al-Jazeera or 10 Downing Street, can be traced back to identity theft."

Not surprisingly, Mockapetris believes the DNS could be the answer to many of the Internet's identity-related problems "We could start from scratch," says Mockapetris, "or, we can use something that's already in place, that's lightweight, and that every computer on the Internet already knows how to use--the DNS."

Mockapetris argues that a work-in-progress extension to the DNS specification called DNSSEC is what makes the DNS up to the task of solving most of the identity related issues on the Internet. Unfortunately, since DNSSEC isn't bulletproof (and, according to some, could result in other vulnerabilities), the specification has been a work-in-progress since November 1993, when the DNS working group of the Internet Engineering Task Force (IETF) held its first DNSSEC design meeting.

Despite the imperfections of DNSSEC, Mockapetris says that it's time to go for it. "The DNS has been growing for twenty years, but during that time, no progress has been made on securing it. The Internet Engineering Task Force (IETF) has been working on it for ten years, but they haven't finished it. As a result, the barriers to forging identity are low and the number of transgressions is on the rise," Mockapetris told me. "After getting nowhere in ten years, it's time to give it a try."

He accuses those trying to solve the problem with settling for nothing less than perfection. "Meanwhile a good solution that can make a significant amount of headway against identity theft is sitting right under our noses. I think that one of the ways to enable a better future for Internet is to add a modicum of security. Sort of like locks on cars. It may not be perfect and people will figure out how to steal the keys, but you have to start somewhere. Let's go back to the way the Internet came to be, and try a few things and see what happens. We need to admit that we're not going to get things perfect the first time."

According to Mockapetris, DNSSEC is the equivalent of a tamper-proof seal for Internet applications like the Web and e-mail. Whereas today, it's relatively easy for hacktivists or spammers to impersonate an Internet-based source of information, DNSSEC raises the barrier by adding a measure of data origin authentication to the information retrieval process. In the context of domain-related transgressions, such as forged credentials on spam or hacked domain mapping information, DNSSEC can increase the probability that an e-mail is actually from the domain it claims to be from and that the information retrieved from a Web site actually came from the intended Web site and not an imposter. Today, however, it's possible to redirect HTTP or FTP requests to imposter domains through privately run, rogue DNS servers.

DNSSEC works by providing a confidence check that the information being retrieved is indeed coming from the source it claims to be coming from and was not subjugated by a packet interception or what some call a monkey-in-the-middle attack. When a browser accesses a Web page from ZDNet for example, that access would be preceded by a verification that the mapping of the zdnet.com domain to ZDNet's actual IP address (the sort of information that a DNS server provides) hasn't been tampered with since it was programmed by ZDNet's domain administrators. Likewise, an e-mail client could perform a confidence check that increases the probability that an e-mail that claims to have come from ZDNet's domain actually did so.

The technology behind these confidence checks uses digital signatures and public key cryptography. For starters, DNSSEC involves the use of secure hash algorithms for the digital signing of the records--called RRSets --that appear in the DNS database. Using its private key, ZDNet could digitally sign the domain mapping information that appears in the DNS for zdnet.com, and any application that depends on that information could retrieve ZDNet's matching public key from a special key record (part of the DNSSEC specification) under ZDNet's DNS entry. Using ZDNet's public key, the application can verify that the domain mapping information was signed with ZDNet's private key, which presumably only ZDNet has. For a more detailed, yet high-level overview of the process that includes a bit of a primer on public key cryptography, I recommend reviewing a presentation written by Cricket Liu that's listed by DNSSEC.net.

The same system that checks for whether DNS data has been tampered with could also come in handy for a problem like spam. Using the aforementioned private key, ZDNet's e-mail server could digitally sign all outbound e-mail. Before allowing that e-mail to proceed into the intended recipient's inbox, a server on the receiving end could retrieve the private key's corresponding public key from the special key record that's associated with ZDNet's domain in the DNS. To make a long story short, if a match between the keys isn't detected, the e-mail is processed accordingly (either dumped or funneled to a 'mail from questionable origin' folder).

Critics (and there are many of them) argue that DNSSEC not only has weaknesses, but creates new problems. To the extent that more information has to be exchanged between DNS servers and client systems to complete a transaction, the Internet-wide implementation of DNSSEC could create a tidal wave of traffic. This situation could overwhelm certain Internet segments, amplify denial of service attacks and trigger more timeouts that ultimately frustrate end users.

Implementation is another challenge. As would be the case with switching from IPv4 to IPv6, success would depend on rapid global adoption, which in turn depends on the rather simultaneous rollout of idiot-proof support in products (like e-mail clients and servers) from leading technology companies. VeriSign principal scientist Phillip Hallam-Baker told me, "The deployment issues are not simple. You basically have to persuade the entire industry to make a move before DNSSEC can provide value. To get there, you first have to ask, 'What are the forces that can bring the industry together?' At this point, spam is probably at the top of the list. The problem with using DNSSEC-- as a domain registrar VeriSign has been looking at it in connection with the spam problem-- is that it's difficult to see what you get from it. If you get DNSSEC completely deployed, it allows you to defend against certain countermeasures that spammers use to get through your defenses, like DNS spoofing. But then again, there are other ways to protect against it that don't require DNSSEC."

One reason solution providers might be leaning in another direction is that a standards-based approach like DNSSEC could negatively impact the revenue stream of successful proprietary approaches. Whether VeriSign is working on such an approach, Hallam-Baker wouldn't say. But most experts, including Mockapetris agree that one of DNSSEC's thorny problems is answering the question of who gets to sit at the top of trust chain if and when it gets rolled out.

As a leading certificate authority, VeriSign is in a plum position should a DNSSEC rollout create a need for trustworthy digital signatures. At the risk of sounding too opportunistic, it's no wonder that Hallam-Baker didn't want to get pinned down one way or another. As both a domain registrar and certificate authority, VeriSign has been no stranger to the ongoing who-should-control-the-Internet controversy.

Despite what critics say, as an advocate for standards-based approaches to just a about any problem, I'm in Mockapetris' camp. Mockapetris isn't touting DNSSEC as the cure-all. In fact, he'd be the first person to tell you about all of DNSSEC's faults. But in the same breath, he and most others will say that as bulletproof as DNSSEC isn't, its deployment would raise the barrier to casual identity theft, which constitutes the majority of identity-related transgressions on the Internet.

In the case of spam, even if the source of an inbound unsolicited e-mail proved to be authentic and it slipped through the scrutiny of your ever-watchful DNSSEC-aware e-mail system, future e-mails from that authenticated source could be denied passage by the simplest of filters. Furthermore, even though we're living in a world that's remarkably different from the early days of the Internet, I agree with Mockapetris when he says its time to return to an environment that's fertile for innovation. By putting a less-than-perfect solution like DNSSEC out there, it leaves room for innovation to fill the void.

Against the backdrop of his global deployment of the USSR's navy in the early 1960's, Soviet Admiral S.G. Gorshkov said, "Perfect is the enemy of good enough." Had the first versions of other imperfect specifications such as TCP/IP waited ten years for those in disagreement to work out their differences, the Web might still be hiding somewhere in the back of inventor Tim Berners-Lee's mind. Sometimes, to get those creative juices flowing, it makes sense to go for it, and that is what we should do with DNSSEC.

What do think? When it comes to DNSSEC, is it time to just go for it or should we debate it for another 10 years? Debate with your fellow readers using TalkBack . Or write to me at david.berlind@cnet.com. If you're looking for my commentaries on other IT topics, check the archives.