Quick answer
An NS (nameserver) record names one authoritative DNS server for a zone. Its RDATA is a single domain name that points at that server (RFC 1035 §3.3.11). A parent zone uses a set of NS records to delegate a child zone to those servers (RFC 1034 §4.2). Publish at least two nameservers so the zone stays resolvable if one server or network fails, and change them at your registrar.
What an NS record looks like
An NS record carries one field of RDATA: the domain name of an authoritative nameserver. A record at the example.com apex looks like this:
example.com. 86400 IN NS ns1.example.com.
Read it as "the zone example.com is served by the nameserver ns1.example.com." A zone normally has several NS records at its apex, one per nameserver:
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.
The RDATA is only a name, never an IP address. A resolver takes that name and looks up its A or AAAA record separately to find an address to query. That extra indirection is what makes glue records necessary in one specific case, covered below.
How delegation works: parent and child
DNS is a tree of zones, and NS records are the links between them. When the .com registry delegates example.com to you, it publishes NS records for example.com inside the .com zone. Those parent-side NS records are the ones a resolver follows on its way down from the root toward your zone: the root refers it to .com, and .com refers it to your nameservers, which then answer for the zone (RFC 1034 §4.2).
Your own zone repeats the same NS records at its apex. So the same nameserver set exists in two places: the parent zone, which holds the delegation, and the child apex, which is authoritative for the zone itself. Both copies should list the same servers. If they drift apart, resolvers can behave inconsistently depending on which copy they cached, and DNS checkers flag the mismatch as a lame delegation.
The parent-side records are the ones that make delegation work, and you do not edit the parent zone directly. You change them through your domain registrar, which relays the update to the registry. Editing the NS records inside your own zone file does nothing to the delegation until the parent set matches.
Publish at least two nameservers
A zone should be served by two or more nameservers, and they should sit on different networks. The reason is availability. If a single nameserver or its network goes offline while it is the only source of truth for the zone, every name under the zone becomes unresolvable, and mail, web, and anything else that depends on the domain stops. Nameservers on diverse networks keep the zone answerable through such an outage. This is why registrars require at least two nameservers before they accept a delegation, and why managed DNS providers hand you several nameserver names spread across separate infrastructure.
Glue records and the circular dependency
A subtle problem appears when a zone's nameserver is a name inside the zone it serves. Suppose example.com is served by ns1.example.com. To reach ns1.example.com, a resolver must query the nameservers for example.com, but the only nameserver is ns1.example.com itself. To find its address, you would have to already know its address.
The parent zone breaks this loop with a glue record. Alongside the delegation NS records, the parent publishes the A and AAAA address of the in-zone nameserver directly (RFC 1034 §4.2.1). The .com servers then return both example.com NS ns1.example.com and ns1.example.com A 203.0.113.10 in the same referral, giving the resolver an address to query without a second lookup.
Glue is needed only when the nameserver name lives under the zone being delegated. If your nameservers are ns1.dnsprovider.net, a name in a different zone, no glue is required, because that name resolves through its own independent delegation. You register glue through your registrar, usually as part of creating a "host record" or "private nameserver" for the in-zone name.
NS and SOA both live at the apex
The apex of every zone carries two mandatory record types: the NS records covered here, and a single SOA record. The SOA holds the zone's administrative parameters, including the primary nameserver, the contact address, the serial number, and the timers that govern zone transfers and negative caching. The NS records list which servers are authoritative. NS answers "who serves this zone," and SOA answers "what are this zone's control values." A zone is not well-formed without both. This differs from a CNAME record, which cannot coexist with other data at the same name; NS and SOA are expected to sit together at the apex.
Checking and changing your nameservers
Query the NS set with dig NS example.com on macOS or Linux, or nslookup -type=NS example.com on Windows. Compare what the parent returns against what your own zone publishes at its apex; the two should match. To change nameservers, log in to your registrar and edit the delegation there, then wait for the parent TTL to expire before assuming resolvers have picked up the new set. For the full set of record types that make up a zone, see DNS record types.