Le Quang Lam
← All writing

Configuring DNS records

September 12, 2026·7 min read·software

The journey of a web request covers how a name gets resolved — browser cache, hosts file, OS cache, resolver, root, TLD, authoritative. This note picks up where that left off: you're on the other side now, the one who has to put the records there so that walk ends in the right answer.

What a DNS record actually is

A record is four fields. That's the whole data model:

lamlq.dev.    3600      IN        A      216.198.79.1
└────┬───┘    └─┬┘    └──┬─┘    └─┬─┘    └─────┬────┘
   name        TTL     class     type        value

Name is what's being asked about. TTL is how many seconds a resolver may cache the answer. Class is always IN (Internet). Type decides how the value is interpreted. Value is the answer.

Every DNS provider's web UI is just a form over these four fields, usually with the class hidden and the trailing dot stripped. When a UI asks for "Host" and offers @ as an option, @ means the root domain itself — lamlq.dev. — and a bare www means www.lamlq.dev.. The provider appends the rest for you.

Record types worth knowing

DNS infrastructure itself

  • NS (Name Server) — delegation. Which nameservers are authoritative for this zone, as shown above.
  • SOA (Start of Authority) — one per zone, holding the zone's admin metadata: primary nameserver, a serial number that increments on every change, and the timing values secondary nameservers use to know when to refresh their copy.

Both are created automatically when you add a domain to a provider — that's exactly why they're always sitting at the root: there's no way to create a root that lacks them.

Routing traffic

  • A (Address) — name → IPv4 address. This is what the root of lamlq.dev uses to reach Vercel.
  • AAAA (informally "quad-A") — name → IPv6 address. Same job, longer address.
  • CNAME (Canonical Name) — name → another name, which then gets resolved in turn. This is what www uses:
lamlq.dev.        3600  IN  A      216.198.79.1
www.lamlq.dev.    3600  IN  CNAME  67ccdd184e026976.vercel-dns-017.com.

There's a real reason for this split. A CNAME says "for this name, go ask about that name instead" — and the spec requires that a name with a CNAME have no other records. The root of a domain is obligated to carry NS records (and usually SOA), so a CNAME at the root is illegal by construction. Most providers simply refuse to save it.

Hence the split: an A record at the root pointing at a Vercel IP, a CNAME at www pointing at a Vercel hostname. The CNAME is the better mechanism where it's allowed — Vercel can change the IP behind that hostname without you touching anything — which is exactly what you give up at the root by pinning a literal address.

Mail routing

  • MX (Mail Exchange) — which mail servers accept mail for this domain, each with a priority number (lower wins, equal values load-balance).
  • TXT (Text) for SPF (Sender Policy Framework — which servers may send as you), DKIM (DomainKeys Identified Mail — public key for signing outbound mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance — what receivers should do when SPF or DKIM fails).

lamlq.dev has no MX records — managing DNS doesn't mean configuring every record type, only the ones your domain actually needs.

Verification and security

  • TXT (Text) — also the generic "prove you control this domain" slot. Google, and most SaaS onboarding flows, hand you a string to publish:
$ dig lamlq.dev TXT +short
"google-site-verification=lmK0PpcGsVZ8kAe_Gx5L1yrEcYiotyHhkoZlBl57DRM"
  • CAA (Certification Authority Authorization) — the list of certificate authorities allowed to issue certs for this domain. Absent means "anyone may," which is the default most domains quietly run on.

TTL is a cache, with the usual trade-off

TTL is a cache expiry, and it buys the same thing every cache buys, at the same price:

  • Low TTL (60–300s) — changes take effect fast, resolvers ask more often.
  • High TTL (3600s+) — fewer lookups, but a change you made ten minutes ago is invisible to anyone holding a cached answer.

lamlq.dev sits at 3600 — one hour — which is a reasonable default for records that rarely move.

The common failure: you migrate to a new host, update the A record, and dig from your machine confirms the new IP. But resolvers that cached the old record beforehand keep serving it until their hour runs out — so a slice of your traffic keeps landing on the old server, and you're left comparing two sets of logs.

The fix is a day ahead of the migration, not during it: drop the TTL to 300 first, wait a full old-TTL period for the low value to spread, then make the change, then raise it back once things are stable. TTL changes are themselves subject to the old TTL, which is the part that catches people.

Reading dig output

dig is the tool. Default output is verbose, but every section earns its place:

$ dig lamlq.dev A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50516
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;lamlq.dev.                    IN      A

;; ANSWER SECTION:
lamlq.dev.             3600    IN      A       216.198.79.1

;; Query time: 278 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
  • HEADER — status: NOERROR means the query succeeded. NXDOMAIN means the name doesn't exist; NOERROR with ANSWER: 0 means the name exists but has no record of that type, which is a meaningfully different problem and the distinction most worth internalizing here.
  • QUESTION — what was asked, echoed back. Useful for catching a typo or an unintended search-domain suffix.
  • ANSWER — the records themselves, in the four-field layout from the top of this post.
  • AUTHORITY / ADDITIONAL — which nameservers are authoritative, and any addresses thrown in for free. Often empty on a cached answer.
  • SERVER — who answered. Here 1.1.1.1, a public resolver, not the authoritative source.

That last line is why the TTL in an answer is a countdown, not a constant: a resolver decrements it as the entry ages in its cache — a direct read of how much staleness is left.

Querying a specific resolver

To step around local and ISP caching, name the resolver:

$ dig @8.8.8.8 lamlq.dev A +short
216.198.79.1

And to get the truth with no cache in the path at all, ask an authoritative nameserver directly — the aa (authoritative answer) flag in the response confirms you reached it:

$ dig @ns1bcp.name.com lamlq.dev A +short
216.198.79.1

During a migration this pairing is the whole diagnostic: authoritative shows the new value, a public resolver still shows the old one, and the gap between them is your remaining TTL.

Checking each name independently

Root and www are separate records that fail separately, so verify them separately:

$ dig lamlq.dev A +short
216.198.79.1

$ dig www.lamlq.dev +short
67ccdd184e026976.vercel-dns-017.com.
216.198.79.1

The www query returns two lines because +short prints the full chain: the CNAME, then the A record it resolves to. Seeing both is confirmation the chain terminates in an address rather than dangling.

nslookup and host

dig isn't always the one you want:

  • host lamlq.dev — one line per record, nothing else. Best when you just want the answer.
  • nslookup lamlq.dev — ships on Windows by default, where dig usually doesn't. That's the main reason to reach for it.

For anything diagnostic, dig is worth the extra output — the flags and the answering server are exactly the parts the other two hide.

Try it yourself

Nothing above needs a domain of your own to explore. Run these against lamlq.dev:

dig lamlq.dev A              # the root A record → a Vercel IP
dig www.lamlq.dev            # the CNAME, and what it resolves to
dig lamlq.dev NS +short      # who's authoritative
dig lamlq.dev TXT +short     # the Google verification record
dig lamlq.dev MX +short      # empty — no mail on this domain

Then run the A query twice, a minute apart, and watch the TTL count down. That number is the entire propagation story in one integer.

References