Domain Name System

Domain Name System (DNS) is the distributed, hierarchical naming system used by Internet applications to associate domain names with information such as IP addresses, mail servers, and authoritative name servers. Rather than operating as a single directory, the DNS consists of interoperating name servers, resolvers, zones, and caches organized under a common root. It allows names to remain stable when the systems or addresses providing a service change, and is both a technical protocol and a central component of the Internet's system of globally unique identifiers.

Functions and Data

The DNS is commonly described as translating domain names into IP addresses, but address resolution is only one of its functions. Each name in the DNS can be associated with one or more typed pieces of information called resource records. Common record types include:

• A and AAAA records, which associate names with IPv4 and IPv6 addresses;
• MX records, which identify mail servers;
• NS records, which identify the authoritative name servers for a zone;
• SOA records, which describe administrative and operational parameters for a zone;
• CNAME records, which make one name an alias of another;
• TXT records, which carry text used by numerous applications and verification mechanisms; and
• PTR records, which are commonly used for reverse DNS lookups.

Applications query for the type of information they require. A web browser may request A or AAAA records, while an email server may request MX records. DNS data is therefore not limited to a one-to-one relationship between a name and a single address.

Reverse DNS, in which an address is used to retrieve a name, is implemented through separately administered parts of the namespace, principally under in-addr.arpa for IPv4 and ip6.arpa for IPv6. A forward mapping does not automatically create a corresponding reverse mapping.

How Resolution Works

When an application needs DNS information, it normally sends a request through a local or stub resolver to a recursive resolver. The recursive resolver may be operated by an Internet service provider, an enterprise network, a public DNS service, or the user's own system.

If the requested information is already in the recursive resolver's cache and remains valid, it can return the cached answer immediately. Otherwise, it generally performs a sequence of iterative queries:

1. The resolver asks a root name server where to find information for the relevant top-level domain (TLD).
2. The root server returns a referral to the TLD's authoritative name servers.
3. A TLD server returns a referral to the authoritative name servers for the requested domain.
4. The authoritative server returns the requested resource records, an additional referral, or a response indicating that the name or record does not exist.

The root and TLD servers do not ordinarily contain the final address of a website or other Internet service. Their principal role in resolution is to direct resolvers toward the next authoritative part of the hierarchy.

Responses are cached according to their time to live (TTL). Caching reduces latency and query volume, but it also means that changes to DNS data take time to become visible across different resolvers. Resolution may require additional queries when aliases, delegations, or other dependencies are encountered.

Namespace, Zones, and Delegation

The DNS namespace is structured as a tree. A domain name consists of labels separated by dots, ordered from the most specific label on the left toward the root on the right. The root is represented by an empty label and may be shown explicitly by a final dot, as in www.example.com.

A domain is a node in the namespace together with the names beneath it. A zone is the portion of the namespace for which a particular administrative authority publishes authoritative data. Domains and zones are therefore related but are not synonymous: a domain may contain subdomains that have been delegated into separate zones.

Delegation distributes responsibility through the hierarchy. A parent zone delegates a child zone by publishing NS records identifying the child's authoritative servers. The parent may also publish address records needed to reach those servers, known as glue records. For DNSSEC-signed delegations, the parent can publish a DS record establishing the next link in the cryptographic chain of trust.

The root zone is the highest level of this hierarchy. It principally contains delegations for TLDs rather than registration or address information for every domain on the Internet. The IANA Root Zone Database records the delegation details for these TLDs.

In ICANN policy, most publicly delegated TLDs are treated as either generic top-level domains (gTLDs) or country code top-level domains (ccTLDs). Sponsored TLDs are a policy subtype of gTLD rather than a separate technical layer of the DNS. Infrastructure domains such as .arpa have distinct functions. An internationalized domain name (IDN) may be either a gTLD or a ccTLD; IDN describes the use of non-ASCII scripts and is not a separate category parallel to gTLDs and ccTLDs.

Within the domain registration system:

• a registry operator maintains registration data and the authoritative zone for a TLD;
• a registrar provides registration services to customers, particularly under the gTLD model; and
• a registrant is the person or organization to which a domain name is registered.

ccTLD registration arrangements vary and do not always follow the registry-registrar structure used by gTLDs. Registration policies, fees, contracts, and rights to use labels are external to the DNS protocol itself.

Origins and Standardization

Before the DNS, hosts on the early Internet were identified through a centrally maintained file commonly known as HOSTS.TXT. As the network expanded, distributing and updating a single host table became increasingly difficult. The DNS replaced this model with a hierarchical namespace in which administrative responsibility and authoritative data could be distributed.

Paul Mockapetris introduced the initial DNS design in RFC 882 and RFC 883 in November 1983. RFC 882 described the conceptual model, while RFC 883 specified name servers, resolvers, messages, and implementation behavior.

These documents were superseded in November 1987 by RFC 1034 and RFC 1035, which remain the core DNS specifications and together form Internet Standard 13. The DNS has since been extended and clarified through dozens of additional RFCs. RFC 9499 consolidates much of the terminology used in contemporary DNS engineering and operations.

RFC 1591, published by Jon Postel in 1994, provided an influential early description of the TLD hierarchy and the responsibilities associated with delegated management. Its operational details reflect the institutional arrangements of its period, but its treatment of delegation as a responsibility to serve the relevant community remains important to the history of DNS administration.

See Pre-ICANN History of the DNS for the broader institutional development of the DNS before ICANN's creation.

Security, Privacy, and Resilience

The original DNS protocol did not provide cryptographic authentication of DNS data or confidentiality for ordinary queries. Several later mechanisms address different parts of this problem.

DNS Security Extensions (DNSSEC) allow resolvers to verify the origin and integrity of signed DNS data and to authenticate statements that requested data does not exist. DNSSEC does not encrypt queries or responses and therefore does not provide confidentiality.

Encrypted DNS transports protect DNS messages while they travel between participating systems. DNS over TLS, DNS over HTTPS, and DNS over QUIC encrypt query and response traffic over different transport protocols. These mechanisms address transport privacy and interference, while DNSSEC addresses the authenticity of the DNS data itself.

DNS operations face threats including cache poisoning, spoofed responses, denial-of-service attacks, route hijacking, configuration errors, compromised registrar accounts, and unauthorized changes to authoritative data. DNS Abuse concerns malicious activity that uses domain names, DNS infrastructure, or domain registration processes. For ICANN's gTLD contracts, the term covers malware, botnets, phishing, pharming, and spam when used to deliver the other listed forms of abuse.

The DNS derives much of its resilience from decentralization, redundant authoritative servers, caching, and anycast deployment. The Root Server System has 13 named service identities, from A through M, operated by 12 independent organizations and delivered through many server instances around the world. The root zone itself is the same across these services.

Continued extension of the protocol also creates implementation and operational complexity. The term DNS Camel refers to concern that successive additions to the DNS may eventually make complete and secure implementations increasingly difficult.

The expansion of the root zone, longer TLD strings, and the use of additional writing systems also expose assumptions in older software. Universal Acceptance is the effort to ensure that all valid domain names and email addresses work consistently across applications, devices, and systems.

Governance and Operational Roles

No single organization operates or controls the entire DNS. Its functioning depends on distributed technical, administrative, commercial, and policy roles:

• The Internet Engineering Task Force (IETF) develops DNS protocol standards and operational guidance through the RFC process.
• The Internet Assigned Numbers Authority (IANA) functions, performed by Public Technical Identifiers (PTI), process root zone changes and maintain DNS-related registries.
• Root server operators publish the root zone through the globally distributed Root Server System.
• TLD registry operators and authoritative DNS providers operate delegated zones.
• Registrar and registry systems administer domain registrations, while registrants determine how their delegated names are used.
• Recursive resolver operators perform resolution for users and make operational decisions concerning caching, validation, privacy, filtering, and transport protocols.
• Network and application operators implement the software through which users access DNS services.

ICANN coordinates the allocation and assignment of names in the DNS root zone and the development and implementation of policies concerning second-level registrations in gTLDs. It also maintains contractual relationships with gTLD registry operators and accredited registrars. ICANN does not operate the entire DNS, control all authoritative servers or resolvers, or possess general authority over Internet content.

Within ICANN, the Root Server System Advisory Committee (RSSAC) advises the ICANN Board and community on the operation, administration, security, and integrity of the Root Server System. The Security and Stability Advisory Committee (SSAC) advises on the security and integrity of the Internet's naming and address allocation systems.

The globally interoperable public DNS depends on participants using a common namespace and assigning the same meaning to the same names. Alternative roots, private namespaces, and uncoordinated name allocations can produce inconsistent answers or name collisions. Questions concerning TLD allocation, delegated authority, resolver choice, privacy, DNS abuse mitigation, multilingual naming, and the boundary between technical coordination and content regulation consequently remain recurring subjects of Internet governance.

See Also

• Pre-ICANN History of the DNS
• Root Zone
• Name Server
• Domain Name Resolvers
• DNS Abuse
• Universal Acceptance
• Name Collision

Domain Name System

Internet Protocol Version 4

Internet Protocol Version 6

Top-Level Domain

Domain Name System Security Extensions

Top-Level Domain

Generic Top-level Domain

Country code top-level domain. Determined by "ISO 3166-1: Codes for the representation of names of countries and their subdivisions — Part 1: Country codes".

Generic Top-level Domain

Internationalized Domain Name

Country code top-level domain. Determined by "ISO 3166-1: Codes for the representation of names of countries and their subdivisions — Part 1: Country codes".

American Standard Code for Information Interchange

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Internet Engineering Task Force

Internet Assigned Numbers Authority

Public Technical Identifiers

Root Server System Advisory Committee. Advises the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's Root Server System (ICANN Bylaws).

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).