What are name servers?

What they are#

Name servers are DNS servers that hold the authoritative zone data for a domain and respond to queries about the names within that zone. When a recursive resolver needs to look up example.com, it ultimately reaches the domain's name servers, the servers listed in the domain's NS (Name Server) records, to obtain the definitive answer. Name servers are the foundation of DNS delegation, the mechanism that allows the global DNS hierarchy to scale.

The delegation model#

DNS delegation works through NS records published in the parent zone. When .com needs to tell resolvers where to find data for example.com, it publishes NS records like:

example.com.  NS  ns1.example.com.
example.com.  NS  ns2.example.com.

If the name servers are themselves within the delegated zone (as in this example), the parent zone also includes glue records (A or AAAA records that provide the IP addresses of the name servers). Without glue records, resolvers would face a circular dependency. They need to resolve ns1.example.com to find the name server for example.com, but that resolution itself requires querying the name server for example.com.

The delegated zone repeats these NS records in its own zone file, and may list additional servers not in the parent delegation. The parent zone's NS records control where resolvers initially look; the zone's own NS records are authoritative within the zone.

Authoritative vs. recursive#

Authoritative name servers hold zone data and answer queries for the domains they are responsible for. They do not perform recursive lookups on behalf of clients. Recursive resolvers (sometimes called caching resolvers) accept queries from clients, perform the full resolution chain (root → TLD → authoritative), cache results, and return answers. Some software (like BIND) can operate in both roles, but best practice separates them to reduce attack surface.

NS record security#

NS records are among the highest-impact DNS records from a security perspective. Unauthorized modification of NS records, whether through registrar account compromise, social engineering of the registrar, or exploiting registrar API vulnerabilities, gives the attacker full control over all DNS responses for the domain. This is more severe than modifying individual A or MX records because every record type is affected simultaneously.

Key protective measures include:

• Registrar lock. Prevents unauthorized changes to NS records at the registrar level, typically requiring manual identity verification to unlock
• Registry lock. An additional layer at the registry (e.g., Verisign for .com), requiring out-of-band confirmation before any NS changes propagate
• Multi-factor authentication (MFA). MFA on registrar accounts is a baseline control that prevents credential-based compromise
• DNSSEC. While DNSSEC doesn't prevent NS changes at the registrar, it causes validation failures at resolvers if the attacker's servers don't have the correct signing keys, providing a detection signal

Monitoring NS changes#

Tracking NS record changes for owned domains and domains of interest is one of the most valuable monitoring activities in DNS security. An unexpected NS change on an owned domain is a critical alert, it may indicate an active hijacking. For external domains under investigation, NS changes can reveal shifts in hosting infrastructure, transfers between providers, or attacker preparation of newly registered domains.

Most NS changes are benign (provider migrations, CDN onboarding), so effective monitoring requires context. Correlating NS changes with registrar WHOIS data, A record changes, and certificate issuance provides the signal needed to distinguish routine operations from threats. Comprehensive domain protection programs track NS records as a core data point alongside registration and hosting changes.