- All other factors being equal, a lower TTL is preferred
- This minimizes time to re-direct traffic away from a failed site
- Should always be at least long enough that DNS operations don’t become a hindrance to application/service access
- For active/standby site configurations
- No special considerations
- For multi-active-site GLB configurations
- Persistence should be enabled
- Timer has to be higher than the TTL of the DNS record itself.
- Otherwise, persistence could expire before it actually gets invoked.
- Timer has to be higher than the TTL of the DNS record itself.
- Persistence should be enabled
- If the GLB’s target-pool is populated with FQDNs (and not IP addresses), the TTL value used in the GLB DNS responses to clients must not exceed that of the A records for the target FQDNs.
- If, for example, a 3rd-party dGLB is configured with an FQDN that load-balances to multiple AWS application-load-balancers
- AWS DNS always responds to resolution requests for ALB’s FQDNs with a TTL of 60 seconds.
- If the dGLB is configured with a 30-second persistence timer, the clients (recursive resolvers) would keep the A records cached past the 30 seconds, and the GLB would expire the persistence-able entry before it received another query
- If, for example, a 3rd-party dGLB is configured with an FQDN that load-balances to multiple AWS application-load-balancers
DNS TTL Guidelines
Things to consider (and why) regarding DNS record time-to-live values.