{
  "id": 1934456,
  "title": "DNS Troubleshooting with dig: The Commands DevOps Engineers Actually Need",
  "url": "https://urgent.news/2026/08/19/dns-troubleshooting-with-dig-the-commands-devops-engineers-actually",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-19T12:41:16.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/jjoyneriv/dns-troubleshooting-with-dig-the-commands-devops-engineers-actually-need-19b0"
  },
  "original_language": "en",
  "account": "Many application issues stem from name resolution problems rather than service failures. A single command called dig can quickly diagnose the issue instead of guessing. Think of it as checking the resolution chain - the client's resolver, the resolver's response, and what authoritative DNS actually says. Most problems occur in the gap between these components.\n\nTo troubleshoot DNS issues, follow a systematic approach: observe the symptom, hypothesize where the break occurs in the chain, test with one query, read the evidence, fix the problem, then validate. The key habit is to query the name from the same host and resolver the application uses. Running dig from your laptop doesn't reflect what the pod or VM views.\n\nThere are several key record types to understand: A/AAAA converts names to IP addresses, CNAME is an alias, MX handles mail routing, TXT contains SPF/DKIM data, NS lists authoritative servers, SOA tracks serial and TTL, and PTR does reverse lookups.\n\nThe most frequently useful dig commands are:\n+short to get just the IP address\nA to query for an A record\n-x for reverse lookups (PTR records)\n+trace to follow delegation from root servers down\nresolvectl status to see the actual resolvers and search domains used on a host\n\nCommon issues include wrong A records (old IP), stale cache/TTL, querying the wrong resolver, search-domain problems, and container DNS setups. Dig runs from the correct host against the right resolver turns guessing into evidence. Follow the steps in the DNS troubleshooting guide for end-to-end scenarios. Remember, only inspect DNS on systems you're authorized to assess.",
  "summary": "A surprising share of \"the app is down\" pages resolve to a name-resolution problem, not a broken service. The service is fine; the client can't turn a name into an address. dig is the precision tool for proving that in seconds instead of guessing. Think about it as a resolution chain, not \"is DNS broken\" When a name fails, work the chain: which resolver did the client ask, what did that resolver…",
  "key_points": [
    "Dig is a command to quickly diagnose DNS issues.",
    "Key record types: A/AAAA, CNAME, MX, TXT, NS, SOA, PTR.",
    "Most common dig commands: +short, A, -x, +trace, resolvectl status."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}