why do glue records *always* *have* to overwrite the cache ?

[JINMEI Tatuya / 神明達哉]

At Mon, 11 Aug 2008 19:44:41 -0400,
"Gabriel Somlo" <gsomlo at gmail.com> wrote:

> > Did you actually confirm this behavior?  As far as I understand the
> > code (and I actually checked the behavior previously) BIND9 doesn't
> > replace an authoritative RRset with a glue.  Or in other words, it
> > strictly follows the rule of RFC2181.
> 
> I was just trying to locate the code that's actually responsible for
> Dan Kaminsky's
> vulnerability. As described by him, upon successful poisoning, the
> attacker returns
> a message that says "don't know the IP for abc123.foo.com, but check
> with www.foo.com
> at 5.6.7.8". The exploit relies on the fact that BIND will overwrite
> its currently cached entry
> for www.foo.com (1.2.3.4) with this new information (5.6.7.8). I was
> trying to locate where
> in the code this happens, and also to understand why it *has* to
> happen that way (i.e., what
> would break if I simply ignored the new info and kept my current data
> in the cache)?

If an implementation (wrongly) replaced an authoritative set with a
glue (btw, there have actually been such (non-BIND9) implementations),
Kaminsky's attack would be *even more effective*, but it's not the
most essential part of this attack.

Even if the implementation correctly prefers authoritative data over a
glue (as BIND9 does), the attacker should simply waits for the time
when the cached record expires (the attacker can detect the expiration
time if they have the right to send queries to the caching server, or
they can simply keep attacking).  In this sense, the TTL actually
matters a bit, but once the data expires the bad guy can repeat the
attack as many times as necessary without worrying about TTL (until,
of course, some other client asks the name under attack like
'www.foo.com').

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.