NS Resilience

If every authoritative nameserver for your domain sits behind one network, one outage takes the entire domain offline. RedScore checks how many distinct nameserver hostnames you publish and how widely their IPs are spread across /24 subnets. Two failure modes show up here, and they have different fixes.

Fail: only one (or zero) nameserver

A single nameserver is a single point of failure. If it goes down, your entire domain becomes unresolvable until it comes back; mail bounces, the website disappears, monitoring goes blind. Most public DNS providers will not let you operate a zone with just one NS, so seeing this verdict usually means one of:

• Self-hosted DNS where someone shut down the secondary and never restarted it.
• A migration that left one delegation NS at the registrar by accident.
• An NS record set that was hand-edited and lost entries.

Fix: publish at least two nameservers, ideally three or four. The simplest path is to move authoritative DNS to a managed provider (Cloudflare, AWS Route 53, Google Cloud DNS, NS1, Azure DNS, DNSimple). All of them assign multiple anycast nameservers per zone by default and you do not have to think about resilience again. After publishing the new NS, update the registrar (parent side) and re-scan.

Warn: multiple nameservers, but all in one /24

You have two or more NS hostnames, but their resolved IPs all live in the same /24 subnet. Same subnet usually means same datacenter, same rack, sometimes the same physical switch. A network-level event takes them down together. Common shapes:

• Two self-hosted nameservers running in the same VPC subnet or same availability zone.
• Two NS provided by a small DNS host that runs everything from one facility.
• An older Cloudflare/Route 53 setup that has not been migrated to current anycast assignment.
• NS hostnames where socket.gethostbyname returned no IPv4 (IPv6-only or unresolvable) so the resilience check fell back to whatever IPs it could resolve, which all happened to share a subnet.

Two paths to fix:

• Within one provider: switch to a provider that uses anycast (Cloudflare, Route 53, Google Cloud DNS, NS1, Azure DNS). Each NS hostname they assign resolves to a globally distributed anycast prefix, and the assigned hostnames intentionally live in distinct prefixes.
• Across providers: run secondary DNS at a second provider. Your primary serves the zone via AXFR/IXFR or API push to a secondary at a different network. Your published NS list mixes hostnames from both providers. This survives a complete outage of either provider.

Verify the fix

• Run dig +short NS yourdomain to list your published nameservers.
• For each NS hostname, run dig +short A <ns-hostname> to see the IPv4 it resolves to. Confirm the first three octets differ across the set.
• Re-run the RedScore lookup. Pass requires at least two NS hostnames and two distinct /24 subnets.

Common pitfalls

• Anycast can confuse this metric. Anycast NS publish a single advertised IP that is announced from many networks worldwide. The /24 check does not see that diversity, but the underlying resilience is excellent. If your provider documents anycast and you have two or more NS hostnames in distinct prefixes, treat the /24 number as a floor, not a ceiling.
• IPv6-only nameservers. The check resolves IPv4 only. If a nameserver has no A record, it counts as zero subnets toward this metric even if its AAAA addresses are widely distributed. Publish at least one A-record-backed NS per zone.
• Glue records. When your nameservers live inside your own domain (ns1.yourdomain.tld), the registrar must publish glue A records. Without glue, recursive resolvers cannot reach those nameservers on a cold cache.
• Adding a nameserver in DNS but forgetting to add it at the registrar. RedScore reads NS via recursive lookup, which reflects the in-zone view; the registrar parent-side delegation is checked separately by NS Delegation Consistency.