Reason about DNS records, resolution, TTLs, and caching so name changes land predictably instead of mysteriously. Use when configuring a domain, moving a service, or debugging why a hostname resolves to the wrong place.
Installs into .claude/skills of the current project.
Are you the author of Dns Fundamentals?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/amey-thakur-dns-fundamentals)
---
name: dns-fundamentals
description: Reason about DNS records, resolution, TTLs, and caching so name changes land predictably instead of mysteriously. Use when configuring a domain, moving a service, or debugging why a hostname resolves to the wrong place.
---
# DNS fundamentals
DNS is the first hop of almost every request and the last place people
look when something breaks. Most DNS incidents are not exotic: a TTL
was longer than the change window, a record was edited at a provider
nobody queries, or a stale cache still holds the old answer.
## Method
1. **Know which record answers which question.** A and AAAA map a name
to an address, CNAME aliases one name to another, MX routes mail,
TXT carries verification and policy, and NS delegates a zone.
Picking the wrong type is the most common misconfiguration, and a
CNAME at the zone apex is invalid in plain DNS, so it needs the
provider's ALIAS equivalent.
2. **Treat TTL as your change window.** A record's TTL is how long
resolvers may keep the old answer, so a 24-hour TTL means a 24-hour
tail after any change. Lower it well before a planned move, make
the change, then raise it again once the new value is stable.
3. **Verify at the authoritative server, not just locally.** Query the
zone's own nameservers to see the truth, then a public resolver to
see what the world currently gets. A difference between the two is
cache, not misconfiguration, and it clears with time rather than
with more edits.
4. **Confirm you are editing the zone that is live.** Domains often
have records at a registrar, a DNS host, and a CDN, and only the
delegated nameservers matter. Check the NS records before spending
an hour editing a zone nobody queries.
5. **Give DNS its own redundancy.** Multiple nameservers across
providers survive one provider's outage, and health-checked records
steer traffic away from a dead endpoint (see multi-region-design).
DNS is a dependency like any other.
## Boundaries
- DNS resolves names to addresses; it does not load balance with any
precision. Round-robin records spread requests roughly at best, and
caching skews the split (see load-balancing for real control).
- Propagation is a misnomer: nothing pushes, everything expires. If a
change is not visible, suspect a cached TTL, not a stuck record.
- Registrar operations such as transfers, locks, and expiry sit
outside the zone and can take days regardless of your TTLs.