A web server failure is visible and contained. A DNS failure is neither, and it takes several things that have nothing obvious to do with the website.
What a DNS outage actually breaks
The domain stops resolving, which means it stops existing as far as the internet is concerned.
The website is unreachable: not showing an error, unreachable. Mail cannot even be addressed to the domain, because the records that say where to deliver it cannot be looked up. Certificate renewal fails, because validation requires resolution. Anything identifying itself by hostname stops working.
Compare that with a web server outage, where the domain resolves, visitors get a comprehensible error, mail queues at the sending end and delivers later, and monitoring tells you exactly what is wrong.
Cached records are the only cushion
Resolvers that already have your records keep answering from them until the TTL expires.
So a long TTL is genuine protection: records cached for an hour keep working for up to an hour after your DNS stops. Records with a five-minute TTL vanish within five minutes.
Which is why raising TTLs back up after a migration matters, and why leaving everything at 300 seconds permanently is a resilience cost people do not realise they are paying. Understanding TTL explains the trade.
Two nameservers is not redundancy
Every domain lists at least two nameservers, and people reasonably assume that is the redundancy.
It usually is not. If both are at the same provider, on the same network, they fail together in every scenario that matters; a provider outage, a network problem, an attack on that provider, an account suspension.
Two names is a requirement of the registration, not a guarantee of independence.
What real redundancy looks like
Nameservers at two different providers, on separate networks.
The usual arrangement is a primary that holds the zone and a secondary that copies it automatically, so records are edited in one place and appear in both. Some providers offer the secondary role specifically for this.
Then list nameservers from both providers at the registrar. Resolvers try them in no fixed order, so if one provider is unreachable, queries reach the other.
The cost is usually small. The scenario it covers is total unavailability of everything.
Keep the copies in step
The failure this arrangement introduces: a record changed on one provider and not the other, so some resolvers get the new answer and some the old.
That is worse than either alone, because the symptom is intermittent and depends on which nameserver a visitor's resolver happened to ask.
Automatic transfer between primary and secondary avoids it. Maintaining two by hand does not, and it will drift: check both after any change:
dig @ns1.provider-a.com example.com A +short dig @ns1.provider-b.com example.com A +short
Using dig and nslookup goes over asking each one directly.
Whether you need it
For a small site, probably not. DNS providers are generally reliable, and the outage is unlikely.
It becomes worth having when an hour of total unavailability has a real cost. A store, a service people depend on, anything where email failing to arrive matters. That is the case where the outage is not just downtime but mail that was never delivered and cannot be recovered.
Where your DNS actually is
Worth confirming rather than assuming, because it is frequently not where people think:
dig example.com NS +short
Domains commonly end up with DNS at the registrar, at the host, or at a service added years ago for one feature. Knowing which is a prerequisite for any of this, and for knowing who to contact when it stops answering.
Moving DNS to a third-party provider explains changing it deliberately, and setting up a DNS cluster explains the server-side arrangement when you run the nameservers yourself.
How a secondary actually gets the zone
The copying is a standard mechanism, and knowing which parts have to line up saves most of the setup trouble.
The primary must be told to allow transfers to the secondary's addresses, and to notify it when the zone changes. The secondary must be told where the primary is and which zone to fetch.
The serial number in the zone's SOA record is what triggers a copy: the secondary compares its serial against the primary's and fetches only when the primary's is higher.
dig @ns1.provider-a.com example.com SOA +short dig @ns1.provider-b.com example.com SOA +short
Those two must show the same serial. When they diverge, the secondary is serving stale records, which is the failure this arrangement introduces, and it is silent.
A serial that does not increase
The most common secondary-DNS fault, and it produces a confusing symptom: you edit a record, the primary serves the new value, and the secondary keeps serving the old one indefinitely.
The cause is a zone edited without the serial being incremented. Panel-driven DNS usually handles this; a zone edited by hand, or by a script, frequently does not.
The result is that roughly half of lookups get the old answer, depending on which nameserver a visitor's resolver happened to ask. That is worse than having no secondary at all, because the fault is intermittent and cannot be reproduced reliably. Using dig and nslookup explains asking each nameserver directly, which is how it is found.
Test it by pretending one is down
Redundancy that has never been exercised is a belief.
dig @ns1.provider-a.com example.com A +short dig @ns1.provider-b.com example.com A +short
Both must return the same answer, from a zone that is genuinely current. If the second returns nothing, the transfer is not working and the secondary is decorative, which is the state most secondary setups are actually in, because nobody checked after configuring it.
Repeat this check after any change to the zone, and include it in the annual round. There is more on where it belongs in the yearly maintenance checklist.
The failure a secondary does not cover
Worth being clear about, because it is the more likely scenario.
A secondary protects against your DNS provider becoming unreachable. It does not protect against a wrong record, because the wrong record is copied faithfully to both.
Nor does it help if the registrar account is compromised and the nameserver delegation itself is changed. Both of your nameservers are then simply not being asked.
Those are different problems with different defences: monitoring for the first, account security for the second. Monitoring DNS and detecting unauthorised changes goes into it.