NS Records Explained: How DNS Nameservers Work

An NS record identifies a nameserver associated with a DNS zone. The domain's delegation tells recursive resolvers where to ask for authoritative answers, while NS data inside the zone also describes the servers responsible for that zone. NS records do not contain the website's IP address; they point the DNS resolution process toward the servers that can provide records such as A, AAAA, MX, and TXT. Understanding this distinction is useful when a record change made in a dashboard does not appear publicly. The domain may be delegated to a different DNS provider than the one whose settings were edited.

Delegation starts at the parent zone

DNS authority is delegated down the hierarchy. A registry's top-level-domain servers hold information that directs resolvers to a domain's authoritative nameservers. That delegation is generally configured through the registrar or the domain registry interface, while the records inside the domain's zone are managed by the DNS provider. These two control panels serve different roles. Changing an A record at one provider does not change the delegation at the parent; changing nameservers at the registrar can make the old provider's zone irrelevant. A safe migration requires knowing which control plane changes the delegation and which one edits the zone content.

1. A recursive resolver asks the parent zone where the domain is delegated.
2. The parent returns the domain's nameserver set and any required glue data.
3. The resolver queries an authoritative nameserver for the requested record.
4. The answer is returned and may be cached according to its TTL.

Nameserver hostnames can themselves require address records so resolvers can reach them. When a nameserver is inside the domain it serves, parent-zone glue may be required to break a circular dependency. DNS providers usually handle this detail, but it is important during a custom nameserver setup. A typo in a nameserver hostname, missing glue, or incomplete delegation can prevent resolvers from reaching the zone even if the provider's dashboard shows perfectly configured A records. This is why testing only from inside a provider's own control panel can give a false sense of success.

How to use an NS lookup

Query NS data for the domain and compare the returned names with the provider you expect to serve the zone. If they do not match, verify the registrar's delegation settings and check whether a recent migration is still in progress. Querying each authoritative server for a sample record can reveal whether the zone data is consistent. SOA data can provide additional zone-level context, but neither NS nor SOA proves that the website itself is reachable. An NS query establishes where authority is expected to live; application health requires a separate connection test.

When moving nameservers, prepare the new zone before changing delegation. Copy all records, including email and verification records, and compare them on the new authoritative servers. Keep the previous service available during the transition where appropriate, and verify the new delegation from outside the provider account. If mail or a subdomain is omitted, the website's A record can look correct while other services quietly fail. A repeatable checklist and saved record export reduce that risk considerably.

For additional context, see what a nameserver does, recursive versus authoritative resolvers, and the general DNS record reference. Use NS records to answer the authority question first, then inspect the individual record types needed by your service. This clear separation makes it much easier to locate whether the issue lies with delegation, zone content, caching, or the application that eventually receives the connection.

Nameserver answers need a delegation context

An NS lookup is most useful when you understand whether it shows the parent delegation, the zone's own NS set, or a recursive resolver's cached view. Those views are related but can be displayed in different sections of a diagnostic. During a nameserver migration, compare the registrar or parent-zone delegation with the NS records served by the child zone. They should be coordinated according to the provider's instructions. An old server may still answer for a time, but leaving it active should not be confused with the new delegation being complete. If you operate custom authoritative servers, check reachability and glue where required. For provider-managed zones, keep the assigned nameserver list and verify it after any registrar transfer or account move.