The Blog of an honest Consultant.
There are many reasons why network operators choose long or short TTLs
Longer caching results in faster responses: a longer TTL enables caching for longer periods, and cache hits are far faster than retrieving answers from authoritative servers, as the .uy experience illustrates. We designed several experiments to investigate this, which are described in our paper. The results show that longer caching improves results even more than having a large anycast network.
Longer caching results in lower DNS traffic: authoritative operators may be interested in setting higher TTLs because caching reduces the number of queries they receive. That is especially important if the DNS service is metered.
Longer caching is more robust to DDoS attacks on authoritativeDNS server: DDoS attacks on a DNS service provider have harmed several prominent websites. Recent work has shown that DNS caching can greatly reduce the effects of DDoS on the DNS, provided caches last longer than the attack.
Shorter caching facilitates operational changes: an easy way to transition from an old server to a new one is to change the DNS records. Since there is no way of removing cached DNS records, the TTL duration represents the transition delay necessary to fully migrate to a new server. Therefore low TTLs allow for more rapid transition. However, when deployments are planned further in advance than the length of the TTL, TTLs can be lowered just before a major operational change and raised again once the change is effected.
Shorter caching can help with a DNS-based response to DDoS attacks: some DDoS scrubbing services use the DNS to redirect traffic during an attack. Since DDoS attacks arrive unannounced, DNS-based traffic redirection requires the TTL be kept quite low at all times to be ready to respond to a potential attack.
Shorter caching helps DNS-based load balancing: many large services use DNS-based load balancing. Each incoming DNS request provides an opportunity to adjust the load, so short TTLs may be desirable for rapid response to traffic dynamics. (Although many recursive resolvers have minimum caching times of tens of seconds, placing a limit on agility.)
TTL duration: the choice of a TTL value depends in part on external factors, so no single recommendation is appropriate for all networks or network types.
For general zone owners, we recommend longer TTLs: at least one hour, and ideally four, eight, or 24 hours. Assuming planned maintenance can be scheduled in advance, long TTLs have little cost.
For TLD and other registry operators: DNS operators that allow public registration of domains (such as most ccTLDs, .com, .net, .org and many SLDs) allow clients to duplicate the TTLs in their zone files for client NS records (and glues if in-bailiwick). Most resolvers use TTL values from the child delegation and some use the parent’s TTL. We therefore recommend longer TTLs for both parent and child NS records (at least one hour, preferably more).
Users of DNS-based load balancing or DDoS-prevention may require short TTLs: TTLs may be as short as five minutes, although 15 minutes may provide sufficient agility for many operators. Shorter TTLs here help with agility; they are an exception to our first recommendation of longer TTLs.