~/learn / web-fundamentals / dns

DNS Explained

How names become addresses, how resolvers and caching really work, what each record type means, how encrypted DNS changes the picture, and what DNS reveals about an organization during reconnaissance.

beginnerupdated

DNS, the Domain Name System, is the internet’s directory. It turns names people remember into the addresses computers need, and it carries a surprising amount of other information along the way. It is also a distributed, cached, mostly-unauthenticated database, which is exactly why it is both useful for recon and a recurring source of security problems. Try the DNS lookup tool as you read.

How a lookup works

When you visit www.example.com and nothing is cached:

  1. Your computer asks a recursive resolver (your ISP’s, your company’s, or a public one like 1.1.1.1 or 8.8.8.8).
  2. The resolver asks a root server who handles .com.
  3. The root points to the .com TLD servers, which say who is authoritative for example.com.
  4. The resolver asks those authoritative name servers for www.example.com and gets the answer.
  5. The resolver caches the answer for its TTL (time to live) and returns it to you.

Watch the whole chain:

dig +trace www.example.com

Caching, TTLs, and why they matter

The TTL is a promise about how long an answer stays fresh, and it has direct security and operational consequences. A very low TTL lets an attacker who controls a name change where it points between two lookups, which is the mechanism behind DNS rebinding: a name resolves to a public IP when the browser first checks it, then to an internal IP (like 127.0.0.1 or a metadata address) moments later, letting a web page reach services it should not. It is the DNS half of the SSRF story. High TTLs, conversely, mean a compromised or stale record lingers in caches long after you fix it.

Record types

Type Holds Example
A An IPv4 address 93.184.215.14
AAAA An IPv6 address 2606:2800:21f:cb07:...
CNAME An alias to another name www to example.netlify.app
MX Mail servers, with priority 1 aspmx.l.google.com
NS The domain’s authoritative name servers bart.ns.cloudflare.com
TXT Free text, for verification and email policy v=spf1 include:_spf.google.com ~all
SOA Zone administration details Primary server, serial, timers
CAA Which CAs may issue certificates 0 issue "letsencrypt.org"
SRV Location of specific services SIP, XMPP, Active Directory
PTR Reverse lookup, IP to name Mail server reputation

Email records worth understanding

Three TXT-based records protect a domain’s email from spoofing, and together they are what makes a From address trustworthy:

  • SPF lists which servers may send mail for the domain (checked against the envelope sender’s IP).
  • DKIM publishes a public key; receiving servers verify a signature the sending server added, which also detects tampering in transit.
  • DMARC, at _dmarc.example.com, tells receivers what to do when SPF or DKIM fail and where to send reports, and it requires alignment with the visible From domain.

A domain with no DMARC, or p=none, is far easier to impersonate in phishing. The email header analyzer walks a received message through exactly these checks.

Encrypted DNS

Classic DNS is plaintext UDP, so anyone on the path sees every name you look up and can tamper with answers. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query to the resolver, closing the eavesdropping and on-path-tampering gap (the resolver itself still sees your queries). A related hardening trick, DNS 0x20, randomizes the case of the queried name and checks it is echoed back, which raises the bar for off-path cache poisoning. The DNS lookup tool uses DoH under the hood.

What DNS reveals in recon

DNS records are public by design, and they map an organization’s footprint:

  • The email provider, from MX records (Google Workspace, Microsoft 365, self-hosted).
  • SaaS vendors, from TXT verification tokens (google-site-verification, MS=, atlassian-domain-verification).
  • Hosting and CDN, from A records and CNAME targets.
  • Subdomains, from certificate transparency logs (every public certificate names its hosts) and from brute forcing names against the resolver.

DNS security issues

Issue What it is
Subdomain takeover A CNAME points to a deleted cloud resource an attacker can re-register and then serve content from your subdomain
Zone transfer exposure A misconfigured name server hands the full zone to anyone who runs dig axfr
Cache poisoning Tricking a resolver into caching a false answer; DNSSEC and 0x20 raise the cost
Dangling records Old A records pointing at IPs the organization no longer controls

DNSSEC signs DNS answers so resolvers can verify authenticity (not confidentiality). A validating resolver sets the AD (authenticated data) flag on verified answers. It defends against forged answers; it does not hide your queries, which is what DoH and DoT are for.

Field notes: DNS is the recon goldmine

Before touching the app, you map its attack surface through DNS, because every forgotten subdomain is a way in:

  • Certificate Transparency logs list every TLS certificate ever issued, including for internal-sounding hosts. crt.sh/?q=%25.example.com returns subdomains no wordlist would guess (vpn, jira-staging, old-admin). This is the single highest-yield recon source.
  • Passive and active enumeration. subfinder -d example.com and amass enum -d example.com pull from dozens of sources; then resolve and probe with httpx.
  • Zone transfer (AXFR). A misconfigured secondary nameserver hands you the entire zone: dig AXFR example.com @ns1.example.com. Rare now, but a full map when it works.

Field notes: subdomain takeover and email spoofing

  • Subdomain takeover. A CNAME that points at a deprovisioned cloud resource (shop.example.com -> example.github.io for a deleted repo, or an unclaimed S3 bucket, Heroku app, or Azure host) lets you register that resource and serve content from the victim’s subdomain, with their cookies and trust. subjack and nuclei flag dangling records. Any NXDOMAIN or “no such app” page behind a live DNS record is a candidate.
  • Email spoofing via SPF/DKIM/DMARC gaps. Read the records: dig TXT example.com for SPF, dig TXT _dmarc.example.com for DMARC. A missing DMARC record, or p=none, means you can often spoof mail from the domain. An SPF record ending in ~all (softfail) rather than -all (hardfail) is weak. These are reported constantly in phishing-readiness assessments.
  • DNS rebinding turns a victim’s browser into a proxy into their internal network by flipping a low-TTL record from your IP to an internal one after the page loads. See SSRF.

Enumerate and test only domains you own or are authorized to assess; CT-log and passive recon are public, but takeover and spoofing proofs must stay in scope.

Try it

dig +short A example.com
dig +short MX example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

Or use the DNS lookup tool, which runs these over DNS-over-HTTPS and explains what it finds.