--- id: "name-server" kind: "glossary-term" title: "name server" language: "en" category: "DNS and technical foundations" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/name-server/" translations: es: "https://tldlog.com/es/glosario/servidor-nombres/" de: "https://tldlog.com/de/glossar/nameserver/" fr: "https://tldlog.com/fr/glossaire/serveur-noms/" it: "https://tldlog.com/it/glossario/name-server/" pt-BR: "https://tldlog.com/pt/glossario/servidor-nomes/" ru: "https://tldlog.com/ru/glossariy/dns-server/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-fuwuqi/" --- # name server A server that stores DNS records and answers questions about domain names. For a domain to work, the registrar tells the registry which name servers hold its records. Changing a domain's name servers changes where its website and email are found. A name server is the computer that answers when someone asks where a domain's website or email can be found. Every domain is required to have at least two, and the registrar lists them at the registry. If they are missing, wrong or switched off, the domain stops working, even though it is still registered. ## What a name server does for your domain The words "name server" and "DNS server" cover two jobs. Authoritative servers hold a domain's DNS records and answer for it; resolvers ask those questions on behalf of users. RFC 9499 (March 2024), the DNS terminology document, notes that both are often called name servers. Here the term means the authoritative ones. The zone above the domain, held by the registry of its TLD, contains NS records naming the domain's servers. This delegation tells resolvers where to ask. The registrar sends those names to the registry through EPP. A domain with no name servers has the status inactive and does not resolve. RFC 1034 (November 1987) requires every zone to be on at least two servers, so that it survives the failure of one. The SSAC report SAC125 (9 May 2024) notes that registries typically require at least two at registration and on every update. ## Registrar, DNS provider and host: who runs your name servers Three roles are involved, filled by one company or by three: - The registrar records at the registry which name servers the domain uses. - The DNS provider runs those servers and the zone with the domain's records. It can be the registrar, a web host or a specialist. - Web and email hosts run the services the records point to. Changing DNS provider does not change the registrar: only the name servers listed for the domain are replaced. ## How to change name servers, step by step 1. Set up the zone at the new DNS provider first, with every record the domain uses, including website and email, and NS records matching the new name servers. 2. If the domain is signed with DNSSEC, a DS record left pointing to the old keys can make it fail for resolvers that check signatures. Where the old operator does not cooperate, RFC 6781 describes this order: ask for the DS record to be removed, change the name servers, wait until the change has spread through the DNS, then add a DS record for the newly signed zone. The domain is not protected by DNSSEC until then. 3. Check that the domain is not locked against updates: while clientUpdateProhibited or serverUpdateProhibited is set, the registry rejects changes. The registrar lifts clientUpdateProhibited; serverUpdateProhibited (registry lock) can only be removed by the registry, through the registrar. 4. Enter the new name servers at the registrar, which passes them to the registry. List at least two, ideally on separate networks. 5. Keep the old service running for a while: resolvers keep copies of answers, so some visitors reach the old servers for hours or longer. Do not delete the old zone on the same day. Rules, locks and timing depend on the registry and registrar, so check with them before changing a domain that matters. ## Glue records and name servers inside your own domain Take example.com, with name servers ns1.example.com and ns2.example.com. To find ns1.example.com, a resolver would first have to ask the name servers of example.com: the very servers it is looking for. The way out is the glue record: the registry publishes the IP addresses of those servers with the delegation. RFC 9471 (September 2023) makes this glue mandatory in referral answers, and noted then that addresses (A and AAAA records) were the only kind of glue defined. At the registry, each name server is a host object. Because ns1.example.com sits under example.com, the domain must exist first; the registrar then creates the host object with its IP addresses and links the domain to it. Addresses are required only when glue is needed: if example.com used ns1.example.net, the .com registry would need no glue for it. ## Primary and secondary servers, and why redundancy matters The primary server holds the copy of the zone where changes are made. Secondary servers copy it by zone transfer: a full transfer (AXFR) copies the whole zone, an incremental one (IXFR) only what has changed. The DNS UPDATE protocol (RFC 2136), the standard part of dynamic DNS, adds or deletes records without editing the zone by hand. Two servers are the minimum, not the advice: RFC 2182 (July 1997) warns that a zone with only two "is actually running with just one" once one fails, and recommends three for most organisations, with at least one well removed from the others, and four or five for higher reliability. IANA's technical requirements (last revised on 14 November 2024, as of October 2026) apply only to the root zone, .INT and .ARPA, but make a useful checklist: at least two NS records on different IP addresses, servers in at least two topologically separate networks, authoritative answers and no recursive service. ## What goes wrong: lame delegations and forgotten servers "Lame delegation" is used for several faults: a listed server that does not answer, cannot be reached, or answers with an error or without authority. RFC 9499 recommends more specific wording. Either way, lookups slow down or fail. A common cause is a forgotten server: a registrant leaves a DNS provider without changing the NS records, and the domain stays delegated to servers that no longer answer for it, which can open the way to a takeover. A less visible risk: according to SAC125, most registries refuse to delete an expired domain while other domains depend on it, and RFC 5731 says it should not be deleted until its host objects are deleted or renamed. Some registrars have renamed them into another domain. SAC125 calls these sacrificial name servers, unsafe when that other domain can be registered: whoever registers it controls resolution of every domain still using them. As of September 2020, it reports, this had exposed over 500,000 gTLD domains to hijacking risk, and the resolution of over 163,000 had fallen under unauthorized control; SAC125 notes that the extent in ccTLDs is unknown. It recommends a code of conduct for registries and registrars; as of October 2026 no adopted code had been confirmed. Renewing the domains that host your name servers reduces this risk. ## Sources - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 2182: Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [Technical requirements for authoritative name servers (IANA)](https://www.iana.org/help/nameserver-requirements) - [SAC125: SSAC Report on Registrar Nameserver Management](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf) ## related terms - [authoritative server](https://tldlog.com/glossary/authoritative-server/) - [NS record](https://tldlog.com/glossary/ns-record/) - [glue record](https://tldlog.com/glossary/glue-record/) - [DNS](https://tldlog.com/glossary/dns/)