OfferTurnkey landing from $150
All posts
  • dns
  • infra
  • devops
Infrastructure

DNS that doesn’t lie at 3 a.m.

Records, TTLs and cutovers that keep migrations calm — plus the checks we run before touching production names.

  • AK
Authors

DNS outages feel mysterious until you treat records as contracts. Then most “mysteries” become TTL math and missing checks.

Write the cutover plan first

Before changing anything live:

  1. Inventory every name that must resolve after the move.
  2. Decide TTL strategy for the freeze window.
  3. Name the rollback record set explicitly.

TTL is a schedule

If TTL is tt seconds, plan as if clients may cache for a full tt after you publish. That is the real cutover length — not the moment you click save.

Checks that catch lies early

bash
# Resolve from more than one vantage point
dig +short api.example.com @1.1.1.1
dig +short api.example.com @8.8.8.8

# Confirm the authority you think you edit
dig NS example.com +short

Also verify HTTPS and health endpoints through the new name before you drop the old one.

Common failure modes

SymptomUsual cause
Half the world worksStale cache + mixed records
Cert errors after moveName live before cert covers it
“It works for me”Local resolver still on the old answer

Closing

DNS is boring when planned. Make the plan visible, keep TTLs honest, and never cut over on hope.