Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: DNS cache poisoning attacks -- are they real?

  • From: Joe Abley
  • Date: Sat Mar 26 21:25:30 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
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

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.


Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.