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