yukt.tools
resources
guide · dns

DNS Dig Troubleshooting Guide: how to find and fix common DNS failures fast

Use this playbook when websites do not resolve, email delivery breaks, or verification TXT records fail. It is designed to work directly with the yukt.tools DNS dig utility so you can isolate issues in minutes instead of hours.[1][3][6]

Published 2026-02-28 · Updated 2026-03-03

Quick flow: identify what is failing, query the exact record type and hostname, compare observed values with expected provider values, then wait based on TTL before retesting.

1) Start with a precise symptom, not a guess

DNS issues look similar from the outside, but root causes differ. Write one specific failure statement first: "homepage unreachable", "new subdomain not resolving", "Google Workspace mail bouncing", or "SSL TXT challenge not found." That statement determines the record type you should query first.[1][2][5]

2) Query the right record type in dig

In yukt.tools DNS Dig, run one lookup at a time using the exact record you need: A/AAAA for host-to-IP routing, CNAME for alias targets, MX for mail routing, TXT for SPF/DKIM/DMARC and verification, and NS when delegation seems wrong.[1][3][4]

  • Website down: check A and AAAA first.
  • Subdomain redirect/pointing issue: check CNAME.
  • Email problems: check MX, then TXT records related to SPF/DKIM/DMARC.
  • Verification/SSL challenge failures: check the exact TXT hostname provided by the platform.

3) Compare expected vs observed values line by line

Most DNS incidents are simple mismatches: wrong target, old IP, missing trailing hostname, or extra whitespace in TXT content. Keep a two-column checklist (expected provider value vs current dig output) and resolve one mismatch at a time.[1][2][5]

4) Do not ignore TTL and negative caching

If the answer is still old immediately after an edit, caching may be the reason. TTL defines how long resolvers may reuse data. NXDOMAIN/"not found" responses can also be cached (negative caching), which can delay visibility even after you add a record.[6]

Practical rule: after a correction, retest at the TTL boundary before escalating. Testing too early can create false alarms.

5) Escalation checklist when the zone still looks wrong

  • Confirm the domain uses the nameservers you think it uses (registrar view / ICANN lookup).
  • Confirm records were saved in the authoritative DNS provider for that zone, not a different dashboard.
  • Re-run dig for NS at the zone apex and verify delegation aligns with registrar settings.
  • Capture a share link from yukt.tools DNS Dig results so teammates can review the same evidence quickly.

These four checks catch the majority of persistent "we changed DNS but nothing happened" incidents.[7]

Pro tip: when making planned DNS migrations, lower TTL in advance (if possible), execute the change, validate with dig, then restore a higher TTL after stability. This reduces user-facing inconsistency windows.

FAQ

Why does one DNS checker show the new value while another still shows the old one?

Different resolvers cache responses independently. If one resolver refreshed and another has not, you can see mixed answers for a while. TTL and negative caching both affect how quickly consistency appears.[1][6]

Should I use CNAME or A records for a website root domain?

Apex/root domains traditionally use A/AAAA records because CNAME has compatibility limitations at the root in classic DNS setups. Many providers offer flattening/alias features to mimic CNAME behavior while still returning A/AAAA answers.[1][3]

My email stopped after DNS edits. What should I check first?

Validate MX records first, then confirm SPF/DKIM/DMARC TXT records and ensure there are no conflicting stale values. Compare current DNS answers with your mail provider's exact required values.[1][2][4]

How do I verify ACME/SSL DNS challenges quickly?

Query the exact TXT hostname required by your certificate provider (often _acme-challenge.yourdomain.com) and confirm the token value before retrying issuance.[5]

Sources

  1. [1] Cloudflare Learning Center: DNS records — https://www.cloudflare.com/learning/dns/dns-records/
  2. [2] Google Workspace Admin Help: MX record setup — https://support.google.com/a/answer/174125?hl=en
  3. [3] RFC 1035: Domain names - implementation and specification — https://www.rfc-editor.org/rfc/rfc1035
  4. [4] RFC 1464: Using the Domain Name System to store arbitrary string attributes — https://www.rfc-editor.org/rfc/rfc1464
  5. [5] Let's Encrypt: Challenge types — https://letsencrypt.org/docs/challenge-types/
  6. [6] RFC 2308: Negative Caching of DNS Queries — https://www.rfc-editor.org/rfc/rfc2308
  7. [7] ICANN WHOIS / RDAP lookup — https://lookup.icann.org/en

Use the tool now

Open DNS Dig and run your first targeted lookup. If the values differ from your expected config, you already have the next action.

open DNS Dig