DNS Cheatsheet

1. The mental model

DNS is a distributed system that maps names to data. It is not one server, and by itself it neither encrypts nor authenticates an answer.

A name is made of labels separated by dots and is read right to left; the final dot represents the root. www.example.com. is absolute; www.example.com may be completed using zone context.

1. 1

   Application and stub

   The device checks local caches and sends the question to its configured resolver.

2. 2

   Recursive resolver

   If no valid answer is cached, it looks up the data for the client.

3. 3

   Root

   It points to the TLD servers that can answer for .com, .it, and other TLDs.

4. 4

   TLD

   It points to the authoritative servers delegated for the domain, such as example.com.

5. 5

   Authority

   It returns the zone answer, for example an A record or a CNAME.

6. 6

   Cache and answer

   The resolver caches the data for its TTL and returns the result to the client.

2. Names, records, and zones

A record binds an owner name to a type and value. Records with the same owner and type form an RRset and share a TTL.

3. Reading a zone

A zone is an administratively managed part of the namespace. A final dot marks an absolute name; without it, $ORIGIN may be appended.

$ORIGIN example.com.
$TTL 3600

@   IN SOA ns1.example.com. hostmaster.example.com. (
        2026102301 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        300        ; negative cache TTL
)
@   IN NS  ns1.example.com.
@   IN NS  ns2.example.com.
@   IN A   192.0.2.10
www IN CNAME @

mail IN A 192.0.2.25
@    IN MX 10 mail.example.com.
@    IN TXT "v=spf1 mx -all"
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
selector1._domainkey IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_PROVIDER"

4. Query commands

dig is the most flexible tool on Linux and macOS. On Windows, use nslookup or Resolve-DnsName. Query only servers you are allowed to use.

dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com MX +noall +answer
dig example.com NS +noall +answer
dig @1.1.1.1 example.com A

dig +trace www.example.com A
dig @ns1.example.com example.com SOA +norecurse
dig +tcp example.com A
dig -x 192.0.2.10

nslookup -type=A example.com
nslookup -type=AAAA example.com
Resolve-DnsName example.com -Type A

5. Reading answers and errors

Check status, flags, and answer first. NOERROR does not guarantee that the requested type exists: an answer can be empty (NODATA).

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1234
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
example.com. 300 IN A 192.0.2.10

Useful flags

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1234
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
example.com. 300 IN A 192.0.2.10

6. Caches, TTL, and delegations

Resolvers cache answers to reduce latency and load. Each cache expires data according to the TTL it saw when it obtained the answer.

• TTL is measured in seconds: 3600 is one hour.
• The displayed TTL is the remaining cache time; different resolvers can show different values.
• A negative answer (NXDOMAIN/NODATA) can be cached using the zone SOA parameters.
• Glue is an address published by the parent for an NS inside the delegated child zone. It breaks a resolution loop and is a starting hint, not the authoritative source for child data.
• Before a service migration, lower the TTL ahead of time and wait at least the old TTL before changing the data.
• NS delegation and the parent DS record have their own caches; changing the zone apex does not replace them.

7. DNSSEC: authenticity, not secrecy

DNSSEC lets a validating resolver check data origin and integrity along a trust chain. DNS data remains public.

DS links the child key to the parent. Expired keys, missing signatures, or mismatched DS records can cause SERVFAIL on validating resolvers. NSEC/NSEC3 proves absence; it does not make the zone secret.

dig example.com A +dnssec
dig example.com DNSKEY +dnssec
dig example.com DS
delv example.com A

8. Encrypted transport and privacy

DoH, DoT, and DoQ protect the link between a device and its resolver. The chosen resolver can still see and log queries.

9. Threats and defensive controls

DNS defense needs controls on resolvers, authoritative servers, credentials, and the systems that consume DNS results.

10. Change checklist

Plan each change like infrastructure work: check dependencies, timing, rollback, and health signals.

1. 01Confirm owner, scope, approval, and change window.
2. 02Export the current zone and record values needed for rollback.
3. 03Check dependencies: NS, glue, MX, CAA, TXT, DNSSEC, and names used by other services.
4. 04Lower TTL ahead of time; wait at least the old TTL before the planned change.
5. 05Validate syntax and consistency: updated SOA serial, existing targets, and no conflicting CNAME.
6. 06For DNSSEC, follow the provider procedure for publishing keys and DS in the correct order.
7. 07Limit AXFR to authorized secondaries; TSIG authenticates and protects transfer integrity, but does not encrypt it.
8. 08Check authoritative servers first, then multiple trusted resolvers; also check IPv4, IPv6, and mail.
9. 09Monitor SERVFAIL, unexpected NXDOMAIN, latency, and application errors; keep a rollback procedure.

11. Quick troubleshooting

Compare authoritative and recursive answers, then narrow the issue to name, type, delegation, cache, network, or validation.

12. Ports and transports

Ports describe common transports; they do not prove which service is running or whether it is trustworthy.