I'm still rather haunted by Dan Kaminsky's DNS presentation from last week's Black Hat conference. As I mentioned in my Day 1 wrap-up, you forget how pretty much everything you do is dependent on having trustworthy DNS. Dan showed that DNS is anything but trustworthy.

So I spent some time trying to figure out how to solve the problem. Sure, a lot of really smart folks spent some time doing the same. And they couldn't really see a tangible answer, so they are pushing towards source port randomization to at least minimize the likelihood that the DNS cache will be poisoned via a Kaminsky attack.

Part of the luxury of not being a real technical guy is that I tend to look at the problem in an unconventional way. I suspect (but don't know this for sure) that many others are trying to solve the entire problem. Which I suspect is akin to boiling the ocean.

After looking at DNSSEC for a little while, clearly that is intangible for a network the scale of the Internet. The idea of digitally signing all of the requests is a good one in theory, but clearly ain't going to get there. And with the zone enumeration issue inherent to early versions of DNSSEC, folks are starting to layer band-aids and duct tape over the issues, in a feeble attempt to try to get the technology to "work."

I really doubt it's going to happen. So what's plan B?

I've also been doing a lot of research into CSRF (cross-site request forgery attacks) and I see some similarities to the Kaminsky DNS issue. Not like twin brothers. More like 3rd cousins. Basically, in both scenarios, it's not clear that you can trust the other side of the transaction, so you need to layer some more "tests" on top of the base transaction to make sure you are receiving traffic from the real McCoy.

One of the techniques to defending against CSRF is to add a token to each transaction, which would be difficult (not impossible, but difficult) to spoof and therefore would sort of validate that the other side of the transaction is legit.

Why couldn't we do this for DNS requests? I know, I know. We'd have to update all the name servers and then propagate the software through the DNS hierarchy. But that's only if we are trying to boil the ocean.

What if we only tried to boil a lake, or even a puddle and started building some of the code into our key applications (or as a proxy for our key applications)? And then we could get our trading partners (who we are doing high value transactions with) to add the same code to their applications. Thus, any traffic I'm sending to IP addresses in their environment are also "tokenized."

If a large enterprise moves in this direction, they likely have enough pull to get their ISP (or multiple ISPs as it may be) to build the code into their name servers. Then it sort of becomes a bottoms-up movement, as opposed to a top-down mandate. Top down doesn't work too well in the age of the Internet.

In terms of caveats, I have no idea if this would even work. I'm literally making this up. Or if Kaminsky would make mince-meat out of this in seconds. Or if many others have tried this and failed already.

I also don't know how complicated it would be to add this proxy layer to tokenize the DNS requests. I don't know if it will scale or if it will solve the problem. Or if the very nature of DNS requires that we boil the ocean, as opposed to the puddle.

Basically, I'm throwing some spaghetti against the wall and I figure the real smart guys out there will take a look, tell me I'm an idiot and then maybe suggest something that would be more tangible/feasible/logical, etc. It's all about fostering the discussion, since after seeing Kaminsky's pitch, sticking our heads in the sand and waiting for divine intervention to fix the problem ain't going to happen.

Photo credit: "lake (or puddle?) of free boiling mud" originally uploaded by magtravels [1]