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

["Antoin Verschuren" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:owner-
> Subject: Why *can* cached DNS replies be overwritten?
> 
> Do djb and Power in fact do that?

I did some investigation after my post of http://lists.oarci.net/pipermail/dns-operations/2008-February/002526.html
I did not test this myself, but what people have told me is:

Dnscache, powerdns: Updates the cache by resetting the TTL if a new authoritative answer for the same entry is received.

Bind: Updates the cache, but only replaces the TTL with the min value

Unbound: Never updates, always waits for an entry to expire before accepting a new entry

> 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.

I actually like the simple behavior that an authoritative answer can override an already cached answer.
It's efficient, and follows the simple rule that an authorative answer can be cached.
It only goes wrong if people don't maintain their DNS entries operationally, and forget to delete entries they are no longer authoritative for.
So the bad guys get hit.
The benefit for the good guys is that less lookups are needed, and more importantly, parents are hit less.
In the DNS hierarchy, you don't want every query to hit the root.
My concern is that if records always expire, like Unbound does, parent nameservers are hit more.

Now we can start an argument on the fact that traffic has become inexpensive, and root and TLD nameservers should be able to cope with this minimal increase in queries, but I think we should define a protocol to be as efficient as it can be.
I actually don't know how parent traffic will be affected, I'm interested to see measurements on that.
But I stay with the thought that even though we only win some bits in traffic, we should always aim to design a protocol to do so.

I also think we must not create protocol complexity to protect ignorant users from making mistakes when that does not benefit educated users.

And then there's the argument that when cached entries cannot be replaced, an attacker can make use of that.
"fixing" a bad cache entry remotely by sending the correct authoritative answer might reduce the time window a poisoned cache is operational.


Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T [phone]
F [phone]
M [phone]
E [e-mail]
W http://www.sidn.nl/

--
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/>