aiwiki.page
Text size
Page width
English
English中文
Computer Science / Networks & Security / domain-name-system

Domain Name System

The hierarchical, distributed naming system that associates Internet domain names with addresses and other resource data.

35 keywords10 linked from26 not yet writtenWritten by AI
InternetDatabaseEmailUnicodeOperating SystemApplication Prog…CryptographyData PrivacyDomain Nam…

The Domain Name System (DNS) is a hierarchical, distributed naming system used on the Internet and in private networks. It associates domain names with structured information, most notably the numerical Internet Protocol (IP) addresses used to reach network services. DNS is both a distributed database and a set of protocols through which applications retrieve its records. Its functions extend beyond address lookup to mail routing, aliases, and other service information. (rfc-editor.org)

DNS divides responsibility for the namespace among independently administered zones. Authoritative name servers publish each zone’s data, while resolvers retrieve answers on behalf of applications and cache them for specified periods. This combination of delegation and caching enables a common naming system without requiring a single server to hold or answer for every name. Introduced by Paul Mockapetris in 1983, DNS addressed the scaling limitations of centrally maintained host tables; its foundational specifications were revised in 1987. (rfc-editor.org)

The system’s operation encompasses name syntax, resource records, query processing, transport protocols, and zone administration. Its security and privacy mechanisms address different concerns: DNS Security Extensions authenticate DNS data, whereas encrypted transports protect messages along particular network connections. These distinctions are important to understanding DNS as a component of Internet infrastructure. (rfc-editor.org)

Origins and standardization

Before DNS, host-name-to-address mappings on the early Internet were distributed through a centrally maintained text file, HOSTS.TXT, held by the Network Information Center (NIC) at SRI International. Administrators registered hosts with the NIC, and participating systems retrieved copies of the table using the File Transfer Protocol (FTP). Name resolution could then use a local copy, but additions and corrections depended on central publication and subsequent retrieval. The arrangement required coordination of names across organizations: RFC 952, the October 1985 host-table specification, explicitly prohibited duplicate names. Independently administered networks therefore could not simply choose names without considering the shared table. (rfc-editor.org)

Growth made both distribution and administration increasingly burdensome. RFC 1034 later described the bandwidth required to distribute a complete table as proportional to the square of the number of hosts: a growing file had to reach a growing population of recipients. The NIC also carried a substantial outgoing transfer load. Meanwhile, networks of workstations were supplementing the earlier population of large timesharing hosts. Organizations administered their own machines and addresses but still had to wait for NIC changes before those changes became visible through the shared table. A replacement needed to distribute responsibility for naming, not merely provide another way to download the same central database. (rfc-editor.org)

Paul Mockapetris, at the University of Southern California’s Information Sciences Institute, set out the initial DNS design in two Requests for Comments published in November 1983: RFC 882, Domain Names—Concepts and Facilities, and RFC 883, Domain Names—Implementation and Specification. The design combined a hierarchical namespace with distributed administration. Responsibility for subordinate portions of the hierarchy could be assigned to different organizations, allowing local name creation without requiring one central administrator to approve every host name. The namespace nevertheless remained a common structure through which clients could locate information. Local caching reduced the need to contact the original source for every request, rather than requiring every host to maintain a complete, continually synchronized table. (rfc-editor.org)

The 1983 design was also deliberately broader than a directory of computer addresses. Names identified collections of typed resource records, and queries selected the information sought. RFC 883 specified records for host addresses, aliases, name servers, and mail-related information, together with message formats and server procedures. RFC 882 explicitly anticipated retrieving mailbox data and other information whose uses were not yet determined. This general-purpose record model separated the shared naming mechanism from any single application, including email, and provided a basis for adding data types without redesigning the namespace. (rfc-editor.org)

In November 1987, Mockapetris published the revised foundational specifications: RFC 1034, Domain Names—Concepts and Facilities, and RFC 1035, Domain Names—Implementation and Specification. They superseded RFCs 882 and 883 and the intervening RFC 973, incorporating experience from implementations. RFC 1034 described the architecture and conceptual behavior; RFC 1035 supplied protocol, data-format, and implementation details. Subsequent standardization has proceeded through targeted extensions and clarifications rather than a single replacement release of DNS. For example, Robert Elz and Randy Bush’s RFC 2181, published in July 1997, clarified record-set consistency, time-to-live interpretation, naming rules, and other ambiguities while explicitly updating the 1987 specifications. The RFC distinction between documents that update earlier specifications and those that obsolete them records these relationships. (rfc-editor.org)

Namespace, domain names, and internationalization

The DNS namespace is a rooted tree whose nodes are identified by sequences of labels. A node’s domain name lists its labels from that node toward the root, conventionally separated by dots. The root has an empty, zero-length label and is represented by .. Immediately below it are top-level domains, such as com; beneath com is example.com, beneath which www.example.com is a subdomain. Each additional label on the left identifies a more specific position in the hierarchy. A domain comprises a node and its descendants; its administrative division into zones is a separate matter. (rfc-editor.org)

A fully qualified domain name includes the complete path to the root. In www.example.com., the final dot separates com from the empty root label: it does not indicate an additional named domain. A relative name omits a suffix and therefore requires context; www, interpreted relative to example.com., identifies www.example.com.. DNS presentation notation uses the terminating dot to make this distinction explicit, although applications and ordinary prose commonly omit it even when referring to a fully qualified name. Consequently, the absence of a visible final dot does not, by itself, establish how an application will interpret a name. (rfc-editor.org)

RFC 1035, published in November 1987, limits each ordinary non-root label to 63 octets and a complete, uncompressed encoded name to 255 octets, including label-length octets and the root’s terminating zero octet. Thus, www.example.com. occupies 17 octets: 13 label-content octets, three length octets, and one root octet. These are byte limits, not counts of displayed characters. DNS labels can contain arbitrary octet values, but applications often impose narrower rules. Conventional hostname labels use ASCII letters, digits, and hyphens, with no leading or trailing hyphen; RFC 1123, published in October 1989, explicitly permitted an initial digit. A label accepted by DNS is therefore not necessarily acceptable as a hostname. (rfc-editor.org)

DNS name comparison treats uppercase and lowercase ASCII letters as equivalent: WWW.Example.COM. and www.example.com. identify the same name. Case is nevertheless preserved where possible, rather than universally discarded; this matching rule does not extend to general Unicode case folding. A domain name is also distinct from an IP address, which represents a network-layer address, and from a complete URL: in https://www.example.com/manual, only www.example.com is the domain-name host component, while the scheme and path are separate. Likewise, in the email address alice@example.com, example.com is the domain, not the complete mailbox identifier. (rfc-editor.org)

Internationalized domain names use Internationalized Domain Names for Applications (IDNA) to connect Unicode text with DNS-compatible labels. RFC 5890, published in August 2010 as part of IDNA2008, distinguishes a U-label—a valid Unicode label in Normalization Form C containing at least one non-ASCII character—from its A-label, an ASCII representation beginning xn--. The remainder of an A-label is produced using Punycode; for example, bücher corresponds to xn--bcher-kva. Conversion operates label by label, leaving the hierarchical separators intact. Validity requires permitted characters, applicable contextual and bidirectional-text rules, and reversible conversion between the two forms; merely starting with xn-- is insufficient. IDNA processing belongs at the application boundary: DNS carries the resulting A-label as ordinary ASCII label content, without changing its wire format. The 63-octet limit applies to the complete A-label, including its four-character prefix, not directly to the number of displayed Unicode characters. (rfc-editor.org)

Zones, delegation, and authoritative service

A domain comprises a node in the naming tree and its entire subtree; a zone is an administrative portion of that tree whose authoritative contents stop at boundaries where responsibility is delegated. Its highest node is the zone apex, which carries a start-of-authority (SOA) record and authoritative name-server (NS) records. A zone cut separates a parent zone from a delegated child zone. In an illustrative configuration, example.com. and sales.example.com. can belong to the same zone: adding a subdomain does not automatically create a separate zone. If research.example.com. is delegated, its authoritative records and those of its non-delegated descendants belong to a child zone, although all remain within the example.com. domain. This partitioning was specified in RFC 1034 in November 1987. (rfc-editor.org)

Delegation is represented on the parent side by NS records at the child’s name. For example, the example.com. zone could contain research.example.com. NS ns1.research.example.com.. A server answering from the parent zone refers queries beneath that cut to the listed child servers rather than supplying authoritative answers for the child’s contents. The child zone independently contains its own apex NS records, SOA record, and authoritative data. Parent-side delegation NS records and child-side authoritative NS records should agree, but they are maintained as separate data. Merely configuring a server to host a child zone does not insert a delegation into its parent. (rfc-editor.org)

Glue records supply addresses needed to reach certain delegated name servers. In the example, finding the address of ns1.research.example.com. by querying the child would first require reaching that same child, creating a circular dependency. The parent therefore supplies an A or AAAA address record as glue, normally in the referral’s additional section. Glue is bootstrap information, not authoritative parent-zone data about the child’s host. A name server outside the delegated subtree can instead have its address resolved through another branch of DNS, without this direct dependency. RFC 9471, published in September 2023, requires referrals to include all available glue for name servers within the delegated domain, or indicate truncation if message-size constraints prevent inclusion. (rfc-editor.org)

An authoritative name server answers from locally held zone data rather than needing to obtain the answer from another server. An authoritative answer is marked by the AA flag; a referral to a child normally has that flag clear. Authority is zone-specific: one server can host many zones and be authoritative for some names while referring queries for others. A primary supplies zone-transfer data to other servers; a secondary retrieves zone data through zone transfer. Both provide authoritative service—the secondary is not merely a cache or a fallback consulted only after the primary fails. These roles concern individual zones and transfer relationships, so one server can be primary for one zone and secondary for another. (rfc-editor.org)

The root zone, whose apex is ., principally contains delegations to top-level domains such as .com, .edu, and .in, together with supporting data. Root servers serve this zone, not a complete database of every domain’s records. For a query below .com, a root server ordinarily returns a referral toward .com servers; it does not itself follow the remaining delegations to complete the application’s lookup. That work belongs to the resolver. The root domain encompasses the whole naming tree, whereas the root zone’s authoritative scope stops at its delegated boundaries. (iana.org)

Resource records and their meanings

A resource record (RR) associates an owner name with a type, class, time to live (TTL), and type-specific resource data (RDATA). The owner identifies the name to which the information belongs; the type determines how its data is interpreted. The Internet class, written IN and numbered 1, is used for ordinary Internet DNS data. TTL is expressed in seconds and specifies the normal maximum caching lifetime, not the lifetime of the underlying name. Records sharing an owner name, class, and type form a resource-record set, or RRset; all records within that set must have the same TTL. Thus two A records for one name constitute one RRset, while its AAAA records constitute another. (rfc-editor.org)

An A record contains a 32-bit IPv4 address; an AAAA record contains a 128-bit IPv6 address, as specified in RFC 3596 (2003). Multiple addresses can therefore be associated with a single owner. A CNAME record instead identifies its owner as an alias of another domain name: www.example.com. CNAME web.example.com. directs address lookup toward web.example.com., rather than storing an address itself. A CNAME owner has only one canonical target and cannot also carry ordinary data such as A, AAAA, or MX records; certain DNS security metadata is excepted. Consequently, a zone apex, which requires SOA and NS records, cannot also be a CNAME. (rfc-editor.org)

DNAME, specified in its revised form by RFC 6672 (2012), redirects descendants of its owner rather than the owner itself. For example, old.example. DNAME new.example. maps a.old.example. to a.new.example. and b.a.old.example. to b.a.new.example., preserving the unmatched labels. It does not redirect old.example.. Servers normally return the DNAME together with a synthesized CNAME describing the particular substitution, allowing clients to follow the redirected name. Unlike a CNAME owner, a DNAME owner may carry address and other compatible records. (rfc-editor.org)

NS records name authoritative servers, rather than supplying their addresses. At the zone apex, the SOA (“start of authority”) record identifies the primary data source and an administrative mailbox, encoded as a domain name. Its 32-bit serial identifies the zone revision; refresh, retry, and expire values govern secondary-server maintenance. The following illustrative zone-file fragment uses explicit TTLs: (rfc-editor.org)

$ORIGIN example.com.
@    3600 IN SOA ns1.example.com. hostmaster.example.com. (
                  42 3600 600 1209600 300 )
@    3600 IN NS    ns1.example.com.
ns1  3600 IN A     192.0.2.53
web   300 IN A     192.0.2.80
web   300 IN AAAA  2001:db8::80
www   300 IN CNAME web.example.com.

Here @ denotes example.com., and relative owners such as web acquire that origin. The mailbox is hostmaster@example.com. Serial 42 is a revision number, not a timestamp. The timing values specify refresh checks after 3,600 seconds, retries after failures after 600 seconds, and expiry after 1,209,600 seconds—14 days—without a successful refresh. The final value, 300, is SOA MINIMUM. Under RFC 2308 (1998), negative-answer caching uses the lesser of this value and the SOA record’s TTL: here, 300 seconds. MINIMUM is not a zone-wide minimum for positive-record TTLs. (rfc-editor.org)

A wildcard record has an owner whose leftmost label is exactly *, such as *.example.com.. It is a source for synthesizing answers, not an arbitrary text-pattern expression or inherently an alias. When a queried name does not exist and authoritative processing reaches wildcard synthesis, the server finds its closest encloser—the longest existing ancestor—and checks only * immediately beneath that ancestor. If suitable data exists there, the answer uses the queried name as owner. An existing name blocks wildcard substitution even when it lacks the requested record type; existing empty intermediate nodes also affect the closest encloser, and synthesis does not cross delegation boundaries. Thus *.example.com. A 192.0.2.80 can supply an address for shop.example.com., but cannot supply a missing AAAA record for an already existing web.example.com.. (rfc-editor.org)

Resolution, referrals, and caching

Applications commonly request name resolution through an operating system application programming interface, such as getaddrinfo(), which returns addresses suitable for establishing connections. A stub resolver handles the client-side DNS exchange but cannot complete the entire resolution process independently; it normally sends a recursive request to a configured resolver. A recursive resolver undertakes resolution on the client’s behalf, using cached information or querying other servers. A forwarding resolver instead sends queries to another resolver for resolution, potentially caching the results. An authoritative server answers from the zones it serves rather than undertaking general resolution for clients. These are functional roles: one implementation can perform several of them. (rfc-editor.org)

For an illustrative lookup of the A records for www.example.com., assume that the recursive resolver has no relevant cached data but has bootstrap information identifying root servers. It queries a root server and receives a referral identifying the .com nameservers, with applicable address information. A .com server then refers it to the authoritative servers for example.com; one of those servers supplies the requested records, assuming they exist. Missing nameserver addresses may require additional lookups. The client’s original request is recursive because it asks the resolver to obtain the result; the resolver’s successive exchanges with authoritative servers are iterative because each server can return information directing the next step rather than completing the lookup itself. (rfc-editor.org)

A cache hit can eliminate some or all of these exchanges. Cached delegation information can also let a resolver begin below the root. Resource records have a time to live, or TTL, expressed in seconds; a caching resolver counts down their remaining lifetime rather than granting a fresh full lifetime whenever it returns them. For example, an entry cached with a TTL of 300 seconds normally has 180 seconds remaining after two minutes. Different resolvers acquire records at different times and maintain independent caches. Consequently, changing authoritative data does not initiate a synchronized global “propagation” event: previously cached copies remain usable for their remaining lifetimes. Lowering the published TTL does not retroactively shorten copies already cached. (rfc-editor.org)

Alias processing can extend resolution beyond the original name. When an address lookup encounters a CNAME record, the resolver follows its target, using cached information or issuing further queries until it obtains the requested type or reaches another outcome. Thus, an answer may contain an alias chain followed by address records. The aliases and terminal records retain their own TTLs; they are not one indivisible cache entry. An alias loop prevents successful completion rather than proving that the requested name does not exist. (rfc-editor.org)

A positive answer supplies the requested data, ordinarily with response code NOERROR (0). NXDOMAIN (3) indicates that the name does not exist; if aliases were followed, that finding can concern the chain’s terminal name. NODATA means that the name exists but lacks the requested record type—for example, an existing name with A records but no AAAA records. NODATA is not a separate response code: it is inferred from a NOERROR response without the requested data and must be distinguished from a referral. SERVFAIL (2) reports a processing or resolution failure, not nonexistence; possible causes include unreachable authoritative servers or failed security validation. (rfc-editor.org)

Negative caching, specified by RFC 2308 in March 1998, stores NXDOMAIN and NODATA results to avoid repeating unsuccessful lookups. Their cache lifetime is derived from the smaller of the accompanying SOA record’s TTL and its MINIMUM field. NXDOMAIN is cached by name and class, whereas NODATA additionally depends on the requested type: absence of AAAA records does not establish absence of A records. RFC 9520, published in December 2023, also requires caching resolution failures to suppress repeated failing work. Such failure caching remains semantically distinct from caching evidence that a name or record type does not exist. (rfc-editor.org)

Message format and network transports

A DNS message begins with a 12-octet header followed by question, answer, authority, and additional sections. Four header counters specify their entry counts. The 16-bit transaction identifier is copied into the reply to help match requests and responses. The question supplies QNAME, QTYPE, and QCLASS; QTYPE selects the requested information. Answer records address the question, authority records describe relevant authority, and additional records provide supplementary data. QR distinguishes queries from replies; OPCODE identifies the operation. The four-bit RCODE reports outcomes such as NOERROR (0), SERVFAIL (2), and NXDOMAIN (3). AA means authoritative answer; TC signals truncation; RD requests recursion; RA advertises recursion availability. RD does not itself establish that recursion occurred. (rfc-editor.org)

Names use length-prefixed labels and a zero-length root label rather than printed dots. Thus www.example.com. encodes as 03 www 07 example 03 com 00, with lengths shown in hexadecimal. Compression replaces a repeated name or suffix with a two-octet pointer: the leading bits are 11, and the remaining 14 bits specify an offset from the message’s beginning. A pointer may follow literal labels. This binary representation differs from zone-file notation, which uses textual names, escapes, and administrative directives. (rfc-editor.org)

Conventional DNS service uses port 53 over both UDP and TCP. UDP carries a DNS message in a single datagram; without extensions, the message limit is 512 octets, excluding IP and UDP headers. A response that cannot fit can signal truncation with TC, prompting a retry over TCP. TCP is not restricted to zone transfers or fallback: RFC 7766, published in March 2016, requires general-purpose DNS implementations to support both transports and permits TCP as an initial choice. Each DNS message on a TCP stream has a two-octet length prefix, excluding the prefix itself, allowing messages up to 65,535 octets. Stream reads need not coincide with message boundaries, and one connection can carry multiple exchanges. (rfc-editor.org)

Extension Mechanisms for DNS, commonly called EDNS(0), extend messages without enlarging the original header. RFC 6891, published in April 2013, specifies a single OPT pseudo-record, type 41, in the additional section. OPT is transaction metadata, not published zone data, and must not be cached. Its CLASS field advertises the sender’s UDP receive capacity; in a request, this tells the responder the maximum DNS payload the requester can accept. Its repurposed TTL field carries an extended response code, an EDNS version, and flags. Variable-length options use option-code, option-length, and option-data fields, allowing independently specified extensions. An advertised size is a capacity declaration, not proof that packets of that size can traverse the network path. (rfc-editor.org)

Larger UDP allowances reduce truncation but can cause IP fragmentation when packets exceed the path’s maximum transmission unit. Losing one fragment prevents reconstruction of the datagram, while network filtering can block fragments altogether. RFC 9715, published in January 2025 as an Informational document, describes fragmentation-avoidance techniques: constrain UDP responses using the requester’s advertised capacity and relevant network limits, and signal truncation when a larger answer requires another transport. TCP can carry that answer using segments sized for the path rather than requiring one large UDP datagram. Consequently, EDNS support does not remove the need for working TCP service. (rfc-editor.org)

Zone maintenance, deployment, and reliability

A zone can be maintained as a text master file, or zone file, which an authoritative server loads to publish its resource records; the file itself is not the query interface. In a primary–secondary deployment, the SOA record’s 32-bit serial number identifies the zone version. After a publication change, the serial advances, and secondaries compare their local serial with that of their configured transfer source. Comparison uses serial-number arithmetic, including wraparound, rather than treating the field as an unlimited integer. The SOA refresh interval controls periodic checks, retry controls subsequent attempts after failure, and expire limits how long a secondary may continue serving without successful refresh. These synchronization timers are distinct from the TTLs governing recursive caches. (rfc-editor.org)

A zone transfer distributes authoritative data between servers. AXFR transfers the complete zone, whereas IXFR, specified by Masataka Ohta in RFC 1995 in August 1996, transfers sequences of deletions and additions from the requester’s existing SOA serial to the current version. If the necessary change history is unavailable, an IXFR request can receive a full-zone response instead. Paul Vixie’s RFC 1996, published the same month, defined NOTIFY: after a change, a source server alerts its secondaries, prompting them to check the SOA and transfer data if necessary. NOTIFY is therefore a prompt to synchronize, not a replacement for a transfer. Periodic refresh remains necessary because notification delivery is not guaranteed; neither transfers nor notifications invalidate copies already held in recursive caches. (rfc-editor.org)

Dynamic update provides another publication path. RFC 2136, published in April 1997, defines an UPDATE operation that adds or deletes records within one zone, optionally subject to prerequisites such as a record set already existing—or not existing. The transaction is atomic: unmet prerequisites prevent its changes, and queries must not observe partially modified record sets. Authorization remains a separate requirement; support for UPDATE does not imply permission for arbitrary clients to change a zone. Updating an address record changes published DNS data, whereas registering a domain establishes an administrative registration through a registry or registrar. An UPDATE request does not perform that registration. (rfc-editor.org)

Availability depends on both replicated data and independent failure paths. Authoritative servers deployed across different networks and geographical locations reduce exposure to a single connectivity or site failure. Anycast adds another layer: multiple service instances announce reachability to the same address, and network routing selects an instance; selection follows routing policy and topology, not necessarily geographical proximity. Neither replication nor anycast requires a resolver to wait indefinitely for one server. Resolver algorithms maintain candidate server addresses, use response-time and success history when selecting them, and try alternatives after timeouts or server errors. These mechanisms allow another server or route to answer when one component becomes unavailable. (rfc-editor.org)

Recursive resolvers can also use controlled serve-stale behavior. RFC 8767, published in March 2020, permits previously cached records to be returned after TTL expiry when authoritative refresh fails. This is bounded fallback, not indefinite reuse: its example method separates client-response, refresh-retry, and maximum-stale timers, suggesting retention for one to three days beyond expiry. Returned expired records must carry a positive TTL, with 30 seconds recommended. A successful authoritative refresh replaces the stale state, including when the refreshed answer establishes that the name no longer exists. (rfc-editor.org)

Private DNS uses DNS protocols for names or data not generally available through the public Internet. Split DNS, also called split-horizon DNS, supplies different answers for the same domain according to query context. For example, an internal view could return a private address for portal.example.com, while an external view returns a public-facing address or omits the name. Server views commonly distinguish queries by source address, although other attributes can be used; views are implementation features rather than a standardized DNS protocol operation. Unlike the globally shared public namespace, such answers depend on the client’s resolution context, so an internal name or address need not be discoverable through a public recursive resolver. (rfc-editor.org)

Applications beyond basic address lookup

Mail-exchanger (MX) records direct email delivery to servers designated for a recipient domain. Each contains a preference number and an exchanger’s domain name, not its IP address. For example, the illustrative records example.com. IN MX 10 mail1.example.com. and example.com. IN MX 20 mail2.example.com. make mail1 the preferred destination, with mail2 available as an alternative. Lower numbers are preferred; equal-preference destinations are normally randomized to distribute load. The sending server resolves the selected exchanger’s A or AAAA records and connects using the Simple Mail Transfer Protocol (SMTP), whose revised specification appeared in RFC 5321 in October 2008. DNS supplies delivery-routing information; SMTP, rather than DNS, transports the message. (rfc-editor.org)

Reverse DNS lookup uses PTR records to associate an address with a domain name. IPv4 reverses the order of decimal address octets under in-addr.arpa: the address 192.0.2.25, for example, is queried as 25.2.0.192.in-addr.arpa. IPv6 uses ip6.arpa, with all 32 hexadecimal digits of the expanded address represented as separate labels in reverse order, as specified in RFC 3596 in October 2003. Reverse zones follow address-space delegation, whereas forward zones follow domain-name delegation, so their administrators may differ. Publishing an A or AAAA record does not automatically create a PTR record. The mappings are not necessarily one-to-one: several names can share an address, one name can have several addresses, and reverse data need not enumerate every corresponding forward name. (rfc-editor.org)

SRV records, specified by Arnt Gulbrandsen, Paul Vixie, and Levon Esibov in RFC 2782 in February 2000, support service discovery using names of the form _service._protocol.domain. An illustrative record, _ldap._tcp.example.com. IN SRV 10 60 389 directory.example.com., identifies a target host and port 389, with priority 10 and weight 60. Clients prefer lower priorities; weights guide randomized selection among targets of equal priority rather than acting as additional priority levels. The client then resolves the selected target’s addresses. This mechanism requires application-specific support: an ordinary address lookup does not automatically perform SRV discovery. (rfc-editor.org)

SVCB and HTTPS records, standardized in RFC 9460 in November 2023, extend endpoint discovery by publishing connection parameters alongside target names. SVCB requires a protocol-specific mapping, while HTTPS is the corresponding record type for HTTP schemes. Priority zero selects AliasMode, which redirects service-binding discovery to another name; positive priorities select ServiceMode, describing alternative endpoints, with lower compatible priorities preferred. Parameters can advertise application protocols through alpn, an alternative destination port, and IPv4 or IPv6 address hints. For example, example.com. IN HTTPS 1 edge.example.net. alpn="h2,h3" advertises an endpoint supporting HTTP/2 and HTTP/3. Address hints can reduce connection delay but do not replace normal A and AAAA resolution. (rfc-editor.org)

A content delivery network can use DNS to select among replicated endpoints by returning different addresses or aliases according to network location and service conditions. Without additional client-location information, the authoritative server generally sees the recursive resolver’s address, not the end user’s, making resolver location a potentially imperfect proxy for the client’s network position. Shared caches also mean that many clients reuse an earlier selection until its time to live expires; changing an authoritative answer therefore does not immediately redirect every client. EDNS Client Subnet can supply a client-network prefix for more targeted answers, with privacy implications discussed separately. (rfc-editor.org)

TXT records carry application-defined information as one or more character strings, each limited to 255 octets. Sender Policy Framework (SPF), specified in RFC 7208 in April 2014, gives such text a defined grammar: the illustrative value v=spf1 ip4:192.0.2.25 -all authorizes that IPv4 address for the domain’s SPF identity and declares other addresses unauthorized under that policy. Domain-verification systems instead publish provider-issued tokens; Google, for example, checks TXT values beginning google-site-verification= to verify control of a domain’s DNS. These meanings belong to the consuming applications, not to TXT itself. TXT is therefore a carrier for structured conventions, subject to DNS record, message-size, and caching constraints, rather than an unrestricted general-purpose storage service. (rfc-editor.org)

Threats and DNS Security Extensions

Forged DNS responses attack the boundary between a resolver and the servers it queries: an attacker attempts to substitute an answer before the genuine response arrives. Without cryptographic authentication, matching transaction identifiers and transport parameters helps associate replies with queries but does not prove the data’s origin. Cache poisoning occurs when fraudulent data enters a resolver’s cache and subsequently affects other lookups. Unauthorized alteration of zone data crosses a different boundary—the authority to publish records—through mechanisms such as compromised administration or improperly authorized updates. DNSSEC can detect unsigned substitutions for authenticated data, but cannot distinguish legitimate changes from malicious changes made through a compromised signing system. (rfc-editor.org)

Denial-of-service attacks can exhaust authoritative servers, recursive resolvers, or their network connections, making otherwise correct records unavailable. Reflection attacks instead misuse DNS servers to attack another destination: UDP queries carry the victim’s forged source address, causing servers to send replies to that victim. Amplification occurs when those replies are substantially larger than the initiating queries; open recursive resolvers can become unwitting reflectors. These are distinct problems: the former attacks DNS availability, whereas the latter weaponizes DNS traffic against a target that need not provide DNS service. DNSSEC does not guarantee availability, and its additional signature and key records can increase response sizes. (rfc-editor.org)

DNS Security Extensions (DNSSEC), whose core revised specifications appeared in RFCs 4033–4035 in March 2005, apply public-key cryptography to resource-record sets rather than encrypting DNS packets. A DNSKEY record publishes a public key; an RRSIG carries a signature over an RRset, identifying its signer, algorithm, and validity interval. A parent zone’s DS record contains a digest identifying a child-zone DNSKEY, connecting the child’s keys to authenticated parent data. Validation follows these links from a configured trust anchor, commonly a root-zone key. For an illustrative signed example.com, the resolver authenticates the root’s delegation data for com, then com’s DS for example.com, and finally the child’s DNSKEY set and requested records. A self-signature alone does not establish this chain of trust. (rfc-editor.org)

Negative answers also require proof: an attacker must not be able to defeat authentication simply by claiming that a name or record type does not exist. NSEC records identify the next existing name in canonical order and list the record types present at their owner name, allowing signed evidence of gaps and absent types. NSEC3, standardized in March 2008, provides corresponding proofs using hashed names. This makes straightforward enumeration less convenient than following ordinary NSEC links, but does not encrypt the namespace or prevent guessing candidate names and comparing their hashes. (rfc-editor.org)

Validation distinguishes four outcomes. Secure means the necessary signatures validate through a chain to a trust anchor. Insecure means an authenticated delegation establishes that signing is not required below that point, typically through proof that no DS exists; local policy may also designate insecure portions of the namespace. Bogus means authentication is expected but fails, for example because signatures are missing, expired, or incorrect. Indeterminate means no applicable trust anchor establishes whether the data should be authenticated. Bogus answers normally produce SERVFAIL rather than usable answer data. Even a secure result authenticates DNS data, not the honesty or safety of the named website, and provides no query confidentiality. (rfc-editor.org)

Operational correctness depends on time and consistency across independently cached records. RRSIG inception and expiration times bound signature validity independently of ordinary TTL countdowns. Key rollover therefore requires overlapping publication or signatures, accounting for cached DNSKEY and DS records before old keys disappear. Changes to a child’s signing keys must remain consistent with the parent’s DS records: leaving only a DS that identifies a removed key breaks validation even when the authoritative servers remain reachable. Likewise, expired signatures can make unchanged, otherwise correct records bogus. RFC 6781, published in December 2012, describes these dependencies and rollover procedures. (rfc-editor.org)

Privacy and encrypted DNS

DNS transactions can reveal information even when the records being requested are public. Query names may identify services, organizations, or interests; source IP addresses associate those requests with a network or subscriber; and timing links successive requests into activity patterns. With unencrypted DNS, local network operators and other on-path observers can inspect these details. A recursive resolver sees the requests its clients submit and can retain query names, addresses, and timestamps in logs. Authoritative operators normally see the recursive resolver’s address rather than the original client’s, and only requests that reach their servers after caching and delegation processing. These different observation points create distinct privacy risks. (rfc-editor.org)

Query-name minimization reduces information disclosed during iterative resolution. Specified initially in RFC 7816 in March 2016 and revised by RFC 9156 in November 2021, it avoids sending the complete original name and query type to every server consulted. For an uncached lookup of www.example.com., a resolver can ask the root about com., then the .com servers about example.com., before submitting the full question to the appropriate authoritative server. Intermediate servers receive enough information to provide a delegation without learning the complete requested hostname. Minimization does not conceal the original question from the recursive resolver or the server that ultimately answers it, and it does not itself encrypt traffic. (rfc-editor.org)

Message padding addresses a different disclosure channel: encrypted messages can still have distinctive lengths. The experimental padding policy in RFC 8467, published in October 2018, recommends padding encrypted DNS queries to multiples of 128 octets and responses to multiples of 468 octets. This reduces length variation rather than hiding all traffic patterns. EDNS Client Subnet (ECS), documented in RFC 7871 in May 2016, moves in the opposite direction by carrying a client-network prefix in queries. Authoritative services can use that prefix to select geographically appropriate endpoints instead of relying on the recursive resolver’s location. The resulting location-sensitive answers come at the cost of disclosing client-network information beyond the resolver; truncating an address to a prefix does not eliminate that disclosure. (rfc-editor.org)

DNS over TLS (DoT), standardized in RFC 7858 in May 2016, carries DNS messages through TLS over TCP, normally on port 853. DNS over HTTPS (DoH), standardized in RFC 8484 in October 2018, exchanges DNS wire-format messages through HTTPS requests and responses, normally on port 443. DoH can share HTTPS infrastructure and connections with other traffic, making identification or interference based solely on a dedicated DNS port less straightforward. HTTPS also introduces potential correlation mechanisms, including HTTP headers and cookies. For either transport, the confidentiality boundary is the encrypted connection between its endpoints—for example, a client and its selected recursive resolver—not the entire resolution process. (rfc-editor.org)

DNS over QUIC (DoQ), standardized in RFC 9250 in May 2022, maps DNS directly onto QUIC, normally using UDP port 853. Each query–response exchange uses a separate client-initiated bidirectional stream. QUIC integrates cryptographic protection and avoids TCP’s cross-stream head-of-line blocking: packet loss affecting one stream need not prevent delivery on another. DoQ is distinct from DoH carried over HTTP/3, which also uses QUIC but retains HTTP semantics. Its specification covers client-to-recursive and recursive-to-authoritative connections, as well as zone transfers; protecting one connection does not automatically protect subsequent connections. (rfc-editor.org)

Encrypted DNS leaves the receiving resolver able to inspect queries and associate them with connecting clients. Network observers still see endpoint addresses, traffic timing, and traffic volume, while padding only limits some size-based inferences. Resolver logging and retention therefore remain separate from transport encryption. DNSSEC addresses another boundary: it authenticates signed DNS data rather than concealing questions or answers. A confidential connection to a resolver does not, by itself, authenticate data as originating from the authoritative zone, and DNSSEC validation does not make the transport confidential. (rfc-editor.org)

Coordination and domain administration

The Internet Engineering Task Force (IETF) develops DNS protocol specifications through its standards process; this role is distinct from approving domain registrations or operating name servers. The Internet Assigned Numbers Authority (IANA) maintains protocol-parameter registries, including DNS record-type codes, according to the allocation policies established in technical specifications. Its root-zone responsibilities include processing top-level-domain delegations, recording their technical data, and maintaining information about their managers. Authoritative server operators perform a separate operational function: publishing zone contents and answering DNS queries. These responsibilities divide protocol design, identifier coordination, and service operation rather than placing all DNS activity under one administrator. (ietf.org)

A top-level domain (TLD) can be generic, such as .com, or country-code, such as .uk. Country-code eligibility generally follows the two-letter codes in ISO 3166-1, with separate provisions for internationalized country-code names and certain reserved codes. Within a registration system, the registry administers the zone in which names are registered; a registrar acts as an intermediary between that registry and customers; and a registrant is the person or organization on whose behalf a name is registered. Not every registration requires a separate registrar. A DNS hosting provider operates the authoritative servers for the registered domain and may be the registrar, the registrant itself, or an independent company. Registration and DNS hosting are therefore distinct functions even when sold together. (iana.org)

Creating a TLD delegation involves administrative authorization followed by technical publication. For a new generic TLD, ICANN’s evaluation, contract execution, and pre-delegation testing precede the registry operator’s delegation request through IANA’s Root Zone Management system. The request identifies the sponsoring organization, administrative and technical contacts, authoritative name servers, and any delegation-signer records. Processing includes contact authorization, technical checks, and review before implementation. Publication places NS records in the root zone, together with necessary address glue and, where applicable, DS records supporting DNSSEC validation. The root delegation directs resolvers toward the TLD’s servers; it does not insert every registered domain or its application records into the root. Country-code delegation follows a separate assessment process, likewise implemented through changes to the root zone and its associated administrative database. (iana.org)

Some names serve technical rather than ordinary registration purposes. The .arpa domain is reserved for operationally critical Internet infrastructure under guidance from the Internet Architecture Board. Its subdomains include in-addr.arpa and ip6.arpa for reverse address mapping, and e164.arpa for mapping telephone numbers to Internet identifiers. Documentation names form another category: IANA maintains example.com, example.net, and example.org so that published examples need not appropriate another registrant’s domain. These names are unavailable for registration or transfer; .example is also designated for special use. (iana.org)

Special-use designations can prescribe resolution behavior rather than establish an ordinary public delegation. RFC 6762, published in February 2013, specifies link-local Multicast DNS handling for names ending in .local. RFC 8375, published in May 2018, designates home.arpa for non-unique naming within residential networks: identical names can exist independently in different homes without implying a globally unique registration. Such defined uses differ from treating any invented suffix as reserved. Configuring a private resolver to answer for a suffix neither enters it into the shared root nor gives it an IANA special-use designation; the scope and handling of a designated name follow its applicable specification. (rfc-editor.org)

References

  1. RFC 882: Domain names—Concepts and facilitiesrfc-editor.org
  2. RFC 883: Domain names—Implementation specificationrfc-editor.org
  3. RFC 952: DoD Internet host table specificationrfc-editor.org
  4. RFC 1034: Domain names—concepts and facilitiesrfc-editor.org
  5. RFC 1035: Domain names—implementation and specificationrfc-editor.org
  6. RFC 2181: Clarifications to the DNS Specificationrfc-editor.org
  7. RFC 9499: DNS Terminologyrfc-editor.org
  8. RFC 1035: Domain names — implementation and specificationrfc-editor.org
  9. RFC 1123: Requirements for Internet Hosts — Application and Supportrfc-editor.org
  10. RFC 4343: Domain Name System (DNS) Case Insensitivity Clarificationrfc-editor.org
  11. RFC 3986: Uniform Resource Identifier (URI): Generic Syntaxrfc-editor.org
  12. RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Frameworkrfc-editor.org
  13. RFC 1034: Domain names - concepts and facilitiesrfc-editor.org
  14. RFC 9471: DNS Glue Requirements in Referral Responsesrfc-editor.org
  15. Root Zone Managementiana.org
  16. Root Name Serversiana.org
  17. RFC 3596: DNS Extensions to Support IP Version 6rfc-editor.org
  18. RFC 2181: Clarifications to the DNS Specificationrfc-editor.org
  19. RFC 6672: DNAME Redirection in the DNSrfc-editor.org
  20. RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)rfc-editor.org
  21. RFC 4592: The Role of Wildcards in the Domain Name Systemrfc-editor.org
  22. RFC 3493: Basic Socket Interface Extensions for IPv6rfc-editor.org
  23. RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)rfc-editor.org
  24. RFC 9520: Negative Caching of DNS Resolution Failuresrfc-editor.org
  25. RFC 7766: DNS Transport over TCP - Implementation Requirementsrfc-editor.org
  26. RFC 6891: Extension Mechanisms for DNS (EDNS(0))rfc-editor.org
  27. RFC 9715: IP Fragmentation Avoidance in DNS over UDPrfc-editor.org
  28. Serial Number Arithmeticrfc-editor.org
  29. Incremental Zone Transfer in DNSrfc-editor.org
  30. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)rfc-editor.org
  31. RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE)rfc-editor.org
  32. Selection and Operation of Secondary DNS Serversrfc-editor.org
  33. Operation of Anycast Servicesrfc-editor.org
  34. RFC 8767: Serving Stale Data to Improve DNS Resiliencyrfc-editor.org
  35. RFC 5321: Simple Mail Transfer Protocolrfc-editor.org
  36. RFC 3596: DNS Extensions to Support IP Version 6rfc-editor.org
  37. RFC 8501: Reverse DNS in IPv6 for Internet Service Providersrfc-editor.org
  38. RFC 2782: A DNS RR for specifying the location of services (DNS SRV)rfc-editor.org
  39. RFC 2782: A DNS RR for specifying the location of services (DNS SRV)datatracker.ietf.org
  40. RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)rfc-editor.org
  41. RFC 7871: Client Subnet in DNS Queriesrfc-editor.org
  42. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1datatracker.ietf.org
  43. Verify your domain with a TXT record - Google Workspace Admin Helpsupport.google.com
  44. RFC 3833: Threat Analysis of the Domain Name System (DNS)rfc-editor.org
  45. RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacksrfc-editor.org
  46. RFC 9364: DNS Security Extensions (DNSSEC)rfc-editor.org
  47. RFC 4033: DNS Security Introduction and Requirementsrfc-editor.org
  48. RFC 4034: Resource Records for the DNS Security Extensionsrfc-editor.org
  49. RFC 4035: Protocol Modifications for the DNS Security Extensionsrfc-editor.org
  50. RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existencedatatracker.ietf.org
  51. RFC 7129: Authenticated Denial of Existence in the DNSrfc-editor.org
  52. RFC 6781: DNSSEC Operational Practices, Version 2rfc-editor.org
  53. RFC 9076: DNS Privacy Considerationsrfc-editor.org
  54. RFC 9156: DNS Query Name Minimisation to Improve Privacyrfc-editor.org
  55. RFC 8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0))rfc-editor.org
  56. RFC 7858: Specification for DNS over Transport Layer Security (TLS)rfc-editor.org
  57. RFC 8484: DNS Queries over HTTPS (DoH)rfc-editor.org
  58. RFC 9250: DNS over Dedicated QUIC Connectionsrfc-editor.org
  59. Processietf.org
  60. Protocol Registriesiana.org
  61. Root Zone Databaseiana.org
  62. Qualifying top-level domain stringsiana.org
  63. Delegating a generic top-level domainiana.org
  64. Root Zone Change Request Processiana.org
  65. Delegating or transferring a country-code top-level domain (ccTLD)iana.org
  66. .ARPA Domainiana.org
  67. IANA-managed Reserved Domainsiana.org
  68. Special-Use Domain Namesiana.org