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

* Jack Bates · * Mon Aug 11 12:31:09 2008

Leo Bicknell wrote:

That's not to say there aren't possibly other checks or rechecks
that could be done, but in the vast majority of day to day cases
when someone properly gives you additional information it is useful.
Authorities are updated all the time.  There are thousands of these
cache overwrites with new, more up to date info every day.

The problem is, it's not trustworthy. There's lots of heuristics that could be
done to determine pre-expiration of cached data, but it should be just that an
expiring of the cached data allowing for a new request for it.
Possible scenario's:
1) Mismatched auth records causes expiring of the records. Attacker has
successfully spoofed a packet and caused a cache dump for the record in
question. He must now spoof another packet before the cache is rebuilt.
2) Mismatched auth records are ignored, causing delays in the remote updating to
new records. This is a better distrust model, though it may have a longer impact
on outage situations.
3) Recognize successive timed out queries to an auth server, marking it as
possibly not there, stale out the cache and ask for new information, or allow
for cache overwrite only concerning records which appear not to be working.
4) Recognize entries which are receiving forged packet attempts (easiest to do)
and do not support cache overwrites for those domains. This supports normal
operation unless someone is specifically attacking a domain, and then that
domain leaves a trust model to an untrusted model, which may have performance
hits in that we will ignore valid updates too, but given that the server cannot
tell the forgery from the real update, it should be ignored. This method is
vulnerable to the once in a X shot that the first forged packet actually makes
it with the right port/id combo.
Cache overwrites are dangerous. IMHO, They need to go away or be protected by
extensive checks to insure integrity of the cache.
Jack