DNS Modes

When a container runs in multiple regions, Bahriya needs to decide how to route traffic to it. DNS modes control this routing strategy for vanity hostnames and custom domains.

None

Mode: none

No multi-region DNS routing. The hostname resolves to a single region only — whichever region is considered the primary.

Use this when:

• Your container runs in only one region.
• You want full control over which region receives traffic.
• You are testing before enabling global routing.

Round-robin

Mode: round-robin

The hostname resolves to the IP addresses of all regions simultaneously. DNS returns all IPs and clients rotate between them on each query (standard DNS round-robin).

my-api.rr.on.bahriya.app → 1.2.3.4 (helsinki-1)
                          → 5.6.7.8 (falkenstein-1)
                          → 9.10.11.12 (virginia-1)

Traffic is distributed roughly equally across all active regions. This provides basic load distribution and redundancy — if one region's IP stops responding, most clients will eventually try another IP.

Use this when:

• You want simple global load distribution.
• Your application is stateless and any region can serve any request.
• You don't need users to be consistently routed to their nearest region.

Geo

Mode: geo

GeoDNS routes users to the nearest region based on where their DNS query originates. A user in Europe resolves the hostname to the European region; a user in Asia resolves it to the Asian region.

my-api.geo.on.bahriya.app → 1.2.3.4 (helsinki-1)      for European users
                           → 9.10.11.12 (virginia-1)   for North American users
                           → 5.6.7.8 (singapore-1)     for Asian users

This minimises latency by ensuring users talk to the geographically closest instance of your container.

Use this when:

• Latency is important to your users.
• You are running in three or more regions.
• Your application is stateless or you handle session affinity at the application layer.

Switching modes

You can change the DNS mode on a running container at any time. The change takes effect after the next deployment cycle and propagates within the configured TTL window.