RFC 2182 says every delegated DNS zone needs multiple servers placed so at least one stays reachable through any likely failure. That means diversity of location and network path. A second DNS provider is one way to get it, but check first whether your current setup already offers real independence.
What the RFC actually says
RFC 2182, an IETF practice document from July 1997, is titled Selection and Operation of Secondary DNS Servers. It opens by noting that many DNS operational problems come from poor choices of secondary servers. Its guidance on selection is direct.
- Servers should be placed so it is likely that at least one is available to all significant parts of the Internet, for any likely failure.
- Placing all servers at the local site is easy to manage but not a good policy. A single link, power or building failure could disconnect every server.
- Secondary servers should be at geographically distant locations and connected through quite diverse paths, so that a failure of one link or one service provider's routing does not make them all unreachable.
- Putting all servers on the same network segment in the same room of the same building almost defeats the purpose of having more than one.
The document is old, and the Internet has changed. The principle, that redundancy helps just when failure modes are independent, still reads clearly.
Translating it to today
| Your setup | What it protects against | What it does not |
|---|---|---|
| Several servers from one provider on different networks | Loss of one server or site | A provider wide failure, account problem or bad change |
| Two providers, zone data synchronized between them | A failure at either provider | Mistakes in the zone data itself, copied to both |
| Self-hosted primary plus provider secondary | Provider loss, if primary is reachable | Loss of your own site |
A provider with many servers can still be one failure domain if it shares a control system, an account, or an update path. That is a question to ask the provider and test, not assume.
A decision guide
- Find your NS records. Who runs each server, and on how many distinct networks?
- Ask what a single account or billing problem with your DNS provider would do. If it takes down every name server, you have one failure domain.
- Decide how long you can tolerate your names not resolving. If the answer is a few minutes for a customer facing service, independence matters more.
- If you add a second provider, decide how zone data stays in sync. Manual copying drifts, so use the transfer mechanism or tooling that both support, and check the result.
- Reduce your TTLs ahead of planned changes, but note that caches hold records for the time you set, so a short TTL helps recovery from your own mistakes more than it helps a resolver that cannot reach any server.
- Test. Resolve your names from outside your network while one provider is blocked in a test environment.
Risks of a second provider
Two providers add work. Features that are specific to one, such as proprietary alias records or traffic steering, may not exist at the other. Changes must reach both. Access to both accounts needs protection, with multi-factor authentication and a break-glass plan. A second provider that nobody tests gives false comfort.
A worked example: reading your own name server list
This example is hypothetical. A company looks up the name servers for its main domain and finds four, all from one provider. It asks the questions below and records the answers.
| Question | Answer found | Concern |
|---|---|---|
| How many name servers? | Four | Good count |
| Do they sit on different networks? | The provider says yes, using several networks | Confirm with the provider's documentation |
| Is there one account that controls them all? | Yes | One account problem affects all four |
| Is there a second provider? | No | No independence at provider level |
| Who can change records? | Three engineers, no multi-factor on one account | Fix access first |
| What is the longest outage we can tolerate for name resolution? | 30 minutes for the app, a day for marketing sites | App domain deserves more care |
The answers point to two different actions. The unprotected account is the easiest risk to remove and probably the most likely cause of trouble, so fix that first. The single provider question is a business decision about the app domain alone.
Step by step: adding a second provider if you decide to
- Choose which zones need it. Often that is the primary application domain, not every marketing domain.
- Check feature compatibility. List the record types and special features you use, such as alias records or traffic steering, and see whether the second provider supports the same behavior.
- Decide how data flows. One approach is a hidden primary you control, with both providers acting as secondaries through zone transfers. Another is pushing the same records to both through automation. Either way, one source of truth should drive both.
- Add the second provider's name servers to the delegation at your registrar, and keep the old ones until you confirm that answers match.
- Compare answers from each provider for every record. Automate the comparison and run it on a schedule.
- Protect both accounts with multi-factor authentication, give each a break-glass plan and note the recovery steps.
- Test failure: block one provider in a test network and confirm resolution continues.
Registrar and registry matter too
Name servers are one part of the chain. Your registrar controls delegation, so access to that account is as important as the DNS provider account. Enable registrar locks where offered and protect the account with strong authentication. Our post on a domain registrar checklist for startups covers the points. If you use DNSSEC, remember that changing providers involves key handling, so plan that step carefully.
Monitoring
Monitor resolution from outside your network, from more than one location, and alert when answers are missing or differ between providers. A check that runs from inside your network may hide an outside problem. Keep the history so that you can see trends and show it in later reviews.
Do not skip the basics
For many small teams the most valuable steps are not a second provider. They are strong access control, change review for DNS edits, backups of the zone data, and a documented way to restore records. Those protect against the commonest problems, which are mistakes and account takeovers.
Try it yourself
Open the continuous monitoring demo and look at how checks run repeatedly and report changes. DNS answers deserve the same treatment: a scheduled comparison that tells you when something differs.
Click through it at your own pace, or open it full screen.
Quick check
Is one provider with many servers enough?
It protects against server and site failures. It does not protect against a failure common to the provider, such as an account issue or a bad global change. Whether that risk is acceptable is your call.
Does a long TTL help in an outage?
Caches may keep serving an answer for the TTL, but just where it was cached. Do not rely on it as a continuity plan.
Does DNSSEC change this decision?
It adds a signing step to plan for. When you use multiple providers, the way keys are handled must be supported by both, so check that before you start and rehearse any change.
Sources
Last reviewed: 19 October 2026.
