Q&A: DNS inventor Paul Mockapetris

The design of DNS was intended so that security features could be added later. But the primary design criteria 25 years ago was, critically, not as complicated as it's come to be over the years. In 1989, which was the first year we saw cache poisoning in the wild, the reaction was to use the mechanisms in DNS for security. But a 16-bit ID field designed as a local extension field wasn't a long-term strategy. And that's what Dan Kaminsky's attack research showed.

So now that DNS has proven to be flawed, what do believe will remedy the situation? Or is the reliance on DNS in IPv4-based web environments always destined to be weaker from a security and resilience perspective now?

At Nominum, the software we've designed for our carriers has to take account of a wide variety of users. Some are very good when it comes to security, like not clicking on unknown attachments and so on, and some aren't. What we're trying to do is to use an internet reputation database to distribute information to carriers and users about whether the IP address of a particular website is trusted or not.

We can't stop users visiting dodgy websites, but we can at least allow them to know a website is dodgy before they visit it. I think the time is right to get digital signature systems built into the DNS and the protocols are there to do it.

But all this work is taking place at agency or vendor level. How can IT professionals adopt a similar approach around designing security into their web services and applications?

I believe something along those lines of signature technology will happen sometime during the second decade this century. Realistically, I think this will be by 2012, but a worst-case scenario would be not to see widespread adoption until as late as 2019.

The good work already done to defend against the Kaminsky flaw has taken the pressure off the industry somewhat. But digital signature technology fundamentally increases security levels for users and for other levels of the internet overall.

But how does this activity translate to the average internet user? Are there any best-practice development lessons that can be learned from having to deal with the Kaminsky flaw?

Essentially, security needs to be simple to understand. That doesn't mean security has to be inherently weak, but the interface has to be something the user can understand.

For instance, I draw an analogy here with a car door lock. Now most people are aware that the skills exist out there for thieves to potentially pick that lock and steal their car. But the level of security it offers allows you to drive your car around and still expect it to be there for you to drive off on your return to it. The same should be true of the internet web security has to be simple and understandable for it to be effective.