Why *can* cached DNS replies be overwritten?

Jack Bates jbates at brightok.net
Mon Aug 11 16:31:01 UTC 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




More information about the NANOG mailing list