DNS Helper

NS

An NS record names which servers are authoritative for a zone, the servers a resolver ultimately asks to get any other record covered on this site. The Zone file & SOA page's own example already shows a pair of them, sitting near the top of the file alongside the SOA record.

At the apex: almost never something you type

At a domain's own apex, NS records aren't usually something you add in a zone editor, and if your panel does let you edit them there anyway, doing so typically has no effect.

What actually determines a domain's authoritative nameservers is a separate setting at your registrar, not a record inside the zone itself, so that's where you'd change them instead. Walking through that part of a registrar's own interface is outside what this site covers, it varies too much from one registrar to the next, but the takeaway holds regardless: if you want different nameservers, the DNS editor is the wrong place to look.

How many nameservers, and why they can't all be neighbours

In practice, most registries require at least two NS records for a domain, precisely because a single nameserver is a single point of failure. Some registries also cap the number, often somewhere around 13, though that ceiling is registry policy rather than a rule of DNS itself.

Having two names isn't enough on its own, either. Good practice, and something some registries actively require, is that a domain's nameservers sit on genuinely different networks, different subnets, often different data centres or providers entirely, rather than different hostnames that happen to answer from the same rack. Two nameservers sharing one connection or one piece of hardware share exactly the single point of failure that having two in the first place was meant to avoid, the same reasoning as a second MX record that quietly points back at the same one server.

The most literal version of this mistake shows up often in practice: naming two or three nameservers differently, then pointing every one of them at the exact same IP address through their glue records. Registries routinely refuse that outright when a domain is being registered, precisely because it provides no redundancy at all, different names or not, one server going down still takes every one of them with it.

Delegating a subdomain: where NS records are genuinely hand-typed

The case where you will actually add an NS record yourself is delegating part of a domain to a different set of nameservers. Say dev.example.com needs to be managed somewhere else entirely, a different provider, a different team. Adding NS records for dev, pointing at that provider's own nameservers, hands off everything under dev.example.com to them: their zone, their records, looked up independently of the rest of example.com.

Glue records: only needed in one specific case

A glue record only comes up when the nameserver you're pointing at has a name that lives inside the very domain it's authoritative for, ns1.example.com being one of the nameservers for example.com itself, for instance. Looking that name up would normally mean asking example.com's own nameservers, but that's exactly what you're still trying to find, a circular dependency. A glue record breaks the loop: an A or AAAA record for that nameserver's name, published in the parent zone alongside the delegation itself rather than inside your own zone. Your registrar normally manages this for you. If your nameservers are named after a different domain entirely, ns1.other-provider.example rather than something inside example.com, none of this applies, there's no loop to break.

Lame delegation: when a nameserver isn't actually authoritative

A delegation is lame when it points at a nameserver that isn't actually authoritative for the zone. One common way to get there is a mismatch between the two places a domain's nameservers are recorded, which are supposed to say the same thing: the registrar's own delegation (what the parent zone hands out when asked who's authoritative for your domain), and the NS records inside your own zone. When those two lists disagree, some resolvers end up asking a nameserver that either doesn't have the zone at all or has a different idea of what's in it. It doesn't fail cleanly and consistently, which makes it a frustrating one to chase: some visitors get correct answers, others get failures or stale ones, depending on which nameserver they happened to ask and what it happens to know. Worth checking directly if a domain seems inconsistently reachable and the usual TTL and serial explanations elsewhere on this site don't account for it.