Nameserver Redundancy: Counting Records Is Not The Same As Counting Providers.
All six domains we own run on a single DNS provider. Here is the honest case for and against fixing that, with the check to audit a portfolio.
Short answer: nameserver redundancy is measured in providers, not in NS records. Six nameservers from one company is one provider and one failure domain. Two nameservers from two companies is genuine redundancy. Most domains, including every one of ours, have the first kind.
What our own portfolio looks like
on a major anycast provider is not two servers, though: each of those names answers from hundreds of locations.*
| Domain | NS records | Distinct providers | DNSSEC | CAA |
|---|---|---|---|---|
| protuno.com | 2 | 1 (Cloudflare) | no | none |
| posimyth.com | 2 | 1 (Cloudflare) | no | present |
| theplusaddons.com | 2 | 1 (Cloudflare) | no | none |
| nexterwp.com | 2 | 1 (Cloudflare) | no | none |
| uichemy.com | 2 | 1 (Cloudflare) | no | none |
| wdesignkit.com | 2 | 1 (Cloudflare) | no | none |
That nuance matters, and it is where a lot of DNS advice goes wrong. The thing two anycast nameservers protect you against is not a machine failing. That is already handled. The thing they do not protect you against is the provider itself having a bad day, and every large DNS provider has had at least one.
When that happens, every domain in the table above goes dark at the same moment. Not the websites, which are fine. The names that point at them.
The honest trade
than one zone that is correct, and CDN proxying generally assumes it owns the zone.*
| One provider | Two providers | |
|---|---|---|
| provider-wide outage | whole portfolio offline | resolves from the other |
| setup effort | none | zone transfer or API sync to configure and monitor |
| ongoing risk | none | two zones that disagree is worse than one that is right |
| proxy features | work normally | complicated, CDN proxying usually assumes it owns the zone |
| cost | usually free | a paid tier on at least one side |
Caveat: six domains, all ours, all on one provider. That is not evidence single-provider is common practice generally, it is a disclosure that we have not made the multi-provider trade ourselves, which is the honest starting point for recommending it to anyone else.
For most agency portfolios, a single reputable anycast provider is a defensible choice. Saying otherwise sells work nobody needs.
Multi-provider earns its place when downtime carries a contractual cost: a store, a booking system, anything with an SLA attached. The point is to decide it deliberately and write down which you chose, rather than discovering your answer during an outage.
Confirming the anycast claim rather than repeating it
The claim that two Cloudflare nameservers already answer from many locations is worth checking rather than taking as received wisdom, since it is the entire basis for this post’s argument that record count is the wrong thing to measure.
dig +short chris.ns.cloudflare.com A
dig +short jade.ns.cloudflare.com A172.64.33.85
108.162.193.85
173.245.59.85
173.245.58.167
172.64.32.167
108.162.192.167Each nameserver name resolves to three distinct IP addresses on its own, six total for what the zone lists as two nameservers. That is anycast in miniature: the same hostname routed to different physical infrastructure depending on where the query originates, which is exactly why “two nameservers” understates what is actually answering.
I also checked whether the answer holds up across independent resolver infrastructure, not only whichever resolver happened to be closest to me:
dig +short protuno.com @1.1.1.1
dig +short protuno.com @8.8.8.8
dig +short protuno.com @9.9.9.9Cloudflare’s own resolver, Google’s, and Quad9’s all returned the identical pair of A records for protuno.com. Three independently operated resolver networks, none of them affiliated with each other, agreeing on the same answer is a reasonable practical stand-in for confirming the zone answers consistently rather than depending on which resolver happens to be doing the asking, which is the property this post’s opening claim actually rests on.
Auditing nameserver redundancy across a portfolio
describes your actual failure domain.*
Two related records are worth capturing in the same pass, because you are already there.
DNSSEC. None of ours publish a DS record. DNSSEC signs DNS answers so a resolver can detect tampering. It is genuinely useful and it is genuinely easy to break: a botched key rollover takes the domain off the internet in a way that is hard to diagnose and slow to recover from. Enable it where the registrar and DNS provider handle rotation for you, and leave it alone otherwise.
CAA. One of ours publishes a CAA record, and even that one is incomplete: it has an issuewild entry without a matching issue entry. CAA states which certificate authorities may issue for the domain. It costs one record and it stops a mis-issued certificate from a CA you have never used.
Both are cheap. Neither will show up in any client conversation, which is exactly why they drift, in the same way that an SPF record silently creeps past its lookup limit without anybody editing it badly.
The CAA finding in this post was already out of date
I re-ran the exact lookups this post opens with before expanding it, rather than reuse the original table without checking whether anything had changed since 7 September. Five of the six domains matched exactly: two Cloudflare nameservers, no DS record, no CAA. posimyth.com did not.
dig +short CAA posimyth.com0 issue "pki.goog; cansignhttpexchanges=yes"
0 issue "ssl.com"
0 issue "comodoca.com"
0 issue "digicert.com; cansignhttpexchanges=yes"
0 issue "letsencrypt.org"
0 issuewild "comodoca.com"
0 issuewild "digicert.com; cansignhttpexchanges=yes"
0 issuewild "letsencrypt.org"
0 issuewild "pki.goog; cansignhttpexchanges=yes"
0 issuewild "ssl.com"Ten CAA records, every issuewild entry paired with a matching issue entry across five named certificate authorities. This post’s original table describes exactly the opposite: an issuewild entry with no matching issue entry, described as incomplete. That gap has been closed since this post first went out, and the honest move is to say so plainly rather than leave a stale finding standing because updating it is inconvenient. Whoever manages posimyth.com‘s DNS filled in the missing half of that record at some point in the time since 7 September, which is itself a small, quiet confirmation that the finding was read and acted on rather than published into a void.
The other five domains have not changed, which is worth stating as clearly as the one that has: protuno.com, theplusaddons.com, nexterwp.com, uichemy.com and wdesignkit.com still carry no CAA record at all, still no DNSSEC, still a single provider. Re-checking a finding is only useful when it reports both directions honestly, what moved and what did not, rather than only ever surfacing progress.
What that CAA record does not actually cover
Having a complete CAA record was worth checking against reality rather than treating the fix as finished the moment both issue and issuewild entries existed. I searched certificate transparency logs, the public record every CA is required to publish to, for every certificate ever issued naming posimyth.com or a subdomain of it.
curl -s "https://crt.sh/?q=posimyth.com&output=json" | python3 -c "
import json, sys
for e in json.load(sys.stdin):
print(e['issuer_name'])
" | sort -uAlongside the CAs posimyth.com‘s record actually permits, Google Trust Services and Let’s Encrypt among them, the log also shows certificates issued by ZeroSSL, an authority not named anywhere in the CAA record, as recently as 20 August 2026, for track.posimyth.com:
echo | openssl s_client -servername track.posimyth.com -connect track.posimyth.com:443 \
2>/dev/null | openssl x509 -noout -issuer -datesissuer= /C=AT/O=ZeroSSL GmbH/CN=ZeroSSL ECC DV SSL CA 2
notBefore=Aug 20 2026
notAfter=Nov 18 2026Live, current, not an old certificate lingering in the log. Checking why turned up the actual mechanism: track.posimyth.com is a CNAME pointing at a third-party email-tracking platform’s own domain, not served from POSIMYTH’s own infrastructure at all. Neither track.posimyth.com nor the domain it points to carries its own CAA record, and the CA that issued the certificate evidently did not climb the DNS tree back up to posimyth.com‘s CAA record the way the specification describes, or the third-party platform’s own automation requested the certificate through a path that never checked it.
This is worth understanding as a boundary of what CAA actually protects, not a failure of the record itself. A CAA record stops a certificate authority you did not choose from issuing for names you control when that authority correctly checks it, and enforcement of CAA across a CNAME to a third party’s own infrastructure is one of the genuinely inconsistent corners of how different CAs implement the specification. Any subdomain handed to a SaaS tool through a CNAME, a tracking domain, a custom-domain feature on a marketing platform, a white-labelled support portal, sits at least partly outside the parent zone’s own CAA protection in practice, because the certificate for it may be requested and issued by the third party’s own automation on their own schedule, using whichever CA their systems default to.
The practical takeaway is not to give up on CAA. It is to know which subdomains are actually covered by the protection a CAA record buys, and which are handed to a vendor whose own certificate practices you have not audited and, in most SaaS relationships, cannot control.
Where this sits
DNS is the layer where nothing degrades gracefully. A slow site is annoying; a site whose name does not resolve is simply gone, along with the mail, because the MX records live in the same zone.
It is also the layer with the least monitoring on it. Agencies watch HTTP because that is what uptime tools check. Nobody is watching whether the zone still answers, or whether a record somebody edited last Tuesday is still correct, in the same way nobody notices a scheduled job that stopped.
Protuno’s free audit reads nameserver count and diversity, DNSSEC, CAA and the mail records from the domain alone, which is how the table above was produced. Straight with you as on every post here: Wren, the Care agent that would watch a zone for drift, is built and named but not live yet.
Run the loop across your portfolio. The useful output is not a score, it is a single sentence you can put in a document: these forty domains depend on one company, and that was a choice.
The subdomain question worth adding to that same document
The CAA-and-CNAME gap found while re-checking this post is worth a specific line in that same document, separate from the provider-count sentence above. A portfolio audit that stops at the apex domain’s own DNS settings will not catch a subdomain quietly handed to a SaaS vendor’s custom-domain feature, a support desk, a tracking pixel, a landing-page builder, each of which may provision and renew its own certificates through its own automation, on its own choice of certificate authority, entirely outside whatever CAA policy the parent zone declares.
None of that is necessarily a problem on its own. It is a fact worth having written down rather than discovered while investigating something else, the same argument this post already makes about single-provider DNS: not wrong by default, but worth being a deliberate choice rather than an accident nobody decided on. The audit worth running alongside the nameserver-and-CAA loop above is a simple one: list every CNAME in the zone pointing outside your own infrastructure, and treat each one as a boundary where your own DNS-level protections, CAA included, stop applying.
What a DNS outage actually looks like downstream
The failure mode this post’s single-provider check is trying to prevent, walked through from first principles: why a healthy server behind a dead resolver is indistinguishable from a dead site.
Comments