Nameserver Lookup queries the authoritative NS records for a domain, resolves each nameserver to its IPv4 and IPv6 addresses, measures end-to-end response latency from multiple regions, infers the DNS provider behind each nameserver, and scores the configuration for redundancy. Detects the single-provider dependency that turned the 2016 Dyn attack, the 2021 Akamai outage, and the 2024 AWS Route 53 incident into multi-hour blackouts for some domains and zero-impact events for others.
Six independent classes of output per NS lookup. The NS list and IP resolution are table stakes; the response-time measurements and the single-provider risk detection are the differentiators that distinguish 'I have nameservers' from 'I have resilient DNS'.
Queries the authoritative nameservers for the zone (not a local resolver cache). Returns the complete NS RRset — typically 2 to 6 nameservers. Detects glue records — A/AAAA records for in-bailiwick nameservers that the parent zone returns alongside the NS delegation.
Resolves every nameserver hostname to both A and AAAA records. Flags IPv4-only configurations (a growing operational risk as IPv6-only paths become more common) and dangling NS records that don't resolve at all.
Measures end-to-end query latency from multiple geographic vantage points to each nameserver. Surfaces nameservers that are fast in one region and slow in another — often a sign of nameservers concentrated in a single AS or missing IP-anycast deployment.
Maps each nameserver back to its operator — Cloudflare, AWS Route 53, GoDaddy, Google Cloud DNS, Azure DNS, Dynect, NS1, DNSimple, deSEC, and 20+ more. Reveals single-provider dependency (all NS at one operator = single point of failure).
Compares NS records as seen by multiple public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, OpenDNS). Inconsistency indicates either a recent delegation change still propagating, or a misconfiguration at the parent zone.
Aggregate score weighing redundancy (multi-provider beats single-provider), latency (under 50ms preferred), reachability (all NS responding), and IPv6 coverage. A healthy production zone scores 80+ — most domains we see are at 50-70.
Nameservers are where the entire domain resolves. If they go down, the domain goes down — DNS caching delays the blast radius but doesn't eliminate it. Yet most teams pick nameservers once at domain-registration time and never think about them again. Five reasons that's a problem in 2026:
An NS lookup is more than a single query — it's a walk down the DNS hierarchy from the root through the TLD to the authoritative zone. We do the same walk and surface what we find at each level.
'Nameserver' is overloaded. In any given DNS flow there are three different kinds of nameserver doing different jobs. Knowing which is which clears up most confusion:
Single-provider DNS is the single most preventable infrastructure outage. Every major DNS provider has had a multi-hour incident in the last five years. Multi-provider DNS makes those incidents invisible to your users. The tradeoff is operational complexity — but the complexity is manageable, and the failure mode without it isn't.
Every field — NS list, IP resolution, latency measurements, provider inference, health score — is available as JSON. Useful for change validation after a registrar update, monitoring for delegation drift, and continuous DNS-health observability.
curl 'https://api.domainscan.in/v1/domain/ns?domain=cloudflare.com'const res = await fetch(
'https://api.domainscan.in/v1/domain/ns?domain=cloudflare.com'
);
const ns = await res.json();
console.log(ns.nameservers.length); // 4
ns.nameservers.forEach(n => {
console.log(n.host, '@', n.ipv4, '·', n.provider, '·', n.responseMs + 'ms');
});
// Alert if single-provider
const providers = new Set(ns.nameservers.map(n => n.provider));
if (providers.size === 1) {
console.warn(`Single-provider DNS: ${[...providers][0]} — consider adding a secondary`);
}
// Alert if any NS is slow
ns.nameservers
.filter(n => n.responseMs > 100)
.forEach(n => console.warn(`Slow NS: ${n.host} (${n.responseMs}ms)`));{
"domain": "cloudflare.com",
"nameservers": [
{
"host": "ns3.cloudflare.com",
"ipv4": ["162.159.0.33"],
"ipv6": ["2400:cb00:2049:1::a29f:21"],
"provider": "Cloudflare",
"responseMs": 12,
"reachable": true
}
],
"summary": {
"count": 4,
"providers": ["Cloudflare"],
"singleProvider": true,
"ipv4Coverage": 1.0,
"ipv6Coverage": 1.0,
"medianResponseMs": 14,
"healthScore": 85
},
"AiAnalysis": {
"issues": [
{
"severity": "warning",
"title": "Single-provider DNS",
"description": "All nameservers operated by Cloudflare",
"recommendation": "Add a secondary DNS provider for resilience against provider outages"
}
]
}
}Six patterns we see most often:
Just moved DNS providers? Verify the new NS records are live at the registrar, the new provider is actually serving authoritative responses, and the old provider has been removed from delegation. Run this immediately after the change and again 24 hours later.
Audit your entire domain portfolio for single-provider DNS. Most companies discover that 80%+ of their domains are at one provider — usually the registrar's default. Multi-provider conversion is operationally cheap and outage-prevention significant.
Acquiring a company? Their DNS architecture is a leading indicator of operational maturity. All NS at GoDaddy's defaults? Expect to spend weeks consolidating to a real DNS platform post-close.
First-byte latency is higher than expected from one region. NS lookup measures per-region nameserver response time — if your NS is 250ms from Singapore and you have Singaporean users, that's part of why.
Cron the API against your domains. Alert when the NS set changes unexpectedly — that's either a successful migration you weren't told about or a registrar hijack. Both worth knowing.
Suspicious domain impersonating yours? Check its nameservers. Cheap-bulletproof-hoster NS patterns (Namecheap defaults, Hostinger DNS, certain Russian providers) are a strong signal of low-budget phishing infrastructure.