Cache management is a broad subject. Half of the decisions taken by a DNS server, in how it handles its cache, are purely local and thus non-standard.
In the DNS system, servers which are "authoritative" for a zone (say, a domain) publish some cache delays, which apply restrictions to other servers. For instance, for
$ host -t soa google.com
google.com has SOA record ns1.google.com. dns-admin.google.com. 2013072400 7200 1800 1209600 300
The numbers are, in that order: serial, refresh, retry, expire and minimum. The "serial" is an arbitrary integer increased at each modification, and traditionally encodes the date of the last modification (here, July 24th, 2013). The four other integers are delays, expressed in seconds. They tell that a "secondary" (e.g. the DNS server of an ISP, not the source DNS server for the target domain) should use the following strategy:
- Whatever information was cached, should be refreshed after two hours (7200 seconds), in case newer information is obtained.
- In case of failure to reach the source DNS, a server should wait for half an hour (1800 seconds) before trying again.
- Information which was cached cannot be considered as usable beyond fourteen days (1209600 seconds). A DNS server must not use or keep information which has been obtained more than a fortnight before.
- Unless it cannot be avoided, a DNS server must not talk again to the source DNS server within five minutes (300 seconds) of the previous answer.
Section 2.2 of RFC 1912 gives more details. The most important value, for an attacker bent on DNS poisoning, is the "minimum" delay. Here, it means that the attacker will have a hard time making its victim eat fake DNS data about
google.com before at least 5 minutes have elapsed. Conversely, the attacker just has to wait for five minutes, or maintain his toxic flow of fake answers for five minutes, in order to have a fair chance at poisoning the server.
There are methods to speed up forgetfulness. The attacker stands a chance of poisoning the server if he can get it to forget what it knows about a given domain. As explained above, a DNS server will already "forget" information beased on delays which are advertised by the source server itself. However, a DNS server keeps its cache in RAM, which is not an infinite resource. This means that the following may be applicable:
The attacker can spam the target DNS with lots of requests for many randomly-chosen domains, so that the DNS has more information to cache than it can realistically keep in its allocated RAM, forcing it to evict previously cached information earlier than what the "minimum" delay would have entailed.
In some cases, the attacker can make the target DNS crash and be restarted automatically (it depends on how well the DNS software and the underlying OS handle against massive DoS attacks). A crashed-and-restarted DNS server begins its life with a clean, empty cache, ready to be poisoned.
DNS servers can also agree on proactive notifications of changes: a secondary DNS can ask a primary to tell it whenever some of its data has changed, so that it may invalidate its caches immediately, instead of waiting for the normal delay-based refreshes. An industrious attacker may want to try to fake this mechanism to force an early refresh.