DNS cache poisoning attacks -- are they real?

Sun Mar 27 02:23:51 UTC 2005

On 26 Mar 2005, at 20:15, Sean Donelan wrote:

> Signatures don't create trust.  A signature can only confirm an 
> existing
> trust relationship.  DNSSEC would have the same problem, where do you 
> get
> the trustworthing signatures?  By connecting to the same root you don't
> trust?

No, by using a known local trust anchor for the root and following the 
chain of trust from there.

> As a practical matter, you can stop 99% of the problems with a lot less
> effort.  Why has SSH been so successful, and DNSSEC stumbled so badly?

For most people SSH encrypts a session, and says nothing about the 
identity of the remote host. Most people ignore the warnings about host 
keys changing, and never check an ssh fingerprint with the remote host 
before accepting it and caching it until next time.

DNSSEC doesn't attempt to encrypt the transport; it is all about the 
authenticity of the data. So, they are doing different things.

SSH deployment requires no coordination between organisations really; 
while there are public services deployed over SSH, I would be very 
surprised if its main use is not intra-organisation. DNSSEC, on the 
other hand, requires extensive standardisation and buy-in from a huge 
number of different organisations before it is useful in a general 
sense.

(You can use DNSSEC in a private, intra-organisational context, much as 
you might use SSH, today.)

I'm not sure what 99% of DNS authenticity problems you think you can 
solve without DNSSEC; perhaps it might be useful for you to enumerate 
them.

> Always initiate the call yourself. Always check the nonce in the
> answer. Never accept unsolicited data. Never accept answers to 
> questions
> you didn't ask.

And, according to your theory, be happy that you have no way to 
validate the authenticity of any answers you do get?

> Besides, if you don't trust IP addresses

If?

We have meandered from the topic at hand, a bit. But the general point 
I was trying to make was that all the robust DNS software in the world 
will not avoid the propagation of rogue DNS answers if there's no way 
for a client (or a trusted, validating resolver) to verify the 
authenticity of the data contained within them.

Joe