--- id: "dns" kind: "glossary-term" title: "DNS" language: "en" category: "DNS and technical foundations" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/dns/" translations: es: "https://tldlog.com/es/glosario/dns/" de: "https://tldlog.com/de/glossar/dns/" fr: "https://tldlog.com/fr/glossaire/dns/" it: "https://tldlog.com/it/glossario/dns/" pt-BR: "https://tldlog.com/pt/glossario/dns/" ru: "https://tldlog.com/ru/glossariy/dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns/" --- # DNS Domain Name System The global directory that turns names people can read, such as example.com, into the numeric addresses computers use. It is organized like a tree. The root zone is at the top, then top-level domains, then the names below them. Without it, domain names would not work. The DNS (Domain Name System) is the internet's directory. Devices are reached by numeric IP addresses (IPv4 or IPv6), handed out separately from domain names, but people use names such as example.com. The DNS links the two, so that a name typed in a browser or used in an email address reaches the right computer. No single organisation holds the whole directory: it is spread across many servers run by many operators, which keep answers locally for a while to speed things up. ## What the DNS is and why the internet needs it The DNS is shaped like a tree. The root zone is at the top. Below it are the top-level domains (TLDs), such as .com or .es, and below those are the names people register. A name can hold several kinds of records: addresses (A records for IPv4, AAAA records for IPv6), but also the names of the servers responsible for it (NS records) and security data for DNSSEC. ## What happens when you type a domain name: a lookup step by step Suppose an app needs the address of `www.example.com`. 1. The app asks the stub resolver, a small piece of DNS software on the device. It passes the question to a recursive resolver, usually run by the internet service provider or by a public DNS service. 2. The recursive resolver first checks its cache. If it already holds the answer and the answer's TTL (time to live) has not run out, it replies at once. 3. If not, it starts at the top. It knows the addresses of the root servers from a built-in list, the root hints. 4. A root server does not know the address of `www.example.com`. It replies with a referral: where to find the servers for .com. 5. A .com server does not know the final answer either. It replies with a referral to the name servers that the holder of example.com chose. 6. One of those name servers is authoritative for example.com. It returns the address in an A or AAAA record. The resolver keeps the answer for as long as its TTL allows and passes it to the device. ## Resolvers and authoritative servers: who asks and who answers Resolvers ask questions on behalf of users. Authoritative servers answer them from the data of the zones they hold, without asking any other server. They are a domain's name servers, listed in its NS records. Some recursive resolvers are public DNS resolvers: services meant to be used by anyone on the internet, instead of the one supplied by the internet provider. The technical term "open resolver" usually means something else: a resolver that answers anyone by mistake because it is badly configured. Because every lookup passes through a resolver, it is also a place where names can be filtered. The DNS standards include error codes for a name blocked by the operator's own policy, blocked at someone else's request, or filtered at the user's request. ## Delegation: how the work is split from the root to your domain The DNS tree is cut into zones. A cut is made where an organisation wants to control part of the tree, change its data on its own and delegate parts of it further down. A parent zone delegates a child zone by publishing NS records that point to the child's name servers. For a domain such as example.com, the chain looks like this: - IANA manages the root zone and records which servers are responsible for each TLD. PTI, an affiliate of ICANN, performs the IANA functions, and IANA charges nothing for these services. - Verisign, as Root Zone Maintainer under an agreement with ICANN, compiles the root zone file as IANA directs, signs it with DNSSEC and sends it to the root server operators. - The root servers answer with referrals to the name servers of each TLD. - The TLD registry publishes in its own zone the NS records of each registered name, plus glue records and DS records where needed. - The name servers chosen by the domain's holder answer for the domain itself. This delegation inside the DNS is different from the delegation of a TLD, which means adding a new top-level domain to the root zone. ## Common errors such as NXDOMAIN and SERVFAIL and what they mean Every DNS answer carries a response code. Two error codes come up often. ### NXDOMAIN NXDOMAIN (code 3, "name error") means that the name does not exist, and that no name below it exists either. Typical reasons are a typing mistake, a domain that is not registered, or a domain whose delegation was removed from its TLD zone. ### SERVFAIL SERVFAIL (code 2, "server failure") means that the lookup could not be completed. It does not say the name is missing, only that no trustworthy answer was obtained. Common causes are: - name servers that are listed for a zone but not set up to serve it; - name servers that do not reply, or network failures on the way; - DNSSEC signatures that fail validation, in which case a validating resolver must return SERVFAIL. A resolver may keep a SERVFAIL answer for five minutes at most. Extended DNS Errors let a server add the reason, such as "DNSSEC Bogus". ### A worked example Suppose the holder of example.com moves the domain to new name servers but has not yet set them up to serve the zone. Resolvers that follow the new delegation may return SERVFAIL until the new servers are configured. ## Who runs the DNS and who pays for it No single organisation runs the DNS. Each layer has its own operators and its own way of paying. - **Root servers.** As of October 2026, 13 named root server identities are run by 12 independent organisations, among them universities, companies and ICANN itself, from more than 2,000 instances around the world. The operators are not paid for this service and fund it themselves. - **TLDs.** Each gTLD registry must run its TLD's DNS to service levels set in its contract with ICANN. As of October 2026, under the base registry agreement approved on 12 March 2026, the DNS service must be available 100% of the time, which requires at least two of the TLD's delegated name servers to answer correctly. A total of 4 hours of DNS downtime in a week is a threshold for an emergency transition of the registry. - **Domains.** The holder chooses the authoritative name servers of the domain, either paying a provider for them or using servers included free with another service. Since 1987 the rules have asked for more than one: RFC 1034 expects anyone taking over a zone to show redundant name server support. - **Resolvers.** Internet service providers and public DNS services run the resolvers that users rely on. ## Sources - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 1034: Domain Names - Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034.txt) - [RFC 8914: Extended DNS Errors](https://www.rfc-editor.org/rfc/rfc8914.txt) - [Root Name Servers (IANA)](https://www.iana.org/domains/root/servers) - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Base Registry Agreement (ICANN), approved 12 March 2026](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-12-03-2026-en.pdf) ## related terms - [root zone](https://tldlog.com/glossary/root-zone/) - [resolver](https://tldlog.com/glossary/resolver/) - [name server](https://tldlog.com/glossary/name-server/) - [TLD](https://tldlog.com/glossary/tld/) - [domain name](https://tldlog.com/glossary/domain-name/)