NS records and provider consistency

NS records name the authoritative nameservers for a zone. They are the only records you can’t query the domain itself to discover — the parent zone (the TLD) has to tell you who owns the answer. Everything else in DNS depends on NS records being correct.

For isidoregroup.com, you’ll typically see two or four NS records, all at the same provider. That uniformity matters more than the count.

What Cathedra checks

DnsHygieneCheck runs two related checks on NS records.

The first is presence. Cathedra calls dns_get_record($domain, DNS_NS). If the result is empty, it returns:

status: error / severity: critical
“No NS records found. DNS resolution for this domain may be broken.”

You won’t see this often on a live engagement. A domain with no NS records doesn’t resolve anywhere — you’d hear about it from the client first. The check exists for the case where the registrar published the wrong delegation or the zone was deleted at the DNS host.

The second check is provider consistency. Cathedra extracts the base domain of each NS host (the last two labels — for ns11.domaincontrol.com., that’s domaincontrol.com). It compares those base domains. If more than one unique base domain appears in the NS set, you get:

status: warning / severity: low
“NS records point to multiple providers ({providers}). This is unusual and may cause inconsistency.”
Recommendation: “Confirm this is intentional (e.g. secondary DNS service).”

When the NS set is uniform, Cathedra returns a clean pass:

status: pass
“{N} NS record(s) found: {list of NS hosts}”

When mixed providers are wrong

Most multi-provider NS sets we encounter in the field are residue from an unfinished migration. The scenario is familiar:

1. Client used to host DNS at GoDaddy.
2. Someone started moving them to Cloudflare or Route53.
3. They added the new provider’s nameservers without removing the old ones.
4. The registrar happily delegates to all four.

Now half the lookups hit GoDaddy’s zone and half hit Cloudflare’s. If the two zones don’t have identical records (and they almost never do), half the clients see the new MX, half see the old MX. The classic symptom: “email works from my laptop but not from my phone.”

Other common causes of unintentional mixing:
– A new staff member added Cloudflare for proxied DNS but didn’t realize the original nameservers were still listed at the registrar.
– A web developer added their own nameserver to point a hostname at a staging site and never removed it.
– An old M&A artifact — the acquired company’s DNS host was never decommissioned.

When mixed providers are intentional

Genuine multi-provider NS configurations exist. The most common is secondary DNS for resilience — primary at one provider, secondary fed by zone transfer or API at another. Large enterprises and high-availability shops run this pattern. Cathedra still warns; that’s correct behavior, because the warning is “confirm this is intentional,” not “this is broken.”

If you confirm with the client that the multi-provider setup is deliberate, document it in IT Glue and note it on the audit report. Don’t try to “fix” the warning by collapsing to a single provider.

Reading the NS check manually

dig isidoregroup.com NS +short
ns11.domaincontrol.com.
ns12.domaincontrol.com.

Both at domaincontrol.com. Cathedra returns pass with no consistency warning.

A mixed example you might see in the field:

dig acme.com NS +short
ns11.domaincontrol.com.
ns12.domaincontrol.com.
sandy.ns.cloudflare.com.
gus.ns.cloudflare.com.

Two base domains: domaincontrol.com and cloudflare.com. Cathedra warns. Your next step is to determine which zone is authoritative for what, by querying each NS directly:

dig @ns11.domaincontrol.com acme.com MX +short
dig @sandy.ns.cloudflare.com acme.com MX +short

If the answers differ, you have your problem. If they match (rare but possible — managed secondary DNS does this), the configuration is intentional.

What the registrar sees vs. what the zone says

A useful detail: the NS records returned by a normal query come from the zone itself — the authoritative server hands them out as part of its own answer. The NS records the registrar publishes at the TLD level (the delegation) are separate. They should match, but they don’t always.

To see the delegation as the world’s recursive resolvers see it, query a TLD nameserver directly or use dig +trace. If the delegation and the zone disagree, the delegation wins — that’s what recursive resolvers follow.

Cheat sheet

Condition	Cathedra status	Severity
No NS records	error	critical
All NS at one provider	pass	—
NS at multiple providers	warning	low

What you should remember

• Cathedra returns error / critical only when no NS records exist — rare on a live domain.
• Multiple NS providers triggers a warning / low with the message “NS records point to multiple providers.” Confirm with the client before assuming it’s broken.
• Migration residue is the most common cause of mixed NS providers. Half the world resolves the old zone, half the new — symptoms are intermittent.
• Query each NS directly with dig @nameserver to see what each one actually serves.
• The delegation at the TLD wins over the zone’s own NS records when they disagree. Use +trace to see the delegation.

Next lesson covers SOA records and the serial number — the field that tells you whether two authoritative servers are in sync.

---

Cathedra alignment: DnsHygieneCheck — NS Records and NS Provider Consistency