DNS for APIs
Clients cache API answers. Make those answers deliberate.
Mobile and backend clients pin API hostnames for a TTL. A static A record is a regional outage with extra steps.
Put api.example.com on Cloud DNS. Steer with GeoDNS or weights, health-check every pool, and use low TTLs so canaries and failovers work.
Why teams use Aptranet
What DNS for APIs looks like on this network.
Cloud DNS answers on 210+ Anycast servers, with GeoDNS, health checks and a one-second minimum TTL for change.
Canary API pools in DNS
Weighted answers send a fraction of resolvers to a new API stack.
Failed API regions disappear
Health checks remove non-responsive endpoints from eligible answers.
Regional API entry points
GeoDNS sends resolvers toward the nearest live API hostname or address.
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.
- 1Host the API zone or record set
api, auth and webhook hostnames.
- 2Publish more than one pool
Even if 100% of weights start on a single pool.
- 3Attach health checks
Probe the API the way clients use it, over HTTPS.
- 4Keep TTLs short on api.*
Clients will cache. Give yourself a way to move them.
Outcomes
What changes once the hostname is on Aptranet.
- API DNS can canary and fail over
- Regional entry points are explicit
- Unhealthy pools leave the rotation
- Authority is Anycast, not a registrar default
Keep reading
Related pages
More DNS use cases on the same Cloud DNS footprint.
Frequently Asked Questions
Cacheable GET APIs often should. See CDN for APIs. Cloud DNS still steers the hostname.
DNS is agnostic to the application protocol. Health checks should match how you determine liveness.
GeoDNS can steer, but tenancy is an application concern. Do not rely on DNS alone for residency.
Most OS resolvers do, with clamping. Document expected TTL behaviour for long-lived mobile clients.