Skip to content
Back to skills

Dns Fundamentals

ASecurity

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.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 5, 2026
ai-agentsdebugging

Security analysis

A100/100

Scanned September 5, 2026

npx -y skills add Amey-Thakur/AI-SKILLS --skill dns-fundamentals --agent claude-code

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.

Security grade badge for Dns Fundamentals
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/amey-thakur-dns-fundamentals/badge)](https://www.skillsdirectory.com/skills/amey-thakur-dns-fundamentals)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…