The Domain Name System (DNS) translates human-readable domain names into IP addresses that computers use to communicate, serving as the internet's directory service. Operating through a globally distributed hierarchy of servers—from root servers through TLDs to authoritative nameservers—DNS enables virtually every internet interaction. Understanding DNS record types, zone management, resolution flows, security mechanisms like DNSSEC, and troubleshooting techniques is essential for network administrators, security professionals, and developers building resilient internet infrastructure. DNS performance, caching behavior, and attack surface remain critical concerns as the protocol continues evolving with privacy enhancements (DoH, DoT, DoQ), security extensions, and automated management tools.
17 tables, 154 concepts. Select a concept node to jump to its table row.
Table 1: Core DNS Record Types
Every DNS resource record follows the format name TTL class type rdata. The seven record types below handle the overwhelming majority of real-world queries — master these before exploring the specialized types in Table 2.
| Type | Example | Description |
|---|---|---|
example.com. 300 IN A 93.184.216.34 | Maps a hostname to an IPv4 address — the most fundamental DNS record used for web hosting and service endpoints. | |
example.com. 300 IN AAAA 2606:2800:220:1:248:1893:25c8:1946 | • Maps a hostname to an IPv6 address (128-bit) • essential as IPv4 addresses are exhausted | |
www.example.com. 300 IN CNAME example.com. | • Creates an alias pointing to another domain name • cannot coexist with other records at the same name • not allowed at zone apex in standard DNS. | |
example.com. 3600 IN MX 10 mail.example.com. | • Specifies mail servers for the domain with priority values (lower = higher priority) • multiple MX records provide failover | |
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all" | • Holds arbitrary text data • commonly used for SPF, DKIM, DMARC, domain verification, and security policies | |
example.com. 86400 IN NS ns1.example.com. | • Delegates a zone or subdomain to specific nameservers • must exist at zone apex and for any delegated subdomains | |
34.216.184.93.in-addr.arpa. 3600 IN PTR example.com. | • Enables reverse DNS lookups (IP to hostname) • critical for email deliverability and server authentication • configured in special .in-addr.arpa or .ip6.arpa zones. | |
example.com. 3600 IN SOA ns1.example.com. admin.example.com. 2026030901 7200 3600 1209600 300 | • Mandatory first record in every zone • contains serial number, refresh/retry/expire timings, and negative caching TTL. | |
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. | • Specifies location of services (priority, weight, port, target) • used by SIP, XMPP, LDAP, and other protocols requiring dynamic service discovery | |
example.com. 3600 IN CAA 0 issue "letsencrypt.org" | • Restricts which certificate authorities can issue SSL/TLS certificates for the domain • prevents unauthorized certificate issuance |
Table 2: Advanced and Specialized Record Types
Beyond the core types, DNS supports dozens of specialized records for service binding, security, identity, and zone management. The rows below cover the most practically useful, ordered from most widely deployed to most niche.
| Type | Example | Description |
|---|---|---|
example.com. 300 IN HTTPS 1 . alpn=h3,h2 ipv4hint=93.184.216.34 | • Service binding record providing connection hints (HTTP versions, IP hints, ports) • enables faster HTTPS connections and HTTP/3 upgrade signaling | |
example.com. 300 IN ALIAS target.example.com. | • Non-standard workaround enabling CNAME-like behavior at zone apex • resolver returns A/AAAA records via CNAME flattening • widely supported by DNS providers | |
_443._tcp.example.com. 3600 IN TLSA 3 1 1 abc123... | • Part of DANE (DNS-based Authentication of Named Entities) • associates TLS certificates with domain names, reducing reliance on third-party CAs | |
old.example.com. 3600 IN DNAME new.example.com. | • Creates an alias for an entire subtree • unlike CNAME which aliases only exact name, DNAME redirects all subdomains beneath it | |
server.example.com. 3600 IN SSHFP 1 2 abc123... | • Publishes SSH key fingerprints in DNS • allows SSH clients to verify server identity without relying solely on known_hosts. | |
example.com. 3600 IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@example.com!" . | • Used in Dynamic Delegation Discovery System (DDDS) • enables URI/service transformation • primarily for ENUM and telecommunications protocols | |
server.example.com. 3600 IN LOC 37 46 29.000 N 122 25 10.000 W 10m 100m 1000m 10m | • Stores geographic coordinates (latitude, longitude, altitude, precision) for a host or network • rarely used in practice but supported by all major DNS servers | |
hash._openpgpkey.example.com. 3600 IN OPENPGPKEY base64encodedkey... | • Publishes OpenPGP public keys in DNS for email encryption and sender verification • keyed by hashed email local-part under _openpgpkey subdomain | |
hash._smimecert.example.com. 3600 IN SMIMEA 3 1 1 abc123... | • Binds S/MIME certificates to email addresses in DNS • similar to TLSA but for email • enables DANE-based email authentication | |
_ftp._tcp.example.com. 3600 IN URI 10 1 "ftp://ftp.example.com/public" | • Maps hostnames to URIs with priority and weight • similar to SRV but returns a full URI string directly rather than requiring client-side assembly | |
example.com. 3600 IN CSYNC 2026030901 3 A NS AAAA | • Signals to the parent zone that it should synchronize specified record types from the child zone • enables automated NS/glue record updates without manual registry interaction | |
example.com. 3600 IN CERT 1 0 5 MIIBIjANBgkqhkiG9w0BAQEFAAOC... | • Stores cryptographic certificates (X.509, PGP, SPKI, etc.) directly in DNS • largely superseded by TLSA and OPENPGPKEY for specific use cases | |
example.com. 86400 IN ZONEMD 2026030901 1 1 7d016e7badfd8b... | • Provides a cryptographic hash of the entire zone for integrity verification • combined with DNSSEC, lets consumers verify zone authenticity • added to the root zone in late 2023. |
Table 3: DNSSEC Records
DNSSEC uses a chain of cryptographic trust from the root zone through TLDs to authoritative nameservers. These specialized record types implement that chain — understand the KSK/ZSK split before working with any of them in production.
| Type | Example | Description |
|---|---|---|
example.com. 300 IN RRSIG A 8 2 300 20260315120000 20260308120000 12345 example.com. abc123... | • Contains cryptographic signature for a DNS record set • verifies authenticity and integrity of DNS data • created by the ZSK for zone records and by the KSK for DNSKEY records | |
example.com. 3600 IN DNSKEY 257 3 8 AwEAAb... | • Holds the public cryptographic key for the zone • flag 257 = Key Signing Key (KSK), flag 256 = Zone Signing Key (ZSK) • KSK signs the DNSKEY RRset, ZSK signs zone records | |
example.com. 86400 IN DS 12345 8 2 abc123... | • Hash of child zone's KSK placed in parent zone • establishes the chain of trust linking parent and child zones • must be updated at registry when KSK is rolled | |
example.com. 3600 IN CDS 12345 8 2 abc123... | • Published in the child zone to signal the desired DS state to the parent • enables automated KSK rollover — parent polls child and updates its DS RRset without manual registry interaction (RFC 7344 / RFC 8078). | |
a.example.com. 3600 IN NSEC b.example.com. A AAAA RRSIG NSEC | • Proves non-existence of DNS records by listing the next existing name • enables authenticated denial of existence • reveals zone contents via zone walking — use NSEC3 for public zones | |
abc123.example.com. 3600 IN NSEC3 1 0 0 - def456 A RRSIG | • Hashed version of NSEC preventing zone enumeration • RFC 9276 mandates 0 hash iterations (higher values cause DoS vulnerability without meaningful security benefit) • empty salt recommended | |
example.com. 0 IN NSEC3PARAM 1 0 0 - | • Placed at zone apex to define NSEC3 parameters (hash algorithm, flags, iterations, salt) for zone signing tools • per RFC 9276: algorithm=1, iterations=0, salt=-. |
Table 4: DNS Zone Types and Management
A DNS zone is the administrative unit that an authoritative server manages. Knowing zone types and their relationships determines how you architect redundancy, split-horizon views, and delegations.
| Concept | Example | Description |
|---|---|---|
Holds master copy: example.com SOA, NS, A records | • Contains the authoritative master copy of zone data • all changes are made here • responsible for incrementing SOA serial on updates | |
Replicates from primary via AXFR/IXFR | • Read-only replica receiving zone data via zone transfer (AXFR/IXFR) • provides redundancy, load distribution, and geographic diversity | |
Contains only NS records: ns1.example.com, ns2.example.com | • Holds only NS records for a delegated subdomain • enables resolver to find authoritative servers without full zone data • lighter than secondary zone | |
example.com → 93.184.216.34 | • Resolves hostnames to IP addresses (standard DNS) • most common zone type for public and internal domains | |
93.184.216.34 → example.com | • Resolves IP addresses to hostnames using PTR records • implemented in .in-addr.arpa (IPv4) or .ip6.arpa (IPv6) domains• critical for email reputation | |
If query for corp.example.com → forward to 10.0.0.1 | • Forwards queries for specific domain to designated DNS servers • commonly used for split-DNS scenarios and Active Directory integration |
Table 5: DNS Resolution Methods
DNS resolution is not a single operation — it is a coordinated sequence of queries between clients, recursive resolvers, and authoritative servers. Understanding this flow is essential for diagnosing latency, misconfiguration, and policy-based filtering.
| Method | Example | Description |
|---|---|---|
Client → resolver: "Give me IP for www.example.com" | • Client requests complete answer from resolver • resolver does all the work querying root, TLD, and authoritative servers • most common for end-user devices | |
Resolver → root: "Where's .com?" → root replies with TLD referral | • Server responds with best referral rather than final answer • recursive resolver performs multiple iterative queries to reach authoritative answer | |
Query for cached record or authoritative zone | • Query answered immediately from cache or local authority • no further lookups needed • fastest resolution path when data is available | |
Internal DNS → corporate resolver → 8.8.8.8 | • DNS server passes unresolved queries to another DNS server • reduces external query load • commonly used in enterprise networks | |
Internal clients see 10.0.0.1, external see 93.184.216.34 | • Returns different responses based on query source • internal vs external view of same domain • achieved through separate zones or view-based configuration |
Table 6: DNS Caching and TTL
Caching is what makes DNS scalable — without it, every query would burden root and authoritative servers. TTL values, negative caching, and modern resilience techniques like serve-stale directly affect how quickly DNS changes propagate and how gracefully infrastructure survives outages.
| Concept | Example | Description |
|---|---|---|
example.com. 300 IN A 93.184.216.34 (300 seconds = 5 minutes) | • Specifies how long (in seconds) a DNS record can be cached • lower TTL = faster updates but more queries • typical values: 300–86400 seconds | |
Cache stores: example.com → 93.184.216.34 for 300 seconds | • Caches successful DNS responses (NOERROR) for TTL duration • reduces resolver workload and improves client response time | |
Cache stores: notexist.example.com → NXDOMAIN for 300 seconds | • Caches non-existent domain responses (NXDOMAIN) or no-data responses • TTL controlled by SOA minimum field • prevents repeated queries for invalid names | |
Resolver serves expired example.com A record while re-fetching in background | • Resolver serves expired cached records when the authoritative server is unreachable instead of returning SERVFAIL • significantly cushions the impact of upstream outages (as seen in the May 2026 .de DNSSEC incident)• default behavior in Unbound 1.23+. | |
NSEC proves a.example.com to c.example.com exists, infer b.example.com doesn't | • Uses DNSSEC NSEC/NSEC3 records to synthesize negative answers from cache • reduces queries to authoritative servers • improves privacy via local denial of existence | |
<link rel="dns-prefetch" href="//cdn.example.com"> | • Browser preemptively resolves domain names before user clicks links • reduces perceived latency • implemented via HTML hint or automatic browser behavior |
Table 7: DNS Query Flags and Response Codes
DNS message headers carry a compact set of flags and a 4-bit RCODE that communicates query intent and server response status. RFC 8914 Extended DNS Errors (EDE) supplement RCODEs when a single code is insufficient to describe the failure.
| Item | Example | Description |
|---|---|---|
QR=0 (query) or QR=1 (response) | Distinguishes between query (0) and response (1) packets. | |
AA=1 flag in response | • Indicates the responding server is authoritative for the queried domain • not set by recursive resolvers | |
RD=1 set by client | • Client requests the server to recursively resolve the query • typically set by stub resolvers | |
RA=1 in response | • Server indicates it supports recursion • set by recursive resolvers, not by authoritative-only servers | |
AD=1 when DNSSEC validated | • Indicates DNSSEC validation succeeded • resolver has cryptographically verified the response • requires DNSSEC-aware resolver | |
CD=1 in query | • Instructs resolver to disable DNSSEC validation • used for troubleshooting or when client performs own validation | |
Successful query with answer | • Query completed successfully • valid data returned. | |
Malformed query packet | • Server could not interpret the request due to a format error • often caused by corrupted packets, software bugs, or network interference | |
Server encountered internal error | • Server failed to complete the query • often indicates DNSSEC validation failure, upstream timeout, or misconfiguration • diagnosed with EDE codes (RFC 8914). | |
Domain does not exist | • Domain name does not exist • authoritative negative answer • can be cached per negative TTL | |
Unsupported opcode or query type | • Server does not support the requested operation or query type • seen with unusual opcodes on older servers | |
Server policy denies the query | Server refuses to answer due to policy — ACL restriction, recursion disabled for external client, or rate limiting. | |
Dynamic update tries to create existing domain | • Domain exists when it should not • used in dynamic DNS updates (RFC 2136). | |
RRset exists when it should not in dynamic update | • RRset exists when the update prerequisite requires it absent • dynamic DNS updates only | |
Required RRset does not exist | • RRset does not exist when the update prerequisite requires it present • dynamic DNS updates only | |
Server not authoritative for zone | • Server is not authoritative for the zone named in the update request • the query was sent to the wrong server | |
Name outside zone in update | • Name in the update falls outside the zone the server manages • dynamic DNS updates only |
Table 8: DNS Security Mechanisms
DNS security is layered: DNSSEC ensures data integrity, encrypted transports protect confidentiality, RPZ enables policy-based threat blocking, and anti-spoofing measures harden resolvers against injection attacks. These mechanisms are complementary, not mutually exclusive.
| Mechanism | Example | Description |
|---|---|---|
Zone signed with RRSIG, DNSKEY, DS records | • Uses public key cryptography to sign DNS records • provides authentication and integrity but not confidentiality • prevents cache poisoning • organized around a chain of trust from the root zone | |
https://1.1.1.1/dns-query with encrypted DNS query | • Encrypts DNS queries inside HTTPS (port 443) • indistinguishable from normal HTTPS traffic • widely supported by browsers • most deployed encrypted DNS protocol today | |
DNS query over TLS connection (port 853) | • Encrypts DNS queries using a dedicated TLS connection on port 853 • provides confidentiality • easier to detect/block than DoH by network operators | |
kdig @9.9.9.9 example.com +quic (port 853 UDP) | • Encrypts DNS over QUIC transport (RFC 9250, UDP port 853) • lower latency than DoT via 0-RTT session resumption and no head-of-line blocking • supports connection migration for mobile devices • Quad9 and Cloudflare deploy it in production. | |
response-policy { zone "rpz.feed"; }; in BIND | • Acts as a DNS firewall intercepting queries based on policy triggers (domain name, IP, nameserver) • can return NXDOMAIN, redirect to walled garden, or drop queries • supported by BIND 9.8+, Unbound 1.10+, PowerDNS • consumes external threat-intelligence feeds. | |
Zone transfer authenticated with HMAC-SHA256 shared secret | • Uses shared secret keys to authenticate DNS messages • primarily for securing zone transfers (AXFR/IXFR) and dynamic updates between servers | |
Limit identical responses to 5/second from same client | • Mitigates DNS amplification attacks by limiting rate of identical responses • prevents DNS servers from being weaponized in DDoS attacks | |
Query to .com TLD only reveals example.com, not www.example.com | • Resolver sends minimum necessary query name to each server • reduces information leakage to upstream servers • privacy enhancement | |
Use random source ports (e.g., 54321, 47892) instead of fixed port 53 | • Randomizes UDP source port for queries • adds ~16 bits of entropy • makes DNS cache poisoning significantly harder • critical security measure | |
Query: WwW.ExAmPlE.CoM → expect same case in response | • Randomizes case of query name • resolver validates response preserves same case • adds ~7 bits of entropy • defends against cache poisoning • deployed by Google Public DNS |
Table 9: DNS Attack Types and Threats
DNS is a high-value attack surface: every internet-connected device trusts DNS responses implicitly. Attacks range from passive eavesdropping to active cache poisoning and infrastructure flooding. Understanding each threat model is prerequisite to deploying the correct countermeasure from Table 8.
| Attack | Example | Description |
|---|---|---|
Attacker injects false example.com → malicious IP into resolver cache | • Injects forged DNS responses into resolver cache • redirects users to malicious servers • mitigated by source port randomization, DNSSEC, and 0x20 encoding | |
Small query ( EDNS0 ANY) triggers 4000+ byte response using spoofed source IP | • Amplifies attack traffic by sending small queries (with spoofed source IP) that generate large responses toward victim • amplification factor up to 130x • mitigated by BCP38, RRL, and disabling ANY queries | |
Data: encoded-data.evil.com TXT "base64payload" | • Exfiltrates data or tunnels C2 traffic over DNS • encodes arbitrary data in DNS queries/responses • bypasses firewalls • detected by monitoring query frequency, subdomain length, and entropy | |
Flood of random123abc.example.com queries | • Overwhelms authoritative servers with queries for non-existent domains • exhausts resolver and authoritative server resources • mitigated by rate limiting and anycast | |
Malicious resolvers return bank.example.com → attacker IP | • Modifies DNS resolution path by compromising resolvers, routers, or registrar accounts • redirects users to attacker-controlled servers | |
CNAME sub.example.com → unclaimed.github.io | • DNS record points to expired or released third-party resource (cloud hosting, CDN) • attacker claims the target resource and hijacks subdomain • monitored via regular DNS auditing | |
Attacker domain resolves to 192.168.1.1 after initial IP validated | • Attacker serves a domain with very short TTL; browser fetches initial IP to pass same-origin checks; subsequent lookups rebind to internal/private IP addresses • bypasses same-origin policy, enabling browser as pivot to internal network • mitigated by rejecting private IPs in responses, DNS pinning, and validating Host headers. | |
Attacker strips RRSIG/DNSKEY records from responses | • Attacker removes DNSSEC records to make validating resolver fall back to insecure DNS • prevented by validators that reject unsigned responses for signed zones | |
Botnet IP changes every 60 seconds using low TTL | • Changes A records very rapidly (60–300 second TTL) across many IPs • provides resilient, hard-to-block infrastructure for malware C2 and phishing | |
ISP-level prefix hijack redirects DNS traffic to rogue resolver | • BGP route hijacking redirects IP prefixes containing DNS servers • targeted at public resolvers • difficult to detect without BGP monitoring |
Table 10: DNS Zone Transfer Methods
Zone transfers are the mechanism by which secondary servers receive authoritative data from primaries. Securing transfers via TSIG and controlling which servers may request them is fundamental to authoritative DNS hardening.
| Method | Example | Description |
|---|---|---|
dig example.com AXFR | • Transfers the complete zone file from primary to secondary • used for initial sync or after large changes • should be restricted to authorized secondaries via ACLs and TSIG | |
dig example.com IXFR=2026030900 | • Transfers only the changes since the last known serial • far more efficient than AXFR for large zones with frequent small updates • falls back to AXFR if deltas unavailable | |
Primary sends NOTIFY to ns2.example.com on zone change | • Primary proactively notifies secondaries of zone changes instead of waiting for the SOA refresh interval • reduces propagation delay significantly | |
key "transfer-key" { algorithm hmac-sha256; secret "..."; }; | • Uses HMAC-based shared keys to authenticate and verify integrity of zone transfer messages • prevents unauthorized zone pulls | |
allow-transfer { 192.168.1.2; key transfer-key; }; | BIND configuration directive restricting which servers may request zone transfers by IP address and/or TSIG key. |
Table 11: DNS Infrastructure Components
DNS infrastructure spans multiple tiers, from the client's stub resolver to the global root server network. Knowing each component's role clarifies where performance bottlenecks and security boundaries exist.
| Component | Example | Description |
|---|---|---|
13 root server addresses (a.root-servers.net through m.root-servers.net); operated by 12 independent organizations | • Serve the root zone ( .) and direct resolvers to the correct TLD nameservers• implemented via anycast providing 1500+ physical instances globally | |
.com → Verisign; .org → PIR; .uk → Nominet | • Maintain NS and DS delegations for all domains within their TLD • Verisign alone manages billions of .com/.net queries daily | |
Responds AA=1; ns1.example.com answers for example.com | • Holds the definitive DNS records for a zone • returns answers with the AA (Authoritative Answer) flag set | |
8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9) | • Performs full resolution on behalf of clients • queries root → TLD → authoritative • caches results • provides DNSSEC validation | |
OS resolver library sending queries to configured DNS server | • Minimal resolver in the OS or application • sends queries to recursive resolver rather than performing full resolution itself | |
Internal DNS forwards all external queries to 8.8.8.8 | • DNS server that forwards queries it cannot resolve locally to designated upstream servers • common in enterprise architectures | |
Multiple root servers sharing IP 198.41.0.4 routed by BGP | • Multiple servers share the same IP address • client reaches the topologically nearest instance • provides DDoS resilience and reduced latency | |
OPT record: EDNS version=0, payload=4096 | • Extends DNS with larger UDP payloads (beyond 512 bytes), signaling DNS cookie support, DNSSEC OK flag, and other capabilities • required for DNSSEC responses | |
Client cookie: 8-byte random value; server cookie: HMAC-based | • Lightweight anti-spoofing protection using client and server cookies exchanged via EDNS0 OPT • prevents reflection attacks and off-path cache poisoning |
Table 12: DNS Troubleshooting Commands
DNS troubleshooting follows a consistent workflow: confirm resolution path, verify record content, check delegation, validate DNSSEC, and test connectivity at each layer. The tools below cover every step.
| Command | Example | Description |
|---|---|---|
dig @8.8.8.8 example.com A +short | • Swiss-army DNS tool • queries specific record types against chosen servers • most versatile DNS troubleshooting command • supports +dnssec, +trace, +short modifiers | |
dig +trace example.com | • Traces the full DNS resolution path from root servers to authoritative answer • essential for diagnosing delegation issues | |
nslookup example.com 8.8.8.8 | • Interactive or command-line DNS lookup • available on Windows and Unix • less powerful than dig but ubiquitous | |
host -t MX example.com | • Simpler DNS lookup utility • good for quick checks • shows A, AAAA, and MX by default | |
delv +rtrace +multiline @8.8.8.8 example.com A | • BIND utility that performs DNSSEC validation locally using a configured trust anchor • diagnoses validation failures that dig cannot show | |
kdig @9.9.9.9 example.com +quic | • Knot DNS query tool • supports DNS over QUIC (+quic), DoH, DoT, and EDNS client subnet • used for testing modern encrypted DNS protocols | |
whois example.com | • Queries registrar records for domain registration info, nameservers, and registrar • useful for tracking down registrar-level issues | |
drill -D DNSKEY example.com | • DNS lookup tool from NLnet Labs • DNSSEC-aware • good for DNSSEC chain verification | |
resolvectl query example.com | • Systemd DNS client • queries local stub resolver on Linux • shows resolved DNS server and validation status | |
tcpdump -i eth0 port 53 | • Packet-level inspection of DNS traffic • essential for diagnosing truncation, EDNS0 issues, and identifying unexpected DNS servers | |
whatsmydns.net, dnschecker.org | • Web tools that check DNS propagation status across global resolvers • verify that record changes are visible worldwide | |
Gibson Research Corporation DNS Benchmark (Windows) | • Tests performance and reliability of DNS resolvers • useful for selecting fastest resolver for your location |
Table 13: Email Authentication DNS Records
Email authentication relies entirely on DNS as the trust medium — without correct SPF, DKIM, DMARC, and BIMI records, modern mail filtering will reject or junk your messages. These four records form an interdependent system; DMARC requires both SPF and DKIM to be meaningful.
| Record | Example | Description |
|---|---|---|
example.com TXT "v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all" | • Lists authorized mail sending IPs for the domain • receiving servers verify sending IP is permitted • -all (hard fail) vs ~all (soft fail). | |
selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjAN..." | • Publishes public key for verifying DKIM signatures • receiving servers use this key to verify messages are signed by the sending domain | |
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com" | • Policy combining SPF and DKIM alignment • specifies action (none/quarantine/reject) on authentication failures • enables aggregate and forensic reporting | |
default._bimi.example.com TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem" | • Enables brand logo to appear in email clients • requires strict DMARC policy • some providers require VMC (Verified Mark Certificate). | |
_mta-sts.example.com TXT "v=STSv1; id=20260309" | • Signals that the mail domain requires TLS for inbound SMTP • combined with a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. | |
_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com" | • Requests TLS failure reports from mail senders • enables monitoring of STARTTLS and MTA-STS enforcement failures |
Table 14: DNS Performance and Load Balancing
DNS is often the simplest lever for distributing load and directing users to geographically optimal endpoints. The techniques below range from basic round-robin to sophisticated latency-based global routing.
| Technique | Example | Description |
|---|---|---|
example.com A 1.1.1.1, example.com A 2.2.2.2 (two records) | • Multiple A/AAAA records with same name • resolver rotates responses • simplest form of load distribution • no health checking • unequal distribution possible due to caching | |
EU clients → eu.example.com, US clients → us.example.com | • Returns different IPs based on client's geographic location • reduces latency by directing to nearest datacenter • requires specialized DNS provider or GeoIP capability | |
AWS Route 53 returns lowest-latency endpoint per region | • Routes DNS queries to lowest-latency endpoint • measured from resolver to endpoint • more accurate than pure geo routing | |
80% weight to new server, 20% to old server | • Assigns percentage weight to each record set • enables gradual traffic shifting for blue-green deployments or A/B testing | |
Route 53 removes unhealthy A record from DNS responses | • DNS provider monitors endpoint health and removes failing endpoints from rotation • provides automatic failover without TTL expiry | |
Root servers, 1.1.1.1, 8.8.8.8 use anycast | • Same IP advertised from multiple PoPs • client routes to nearest BGP-closest node • provides both load distribution and DDoS resilience | |
Reduce TTL to 60s before cutover, increase after | • Lower TTL before planned migrations ensures rapid DNS propagation • standard practice: reduce 24h before cutover, raise again after confirming stability |
Table 15: DNS Standards and Protocol Details
DNS was designed in 1983 and has been extended continuously through RFCs. Understanding the protocol-level constraints — message size limits, transport choices, flag semantics — prevents hard-to-diagnose production issues.
| Concept | Example | Description |
|---|---|---|
Standard DNS query via UDP port 53 | • Default transport • 512-byte limit for standard responses • EDNS0 extends this up to 4096+ bytes • lower overhead than TCP | |
Zone transfers and responses exceeding UDP limit | • Used when response exceeds UDP payload limit (TC bit set), for zone transfers, and as primary transport in DNS over TLS • RFC 7766 modernizes TCP handling | |
OPT RR: payloadSize=4096, DO=1 | • Extends DNS with larger UDP payloads, the DO (DNSSEC OK) flag, client subnet, and DNS cookies • required for DNSSEC • negotiated in OPT pseudo-record | |
Resolver connects to 1.1.1.1:853 with TLS | • Encrypts DNS queries over TLS on TCP port 853 • standardized in RFC 7858 • supported by Android Private DNS, Stubby, and all major public resolvers | |
GET/POST to https://cloudflare-dns.com/dns-query | • DNS transported over HTTPS on port 443 • defined in RFC 8484 • indistinguishable from web traffic • deployed in Chrome, Firefox, and all major public resolvers | |
kdig @9.9.9.9 example.com +quic | • DNS transported over QUIC on UDP port 853 (RFC 9250, 2022) • offers TLS 1.3, 0-RTT resumption, and connection migration • lower latency than DoT • deployed by Quad9, Cloudflare | |
16-bit random query ID matched in response | • 16-bit identifier used to correlate responses to queries • Kaminsky attack exploited predictable IDs • source port randomization substantially mitigates this | |
UDP response with TC=1 triggers TCP retry | • When response exceeds UDP payload limit, TC bit signals client to retry over TCP • critical to monitor in high-DNSSEC environments | |
Pointer references earlier label occurrence in message | • Label compression in DNS messages reduces size by pointing to earlier occurrences of domain name labels • part of original RFC 1035 spec | |
Persistent TCP connection with multiple query-response pairs | • Modernizes DNS over TCP • recommends persistent connections and pipelining for efficiency • enables multiple queries over single connection |
Table 16: Advanced DNS Configurations
Production-grade DNS deployments go beyond simple zone hosting. Split-horizon, DNSSEC signing configurations, dynamic updates, and logging policies are the building blocks of a well-operated authoritative DNS service.
| Configuration | Example | Description |
|---|---|---|
acl "internal" { 10.0.0.0/8; 192.168.0.0/16; }; | • Named list of IP/CIDR ranges used to control access for queries, transfers, and updates • reusable across multiple allow-* statements | |
view "internal" { match-clients { internal; }; zone ... }; | • Serves different zone content to different query sources • implements split-horizon DNS with named match conditions | |
forwarders { 8.8.8.8; 8.8.4.4; }; | • Delegates unresolved queries to designated upstream servers • forward only forces exclusive forwarding• forward first falls back to recursion on failure | |
nsupdate -k keyfile.key then update add host.example.com 60 A 10.0.0.5 | • Allows authorized clients to modify zone records programmatically • secured with TSIG • used by DHCP servers, Kubernetes, and automation pipelines | |
dnssec-policy "standard" { algorithm rsasha256; }; inline-signing yes; | • BIND automatically signs zone data and maintains RRSIG records • separate signed-zone file maintained internally • simplifies DNSSEC operations | |
dnssec-policy "modern" { dnskey-ttl 3600; ksk-lifetime P365D; } | • Declarative DNSSEC key lifecycle management • defines algorithms, key lengths, TTLs, rotation schedules • reduces manual key management | |
zone "rpz.feed" { type slave; masters { 10.0.0.1; }; }; then response-policy { zone "rpz.feed"; }; | • External threat-feed zones used by BIND/Unbound for DNS firewall functionality • automatically block malicious domains via policy-driven resolution | |
logging { channel query-log { file "/var/log/named/queries.log"; }; category queries { query-log; }; }; | • Configures detailed query/response logging • essential for security monitoring, debugging, and audit trails | |
dig ANY example.com → server returns minimal response | • RFC 8482 allows servers to return minimal responses to ANY queries• prevents DNS amplification • most authoritative servers now implement this |
Table 17: DNS Protocol Enhancements and Modern Features
DNS protocol development is active: the 2020s brought encrypted transports from experimental to production-deployed, automated key management, zone integrity verification, and DDR for seamless upgrade paths. This table captures the most significant advances from 2019 to 2026.
| Feature | Example | Description |
|---|---|---|
Firefox and Chrome send DNS to cloudflare-dns.com/dns-query by default | • RFC 8484 (2018) • DNS embedded in HTTPS (port 443) • first widely deployed encrypted DNS transport • now supported by all major browsers and public resolvers | |
Android 9+ "Private DNS" setting uses DoT | • RFC 7858 (2016) • dedicated TLS on port 853 • standard for Android Private DNS and native-OS encrypted DNS on Linux (systemd-resolved). | |
Quad9 and Cloudflare support +quic on port 853 | • RFC 9250 (2022) • DNS over QUIC transport (UDP 853) • TLS 1.3, 0-RTT resumption, connection migration • less head-of-line blocking than DoT • growing deployment | |
OS queries _dns.resolver.arpa SVCB to discover resolver's encrypted endpoints | • RFC 9462 (2023) • clients automatically discover encrypted DNS support from their configured resolver via SVCB records • enables transparent upgrade from plaintext to DoH/DoT/DoQ | |
Parent registry polls _cds.example.com periodically and auto-updates DS | • RFC 7344 / RFC 8078 • child publishes CDS/CDNSKEY signaling desired DS state • parent automatically updates delegation • eliminates manual registry portal interaction for key rollovers | |
Root zone includes ZONEMD record with SHA-384 hash | • RFC 8976 (2021) • cryptographic digest of entire zone at zone apex • enables consumers of zone transfers or zone files to verify integrity • root zone adopted 2023. | |
NSEC3 record with iterations=0, salt=- | • RFC 9276 (2022) guidance: NSEC3 iterations MUST be 0, salt SHOULD be empty • high iteration counts enable DoS without meaningful security benefit • Google treats >100 iterations as broken DNSSEC | |
Browser receives HTTPS hint enabling HTTP/3 on first connection | • RFC 9460 (2023) • service binding records replace HINFO-style hints • carry ALPNs, port, IP hints • enable HTTP/3 upgrade signaling and alternative connection endpoints | |
SERVFAIL + EDE code 6 "DNSSEC Bogus" | • RFC 8914 (2020) • EDNS0 option carrying additional error detail beyond 4-bit RCODE • resolvers can explain why they returned SERVFAIL rather than just that they did | |
Non-EDNS-compliant servers began receiving EDNS queries; workarounds removed | • Industry-coordinated date when DNS software vendors dropped EDNS workarounds • servers not properly handling EDNS OPT queries became unreachable | |
IP fragmentation issues addressed; min MTU guidance | • Second industry-coordinated update • addressed IP fragmentation problems with large DNS packets • promoted use of DNS cookies and TCP fallback | |
example.com DELEG "alpn=dot ipv4hint=1.2.3.4 dohpath=/dns-query" | • Internet Draft • proposes new record type providing enhanced delegation with encrypted resolver hints • extends NS delegation to include transport and capability information |