What does a record's TTL determine; how should it be chosen in GTM?
Short answer
A record's TTL value states for at most how many seconds the answer given by the DNS Service can be kept in the cache in resolvers and clients; the default is 3600, the range is 0–31,536,000 seconds. When GTM removes an address from the answer or switches to the DR DC, the new answer is given within a few seconds, but clients that cached the old answer use the old address until the TTL expires. For this reason, in the worst case, the time it takes for a failure to be reflected to the clients is the sum of the time it takes for the health check to notice the failure and the TTL. On records that have an address bound to a health check, or a Disaster Recovery or Datacenter selection, a short TTL (e.g. 60–300 seconds) is chosen, and on records whose address does not change, a longer TTL.
How Does It Work?
Between an address failing and the client going to the new address, three periods pass one after another:
- Noticing: The health check tries the target at the Period interval and becomes Error after Required Failures consecutive failures. In the automatic health checks of a remote data center, this time is determined by Access Period and Required Failure.
- The answer changing: When the Health Scenario decision changes, the record is evaluated again and the DNS Service gives the new answer.
- The cache emptying: The resolvers and clients holding the old answer ask again when the TTL expires and receive the new answer.
TTL 0 states that the answer must not be cached (RFC 1035); with this value, the same name is queried again every time it is needed, and the number of queries coming to GTM increases.
TTL in TR7
- Where: The TTL field in the record form, in seconds; its shortened equivalent (e.g.
1h) appears next to the box. It is monitored in the TTL column of the Records list. - Scope: TTL is per record; all answers of the record (Main DC, DR DC, the selected data centers or Fail-Safe Records) are returned with the same TTL.
- Zone transfer: Records newly created with Zone Transfer take the TTL from the source.
- Difference from Cache TTL: The Cache TTL in the DNS Service is not announced to the clients; it is the duration of the service's own cache (What is TTL; on which TR7 screens does it appear, and with what meaning?).
| Record | Recommended approach |
|---|---|
| A / AAAA / CNAME records that have an address bound to a health scenario, or that are in Disaster Recovery or Datacenter mode | Short TTL (e.g. 60–300 seconds); the speed of the switchover is important. |
| Records with a fixed address (such as NS, MX, TXT) | A longer TTL; the query load decreases. |
| Planned address change | The TTL is lowered at least one old TTL period before the change. |
Common Misconceptions
- "When GTM switches, all clients go to the new address immediately." The new answer is given within a few seconds; clients with the old answer in the cache use the old address until the TTL expires (What are the limits of DNS-based routing; how do TTL and the resolver cache affect the decision?).
- "A short TTL alone provides fast failover." The time it takes for the failure to be noticed is also added to the total time; the health check Period and Required Failures values are considered together with the TTL.
- "DR or fail-safe answers are returned with a separate TTL." The record has a single TTL; whichever group gives the answer, the same TTL is used.
- "The shorter the TTL, the better." As the TTL gets shorter, the number of queries coming for the same name increases; the TTL is chosen by weighing the need for switchover speed against the query load.
How it is done in the documentation
Related questions
- What is TTL; on which TR7 screens does it appear, and with what meaning?
- What are the limits of DNS-based routing; how do TTL and the resolver cache affect the decision?
- How does the switchover between the primary and backup data centers work in Disaster Recovery mode?
- For redundancy across data centers, should I use Load Balancer or GTM?
