GeoDNS operations
Route only to nodes that are eligible now.
A routing answer should combine site placement, node state, health, capacity, geography, and policy. “Server responds” is not enough when the customer route or rendered page is wrong.
Eligibility sequence
PlacementIs this site allowed on the POP?
StateIs the POP active rather than planned, drained, or quarantined?
HealthDo service and customer-route checks pass?
CapacityCan the node accept traffic safely?
Health levels
Process health
Service is running and listening.
Transport health
TLS, HTTP, compression, and network connectivity work.
Customer-route health
The actual hostname, route, WAF marker, cache policy, and origin behavior are correct.
Visual/content health
Expected page markers, assets, hashes, and responsive rendering are correct rather than merely returning 200.
TTL tradeoffs
- Short TTLs can make future answer changes visible sooner but increase authoritative query load.
- Resolvers may prefetch, serve stale data, or apply minimum/maximum caching behavior.
- A TTL cannot recall an answer already cached under an older, longer TTL.
- Very short TTLs do not replace connection retry, application failover, or state management.
Safe drain and recovery
- Mark the node ineligible. Stop selecting it for new answers and placement decisions.
- Publish the new routing snapshot. Retain the signed decision and affected routes.
- Allow existing traffic to age out. Account for DNS cache, persistent connections, and sessions.
- Repair and prove. Run service, customer-route, content, WAF, cache, TLS, and origin tests.
- Soak while drained. Require stable checks before reactivation.
- Restore gradually. Re-enable selection and confirm public traffic reaches the intended node.
Evidence to retain
- Incident start and end in UTC.
- Eligibility decision and reason.
- Routes withdrawn or retained.
- Fallback candidates selected.
- Public response headers.
- Customer-route and visual probes.
- Recovery gates and soak duration.
- Final routing snapshot generation.