North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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
No, by using a known local trust anchor for the root and following the
chain of trust from there.
trust relationship. DNSSEC would have the same problem, where do you
the trustworthing signatures? By connecting to the same root you don't
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.
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?
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
(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
Always initiate the call yourself. Always check the nonce in the
And, according to your theory, be happy that you have no way to
validate the authenticity of any answers you do get?
answer. Never accept unsolicited data. Never accept answers to
you didn't ask.
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.