Domain Name System, commonly abbreviated DNS, is the distributed naming system used to map human-readable domain names and other structured names to data such as IP addresses, mail-server information, service locations and cryptographic or policy-related records. DNS allows users and applications to refer to names such as example.com rather than depending on numerical IP addresses, while also providing infrastructure for service discovery and Internet administration. DNS is hierarchical and distributed rather than being a single central database.
Its hierarchy includes the root zone, top-level domains such as .com and country-code top-level domains, and authoritative zones containing records for individual domains. Resolvers obtain answers by querying DNS infrastructure, frequently using caching to reduce latency and traffic. DNS can use UDP or TCP on port 53 for traditional DNS, while encrypted resolver transports such as DNS over TLS and DNS over HTTPS carry DNS messages through different transport mechanisms.
DNS names are structured hierarchically from right to left in conventional notation. A fully qualified domain name such as www.example.com consists of labels separated by dots, with the root represented conceptually by a final dot. The root is at the top of the DNS hierarchy, followed by top-level domains and progressively more specific delegated domains. DNS delegation allows control of a subdomain to be assigned to different authoritative name servers, creating a distributed administrative structure.
Domain registries maintain information about registrations under relevant top-level domains, while registrars provide registration services to customers. Authoritative DNS servers answer queries using data for zones they serve, whereas recursive resolvers retrieve answers on behalf of clients and commonly cache the results. These roles can coexist in some software but represent different functions within the DNS architecture.
DNS resource records associate names with typed data. A records map names to IPv4 addresses, while AAAA records map names to IPv6 addresses. CNAME records create aliases to canonical names, MX records identify mail-exchange hosts with priorities, NS records identify authoritative name servers, and TXT records carry text data frequently used for verification and email-security policies. SOA records describe important properties of a DNS zone, including its primary authoritative server and serial and timing information.
PTR records support reverse DNS mappings, such as mapping an IP address to a name under the in-addr.arpa or ip6.arpa namespaces. SRV records can identify hosts and ports for particular services, while CAA records can specify which certificate authorities are authorised to issue certificates for a domain. DNS therefore is not simply an "IP address lookup system"; it is a general-purpose hierarchical database with a well-defined record-type system.
DNS resolution involves several distinct stages. An application generally asks a local stub resolver to resolve a name. The configured recursive resolver then checks its cache and, if necessary, performs queries to authoritative infrastructure. A recursive process can begin with a root server, follow a referral to the appropriate top-level-domain servers, and then follow another referral to the authoritative servers for the requested domain. Cached records allow subsequent queries to be answered without repeating the complete hierarchy traversal.
Each record has a time-to-live value that determines how long a caching resolver may generally retain the information before refreshing it. DNS caching reduces latency and query load but means that changes to DNS records are not necessarily visible everywhere immediately. The practical interval for propagation is therefore influenced by TTLs, resolver behaviour, negative caching and administrative configuration rather than being controlled by a universal DNS propagation event.
DNS uses both UDP and TCP in traditional deployments. UDP provides low-overhead query transport and is sufficient for many ordinary exchanges, while TCP is required in circumstances specified by DNS standards, including certain large responses and zone transfers. Modern DNS can encounter responses that exceed the practical size of an uncomplicated UDP exchange, particularly when DNSSEC records are included. EDNS extends DNS capabilities and allows larger UDP payloads to be negotiated, although path fragmentation and filtering can still cause problems.
DNS over TLS encrypts DNS traffic between a client or forwarding component and a resolver using TLS, while DNS over HTTPS carries DNS messages within HTTPS. These mechanisms protect the client-to-resolver communication from straightforward observation or modification on that segment, but they do not inherently make the entire DNS ecosystem confidential because authoritative queries and other infrastructure may still involve separate communications.
DNS security includes both authenticity of DNS data and privacy of DNS queries, which are separate concerns. DNSSEC adds digital signatures to DNS data so validating resolvers can verify that responses originate from the authorised DNS hierarchy and have not been altered, assuming a valid chain of trust. DNSSEC does not encrypt ordinary DNS data. Its chain of trust begins from configured trust anchors and can extend through signed delegations.
Operational errors in DNSSEC, such as expired signatures or incorrect delegation information, can make valid domains fail validation. DNS is also involved in email-security systems through TXT records containing SPF-related information, DKIM-related configuration and DMARC policies. Attackers can exploit DNS through cache poisoning, malicious domain registrations, compromised authoritative infrastructure, DNS tunnelling or domain-generation techniques, while defenders use DNS monitoring for both infrastructure management and threat detection.
DNS has important relationships with application availability and network routing but does not itself route packets. A DNS answer tells an application where a service may be reachable, while routing protocols determine how packets travel towards the resulting IP address. A domain can resolve to multiple addresses for redundancy, load distribution or geographic service architectures, and a single IP address can host many domain names through mechanisms such as HTTP Host headers or TLS Server Name Indication.
DNS-based traffic-management systems can return different answers according to geography, resolver location, health status or policy, although their actual effectiveness depends on caching and resolver behaviour. DNS failures can therefore produce apparently network-related symptoms even when IP connectivity is functioning normally. Conversely, successful DNS resolution does not prove that the destination service is reachable or healthy.
DNS is often misunderstood as a simple directory controlled by one global organisation. In reality, the system is distributed across a hierarchy of root, TLD and authoritative infrastructure, with administrative responsibility delegated among many organisations. The Internet Corporation for Assigned Names and Numbers coordinates important aspects of the global DNS namespace, while registry operators administer individual top-level domains and domain owners or their DNS providers operate authoritative zones.
DNS also extends beyond the public Internet into private namespaces, split-horizon configurations and internal service-discovery systems. Effective DNS administration therefore requires understanding delegation, authoritative versus recursive roles, record semantics, TTLs, caching, transport, DNSSEC, privacy and operational dependencies. Its central purpose is to provide a scalable naming and data-distribution system that applications can use without embedding numerical network addresses directly into human-facing interfaces or software configuration.
