DNS Delegation & Global Routing

Spook Systems DNS connects your domain names to the QSCS nodes serving your origins. Delegate your DNS zone to Spook Systems, review the routing plan, and publish it to direct new connections towards healthy regions.

This changes who answers DNS queries for the domain. Your registrar continues to manage domain registration and renewal; your application and email services stay where you host them.

Before you start

• Configure your origins and their nodes in Control Panel → Infrastructure. A DNS domain such as example.com is different from a QSCS domain, which groups nodes and origins.
• Make sure eligible nodes have public addresses, fresh platform monitoring health, and working HTTPS for each origin hostname. A load-balancer endpoint can terminate HTTPS for a group of nodes.
• Have access to the domain’s registrar and its current DNS provider. Export the complete zone in BIND format, including email, verification, and custom records.
• Review provider-specific aliases and routing policies before import. They need equivalent portable DNS records; a provider-specific alias is not an ordinary CNAME.

Keep the old zone available throughout the transition. Importing and checking the new zone before changing nameservers keeps existing records available while delegation propagates.

Group nodes behind a load balancer

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.

1. Give the group a recognisable name, such as London application.
2. Select its member nodes from that QSCS domain. Group nodes in the same region so their routing location represents the shared endpoint.
3. Supply either the load-balancer hostname or one or more public VIP addresses, then save the 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.

Select the domain and verify ownership

1. Open Control Panel → DNS and choose Migrate a domain (or Migrate another domain).
2. Select a configured origin from the dropdown. Origins already covered by a DNS zone in your account are omitted. Use Add new to open origin setup if the required origin is missing.
3. Check Domain to migrate. For www.example.co.uk, this will normally be the registrar-managed domain example.co.uk, not the individual hostname.
4. Choose Start migration. At your current DNS provider, create the TXT verification record shown in the console, with the exact name and value supplied.
5. Choose Check delegation. At this stage it checks ownership and unlocks Import current zone.

Use Import current zone to upload the complete BIND zone file. The service validates it, creates the zone on both nameservers, and replaces the apex SOA and nameserver records with those managed by Spook Systems. Review the imported records before proceeding.

Change nameservers at your registrar

In your registrar’s nameserver settings, replace the current nameservers with both of these:

Use the registrar’s delegation settings. Adding NS records in your old zone alone does not change the parent domain’s delegation. You do not need to register your own nameservers or create glue records for these Spook Systems nameservers.

If the old provider uses DNSSEC, remove its DS record at the registrar before switching to the currently unsigned Spook Systems zone, allowing the previous DS record to expire from caches. Leaving the old DS record in place can cause validating resolvers to reject DNS answers.

Return to DNS and choose Check delegation. The platform checks the parent nameservers and authoritative service. Continue when the domain shows Delegated. Registrar changes and cached delegations can take time to become visible.

Generate and review global routing

1. Choose Generate global routing records and policies.
2. The progress panel shows the platform reading matching origins, QSCS domains, node addresses, groups and monitoring health, then checking their public HTTPS endpoints.
3. 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.
4. 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.

What global routing does

For each managed origin, GeoDNS selects the nearest eligible regional endpoint 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.

How regional failover works

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 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.

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.

Next: Manage DNS zones and read the routing map. For application routes and cluster roles, see Configuring Origins and Choosing the Master.