The following was lifted from Wikipedia on 2013/04/21

TTLs also occur in the Domain Name System (DNS), where they are set by an authoritative name server for a particular resource record. When a caching (recursive) nameserver queries the authoritative nameserver for a resource record, it will cache that record for the time (in seconds) specified by the TTL. If a stub resolver queries the caching nameserver for the same record before the TTL has expired, the caching server will simply reply with the already cached resource record rather than retrieve it from the authoritative nameserver again. Nameservers may also have a TTL set for NXDOMAIN (acknowledgment that a domain does not exist); but they are generally short in duration (three hours at most).

Shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful when changing the address of critical services like Web servers or MX records, and therefore are often lowered by the DNS administrator prior to a service being moved, in order to minimize disruptions.

The units used are seconds. An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

Newer DNS methods that are part of a DR (Disaster Recovery) system may have some records deliberately set extremely low on TTL. For example a 300 second TTL would help key records expire in 5 minutes to help ensure these records are flushed world wide quickly. This gives administrators the ability to edit and update records in a timely manner. TTL values are "per record" and setting this value on specific records is sometimes honored automatically by all standard DNS systems world-wide. However a problem persists in that many caching DNS nameservers set their own TTLs regardless of the authoritative records, so it cannot be guaranteed that all downstream DNS servers have the new records, after the TTL has expired.

Guides for DoIT TTL usage:

• A four hour [14400] TTL was chosen to be the best mix between DNS server performance and the minimization of TTL related outages due to unplanned DNS changes.


• Large TTLs do not prevent DNS outages.  Unlike DHCP leases, in general DNS servers do not prefetch DNS records.  So, let's assume that at time X, record Y has a TTL of 86400.  If a complete authoritative DNS outage occurs at time X + 86359, the outage will be noticed [unless the outage lasts less than 1s] 


• A TTL of 300 or less is recommended when time sensitive DNS changes must occur.   As of 2013/04/21, the largest ADNS load on the campus servers is about 20% CPU.  The consequence of changing hundreds of records [or even dozens of complete zones] to a TTL of 300 is minimal, even weeks ahead of time if needed.


• Individual RR TTLs override zone TTLs.  If you change a zone TTL, be sure that the individual RR you are trying to affect does NOT have an explicitly set large TTL.
  


• Resource constraints should not drive operational efficiency; if the system is inadequate for current needs it can always be grown.