📖 DNS: Resolution, Records and How It Gets Attacked

DNS: Resolution, Records and How It Gets Attacked

DNS is the control plane of everything else. Whoever controls a domain's DNS can receive its mail, obtain valid TLS certificates for it, and point its users anywhere. That makes the zone file one of the highest-value assets an organisation has, and it is routinely managed with less rigour than a staging server.

The resolution chain

Four distinct roles are involved, and confusing them is the source of most DNS confusion:

• Stub resolver — the tiny client in your OS or browser. It asks one question and expects a full answer.
• Recursive resolver — your ISP's, your router's, or a public one. It does the legwork and caches the results.
• Root and TLD servers — they do not know the answer; they know who to ask next. There are 13 named root server identities (a through m.root-servers.net), each served from many physical sites by anycast.
• Authoritative server — holds the actual zone data and answers with the aa (authoritative answer) flag set.

The stub asks recursively ("give me the final answer"). The resolver then works iteratively: it asks a root server for www.example.com and is referred to the .com servers; it asks those and is referred to example.com's nameservers; it asks those and gets the answer. Referrals come with glue records — the A/AAAA addresses of nameservers that live inside the zone they serve, without which ns1.example.com could never be resolved.

$ dig +trace www.example.com A        # watch the whole chain
$ dig @1.1.1.1 www.example.com A      # ask one recursive resolver
$ dig @ns1.example.com example.com SOA +norecurse   # ask the authoritative source directly

Every answer carries a TTL in seconds — how long a resolver may cache it. Set it low (300) before a migration and raise it afterwards; the change only takes effect after the old TTL has expired everywhere, so lower it a full TTL in advance. Failures are cached too: negative caching (RFC 2308) stores NXDOMAIN for the lesser of the SOA's MINIMUM field and the SOA record's own TTL. That is why a newly created record can appear broken for minutes after you fix a typo. Compare a record across public resolvers → to see propagation and caching disagreements directly.

Every record type you need, in zone-file syntax

A zone file is a list of resource records: name TTL class type rdata. A trailing dot makes a name absolute; without it, $ORIGIN is appended — forgetting the dot in an MX or CNAME target is the single most common zone-file bug, because mx1.example.net silently becomes mx1.example.net.example.com.

$ORIGIN example.com.
$TTL 3600

@       IN SOA  ns1.example.com. hostmaster.example.com. (
                2026072601   ; serial
                7200         ; refresh
                3600         ; retry
                1209600      ; expire
                300 )        ; minimum — negative-cache TTL

@       86400 IN NS    ns1.example.com.
@       86400 IN NS    ns2.example.net.

@         300 IN A     203.0.113.10
@         300 IN AAAA  2001:db8::10
www       300 IN CNAME example.com.
blog      300 IN CNAME hosting.example.net.

@        3600 IN MX    10 mx1.example.net.
@        3600 IN MX    20 mx2.example.net.

@        3600 IN TXT   "v=spf1 include:_spf.example.net -all"
_dmarc   3600 IN TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

@        3600 IN CAA   0 issue "letsencrypt.org"
@        3600 IN CAA   0 iodef "mailto:security@example.com"

_sip._tcp 3600 IN SRV  10 60 5060 sip1.example.com.
@         300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10

SOA deserves a field-by-field read, because it governs how the zone is replicated:

The rest, briefly. A and AAAA map a name to an IPv4 / IPv6 address. NS delegates a zone. MX carries a preference before the hostname and lower wins, so MX 10 is tried before MX 20; a single MX 0 . is the "null MX" of RFC 7505, meaning this domain accepts no mail. TXT holds arbitrary strings — each quoted string is limited to 255 characters and long values are split into several strings that are concatenated. SRV is _service._proto with priority, weight, port and target. CAA (RFC 8659) lists which certificate authorities may issue for the domain; CAs are required to check it. PTR lives in the reverse tree — 203.0.113.10 becomes 10.113.0.203.in-addr.arpa, and IPv6 becomes a nibble-reversed name under ip6.arpa. HTTPS and SVCB (RFC 9460) publish connection parameters — ALPN, port, address hints, Encrypted Client Hello keys — so a browser can go straight to HTTP/3 without an extra round trip.

CNAME has one rule that trips everyone: a CNAME must be the only record at its name (RFC 1034 §3.6.2, tightened by RFC 2181 §10.1, with DNSSEC signatures as the sole exception). The zone apex must carry SOA and NS records, so a CNAME there is illegal — that is why example.com cannot be a CNAME to a load balancer while www.example.com can. Vendors work around it with non-standard ALIAS/ANAME records, where the authoritative server resolves the target itself and returns the resulting A/AAAA. It works, but the lookup happens from the DNS provider's location rather than the user's, which can defeat a CDN's geographic steering. The standards-track fix is the HTTPS record in AliasMode (priority 0): example.com. 300 IN HTTPS 0 www.example.com.

Look up any single record type →, or run a full DNS audit → to pull every record type for a domain at once and grade the result.

Failure and attack surface

Cache poisoning

If an off-path attacker can get a forged answer accepted before the real one arrives, the resolver caches the lie for the whole TTL. A forged UDP answer has to match the query name and type, the destination port and the 16-bit transaction ID. When resolvers used a fixed source port, that was 16 bits of entropy — guessable at speed, which is what the 2008 Kaminsky work demonstrated. The mitigation deployed everywhere since is source-port randomisation (RFC 5452): a random ephemeral port adds roughly 16 more bits, taking the search space from tens of thousands to billions. DNS cookies (RFC 7873) and 0x20 case randomisation add more. None of it is a proof — it is a race the attacker is very unlikely to win.

DNSSEC is the actual proof. The zone signs its records (RRSIG), publishes its keys (DNSKEY), and the parent zone publishes a hash of the signing key (DS), forming a chain from the root down. A validating resolver checks the signatures and sets the ad flag; a broken chain returns SERVFAIL rather than bad data. Note what DNSSEC does not do: it authenticates, it does not encrypt — queries and answers remain in the clear. Check a domain's DNSSEC chain →.

Subdomain takeover

The mechanism is mundane, which is why it is so common. A team points promo.example.com at a hosting provider with a CNAME to example-promo.hosting-provider.net. Months later the campaign ends and someone deletes the app on the provider — but nobody deletes the DNS record. The CNAME now dangles: it points at a name the provider no longer assigns to anyone. Anyone who can register that same resource name on that provider inherits the target, and from that moment promo.example.com serves their content, on the real domain, over a real TLS certificate they can obtain themselves because they demonstrably control the host. Cookies scoped to .example.com, OAuth redirect allow-lists and CSP *.example.com entries all become theirs.

Defences are process, not technology: delete the DNS record before the resource, keep an inventory of every CNAME whose target is outside your control, and alert on targets that stop resolving. Enumerate subdomains from certificate transparency → to find the names you forgot you published.

Zone transfers

AXFR copies an entire zone to a secondary. It is essential between your own nameservers and should never be answerable to the internet, because it hands over a complete inventory of internal hostnames — vpn-test, jira-staging, backup-nas — in one request. Restrict it by IP and authenticate it with TSIG. Testing your own domain is a one-liner:

$ dig @ns1.example.com example.com AXFR
; Transfer failed.          <- the correct result from an outside address

Wildcards

A record such as *.example.com. IN A 203.0.113.20 answers for any name that does not otherwise exist. That can be convenient, but it means the zone can never return NXDOMAIN below the apex, which breaks the usual way of detecting dangling records, hides typos that should have failed loudly, and can make every random label a valid host for certificate issuance or phishing. The wildcard does not override names that exist, and it does not apply below an existing node, which surprises people often.

DNS as an exfiltration channel

Recursive resolvers are, by design, an outbound path that survives almost every egress filter. Data encoded into query labels — <base32-chunk>.tunnel.attacker.example — is forwarded by your resolver all the way to a nameserver the attacker controls, and answers can carry data back in TXT records. Protocol limits shape what it looks like: 63 characters per label, 255 for the whole name. Detection is statistical rather than signature-based: an unusual volume of unique subdomains under one parent domain, high-entropy labels, long or frequent TXT queries, and clients that talk to a resolver far more than their peers. The defence is to force all clients through a logging resolver and block direct outbound port 53.

DoH, DoT and what encryption buys you

Classic DNS is plaintext UDP or TCP on port 53 — readable and modifiable by anyone on the path. Three transports fix that between the stub and the recursive resolver: DoT (DNS over TLS, RFC 7858, TCP port 853), DoH (DNS over HTTPS, RFC 8484, an ordinary HTTPS request to a /dns-query endpoint with media type application/dns-message) and DoQ (DNS over QUIC, RFC 9250).

For operators, DoH also has a cost: it moves resolution out of the OS and into individual applications, so a browser using its own DoH resolver bypasses your internal split-horizon DNS, your filtering and your logging. That is a policy decision to make deliberately rather than discover.

Finally, the reverse tree is worth auditing too — mismatched forward and reverse records will get your mail rejected. Check PTR records and forward confirmation →.