8 min read

Learning Objectives

By the end of this module, you will be able to:

  • Distinguish authoritative-server resilience, which Cloud DNS provides natively through secondary zones, from endpoint failover, which Cloud DNS does not perform because it is not health-aware.
  • Explain why cross-endpoint DNS failover on IONOS is a customer-built pattern (your own health check plus a Cloud DNS API record re-point), given Cloud DNS performs no health checking and there is no managed failover product.
  • Choose a TTL deliberately as the dominant lever on recovery time, and design the fronted tiers to be stateless because DNS steers only new connections.
  • Create a Cloud DNS primary zone and records in the Data Center Designer, and orchestrate a customer-driven, health-checked failover at the API level.

Unit 3.7: DNS and Failover Routing

Introduction

When an entire endpoint, zone, or site is lost, no single IP can move to rescue it, and IONOS sells no managed failover appliance to do the steering for you. The answer sits one layer up, at the name: a DNS record that points clients at a healthy endpoint and is re-pointed when that endpoint stops being healthy. The important architectural truth is that Cloud DNS does not do the health checking or the re-pointing for you. Cloud DNS is not health-aware; it serves whatever record you set. The health check that decides an endpoint is dead, and the API call that re-points the record, are automation you own. That makes DNS-based endpoint failover a customer-built pattern in which Cloud DNS is one (highly available) component, not a native failover product. This unit builds the well-documented foundation, a primary zone and its records, foregrounds Cloud DNS's real strengths, and then treats the failover behaviour honestly: what the platform provides natively and what you orchestrate yourself against the API.

1. Cloud DNS: What It Provides, and Where Failover Actually Lives

Cloud DNS is an anycast, fully managed authoritative DNS service: its zones are served from 14 points of presence across Europe and the USA, and the service carries a 99.995 percent uptime SLA. Anycast matters because every resolver reaches the nearest healthy node automatically, so the DNS plane itself is highly available independently of the endpoints it steers toward. Its native strengths are worth stating plainly, because they are what you actually build on: anycast authoritative service, primary and secondary zones, a TTL you can set as low as 60 seconds, DNSSEC, and reverse DNS.

Two of those strengths are easy to conflate, so separate them cleanly.

Authoritative-server resilience is native: secondary zones. A secondary zone is an AXFR mirror of a primary zone. Its job is disaster recovery for the authoritative name server itself: if the primary name server goes offline, the secondary keeps answering queries with the last transferred records. Secondary zones are served from a distinct nameserver set (nscs.ui-dns.*) and are a genuine, platform-native resilience feature. What they are not is endpoint health failover. A secondary zone keeps serving the same records; it does not monitor whether the endpoint those records point to is alive, and it does not change an answer because a backend went down.

Endpoint failover is not native, because Cloud DNS is not health-aware. Cloud DNS does not monitor endpoint health and does not auto-change records based on health. There is no health-check-failover record type. When people say "DNS failover," what they mean on IONOS is a pattern the customer builds: an external monitor or script runs the health check, and on failure it calls the Cloud DNS API to re-point a low-TTL record at a healthy endpoint. Cloud DNS simply serves whatever record you set. The health-checking-and-re-pointing automation is yours; Cloud DNS provides the anycast, SLA-backed, low-TTL record that makes the pattern fast and reliable once you drive it.

Two properties dictate how you design around that customer-built pattern.

First, DNS steers only new connections. Re-pointing a record changes where future lookups resolve; it does nothing for connections already established against the failed endpoint, and it does nothing for clients still holding a cached answer. The hard consequence is that any tier fronted by DNS failover must be stateless: a client that gets redirected to the secondary endpoint must be able to continue without server-side session affinity, because the platform makes no attempt to carry state across the switch. Session and other state must live in a shared tier (the in-memory cache tier of Module 5), not on the endpoint that just failed.

Second, TTL is the dominant lever on recovery time. The TTL you set on a record is how long resolvers may cache the old answer, so it is effectively a floor on how quickly redirected clients can discover the new endpoint after the record changes. Cloud DNS allows TTLs from 60 seconds to 604800 seconds (7 days). A low TTL shortens the window during which clients keep hitting the dead endpoint, which is what your RTO budget actually pays for; the trade-off is more frequent resolver lookups. For a failover-fronted record, set a low TTL on purpose and treat it as the recovery-time knob it is, not a default you inherited. Note also that nameserver propagation can take up to 48 hours, which concerns delegating a new zone, not the per-record failover step, so plan the delegation well ahead of any cutover.

DCD Implementation Walkthrough

You will create FinCorp's authoritative zone, add the records that resolve its public service, and then arrange customer-orchestrated failover across a two-endpoint pair (for example, the primary-region endpoint and a secondary-region endpoint). Creating the zone and records is a well-documented console path; the health-check-driven re-pointing is treated at the design and API level, because Cloud DNS is not health-aware and exposes no failover-record type that runs its own health monitor. The health check and the re-point are yours to build.

Build goal: Create a zone and its records, then wire a customer-orchestrated failover (external health check plus an API re-point) across a two-endpoint pair.

Prerequisite: You must be a contract administrator, owner, or a user holding the "Access and manage DNS" privilege to create and manage zones and records.

Steps (in the Data Center Designer):

  1. Open Cloud DNS and select Create primary DNS zone.
  2. In the Create Primary Zone window set Enabled/Disabled (leave Enabled), the Name (the domain or subdomain, for example app.fincorp.example), and an optional Description. Click Create zone. (Disabling a zone removes its SOA record and detaches it from the IONOS nameservers, so leave it enabled.)
  3. From the zone-creation acknowledgement, copy the assigned IONOS nameservers (the ns-ic.ui-dns.* set) and configure them at your registrar to delegate the domain. Allow for propagation ahead of any go-live.
  4. Open the zone (Primary Zones, then the zone, or Details & Records) and click Create record.
  5. In the Create Record window set: Enabled, the Name (leaving it empty creates an Apex/zone-root record; * creates a wildcard), the TTL in seconds (the default is 3600, but for a failover-fronted record set a low value, for example 60, as the recovery-time lever), the Type (for example A for the primary endpoint's IPv4), and the Content (the endpoint address). Save.
  6. Add the record(s) for the secondary endpoint so that both target addresses exist as managed records you can switch between.

The failover step (customer-orchestrated; Cloud DNS is not health-aware): Cloud DNS has no failover-record type that runs its own health monitor and flips the target automatically, because the service does not check endpoint health at all. Do not fabricate a console flow that does this. Instead, you orchestrate it: run a health check from outside the DNS service (an external monitor, or a check in your operations tooling) against the primary endpoint, and when it fails, call the Cloud DNS API to update the record's Content to the secondary endpoint. Because every record carries the low TTL set in step 5, redirected clients pick up the new target quickly. A record update is a single authenticated API call against the zone and record UUIDs; the record state moves through Provisioning to Available as the change takes effect. This is the honest shape of "DNS failover" on the platform today: zone and record management are native and well documented, and the health-check-and-re-point automation is yours, built around that API. Cloud DNS serves the record you set; it does not decide when to change it.

Common mistakes:

  • Leaving the default 3600-second TTL on a failover-fronted record. The TTL is your RTO floor; a stale high TTL keeps clients pinned to a dead endpoint long after you switch the record.
  • Assuming Cloud DNS performs the health check or the failover for you. It does not; it is not health-aware. Build the health check and the API re-point yourself rather than assuming a native failover-record type exists.
  • Confusing secondary zones with endpoint failover. Secondary zones are an AXFR mirror for name-server disaster recovery (they keep answering if the primary name server dies); they do not detect a dead endpoint or change a record. Endpoint failover is the customer-orchestrated re-point.
  • Fronting a stateful tier with DNS failover. DNS steers only new connections, so externalise session/state to the shared cache tier or redirected users lose their session.
  • Forgetting nameserver delegation and its up-to-48-hour propagation when standing up a new zone; this is a pre-cutover task, not a failover-time one.

Summary

Cloud DNS is an anycast, SLA-backed authoritative service, and it is a strong component in a failover design, but it is not itself a failover product. It is not health-aware: it serves whatever record you set and never changes an answer on its own. Two things it does provide natively matter here: anycast that keeps the DNS plane highly available, and secondary zones that keep the name server answering if the primary goes offline. Endpoint failover is different and is customer-built: an external health check you run detects a dead endpoint and calls the Cloud DNS API to re-point a low-TTL record at a healthy one. Zone and record management is the well-documented console part; the health check and the re-point are automation you own, made fast by a deliberately low TTL. Because the mechanism steers only new connections, every tier it fronts must be stateless, with session state pushed to a shared tier.

Key Points:

  • Cloud DNS is not health-aware: it performs no endpoint health checking and no automated failover. It serves whatever record you set.
  • Endpoint failover is a customer-built pattern: your own external health check plus a Cloud DNS API record re-point, given there is no managed failover product.
  • Secondary zones are native, but they are authoritative-server disaster recovery (an AXFR mirror that keeps answering if the primary name server dies), not endpoint health failover.
  • TTL is the dominant RTO lever (Cloud DNS allows 60 to 604800 seconds); set it low on failover-fronted records on purpose.
  • DNS steers only new connections, so DNS-fronted tiers must be stateless and externalise session/state to a shared cache.
  • Cloud DNS is anycast across 14 points of presence (Europe and USA) with a 99.995 percent uptime SLA; nameserver delegation can take up to 48 hours and is a pre-cutover task.

Important Terminology:

  • TTL (Time To Live): How long resolvers may cache a record; on a failover record it bounds how quickly redirected clients discover the new endpoint.
  • Apex (zone-root) record: A record at the bare zone name, created by leaving the record name empty.
  • Anycast: Serving the same address from many points of presence so resolvers reach the nearest healthy node, making the DNS plane itself highly available.

Further Reading

  • Unit 3.5, High Availability at the Network Edge, for how DNS failover composes with IP failover and multi-zone placement.
  • Unit 5.5, In-Memory Database (Cache Tier), for the shared state tier that makes DNS-fronted stateless tiers safe.
  • Unit 7.1, Resilience and Business Continuity, where a customer-orchestrated low-TTL DNS failover is wired across a two-zone pair in a DR context.