What an NS record identifies
An NS (name server) record identifies a DNS server by name as a server for a zone. For example, an NS record for example.com might name ns1.example.net. The record contains the server’s hostname, not its IP address. A resolver may need to look up that hostname’s address before it can contact the server.
NS records answer a different question from the records used to reach a website. An A or AAAA record can provide an address for a hostname, while an NS record helps a resolver find the servers that can answer questions about a zone. Likewise, an NS record does not select a mail server; that is the role of an MX record. One zone commonly lists more than one name server so that DNS answers do not depend on a single server.
Delegation: where the parent points
DNS names form a hierarchy. To find an answer for www.example.com, a resolver can follow that hierarchy from the root to the .com zone and then to the example.com zone. The parent zone publishes NS records at a delegation point to indicate which name servers should be consulted for the child zone. In this example, the .com zone can provide a referral naming the servers for example.com.
A referral is a direction to ask another set of servers, not usually the final answer to the original question. Once the resolver reaches a server authoritative for example.com, it can ask for the record it needs. The same pattern can occur farther down the tree: example.com could delegate a subdomain such as lab.example.com by publishing NS records for that name in the example.com zone.
The parent’s delegation is often set through a domain registrar or DNS provider interface, but the interface itself is not a DNS record. The published parent-zone data is what resolvers encounter. If a domain changes DNS providers, updating the new provider’s zone alone may not be enough; the parent delegation must point to the intended name servers.
The zone’s own NS records
An authoritative zone also publishes NS records at its apex—the zone’s top name. For the example.com zone, that means NS records at example.com itself. These records describe the name servers for the zone from within the zone. They are distinct from the delegation NS records published by its parent, even when both sets contain the same server names.
Keeping the parent delegation and the zone’s own NS records aligned helps avoid confusing or inconsistent behavior. If they disagree, a resolver may first be directed to one set of servers and then encounter different information in the child zone. When checking an NS change, it is therefore useful to inspect both sides rather than relying on a single lookup. Also confirm that the named servers actually serve the zone; listing a server in an NS record does not, by itself, make that server authoritative.
A domain may have many hostnames without giving each one its own NS records. Names such as www.example.com are typically answered from the example.com zone. An NS record becomes relevant at a lower name when that part of the hierarchy is being delegated as a separate zone.
How addresses and glue fit into the path
Because an NS record names a server rather than providing its address, a resolver needs a way to locate that server. If example.com is delegated to ns1.example.net, the resolver can look up the address of ns1.example.net through the DNS hierarchy. But if it is delegated to ns1.example.com, looking up that address could appear to require reaching example.com first—the very zone the resolver is trying to find.
To help break that dependency, the parent can supply a glue address record alongside the delegation. Glue gives the resolver an address it can use to contact an in-domain name server. It is supporting address information, not a substitute for the NS record or for the authoritative zone’s own address records. Glue is not needed for every delegation.
When troubleshooting, trace the steps separately: Which NS names does the parent publish? Do those names have reachable addresses, with glue where needed? Do the servers answer authoritatively for the intended zone, and what NS records does that zone publish? This approach helps distinguish a delegation problem from a missing website record or another issue deeper in the zone.
