Domain Name System (DNS) is the distributed database that translates memorable domain names (www.example.com) into the IP addresses (93.184.216.34) that are actually used on the wire. Web, mail, APIs, CDNs, SaaS — almost everything you do on the modern internet routes through this resolution. The default is UDP/TCP 53, and the encrypted variants use 853 (DoT) / 443 (DoH / DoQ). This article covers the practical view in order: the hierarchy, the resolution flow, the major resource records, how to use dig, DNSSEC / DoT / DoH / DoQ, and the major attacks and countermeasures.
What is DNS doing #
DNS is the protocol that distributes "domain name → IP address" mappings at internet scale, and is also a distributed database in which authoritative servers and resolvers around the world cooperate. Nobody manages one giant file; each domain operator publishes responsibly only their own slice, and resolvers pull what they need on demand.
The moment you type www.example.com into a browser, the OS stub resolver hands the query to an upstream full resolver, and that full resolver walks the hierarchy from root → TLD → authoritative server, collecting the answer along the way. The result is cached for TTL seconds, and the next lookup returns in milliseconds.
In 1983, Paul Mockapetris designed it (RFC 882/883) to solve the limits of ARPANET's centrally-managed HOSTS.TXT. The standard was finalised in 1987 as RFC 1034 / 1035, and UC Berkeley's BIND became the de facto implementation. Extensions kept piling on: EDNS (1999) / DNSSEC (2005) / DoT (2016) / DoH (2018) / DoQ (RFC 9250, 2022).
What DNS can actually do #
- Forward lookup name → IP (A / AAAA)
- Reverse lookup IP → name (PTR,
in-addr.arpa) - Mail routing (MX) / Sender authentication (SPF / DKIM / DMARC, distributed via TXT)
- Service discovery (SRV / SVCB / HTTPS RR)
- Certificate issuance policy (CAA) / ACME challenges (TXT)
- Response authenticity (DNSSEC: DNSKEY / RRSIG / DS / NSEC)
Hierarchy and the delegation model #
DNS is an inverted tree rooted at . (the root). Each organisation is delegated authority over its own zone by the zone above it. Delegation is expressed by NS records — the parent zone (com) saying "the authority for example.com is ns1.example.com" is what tells a resolver where to look next.
. (root) ─ ICANN / IANA
│
┌───────────┼───────────┐ ← NS delegation
│ │ │
com jp org # TLD (Verisign / JPRS / PIR)
│ │ │
│ ┌─────┴─────┐ │ ← NS delegation
│ │ │ │
example co.jp ne.jp … # 2nd-level (organisations / companies / providers)
│
┌─────┼─────┐
│ │ │
www mail api # subdomains (hosts)FQDN and labels #
The fully-qualified form of a domain name uses . as a separator and is written as www.example.com. (labels further to the right are higher in the tree). The trailing . stands for the root and strictly speaking should always be there.
- Label — each
.-separated piece. Up to 63 octets - FQDN (Fully Qualified Domain Name) — the full form including the root. Up to 253 octets total
- Case-insensitive —
Example.COM=example.com
However many billions of domains there are, the root only knows "go ask .com or .jp." Each TLD only returns "the authoritative NS for this registered domain is here." It scales because nobody knows the whole thing — that's the underlying design principle of DNS.
The main components #
Name resolution requires multiple kinds of server to cooperate. Each has a different "what it holds, and what it returns."
| Component | Role | Examples |
|---|---|---|
| Root servers | Serve the root zone .. Don't hold final answers — only return "the authority for .com is over there" | a.root-servers.net through m.root-servers.net (13 letters + anycast = 1000+ physical instances) |
| TLD servers | Manage TLD zones like .com / .jp. Return "the authority for this domain is over there" | Verisign (.com) / JPRS (.jp) / PIR (.org) |
| Authoritative DNS servers | Hold the actual records for a specific zone and return final answers (AA=1) | Cloudflare DNS / AWS Route 53 / Google Cloud DNS / Akamai |
| Full resolvers (recursive) | Walk from the root, aggregate and cache results. Only the final answer goes back to the client | Cloudflare 1.1.1.1 / Google 8.8.8.8 / Quad9 9.9.9.9 / OpenDNS / ISP resolvers |
| Stub resolvers | A lightweight client built into the OS. Goes through getaddrinfo() and just forwards to an upstream full resolver | Linux glibc resolver / systemd-resolved / Windows DNS Client |
| Forwarders / caching DNS | Sit inside an organisation, cache internal queries and forward outside. Internal-zone resolution stays local | Unbound / dnsmasq / Windows DNS Server (internal AD) |
Notable public resolvers #
- Cloudflare —
1.1.1.1/1.0.0.1(DoT/DoH out of the box, focus on low latency) - Google Public DNS —
8.8.8.8/8.8.4.4(the original public resolver) - Quad9 —
9.9.9.9(also filters known malware C2 domains) - OpenDNS —
208.67.222.222(Cisco-owned, category-based filtering)
The resolution flow #
A canonical example: looking up the A record for www.example.com. The client sends a recursive query (RD=1) to a full resolver, and the full resolver then walks step by step from the root, following each referral via iterative queries.
getaddrinfo("www.example.com"). The OS forwards to the upstream resolver listed in /etc/resolv.conf or handed out by DHCP.www.example.com recursively" is sent to e.g. 8.8.8.8. The client just waits.a.gtld-servers.net for the .com TLD."example.com is ns1.example.com."www.example.com IN A 93.184.216.34 with AA=1 (authoritative answer). That's the final answer.93.184.216.34 to the client. The app then opens a TCP connection to it.Try it yourself #
Set the domain and the IP the authoritative server returns, then press resolve to walk one step at a time through the queries. Watch the delegation descend root → TLD → authoritative with your own values.
Recursive vs iterative — who does what #
- Recursive — between client (stub) and full resolver. "Just give me the final answer"
- Iterative — between full resolver and each authoritative server. "Tell me what you know; if you don't have it, a referral is fine"
A resolver that accepts recursive queries from the open internet (an "open recursive") becomes a launchpad for DNS Amplification attacks. The internet-facing authoritative server and the internal resolver should always be separated, and the resolver should restrict callers by source IP. This is the cardinal operational rule.
Cache and TTL — how to choose #
- Short TTL (60–300 s) — CDN / failover targets. Switching is fast but upstream queries are frequent
- Medium (3600 s = 1 hour) — ordinary A / AAAA. A balance of change rate and load
- Long (86400 s = 1 day) — NS / MX / SOA. Organisational data that rarely changes
The major resource records (RR) #
A "record" (Resource Record) is the unit of data DNS returns. Types each have their own purpose; the ones you actually meet in operations are these.
| Type | Purpose | Example |
|---|---|---|
| A | Name → IPv4 address | example.com. 86400 IN A 93.184.216.34 |
| AAAA | Name → IPv6 address | example.com. 86400 IN AAAA 2606:2800:220:1:: |
| CNAME | Alias. Forwards e.g. www → apex.example.com | www IN CNAME apex.example.com. |
| NS | The authoritative servers for the zone. Used to express delegation | example.com. IN NS a.iana-servers.net. |
| MX | Mail destination. Priority + Hostname pair | example.com. IN MX 10 mail.example.com. |
| TXT | Arbitrary text. SPF / DKIM / DMARC / ACME challenges / domain ownership verification | "v=spf1 include:_spf.google.com ~all" |
| PTR | IP → name (reverse). Lives under the in-addr.arpa zone | 34.216.184.93.in-addr.arpa. IN PTR example.com. |
| SOA | Start of Authority. Serial / refresh / retry / expire / minimum TTL | ns1 admin 2026051901 7200 3600 1209600 86400 |
| SRV | Service location. Form _service._proto.name | _sip._tcp.example.com. IN SRV 10 5 5060 sip.example.com. |
| CAA | Restricts which CAs can issue a certificate for this domain | example.com. IN CAA 0 issue "letsencrypt.org" |
| DNSKEY / RRSIG / DS | DNSSEC public key, signatures, and the delegation signer at the parent zone | Detailed in §07 below |
| HTTPS / SVCB | Service binding (RFC 9460, 2023). Distributes HTTP/3 and ALPN hints over DNS | example.com. IN HTTPS 1 . alpn="h3,h2" |
RFC 1034 forbids CNAME at the apex (e.g. example.com) — it can't coexist with the other required RRs (SOA, NS, MX, …). DNS hosting providers offer vendor-specific workarounds — ALIAS / ANAME / Cloudflare's CNAME flattening. CNAME on a subdomain (www) is fine.
A practical guide to dig #
dig (Domain Information Groper) is the DNS query tool that ships with BIND. For diagnosis, troubleshooting, and packet observation it has the most information density. Knowing just this much will cover most of the day job.
$ dig example.com
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
;; AUTHORITY SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)Switching the record type #
$ dig example.com MX # Mail servers
$ dig example.com NS # Authoritative NS list
$ dig example.com TXT # SPF / DKIM / verification
$ dig example.com AAAA # IPv6
$ dig example.com SOA # Serial and other admin info
$ dig example.com CAA # Permitted CAs
$ dig example.com ANY # Everything (some authorities refuse)Naming the server explicitly #
$ dig @8.8.8.8 example.com # via Google Public DNS
$ dig @1.1.1.1 example.com # Cloudflare
$ dig @9.9.9.9 example.com # Quad9
$ dig @ns1.example.com example.com SOA # Directly at the authority (bypasses cache)Tracing iterative resolution #
+trace walks referrals starting from the root and prints each step exactly as it happened. It is the fastest way to figure out "which stage is broken."
$ dig +trace www.example.com
. 518400 IN NS a.root-servers.net.
; ↑ NS list from the root (the 13 letter set)
com. 172800 IN NS a.gtld-servers.net.
; ↑ referral to the .com TLD
example.com. 172800 IN NS a.iana-servers.net.
; ↑ referral to the example.com authority
www.example.com. 86400 IN A 93.184.216.34
; ↑ final answer from the authority (AA=1)Short / detailed / reverse #
$ dig +short example.com
93.184.216.34
$ dig +noall +answer example.com
example.com. 86400 IN A 93.184.216.34
# Reverse: IP → name
$ dig -x 93.184.216.34
34.216.184.93.in-addr.arpa. 86400 IN PTR example.com.Including DNSSEC #
$ dig +dnssec example.com
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2 ...
# If the ad flag (Authentic Data) is set, DNSSEC validation succeeded
example.com. 3600 IN A 93.184.216.34
example.com. 3600 IN RRSIG A 13 2 3600 ...
$ dig example.com DNSKEY +short # The zone's public keys
$ dig example.com DS +short # Key fingerprint placed at the parent zoneEDNS buffer / force TCP / bulk queries #
$ dig example.com +bufsize=4096 # Set EDNS UDP buffer to 4096
$ dig example.com +tcp # Force TCP/53 (handle TC=1 truncation)
$ dig example.com +notcp +ignore # Don't escalate to TCP even on truncation (testing)
$ dig -f domains.txt # Batch-query the names in a fileOther query tools #
Beyond dig, different tools fit different environments and purposes. For checking encrypted DNS (DoT / DoH) the easiest tool is kdig.
| Tool | Position | What it's good at |
|---|---|---|
| dig | Ships with BIND, UNIX standard | Most information. Diagnosis, traces, DNSSEC, scripting — all of it |
| nslookup | Old-school, default on Windows | Simple. Good for a quick lookup on Windows. Not enough info for diagnosis |
| host | Ships with BIND, the simpler sibling | Concise output, quick name ⇄ IP checks |
| drill | NLnet Labs (ldns) | Visualises DNSSEC chain validation |
| kdig | Ships with Knot DNS | Verifying DoT / DoH; quickest to track new extensions |
| whois | Registration lookup | Owner / registrar / delegated NS. Strictly speaking not DNS |
$ nslookup example.com # Basic
$ nslookup example.com 8.8.8.8 # Choose a server
$ nslookup -type=MX example.com
$ host example.com
$ host -t MX example.com
$ host -a example.com # Equivalent of ANY
$ host 93.184.216.34 # Reverse lookup
$ whois example.com # Registration info / NS setupDNSSEC / DoT / DoH / DoQ #
Plain DNS is cleartext over UDP/53. ISPs, public Wi-Fi, and on-path attackers could easily eavesdrop, tamper, or inject fake answers. Four extensions address this incrementally. DNSSEC provides authenticity, and DoT / DoH / DoQ provide confidentiality — the roles differ, so they are used together.
DNSSEC — proving authenticity with public-key crypto #
RFC 4033-4035 (2005). The zone publishes DNSKEY (public keys) and RRSIG (signatures over each RR), and the parent zone publishes a DS (a fingerprint of the child's key). That creates a verification chain — the Chain of Trust — from root → TLD → authoritative zone. When the resolver successfully validates, the AD flag in the response header is set.
- DNSKEY — the zone's public key
- RRSIG — signature over each RR set
- DS — child's key fingerprint, stored at the parent
- NSEC / NSEC3 — signed proof of non-existence (so NXDOMAIN itself can't be forged)
DNSSEC only guarantees that the response wasn't tampered with. On-path observers can still read the contents. To hide the contents too, combine it with DoT / DoH / DoQ. "Authenticity (DNSSEC) × confidentiality (DoT-style)" is the complete picture.
DoT (DNS over TLS, RFC 7858) #
DNS queries and responses wrapped in TLS over TCP/853. Protects against eavesdropping and tampering by intermediate ISPs and public Wi-Fi. Can be applied at OS level via Android 9+ "Private DNS" or iOS 14+.
$ kdig -d @1.1.1.1 +tls example.com
;; DEBUG: TLS, imported X certificate
;; DEBUG: TLS, established
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
# Fixed at TCP/853. The query flows after certificate validation succeedsDoH (DNS over HTTPS, RFC 8484) #
The query is encapsulated in HTTPS POST/GET. Because it uses the same TCP/443 as ordinary HTTPS, blocking just DNS at a firewall becomes hard. Firefox / Chrome / Edge can enable it transparently inside the browser alone.
$ kdig -d @8.8.8.8 +https example.com
;; DEBUG: HTTPS session (HTTP/2)
;; DEBUG: stream id=1, response received
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
# HTTPS POST /dns-query, content-type: application/dns-messageDoQ (DNS over QUIC, RFC 9250, 2022) #
The newest spec, carrying DNS over QUIC (the transport beneath HTTP/3). 0-RTT resumption and multiplexed streams mean lower latency than DoT. Modern resolvers like AdGuard and NextDNS are rolling out support.
$ kdig @dns.adguard.com +quic example.com
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34
# UDP/443 (QUIC) with 0-RTT and parallel streamsDoT uses dedicated port 853, so "this is DNS" is externally visible (the contents are hidden). Suits OS-wide application. DoH is indistinguishable from ordinary HTTPS, so it punches through censorship and filtering — though that's also why corporate environments dislike it as "DNS outside their control." The two are complementary rather than competing.
Major attacks and countermeasures #
Because DNS is the root of trust, it attracts attacks. The main ones, and what you can do about them today.
Disclosed by Dan Kaminsky, this critical flaw affected every resolver of its era. While a resolver is querying upstream, the attacker floods it with fake responses. The DNS of the time used only a 16-bit transaction ID to match responses, so a birthday attack made forged answers land easily. Once the cache was poisoned, every user got the bad IP until TTL expired.
Mitigation: source port randomization (16+16 bits of entropy) — every major resolver has shipped this. The root fix is DNSSEC.
An on-path attacker on the local segment (after ARP spoofing, say) returns forged DNS answers. The assumption that "the ISP is trustworthy" collapses, which is why this is nasty on free Wi-Fi.
Mitigation: DoT / DoH for end-to-end encryption, trustworthy resolvers, VPN.
Abuses the "small query, large response" property of DNS for reflection DDoS. The attacker spoofs the source IP to be the victim, queries an open recursive resolver for ANY or DNSKEY, and the resolver fires a huge response (amplification factor of 100×+) at the victim, saturating their bandwidth.
Mitigation: don't run open recursive (internal-only) / BCP 38 (Source Address Validation) so ISPs block spoofed sources / Response Rate Limiting (RRL) to throttle excessive answers to the same source.
Encode data inside DNS queries and responses, using the DNS channel the firewall is allowing to carry C2 traffic or exfiltrated data. dnscat2 / iodine are well-known. Slow, but hard to detect.
Mitigation: monitor query length / frequency / pattern (unusually long TXT responses, large query volume to a specific domain) / DPI / Response Policy Zone (RPZ) to sinkhole known C2 domains.
A subdomain like old-blog.example.com still CNAMEs to an external service (GitHub Pages / Heroku / S3 / Azure ...), but the resource on the service side has been deleted. If the attacker can create a resource of the same name, they fully hijack that subdomain — bypassing CORS and same-origin Cookie protections, leading straight to phishing or MFA bypass.
Mitigation: delete CNAMEs when retiring services / take inventory regularly / use automation (subjack / nuclei).
Mass-query random non-existent subdomains (xyz123.example.com). The resolver gets no cache hits and has to ask the authoritative server every time, so the authoritative server is overloaded.
Mitigation: rate-limit traffic to the authoritative server / cache NXDOMAIN at upstream / spread the load with Anycast.
Operational best practices #
The basic set of "do this and incidents drop" practices, broken down by authoritative DNS / resolver / domain management.
- Separate authoritative and resolver — co-located, the open-recursive risk goes up
- At least 2 NS hosts across different AS / geographies (so the other one keeps resolving if one falls over)
- Anycast delivery to absorb broad DDoS (standard on hosting platforms like Cloudflare / Route 53 / NS1)
- Sign with DNSSEC and register the DS at the parent zone (completes the Chain of Trust)
- Use CAA records to restrict which CAs can issue certificates for your domain (mis-issuance / takeover protection)
- Publish SPF / DKIM / DMARC correctly as TXT — the basics of anti-spoofing for email
- Restrict zone transfer (AXFR) via allowlist — don't hand the entire zone to any caller
- Never open recursive — always restrict by source IP
- Source port randomization enabled (Kaminsky mitigation)
- DNSSEC validation enabled (default-recommended in Unbound / Knot Resolver / BIND)
- QNAME minimization (RFC 7816) — send the authority only the minimum necessary labels
- Response Rate Limiting (RRL) to prevent being used as an amplification reflector
- RPZ to sinkhole known malware C2 / phishing domains
- 2FA on the registrar plus registrar lock (domain hijack protection)
- Delete CNAMEs when retiring — the launching point for subdomain takeover
- Pick TTLs per purpose — short for A records that need fast cutover; long for organisational NS / MX
- Take inventory regularly (stale TXT / CNAME / old MX records widen the attack surface)
- Monitor certificate expiry and DNSKEY rollovers