UltraDNS Backup Method Enhancements for SiteBacker and Traffic Controller
When DNS traffic management is operating normally, failure handling remains largely invisible. The real complexity emerges during total failure scenarios, when all monitored endpoints appear unhealthy and the system must decide how to respond.
Historically, SiteBacker (SB) and Traffic Controller (TC) relied on a combination of probe status, priority ordering, and the presence (or absence) of all-fail records to determine behavior during these scenarios. While flexible, this approach made total-failure behavior harder to reason about and more difficult to explain operationally.
To address this, UltraDNS introduces an explicit Backup Method configuration that defines deterministic, validated behavior when all probes fail.
This post walks through the mechanics, constraints, and operational impact of each Backup Method, with concrete examples and a decision table for quick reference.
What Is a Total Failure Scenario?
A pool enters a total failure condition when:
• All numbered priority records have failing probes
• No healthy record remains eligible for normal serving
At that point, UltraDNS must decide whether to:
• Return no answer
• Serve a fallback record
• Continue serving traffic despite probe failures
That decision is now governed explicitly by Backup Method.
Backup Method Overview
Backup Method is a pool-level policy that defines behavior when all numbered priority records fail health checks.
Valid values are:
• FAIL CLOSED
• BACKUP RESPONSE
• FAIL OPEN
Each option has strict configuration rules enforced by the API and UI to prevent ambiguous or unsafe behavior.
Detailed API and configuration updates are documented here:
https://docs.ultradns.com/Content/REST%20API/Content/REST%20API/News%20and%20Updates.htm
FAIL CLOSED – Correctness First
Behavior
When all numbered priorities fail, UltraDNS returns no DNS answer.
• No A/AAAA records are returned
• Traffic is not routed to potentially unhealthy endpoints
Example
Pool configuration:
1.1.1.1 – Priority 1 – Probe FAIL
2.2.2.2 – Priority 2 – Probe FAIL
Backup Method: FAIL CLOSED
Result:
DNS response returns no answer.
Notes
FAIL CLOSED prioritizes correctness over availability. This is the default behavior for pools without an all-fail record.
If an all-fail record exists, the system automatically applies BACKUP RESPONSE to preserve existing behavior.
BACKUP RESPONSE – Explicit Fallback via All-Fail Records
Behavior
BACKUP RESPONSE activates a configured all-fail record once all numbered priorities fail.
Configuration rules
• An all-fail record is required
• API and UI validation fails if BACKUP RESPONSE is selected without one
Example (Valid)
Pool configuration:
1.1.1.1 – Priority 1 – Probe FAIL
2.2.2.2 – Priority 2 – Probe FAIL
3.3.3.3 – Priority ALL – Probe N/A
Backup Method: BACKUP RESPONSE
Result:
DNS response returns 3.3.3.3
Notes
BACKUP RESPONSE preserves long-standing all-fail semantics while making fallback behavior explicit and validated.
FAIL OPEN – Availability First
Behavior
FAIL OPEN prioritizes traffic continuity when probes fail.
When all probes fail:
• Probe status is temporarily ignored
• Records are served based on pool configuration (priority, max-active, max-serve)
• All-fail records are not allowed
FAIL OPEN is temporary and automatically exits once probes recover.
Example
Pool configuration:
1.1.1.1 – Priority 1 – Probe FAIL
2.2.2.2 – Priority 2 – Probe FAIL
Backup Method: FAIL OPEN
Result:
DNS response returns 1.1.1.1
If multiple records are allowed, both records may be returned.
Notes
FAIL OPEN is designed for environments where probes may be noisy or unreliable and availability is preferred over strict correctness.
Default Behavior for Existing Pools
To avoid breaking changes:
• Pools with all-fail records default to BACKUP RESPONSE
• Pools without all-fail records default to FAIL CLOSED
No action is required unless behavior needs to be changed. The selected Backup Method is visible in the UI.
Why This Matters
Backup Method enhancements provide:
• Explicit intent instead of inferred behavior
• Strong validation to prevent unsafe configurations
• Predictable incident behavior for operators and Support
• Clear separation between correctness-first and availability-first strategies
In short, Backup Method turns failure handling into a deliberate, observable choice rather than an emergent side effect.
Learn More
For detailed API usage, validation rules, and release notes, visit:
https://docs.ultradns.com/Content/REST%20API/Content/REST%20API/News%20and%20Updates.htm
Questions or edge cases? Join the discussion in the UltraDNS Community.