Global Routing
On this page 6 sections
Global routing controls which public endpoints receive traffic for each origin. Serve an origin across all eligible regions, restrict it to selected regions or load-balancer groups, or keep it behind one shared load balancer. Configure each hostname separately, even when several hostnames share the same DNS zone.
How global routing chooses a destination
For each managed origin, GeoDNS selects the nearest eligible regional endpoint within the origin’s routing selection by geographic distance. It uses the DNS resolver’s location, or the client subnet when the resolver supplies EDNS Client Subnet. This is a geographic decision, not a live measurement of each visitor’s network latency.
For example, an origin with healthy London, Virginia and Sydney endpoints can return different addresses to resolvers in those parts of the world. The map illustrates their approximate coverage; boundaries are not country borders or a guarantee of the endpoint every visitor will use.
Choose the routing scope for an origin
A DNS zone such as example.com contains hostnames such as www.example.com and api.example.com. A QSCS domain groups nodes and origins. Routing choices come from the origin’s QSCS domain and your account; they do not include unrelated clusters.
| Serve this origin from | Behaviour | Use when |
|---|---|---|
| All regions | Use all eligible individual nodes and load-balancer groups in the origin’s QSCS domain. This is the default. | The origin should use the whole cluster’s available geographic coverage. |
| Selected regions or groups | Use only the destinations you select. Failover stays within that selection. | An application should use particular regions, or a control surface should resolve only to its designated load-balancer group. |
A group is one destination. Its member nodes are not listed as separate direct DNS targets. These settings control DNS answers only: they do not change cluster membership, replication, identity permissions or where an origin is configured. Keep application access controls in place.
Configure a load-balancer group
If several nodes share an ALB, another load balancer, or a virtual IP, represent them as one routing endpoint. In Infrastructure, open the relevant QSCS domain, find Load-balancer groups, and choose Add load-balancer group.
- Give the group a recognisable name, such as London application.
- Choose Add nodes, select one or more members from that QSCS domain, then confirm the selection. Group nodes in the same region so their routing location represents the shared endpoint.
- Supply either the load-balancer hostname or one or more public VIP addresses, then choose Save group.
The platform resolves a load-balancer hostname and publishes eligible IP addresses in DNS answers. Grouped nodes use that shared endpoint rather than appearing as separate direct addresses. The group remains eligible while at least one member has healthy, fresh monitoring and the shared endpoint passes HTTPS hostname checks.
Your load balancer remains responsible for distributing connections among its members and excluding failed targets. Spook Systems controls routing between regional endpoints; it does not create or configure the load balancer for you.
Configure an origin’s routing
- Open Control Panel → Infrastructure, open the relevant QSCS domain and open the origin’s settings.
- Find DNS routing → Serve this origin from.
- Choose All regions, or choose Selected regions or groups then use the Region filter (default All) and the Add region or group dropdown. Each choice appears in the selected list underneath. Only regions with available destinations in this origin’s QSCS domain are listed. Create any required load-balancer group first.
- Review the selected list and use Remove to discard a destination. Changing the region filter keeps destinations already selected. Nothing is applied until you choose Save DNS routing; Cancel DNS changes restores the saved selection.
- Choose Save DNS routing. This saves routing separately from the other origin settings; the ordinary Save settings button does not save this selection.
- Follow the status in the dialog or Recent tasks. For an already-managed origin, the platform checks and updates its published policy. For an origin not yet managed, continue below to generate and publish routing from the DNS page.
If the console asks you to migrate DNS first, complete ownership verification and zone import for that hostname’s domain. An unavailable or removed selected destination does not silently switch the origin back to all regions: review the selection and save an available destination. Before removing a group referenced by an origin, change that origin’s selection.
For example, to keep api.example.com behind a London load balancer, create a group containing its London nodes and the load-balancer hostname, then select only that group in the origin’s DNS routing settings. The published addresses come from the load balancer, not the member nodes’ direct IPs. Configure www.example.com separately if it should use all regions. DNS routing does not create an HTTP redirect between these hostnames.
Generate and publish routing
In Control Panel → DNS, select the DNS domain. Complete ownership verification and import its zone first. Routing can be staged before registrar delegation when replacing provider-specific records; complete DNS Delegation after the replacement answers are ready.
- Choose Generate global routing records and policies.
- The progress panel shows the platform reading matching origins, QSCS domains, node addresses, groups and monitoring health, then checking their public HTTPS endpoints.
- Review the proposed changes. Existing A, AAAA or CNAME records at the matched origin names may need replacing with platform-managed routing. The preview identifies these conflicts.
- Choose Publish these routing policies. The platform publishes the reviewed records and checks regional answers and replication to the second nameserver.
Custom records outside the reviewed routing scope are preserved, including unrelated email and verification records. If infrastructure, endpoint addresses or health change during review, generate a fresh preview before publishing.
Regional failover and single-group routing
The platform regularly rechecks monitoring health and public HTTPS endpoints. Unhealthy, stale or unreachable endpoints become ineligible; recovered endpoints can return after repeated successful checks. Stabilisation checks reduce switching caused by a single transient result.
When a region is removed, subsequent DNS answers choose the nearest remaining eligible region within the origin’s selection. Within a shared load-balancer group, one failed member does not remove the whole region while another member and the shared endpoint remain healthy. Co-located independent endpoints can provide a regional standby.
Failover is not instantaneous. Health detection, policy refresh, nameserver replication and DNS caches all affect when clients see a new answer. Generated routing records use a 60-second TTL, but existing connections and client caches may continue using an earlier address.
One selected load-balancer group means one DNS destination. Its member nodes are not separate regional fallbacks. The load balancer handles member failures; there is no other DNS failover destination unless you explicitly select another eligible region or group.
If no healthy verified endpoint remains, the service retains the last published route and displays a warning requiring attention. DNS failover does not replicate your application or database, promote a QSCS master, or guarantee uncached requests can succeed during a backend outage. Configure those protections separately.
Use the routing map to inspect health, published addresses and any selected failover destination. Configure alert recipients in Settings → Notifications. Backend addresses, HTTPS certificates and HTTP redirects remain separate origin settings.