Re: Why *can* cached DNS replies be overwritten?

[Olafur Gudmundsson <[e-mail]>]

At 15:04 11/08/2008, Jay R. Ashworth wrote:
>[ cross-posted from NANOG, cause vix told me to :-)
>
>On Mon, Aug 11, 2008 at 11:20:07AM -0400, Leo Bicknell wrote:
> > If your vendor told you that you are not at risk they are wrong,
> > and need to go re-read the Kaminski paper.  EVERYONE is vunerable,
> > the only question is if the attack takes 1 second, 1 minute, 1 hour
> > or 1 day.  While possibly interesting for short term problem
> > management none of those are long term fixes.  I'm not sure your
> > customers care when .COM is poisoned if it took the attacker 1
> > second or 1 day.
>
>Correct me if I'm wrong, Leo, but your assertion turns on the fact that
>the server will accept an overwriting cache entry for something it
>already has cacheed, does it not?
>
>Do djb and Power in fact do that?
>
>If they don't, the window of opportunity to poison something like .com
>is limited to the period between when that entry expires from the local
>server's cache and the next time it hears a reply -- which will be the
>time after that expiry when someone next requests a .com name; IE
>almost immediately, no?
>
>Everyone seems to continue asking "why can poisoning overwrite already
>cached answer" and no one seems to be answering, and, unless I'm a
>moron (which is not impossible), that's the crux of this issue.
>
>Cheers,
>-- jra
>--

<no-hat>
The cynical answer is "optimization" the real answer is
"trying to be helpful".

What most/all implementations are doing is assuming that "newer" data
is better if it has the same criticality [RFC2181], this takes two forms:
if the data is identical to the existing one, the TTL on the set is extended.
If the data is different the old data is replaced.

Personally I think we need to sit down and analyze this carefully if
we are better of by outlawing/discouraging this behavior and have all
RRsets expire after the original TTL expires or do something else.

One proposal is to use the "Authority Section data for the question 
being asked" and then ask a direct query to fetch the data inserted into the
Authority section data and overwrite that with the data from Answer
section which should have higher criticality than the stuff from Authority
Section and this should prevent overwrites. (This is strictly/almost
a protocol change)

The effect of not overwriting/stretching TTL on RRsets is that
an  attacker can only poison the set of their choice once in a
while (depends on the RRset TTL and the cache's memory constraints).

<char-hat=on>
What the overall effect is going to be if caches changed this
behavior is debatable but conducting few experiments would be real
useful. Both in seeing if anything in resolution break as well as
see if this helps prevent acceptance of forgeries.

At the same time the WG should look into other approaches in this and
related spaces.

         Comments
         Olafur

   


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>