DNS and Anycast

DNS is a distributed database whose keys are structured names. Its hierarchy lets administrators divide both data storage and responsibility: no organization must maintain every mapping, and an organization can delegate a subordinate namespace to another administrator. The same hierarchy also supplies a path by which a resolver can find the server that is authoritative for an unknown name.

The Hierarchical Namespace and Domains #

The DNS namespace is a rooted tree. Every node has a label of zero to 63 octets; siblings cannot have equal labels, although unrelated nodes can. The root has the zero-length, or null, label. Labels on the path from a node to the root, written from the most specific to the least specific and separated by dots, form a domain name. For example:

org
com
wikipedia.org
example.com

An absolute domain name includes the root label and is conventionally written with a trailing dot: wikipedia.org. and example.com. are fully qualified domain names (FQDNs). The trailing dot distinguishes an absolute name from a name that a resolver or zone-file parser may qualify with a search suffix or $ORIGIN. On the wire, a domain name is length-prefixed labels ending in a zero-length label; the final zero byte represents the root, not a text character.

A domain is the subtree rooted at a node. Thus, example.com. names both a node and the conceptual subtree below it, including names that may be added later. DNS comparisons are case-insensitive; implementations should preserve the received case where practical. A domain name alone does not identify an address, host, or organization. It identifies a location in the namespace at which resource records can be published.

Zones, Delegation, and Resource Records #

DNS answers queries for a (name, type, class) tuple with resource records (RRs). IN is the Internet class used by contemporary Internet DNS. Types describe the requested data: A publishes an IPv4 address, AAAA an IPv6 address, MX a mail exchanger, and NS a name server. For example, an A lookup for ns3.dnsv5.com. may return multiple records:

ns3.dnsv5.com.  172800  IN  A  1.12.0.17
ns3.dnsv5.com.  172800  IN  A  1.12.0.18
ns3.dnsv5.com.  172800  IN  A  1.12.0.20
ns3.dnsv5.com.  172800  IN  A  1.12.14.17
ns3.dnsv5.com.  172800  IN  A  1.12.14.18
ns3.dnsv5.com.  172800  IN  A  108.136.87.44
ns3.dnsv5.com.  172800  IN  A  125.94.59.200
ns3.dnsv5.com.  172800  IN  A  163.177.5.75
ns3.dnsv5.com.  172800  IN  A  35.165.107.227

Other classes existed for separate database-like services, such as Hesiod’s HS class, but Internet software queries IN. DNS has therefore become a general-purpose, replicated key-value system within the constraints of its naming, RR, and caching model.

A zone is the contiguous portion of the namespace for which an operator publishes authoritative data as one administrative unit. It is the unit replicated between a primary server and secondary servers, historically through a master file and now often through generated configuration or an API-backed database. A zone has an apex, whose SOA and apex NS RRsets identify its authority. In a zone file, @ denotes the current $ORIGIN, so an apex NS record has @ as its owner.

The apex NS RRset describes the servers that provide the zone’s authoritative service; it is therefore a property of the zone, even though its textual records have the apex as an owner name. Each NS record names a host rather than embedding an address. A resolver obtains that host’s A or AAAA records when it has no usable address already. Operators must ensure that every published name-server name is resolvable. An out-of-bailiwick name-server address can be resolved independently; an in-bailiwick address needs glue at the parent to break the delegation cycle.

Zones and domains are not interchangeable. A domain remains a complete conceptual subtree, whereas a parent zone stops being authoritative below a zone cut. For example, the com. zone delegates example.com. by publishing an NS RRset at example.com.. That delegation NS RRset belongs to the parent zone; the child publishes its own apex NS RRset. The parent retains the delegation records but not the child’s ordinary data.

Name-server names in a delegation can be inside the delegated domain, such as ns1.example.com. for example.com.. Resolving that name by first following the delegation would be circular, so the parent supplies address records as glue in the referral’s Additional section. Glue is not authoritative child-zone data and is accepted only under resolver bailiwick rules. A resolver treats data as eligible glue only when it is within the delegated zone’s bailiwick, preventing unrelated Additional-section data from being inserted into its cache as if it were authoritative.

CNAME makes its owner an alias for the canonical name in its RDATA. A CNAME owner cannot also have other ordinary data, because an alias must not provide a competing mapping. When a server returns a CNAME while answering another type, the response may include the target data when available; the resolver can otherwise continue at the canonical name. Caching the CNAME is safe because no alternative RR type may exist at the alias owner.

Authoritative Servers and Referrals #

An authoritative name server is reachable at an IP address and, by configuration, serves one or more zones. Authority is local to the server’s loaded zones, not a claim over every name below a suffix. A root server, for example, is authoritative for the root zone only; it delegates top-level domains rather than answering www.example.com. directly.

For a query within its authority, a server can return the answer and set the AA (authoritative answer) bit. For a query below a zone cut, it returns a referral: the Answer section is empty, the Authority section contains the delegated zone’s NS RRset, and the Additional section may contain usable glue. A server may instead return an error, including NXDOMAIN when the queried name does not exist. NOERROR with no requested RRset is different: it is a NODATA response, meaning the name exists but has no record of the requested type.

The Question section identifies the requested tuple, while Answer, Authority, and Additional carry the result and material needed to use it. Their contents are contextual rather than interchangeable: an authoritative negative response includes the zone’s SOA in Authority so a resolver can cache the denial, whereas a referral contains delegation NS records there. A CNAME can appear in Answer before the canonical target’s records. Additional-section data assists resolution but does not change the meaning of the question or make an unrelated name authoritative.

The three outcomes—answer, referral, and error—describe the authority hierarchy. They do not require every server to recurse. A server that declines a request it is not configured to serve can reply REFUSED (RCODE=5). The RD bit asks a server for recursion, while RA advertises that the responding server provides recursive service; RA is a capability indication rather than proof that every query will succeed.

Stub Resolvers, Recursive Resolvers, and Caches #

A stub resolver is the DNS component in an endpoint operating system or application. It accepts application lookup requests and sends DNS queries, commonly with RD=1, to configured recursive resolvers. For example, the glibc resolver reads /etc/resolv.conf; it does not itself normally walk the global DNS delegation tree.

A full-service recursive resolver accepts that request and performs the work on the client’s behalf. On a cache miss for www.example.com., it begins with a root server, receives a referral for com., obtains a referral for example.com., and queries an authoritative server for the final answer. These upstream queries are normally iterative: the resolver asks each authoritative server for the best answer it has, then follows referrals itself. A forwarding resolver also accepts recursive queries but sends them to another recursive resolver rather than initiating that walk. Central forwarding resolvers reduce duplicate external lookups and concentrate policy and cache administration.

Resolvers cache positive RRsets until their TTLs expire. They also cache authoritative negative answers: the zone’s SOA supplies the basis for the negative-cache lifetime, bounded by the SOA TTL and its MINIMUM field under current DNS rules. Consequently, both NXDOMAIN and NODATA can persist after a zone is changed. Lowering a record’s TTL before a planned migration limits new cache entries, but caches that already received the old TTL remain valid until it expires.

Caching is also why referrals, glue, and bailiwick boundaries matter. The resolver can reuse a delegation and its eligible addresses to avoid a root lookup, but it must not mistake non-authoritative auxiliary data for a durable answer. Authoritative servers publish the source data; recursive resolvers make that hierarchy practical for clients by caching and by following its referrals.

Root and Top-Level Infrastructure #

The root zone has a single apex, .. Its NS RRset names the root-server system, whose operators serve identical root-zone content from many network instances. Those servers direct resolvers to top-level domains such as com., org., and edu.. Each TLD publishes delegations for domains beneath it, so administrative control follows suffix boundaries without requiring a monolithic global zone.

Redundant authoritative servers improve availability at every level. Zone transfer keeps secondary servers synchronized with a primary’s version of the zone, but ordinary resolution and zone transfer have separate purposes. Standard DNS query messages carry lookups and referrals; AXFR and IXFR transfer whole zones or incremental changes between authorized servers. Implementations may use different storage systems and provisioning paths internally, provided the authoritative servers publish consistent zone contents.

DNS was designed around UDP, whose low setup cost suits small independent queries. A client retries with TCP when a UDP response has the TC truncation bit, and servers also use TCP for responses or operations that require it, including zone transfers. EDNS extends the DNS message format with negotiated capabilities and a larger advertised UDP payload size; it does not eliminate TCP fallback. Encryption transports such as DNS-over-TLS and DNS-over-HTTPS carry the same DNS semantics over protected connections, while authoritative delegation remains based on DNS records.

DNSSEC #

DNSSEC adds origin authentication to RRsets, not encryption or availability. RRSIG records sign RRsets, DNSKEY records publish public keys, and a DS record in a parent zone links a delegated child to that parent. A validating recursive resolver starts from a configured trust anchor, commonly the root key, and validates each signed delegation in the chain. NSEC and NSEC3 provide authenticated denial of existence; CDS and CDNSKEY let a child signal a requested update to its parent’s DS record.

Anycast for DNS #

Anycast assigns one service address to multiple, geographically distributed server instances. Internet routing selects a reachable instance for packets addressed to that shared address. Root-server operators, authoritative DNS providers, and recursive-resolver fleets use anycast because it distributes load and provides alternative paths when an instance or network becomes unavailable.

Anycast does not make an individual server stateful across the fleet. A BGP routing change can send a later packet to another instance, so DNS service must not depend on a client remaining attached to a particular anycast node. The request-response shape of UDP DNS fits that property. For TCP and encrypted DNS transports, operators keep existing flows routable to the selected instance where possible and design failover with the possibility of connection loss. Replicated zone data and consistent recursive policy therefore matter as much as the shared address.

For message fields, domain-name compression, and resource-record encoding, see DNS Wire Format. For BIND configuration, see BIND 9 Authoritative and Recursive DNS.