Use case
DNS redundancy for SaaS uptime
Your app can run in three regions and still go dark if the one DNS provider that answers for your domain stops answering. A second provider in the NS set removes that single point of failure.
The problem
- Most SaaS teams run one authoritative DNS provider, usually the one bundled with their cloud. It is cheap and it works until the day it does not.
- Adding a second provider by hand means two consoles, two record formats and silent drift: a TXT record updated in one place and not the other, a TTL that differs, a record type one side does not support.
- The usual fix is a DNS pipeline in CI (octoDNS or DNSControl). It works, and someone on the team now owns it.
How RedundantDNS handles it
- You connect the two providers you already use (Route 53 and Cloudflare, for example) with least-privilege credentials.
- You edit records once, in the dashboard, the API, Terraform or MCP. RedundantDNS diffs and applies the change to both providers, then reads them back.
- The NS set at your registrar lists the nameservers of both providers, so any resolver can get an answer from either one.
- Probes query every nameserver directly and alert you (email, webhook, Slack) when a provider stops answering or drifts from the zone.
The result
If one provider has an outage, resolvers retry the other provider’s nameservers and your users get an answer. You find out from an alert, not from your customers.
Plans that fit: Starter or Pro. See pricing or how it works.
Other use cases
Put your zone on two providers
Start with one zone and two providers you already have. Free, no card.