low TTL DNS
A 300-second TTL is a five-minute outage you already agreed to.
High TTLs make migrations and failovers wait. Many DNS hosts discourage low TTLs because their authority cannot take the query rate.
Cloud DNS supports a one-second minimum TTL on 210+ Anycast servers. Use low TTLs where change must be fast, and higher TTLs where records are static.
Why teams use Aptranet
What low TTL DNS looks like on this network.
Cloud DNS answers on 210+ Anycast servers, with GeoDNS, health checks and a one-second minimum TTL for change.
One-second minimum TTL
Planned failovers and migrations can take effect on a production clock, not a cache clock.
Anycast that can take the queries
Low TTLs mean more queries. 210+ servers are the reason that is viable.
Per-record control
Keep MX and static records high. Lower the records you actually move.
How to set it up
A cutover you can validate before DNS moves.
Create the Cloud DNS configuration, prove it on an Aptranet hostname, then point production DNS when the path looks correct.
- 1Inventory records that must move quickly
Application apex, CDN hostnames, failover targets.
- 2Lower those TTLs ahead of the change
Do it before the maintenance window, not during it.
- 3Make the change
Update records, weights or health-check eligibility.
- 4Raise TTLs afterwards if you want
Static records do not need to stay at one second forever.
Outcomes
What changes once the hostname is on Aptranet.
- Critical records can use a 1-second TTL
- Migrations are not blocked by old caches
- Static records can keep higher TTLs
- Query load is absorbed on Anycast
Keep reading
Related pages
More DNS use cases on the same Cloud DNS footprint.
Frequently Asked Questions
No. Some recursive resolvers clamp TTLs. Still lower them: many will honour a short TTL, and health-aware answers help the rest.
Lookups happen more often. Anycast Cloud DNS is built for that. The application handshake is still the larger cost.
No. Use low TTLs where you need change. Leave stable records longer.
Yes, with signature lifetimes planned so validation and low TTLs remain compatible.