DNS

DNS was designed by Paul Mockapetris (RFC 882/883, 1983) to replace the centrally distributed HOSTS.TXT file, and is still specified by RFC 1034 and RFC 1035 (1987) plus a long list of updates. The namespace is a tree of labels; each zone is served by authoritative name servers, and delegation happens through NS records in the parent zone. A lookup normally involves a stub resolver on the device, which sends a recursive query to a recursive resolver (the ISP's, the company's or a public one), which in turn walks the tree iteratively: the root servers (13 named identities, a to m, each operated as many anycast instances) refer it to the TLD servers, which refer it to the domain's authoritative servers, which return the answer.

Answers are resource records such as A and AAAA (IPv4/IPv6 addresses), CNAME (alias), MX (mail exchangers), NS, SOA, PTR (reverse lookups), TXT (used for SPF, DKIM and DMARC) and CAA (which certificate authorities may issue for the domain). Every record carries a TTL that controls how long resolvers may cache it; failed lookups are cached too (negative caching, RFC 2308). TTLs explain why DNS changes "propagate" slowly and why lowering TTLs before a migration matters. Queries go over UDP or TCP port 53; the original 512-byte UDP limit is extended by EDNS(0) (RFC 6891), and truncated answers fall back to TCP.

Classic DNS has no cryptographic protection. Off-path cache poisoning relies on guessing the 16-bit transaction ID, which is why resolvers randomise source ports as well; Dan Kaminsky's 2008 attack showed how practical poisoning had become. DNSSEC (RFC 4033-4035) adds signatures and a chain of trust from the signed root via DS records, giving origin authentication and integrity but not confidentiality. For privacy, DNS over TLS (RFC 7858, port 853), DNS over HTTPS (RFC 8484) and DNS over QUIC (RFC 9250) encrypt the stub-to-resolver leg, and QNAME minimisation (RFC 9156) limits what each upstream server learns.

Many real incidents bypass the protocol entirely. If an attacker takes over the registrar or DNS-hosting account, as in the pension-fund scenario, DNSSEC offers no protection because the attacker can publish legitimately signed records; MFA on those accounts, registry lock and monitoring of NS and A changes are the relevant controls. Other recurring problems are dangling CNAME records that allow subdomain takeover, open resolvers abused for reflection and amplification DDoS, and DNS tunnelling used for command-and-control or data exfiltration. On the defensive side, protective DNS that blocks known-malicious domains and resolver query logs are cheap, high-value sources of detection.