WebBuilding

Foundations

DNS

Summary

The Domain Name System (DNS) is the Internet's distributed directory that turns names such as example.com into the numeric IP addresses computers use, and also says where a domain's email should go. Paul Mockapetris designed it at USC's Information Sciences Institute in 1983 to replace a single shared host file, HOSTS.TXT, and published it as RFC 882 and RFC 883 that November. RFC 1034 and RFC 1035, from November 1987, are still its core standard.

Web Building Encyclopedia · Foundations · Last reviewed October 22, 2026 · 10 min read

What DNS does

The Domain Name System (DNS) is the Internet’s directory of names. It turns a name people can remember, such as a website’s domain name, into the numeric IP address that computers use to find each other. It also stores other facts about a name, such as which servers accept its email.12

No single computer holds the whole directory. The database is split into zones, and each zone is run by whoever controls that part of the name. The standard requires every zone to be available from at least two servers, so one failure does not take a name offline.1

Names form a tree. Each part between the dots is a label, read from right to left: in www.example.com, com sits under the unnamed root of the tree, example sits under com, and www sits under example. A label can be up to 63 octets (bytes) long and a full name up to 255 octets.12 DNS messages travel on port 53, over both UDP and TCP, the Internet’s two basic ways of sending data.2

Many companies run DNS for websites. As of October 22, 2026, W3Techs finds Cloudflare acting as the DNS provider for 18.9% of all websites it surveys, followed by GoDaddy Group at 9.9% and Hostinger at 4.6%.3

Before DNS: one file for the whole network

On the early ARPANET, the research network that grew into the Internet, every computer learned the names of every other computer from a single list. In January 1974, RFC 608 by M. D. Kudlick of SRI agreed to a suggestion from Peter Deutsch that the Network Information Center (NIC) keep an online text file listing each host’s name, address and attributes. The NIC would regenerate it weekly or as needed, and other sites would fetch it over FTP, the file transfer protocol. The file was called HOSTS.TXT.4

By October 1985, RFC 952, written by K. Harrenstien, M. Stahl and Elizabeth Feinler of SRI, described the official host table. Anyone could download NETINFO:HOSTS.TXT from the SRI-NIC computer by anonymous FTP. Host names could be up to 24 characters of letters, digits, hyphens and periods.5

The single file did not scale. Paul Mockapetris wrote in 1983 that the size of the table, and especially how often it changed, were “near the limit of manageability.”6 Local sites had to wait for the NIC to edit HOSTS.TXT before their changes reached the rest of the network.1 USC’s report on ISI’s 20th-anniversary event for DNS cites Joseph Touch, director of ISI’s Postel Center, on the SRI file: edited biweekly, it was becoming too large and too often out of date.7

Distribution cost was the deeper problem. As the number of hosts grew, the file got bigger, changed more often and was copied by more machines, so the total cost rose much faster than the host count itself.8

Paul Mockapetris and the 1983 design

Jon Postel asked Paul Mockapetris, a colleague at the University of Southern California’s Information Sciences Institute (ISI), to create a distributed index of the Internet, then a community of only a few thousand computers.7 The Internet Hall of Fame credits Mockapetris with inventing DNS in 1983 and describes his proposal as “a distributed and dynamic naming system.”9 According to USC, the system was first tested on June 23, 1983.7

Mockapetris published the design in November 1983 as two documents: RFC 882, on concepts and facilities, and RFC 883, on implementation and specification.610 RFCs (Requests for Comments) are the numbered documents in which Internet protocols are written down. RFC 883 called its message formats preliminary.10

In October 1984, RFC 920 by Postel and J. Reynolds of ISI named the first top-level domains: ARPA (marked as temporary), GOV, EDU, COM, MIL and ORG, plus two-letter country codes taken from the ISO 3166 standard. At that point, it noted, no country domains had been set up.11

Two programs did the early work. A 1988 paper by Mockapetris and Kevin Dunlap reports that the root, the top of the tree, was then served by three TOPS-20 machines running software called JEEVES and four UNIX machines running BIND, the Berkeley Internet Name Domain server. The University of California, Berkeley began installing machines that depended on DNS in the spring of 1985. The paper counted about 5,500 host names in HOSTS.TXT at a time when more than 20,000 could be found through DNS.8

In November 1987, RFC 1034 and RFC 1035 replaced the 1983 documents.1 Together they form STD 13, the Internet Standard for domain names.12 Later RFCs have added to them and clarified them, for example RFC 2181 in July 1997, but these two remain the core specification.13

How a lookup works

Three kinds of software take part in most lookups:

  • Stub resolver. The small DNS client inside your computer or phone. It cannot do a full lookup itself, so it hands the question to a recursive resolver.14
  • Recursive resolver. A server, often run by your Internet provider, your employer or a public DNS service, that chases the answer on your behalf and usually keeps a copy (a cache) of what it learns.14
  • Authoritative server. A server that knows the contents of a zone from its own data, rather than from a cache.14

When a browser needs the address for www.example.com and the recursive resolver has no saved copy, the lookup runs down the tree:

  1. The resolver asks a root server. The root server does not know the answer, so it sends a referral: a pointer to servers closer to the name, in this case the servers for com.1
  2. The resolver asks a com server, which refers it to the name servers listed for example.com.1
  3. The resolver asks one of those authoritative servers, gets the address, saves it for as long as the record allows and passes it back to the browser.1

A resolver must know at least one root server address before it can start. It usually reads them from a root hints file, and the act of loading that list is called priming.14 The root zone names 13 root server authorities, a.root-servers.net to m.root-servers.net, but each is run as many machines; IANA describes them as a network of hundreds of servers in many countries.15 As of October 22, 2026, root-servers.org counts 12 independent operating organizations and 2,049 working root server instances.16 Operators include Verisign (which runs both A and J), USC’s Information Sciences Institute, NASA, the US Army Research Lab, Netnod, RIPE NCC, ICANN and the WIDE Project.15

The root servers publish the root zone; they do not decide what goes in it. The Internet Assigned Numbers Authority (IANA) assigns the managers of top-level domains and records their technical delegation data in the root zone.17 ICANN, formed in 1998, coordinates the Internet’s unique identifiers, including its naming system.18

Records a site owner meets

Each fact in DNS is a resource record: a name, a type, a time to live and a value.2 RFC 1035 alone defined 16 record types.2 The table lists six that site owners commonly meet.

TypeWhat it holdsTypical useDefined in
AAn IPv4 addressPoints the domain at a web serverRFC 1035, 19872
AAAAA 128-bit IPv6 addressThe same job for IPv6RFC 3596, 200319
CNAMEThe canonical name an alias points toPointing www at a website builder’s host nameRFC 1035, 19872
MXA mail server and a preference numberTelling other servers where to deliver your emailRFC 1035, 1987; RFC 974, 1986220
TXTFree text stringsProving ownership, email authenticationRFC 1035, 19872
NSThe authoritative name servers for a zoneChoosing which company answers for your domainRFC 1035, 19872

Cloudflare’s documentation says that at Cloudflare, TXT records are most often used to prove ownership of a domain before an SSL/TLS certificate is issued, and that a CAA record can limit which certificate authorities may issue certificates for a domain at all.21 For MX records, the lowest preference number is tried first.20

CNAME records carry a rule that trips up many owners. RFC 1034 says that “if a CNAME RR is present at a node, no other data should be present,” and RFC 2181 repeats the rule.113 The top of a zone, called the apex (the bare example.com), must hold NS and SOA records, so a standard CNAME cannot sit there.114 Some DNS providers work around this: Cloudflare’s CNAME flattening looks up the target itself and answers with an IP address instead of a CNAME.22

TTL and propagation

The time to live (TTL) is the number of seconds a resolver may keep a copy of a record before asking again. A TTL of zero forbids caching.1 The maximum allowed value is 2,147,483,647 seconds.13

RFC 1034 suggested TTLs measured in days for a typical host, and advised lowering a TTL before a change that can be planned, then raising it again afterward.1 The 1988 paper by Mockapetris and Dunlap recommended two days for host names and noted that administrators often chose short TTLs even for data that rarely changed.8 Today, Cloudflare’s automatic TTL is 300 seconds, and its non-Enterprise plans allow values from 60 seconds to one day for records that are not proxied.23

“Propagation” is the name hosting guides give to the wait after a change. Nothing is pushed out to the world: old copies in resolver and device caches simply expire one by one, each when its TTL runs out.1 Namecheap’s guide says the delay depends on the TTL, the visitor’s Internet provider and location.24 Guides disagree on how long a nameserver change can take. Cloudflare tells customers to wait up to 24 hours for the registrar to update nameservers, while Namecheap says up to 24 to 48 hours in its text and up to 72 hours in a heading.2524

Securing and encrypting DNS

The original DNS had no way to prove an answer was genuine. On July 8, 2008, the CERT Coordination Center warned that many DNS programs were open to cache poisoning: an attacker could slip forged data into a resolver’s cache and send its users to the wrong servers. CERT credited Dan Kaminsky of IOActive with showing how practical the attack was. The main mitigation was to randomize the network ports that resolvers send queries from, but ISC and NLnet Labs stated that only DNSSEC fully prevents this kind of attack.26

DNSSEC (DNS Security Extensions) was specified in RFC 4033 and its companion documents in March 2005. It adds digital signatures that let a resolver check that data came from the zone’s owner and was not changed on the way. It defines new record types, including RRSIG (a signature), DNSKEY (a public key), DS (a link from a parent zone to a child zone’s key) and NSEC (proof that a name does not exist). The RFC states plainly that DNSSEC does not provide confidentiality and does not protect against denial-of-service attacks.27

The root zone was signed in production on July 15, 2010, at 20:50 UTC.28 On October 11, 2018, ICANN replaced the root’s key-signing key, the cryptographic key that anchors DNSSEC at the top of the tree, for the first time. The original key, known as KSK 2010, had been in use since 2010.29

Encryption is a separate job. DNSSEC signs answers but leaves them readable, so anyone on the network path can see which names you look up. Two standards encrypt the queries themselves:

  • DNS over TLS (DoT). RFC 7858, published in May 2016, wraps DNS in Transport Layer Security on port 853 “to provide privacy for DNS.”30
  • DNS over HTTPS (DoH). RFC 8484, published in October 2018 by Paul Hoffman of ICANN and Patrick McManus of Mozilla, sends DNS queries and answers inside HTTPS. Its stated goals include stopping devices on the network path from interfering with DNS.31

Browsers adopted DoH first. On February 25, 2020, Mozilla began turning on DoH by default for US users of Firefox, with Cloudflare as the default provider and NextDNS as an option.32 On May 19, 2020, Google announced that Chrome 83 had started rolling out Secure DNS, a feature built on DoH.33

DNS and email

MX records tell sending servers where to deliver a domain’s mail.20 Three further standards, all published as TXT records, help receiving servers decide whether a message that claims to come from a domain is real:

  • SPF (Sender Policy Framework, RFC 7208, April 2014) lists the servers allowed to send mail for a domain. A domain must publish only one SPF record, and a check may use no more than 10 terms that need DNS lookups, such as include; breaking either rule produces an error result.34
  • DKIM (DomainKeys Identified Mail, RFC 6376, September 2011) adds a cryptographic signature to each message. Receivers check it against a public key published at a name such as selector._domainkey.example.com.35
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what the domain owner wants done with mail that fails these checks and where to send reports. It first appeared as RFC 7489 in March 2015, an informational document.36 RFC 9989, published in May 2026 on the Standards Track, replaced it. The policy sits at _dmarc.example.com, with the values none, quarantine or reject.37

Timeline

  1. RFC 9989 replaces RFC 7489 and puts DMARC on the Standards Track37
  2. Google announces that Chrome 83 has begun rolling out Secure DNS, built on DoH33
  3. Firefox begins turning on DNS over HTTPS by default for US users32
  4. ICANN changes the root zone's DNSSEC key-signing key for the first time29
  5. RFC 8484 defines DNS over HTTPS (DoH)31
  6. RFC 7858 defines DNS over TLS on port 85330
  7. The DNS root zone is signed with DNSSEC in production28
  8. CERT/CC warns that many DNS programs are open to cache poisoning26
  9. RFC 4033 and its companions define DNSSEC27
  10. RFC 1034 and RFC 1035 replace the 1983 specification and become the core DNS standard1
  11. RFC 920 names the first top-level domains, including COM, EDU, GOV, MIL and ORG11
  12. Paul Mockapetris publishes RFC 882 and RFC 8836
  13. DNS is first tested at USC's Information Sciences Institute7
  14. RFC 608 proposes an online host names file kept by the Network Information Center4

What it means for your website

If you use a hosted builder such as Squarespace or Wix and bought the domain there, the builder may manage DNS for you. Once you own a domain at a separate registrar, or move hosts, DNS becomes your job, and most problems come from a few avoidable mistakes.

  • Know where your DNS lives. The NS records set at your domain registrar decide which company’s servers answer for your domain.1 That company may be your registrar, your host or a separate provider such as Cloudflare. Our DNS glossary entry gives the short version.
  • Lower the TTL before a move. Cut the TTL on your A and CNAME records (300 seconds is a common choice) at least one full old TTL before you switch, so caches drop the old address quickly.124 Keep the old host running until the change has spread.
  • Copy every record before changing nameservers. New DNS hosts start with only the records you give them. A missing MX record stops incoming email, and a missing TXT record can undo SPF or a verification. Cloudflare warns that activating a domain without the correct records can leave visitors with DNS_PROBE_FINISHED_NXDOMAIN errors, the browser message for a name that does not exist.25
  • Turn off DNSSEC first. If DNSSEC is on at your registrar, switch it off before changing nameservers, then set it up again with the new provider.25
  • Plan the bare domain. A CNAME cannot sit at example.com itself, so use an A record there, or a provider feature such as CNAME flattening, and redirect one version to the other.122
  • Set up SPF, DKIM and DMARC. Publish one SPF record, the DKIM keys your email provider gives you, and a DMARC record. RFC 9989 describes p=none as the setting for an owner who is monitoring and receiving reports; quarantine and reject ask receivers to treat failing mail as suspect.3437

Our guide to moving your website walks through a host change step by step, and websites and email covers email at your own domain.

See also

References

  1. RFC 1034: Domain Names, Concepts and Facilities. P. Mockapetris, USC Information Sciences Institute, RFC Editor. 1987-11. accessed October 22, 2026.
  2. RFC 1035: Domain Names, Implementation and Specification. P. Mockapetris, USC Information Sciences Institute, RFC Editor. 1987-11. accessed October 22, 2026.
  3. Usage statistics of DNS server providers for websites. W3Techs. 2026-10-22. accessed October 22, 2026.
  4. RFC 608: Host Names On-Line. M. D. Kudlick, SRI-ARC, RFC Editor. 1974-01-10. accessed October 22, 2026.
  5. RFC 952: DoD Internet Host Table Specification. K. Harrenstien, M. Stahl and E. Feinler, SRI, RFC Editor. 1985-10. accessed October 22, 2026.
  6. RFC 882: Domain Names, Concepts and Facilities. P. Mockapetris, USC Information Sciences Institute, RFC Editor. 1983-11. accessed October 22, 2026.
  7. ISI Marks 20th Anniversary of Domain Name System. USC Viterbi School of Engineering. 2003-06-26. accessed October 22, 2026.
  8. Development of the Domain Name System. Paul V. Mockapetris and Kevin J. Dunlap, Proceedings of ACM SIGCOMM '88, pages 123 to 133 (copy hosted by Princeton University). 1988. accessed October 22, 2026.
  9. Paul Mockapetris. Internet Hall of Fame. accessed October 22, 2026.
  10. RFC 883: Domain Names, Implementation and Specification. P. Mockapetris, USC Information Sciences Institute, RFC Editor. 1983-11. accessed October 22, 2026.
  11. RFC 920: Domain Requirements. J. Postel and J. Reynolds, USC Information Sciences Institute, RFC Editor. 1984-10. accessed October 22, 2026.
  12. STD 13. RFC Editor. accessed October 22, 2026.
  13. RFC 2181: Clarifications to the DNS Specification. R. Elz and R. Bush, RFC Editor. 1997-07. accessed October 22, 2026.
  14. RFC 9499: DNS Terminology (BCP 219). P. Hoffman and K. Fujiwara, RFC Editor. 2024-03. accessed October 22, 2026.
  15. Root Servers. Internet Assigned Numbers Authority (IANA). accessed October 22, 2026.
  16. Root Server Technical Operations Association. root-servers.org. 2026-10-22. accessed October 22, 2026.
  17. Root Zone Management. Internet Assigned Numbers Authority (IANA). accessed October 22, 2026.
  18. What Does ICANN Do?. ICANN. accessed October 22, 2026.
  19. RFC 3596: DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant and M. Souissi, RFC Editor. 2003-10. accessed October 22, 2026.
  20. RFC 974: Mail Routing and the Domain System. C. Partridge, CSNET CIC BBN Laboratories, RFC Editor. 1986-01. accessed October 22, 2026.
  21. DNS record types. Cloudflare DNS documentation. accessed October 22, 2026.
  22. CNAME flattening. Cloudflare DNS documentation. accessed October 22, 2026.
  23. Time to Live (TTL). Cloudflare DNS documentation. accessed October 22, 2026.
  24. DNS Propagation: Explained. Namecheap Knowledgebase. accessed October 22, 2026.
  25. Change your nameservers (Full setup). Cloudflare DNS documentation. accessed October 22, 2026.
  26. Vulnerability Note VU#800113: Multiple DNS implementations vulnerable to cache poisoning. CERT Coordination Center, Carnegie Mellon University. 2008-07-08. accessed October 22, 2026.
  27. RFC 4033: DNS Security Introduction and Requirements. R. Arends, R. Austein, M. Larson, D. Massey and S. Rose, RFC Editor. 2005-03. accessed October 22, 2026.
  28. Root DNSSEC launch status updates (archive). Internet Assigned Numbers Authority (IANA). 2010-07-16. accessed October 22, 2026.
  29. First Root KSK Rollover Successfully Completed. ICANN. 2018-10-15. accessed October 22, 2026.
  30. RFC 7858: Specification for DNS over Transport Layer Security (TLS). Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels and P. Hoffman, RFC Editor. 2016-05. accessed October 22, 2026.
  31. RFC 8484: DNS Queries over HTTPS (DoH). P. Hoffman and P. McManus, RFC Editor. 2018-10. accessed October 22, 2026.
  32. Firefox continues push to bring DNS over HTTPS by default for US users. Selena Deckelmann, The Mozilla Blog. 2020-02-25. accessed October 22, 2026.
  33. A safer and more private browsing experience with Secure DNS. Chromium Blog, Google. 2020-05-19. accessed October 22, 2026.
  34. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. S. Kitterman, RFC Editor. 2014-04. accessed October 22, 2026.
  35. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. D. Crocker, T. Hansen and M. Kucherawy (editors), RFC Editor. 2011-09. accessed October 22, 2026.
  36. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). M. Kucherawy and E. Zwicky (editors), RFC Editor. 2015-03. accessed October 22, 2026.
  37. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC). T. Herr and J. Levine (editors), RFC Editor. 2026-05. accessed October 22, 2026.

Web Building Encyclopedia. First published October 22, 2026. Last reviewed October 22, 2026. Every fact on this page is linked to a source we opened. Spotted an error? Write to [email protected].