DNS Failover
DNS failover automatically removes a region from DNS resolution if the container in that region becomes unhealthy. Traffic is redirected to the remaining healthy regions without any manual intervention.
How it works
Bahriya configures health checks against each regional container instance. The health check makes periodic HTTP requests to your container's health check path. If a region fails a defined number of consecutive checks:
- That region's IP is removed from the DNS record.
- Traffic for affected users re-resolves to a healthy region.
- Once the region recovers and passes health checks, its IP is added back automatically.
This is handled at the DNS layer — failover operates independently of your container's internal health checks.
Enabling failover
DNS failover is enabled per container. It works alongside your chosen DNS mode:
- With round-robin — a failing region's IP is removed from the rotation.
- With geo — users whose nearest region is failing are redirected to the next-nearest healthy region.
- With none — if the single region fails, failover can redirect to a fallback region if one is configured.
Failover has no effect if the container runs in only one region — there is nowhere to fail over to.
Recovery time
Recovery time depends on your configured DNS TTL. With a TTL of 60 seconds, clients that have cached the failing IP will try a new resolution within a minute. Longer TTLs mean longer exposure to the failing IP for clients who have already cached it.
If fast failover is important, use a short TTL (60s or 300s) alongside DNS failover.
What failover does not cover
DNS failover operates at the DNS level and does not:
- Prevent in-flight requests to a failing region from failing.
- Guarantee zero dropped connections during a failover event.
- Replace application-level health monitoring or alerting.
For high availability, combine DNS failover with autoscaling (minimum 2 replicas) so that a failing instance within a region is replaced before the regional health check trips.
