Posted on
• Artificial Intelligence

Artificial Intelligence for DNS Diagnostics

Author
  • User
    linuxbash
    Posts by this author
    Posts by this author

Artificial Intelligence for DNS Diagnostics: Faster Triage from Your Bash Prompt

If your on-call pager has ever buzzed with “the site is down” and everything looks fine… except DNS, you know how opaque name resolution can be. TXT flags, TTLs, caches, DNSSEC, EDNS, TCP fallbacks, recursive vs authoritative—there’s a lot to correlate quickly.

What if you could keep your familiar Bash workflow, collect clean evidence fast, and let an AI summarize likely root causes? In this post you’ll turn your DNS runbook into a repeatable, automatable pipeline—then layer AI on top to shrink mean time to detection and resolution.

Why use AI for DNS troubleshooting?

  • Pattern recognition across noisy outputs: AI can connect dots across dig, kdig, traces, and resolver differences to surface hypotheses (e.g., “RRSIG expired” vs “negative caching TTL at resolver”).

  • Faster triage: Instead of manually grepping and comparing, get a first-pass incident narrative in seconds.

  • Consistency: Build prompt playbooks that junior engineers can run confidently at 3 a.m.

  • Works offline/local: With a local model you can keep sensitive data on the box and still get structured insights.

Below are actionable steps to set this up with tools you probably already use.

1) Install your DNS and CLI toolkit

We’ll use dig, kdig, drill for diverse resolvers and flags, plus jq, curl, and tcpdump for JSON DoH checks and captures.

  • Debian/Ubuntu (apt):
sudo apt update
sudo apt install -y dnsutils knot-dnsutils ldnsutils jq curl tcpdump
  • Fedora/RHEL/CentOS (dnf):
sudo dnf install -y bind-utils knot-utils ldns jq curl tcpdump
  • openSUSE/SLES (zypper):
sudo zypper refresh
sudo zypper install -y bind-utils knot-utils ldns jq curl tcpdump

What each gives you:

  • dig (dnsutils or bind-utils): the classic workhorse

  • kdig (knot-dnsutils/knot-utils): great for DNSSEC, DoT/DoH checks

  • drill (ldns/ldnsutils): alternative semantics and diagnostics

  • jq, curl: easy DoH queries and JSON filtering

  • tcpdump: last-resort packet capture

2) Capture a clean DNS snapshot with one script

This script collects a reproducible, multi-angle snapshot. Save it as dns-snapshot.sh and make it executable.

#!/usr/bin/env bash
set -euo pipefail

TARGET="${1:-example.com}"
OUT="${2:-dns-snapshot-$(date -u +%Y%m%dT%H%M%SZ).log}"

echo "DNS snapshot for: $TARGET" | tee "$OUT"
echo "Timestamp (UTC): $(date -u +"%F %T")" | tee -a "$OUT"
echo "Hostname: $(hostname -f 2>/dev/null || hostname)" | tee -a "$OUT"
echo "OS: $(uname -a)" | tee -a "$OUT"

echo -e "\n=== Resolver config ===" | tee -a "$OUT"
[ -f /etc/resolv.conf ] && { echo "# /etc/resolv.conf" | tee -a "$OUT"; sed 's/^/  /' /etc/resolv.conf | tee -a "$OUT"; }
command -v resolvectl >/dev/null 2>&1 && { echo "# resolvectl status" | tee -a "$OUT"; resolvectl status 2>&1 | sed 's/^/  /' | tee -a "$OUT"; }

echo -e "\n=== Baseline lookups (system resolver) ===" | tee -a "$OUT"
for t in A AAAA CNAME MX TXT NS SOA; do
  echo -e "\n# dig $TARGET $t +nocmd +noall +answer +ttlunits" | tee -a "$OUT"
  dig "$TARGET" "$t" +nocmd +noall +answer +ttlunits 2>&1 | sed 's/^/  /' | tee -a "$OUT"
done

echo -e "\n# dig +dnssec $TARGET A" | tee -a "$OUT"
dig +dnssec "$TARGET" A 2>&1 | sed 's/^/  /' | tee -a "$OUT"

echo -e "\n# dig +trace $TARGET A" | tee -a "$OUT"
dig +trace "$TARGET" A 2>&1 | sed 's/^/  /' | tee -a "$OUT"

echo -e "\n=== Public resolvers comparison ===" | tee -a "$OUT"
for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  echo -e "\n# dig @$r $TARGET A +dnssec +time=3 +retry=1 +nocmd +noall +answer +ttlunits" | tee -a "$OUT"
  dig @"$r" "$TARGET" A +dnssec +time=3 +retry=1 +nocmd +noall +answer +ttlunits 2>&1 | sed 's/^/  /' | tee -a "$OUT"
done

echo -e "\n=== Authoritative path ===" | tee -a "$OUT"
echo "# NS set:" | tee -a "$OUT"
dig NS "$TARGET" +short 2>&1 | sed 's/^/  /' | tee -a "$OUT"
for ns in $(dig NS "$TARGET" +short); do
  echo -e "\n# dig @$ns $TARGET SOA +dnssec +multi +time=3 +retry=1" | tee -a "$OUT"
  dig @"$ns" "$TARGET" SOA +dnssec +multi +time=3 +retry=1 2>&1 | sed 's/^/  /' | tee -a "$OUT"
done

echo -e "\n=== EDNS / buffer / TCP fallback checks ===" | tee -a "$OUT"
for sz in 512 1232; do
  echo -e "\n# dig +bufsize=$sz +dnssec $TARGET A +vc? (TCP fallback if TC=1)" | tee -a "$OUT"
  dig +bufsize="$sz" +dnssec "$TARGET" A 2>&1 | sed 's/^/  /' | tee -a "$OUT"
done
echo -e "\n# dig +tcp $TARGET A" | tee -a "$OUT"
dig +tcp "$TARGET" A 2>&1 | sed 's/^/  /' | tee -a "$OUT"

echo -e "\n=== DoT / DoH sanity (no secrets) ===" | tee -a "$OUT"
command -v kdig >/dev/null 2>&1 && {
  echo -e "\n# kdig +tls @1.1.1.1 $TARGET A" | tee -a "$OUT"
  kdig +tls @1.1.1.1 "$TARGET" A 2>&1 | sed 's/^/  /' | tee -a "$OUT"
}
echo -e "\n# DoH (Cloudflare JSON) - A record" | tee -a "$OUT"
curl -s 'https://cloudflare-dns.com/dns-query?type=A&name='"$TARGET" -H 'accept: application/dns-json' \
  | jq -c . 2>/dev/null | sed 's/^/  /' | tee -a "$OUT" || true

echo -e "\n=== Done. Snapshot saved to: $OUT ===" | tee -a "$OUT"

Usage:

chmod +x dns-snapshot.sh
./dns-snapshot.sh example.com

This produces a single log you can share internally, archive, or feed to an AI for summarization.

3) Compare from multiple vantage points (one-liners)

When “it works for me” is the problem, check resolvers and paths quickly.

  • Same query, different recursive resolvers:
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "# @$r"; dig @"$r" example.com A +nocmd +noall +answer +ttlunits; echo
done
  • Walk the authoritative chain with DNSSEC:
kdig +dnssec +trace example.com A
  • Check for split-horizon inconsistencies:
echo "# Public:"
dig @1.1.1.1 internal.example.com A +short
echo "# Corp resolver:"
dig @10.0.0.53 internal.example.com A +short
  • DoH JSON without crafting wire format:
curl -s 'https://dns.google/resolve?name=example.com&type=AAAA' | jq
  • Spot EDNS/fragmentation issues:
dig +dnssec +bufsize=512 example.com A
dig +dnssec +bufsize=1232 example.com A
dig +tcp example.com A

If small buffer shows TC=1 or timeout but TCP succeeds, suspect path MTU or firewall rules blocking fragmented UDP.

4) Let a local LLM summarize the evidence

You can run a small, local model with [Ollama] to keep data on-box.

Install Ollama (cross-distro script from upstream):

curl -fsSL https://ollama.com/install.sh | sh

Pull a compact model:

ollama pull llama3:8b

Create a minimal prompt template in prompt-dns-triage.txt:

You are a senior SRE specializing in DNS. Summarize the most likely cause(s)
from the evidence below. Call out:

- Symptoms (resolver differences, errors like NXDOMAIN/SERVFAIL, timeouts)

- DNSSEC status (AD bit, RRSIG validity, chain of trust)

- Caching/TTL or negative caching indicators

- EDNS/buffer/fragmentation/TCP fallback behavior

- Split-horizon or stale delegation clues (NS mismatches, SOA serials)

- Concrete next steps to validate and fix

Evidence:

Now feed your snapshot to the model:

cat prompt-dns-triage.txt dns-snapshot-*.log | ollama run llama3:8b

Tip: Save common “playbook” prompts (DNSSEC failure, NXDOMAIN vs SERVFAIL, recursion denied, stale glue) and reuse them.

5) Real-world mini-cases the AI can flag fast

  • Expired DNSSEC signature (SERVFAIL on validating resolvers)
; flags: qr rd ra ad; ...
example.com.  300  IN  A   93.184.216.34
; RRSIG .... exp 202406050001Z

Likely callout: “RRSIG expired; resolvers that validate return SERVFAIL; bump SOA serial, republish/refresh signed zone, ensure signer cron/CI ran.”

  • Split-horizon mismatch (works internal, fails public)
# Internal
dig @10.0.0.53 api.example.com A +short
10.10.0.15

# Public
dig @1.1.1.1 api.example.com A +short
; no answer / NXDOMAIN

Likely callout: “Record only exists internally; publish external A/AAAA or configure conditional forwarding for clients.”

  • EDNS/fragmentation trouble (timeouts unless TCP)
dig +dnssec +bufsize=1232 bigsig.example A  # times out
dig +tcp bigsig.example A                    # succeeds

Likely callout: “UDP fragments dropped by firewall; cap EDNS to 1232, enable TCP fallback, or fix MTU/firewall.”

What makes this approach work

  • Bash remains the source of truth. The AI augments, it doesn’t replace, your evidence.

  • Multiple tools reduce blind spots: dig, kdig, and drill can disagree in useful ways.

  • Structured prompts turn raw logs into consistent next steps, speeding up triage and handoffs.

Conclusion and next steps

You don’t need a new SaaS or an agent to get value from AI in DNS diagnostics. Keep using your terminal, gather a clean snapshot with one command, and let a local model draft the first incident narrative and hypothesis list.

Try this now: 1) Install the toolkit (apt/dnf/zypper commands above). 2) Run ./dns-snapshot.sh yourdomain.tld. 3) Feed the log to ollama run llama3:8b with the triage prompt. 4) Turn your best prompts into playbooks and share them with your team.

Have a favorite DNS check or prompt? Turn it into a function, add it to your snapshot, and keep the loop tight. Happy debugging!

Related posts