DNS-Abfragen mit dig und host in Bash automatisieren

1. Warum DNS-Abfragen in Bash automatisiert werden

DNS-Probleme gehören zu den häufigsten, aber am schwersten sichtbaren Ursachen für Ausfälle: Ein falsch gesetzter A-Record, ein vergessener MX-Eintrag oder ein Resolver, der noch alte Werte zwischencacht, führt zu Fehlern, die im Anwendungscode nie auftauchen. Wer DNS-Abfragen mit dig und host automatisiert, verlagert diese Prüfung aus dem manuellen "mal kurz nachschauen" in ein wiederholbares, dokumentiertes Skript.

Gerade bei Domainmigrationen, dem Wechsel des Hosting-Providers oder dem Rollout neuer Subdomains ist es entscheidend, den Status vieler Domains gleichzeitig zu kennen, nicht nur einer einzelnen. Ein Bash-Skript, das DNS-Abfragen automatisiert, prüft in Sekunden hunderte Domains gegen mehrere Resolver und liefert eine strukturierte Übersicht statt einzelner Terminal-Ausgaben.

Auch im laufenden Betrieb lohnt sich die Automatisierung: DNS-Einträge ändern sich seltener als Anwendungscode, aber wenn sie sich ändern, oft mit erheblicher Auswirkung, zum Beispiel bei einem CDN-Wechsel oder einer neuen Mailserver-Konfiguration. Ein Skript, das DNS-Abfragen mit dig und host automatisiert und regelmäßig läuft, erkennt solche Änderungen zuverlässig, lange bevor ein Nutzer eine fehlgeschlagene E-Mail-Zustellung meldet.

2. dig, host und nslookup: Werkzeuge im Überblick

Für DNS-Abfragen mit dig und host automatisiert in Bash stehen drei klassische Werkzeuge zur Wahl. dig (Domain Information Groper) aus dem Paket bind-utils beziehungsweise dnsutils liefert die detaillierteste und am besten skriptbar formatierte Ausgabe, inklusive expliziter Optionen zur Reduktion auf genau die benötigten Informationen. host ist knapper in der Standardausgabe und eignet sich gut für schnelle, lesbare Einzeiler.

nslookup ist historisch älter, gilt als weniger konsistent zwischen Plattformen und wird für neue Skripte in der Regel nicht mehr empfohlen, taucht aber noch in vielen älteren Anleitungen auf. Für Bash-Automatisierung ist dig die robusteste Wahl, weil es explizite Flags für maschinenlesbare Ausgabe bereitstellt, die host und nslookup in dieser Form nicht kennen.

#!/usr/bin/env bash
# dns-tools-check.sh — verify dig, host and nslookup availability
set -euo pipefail

for tool in dig host nslookup getent; do
  if command -v "$tool" &>/dev/null; then
    echo "[OK] $tool: $(command -v "$tool")"
  else
    echo "[MISSING] $tool not installed"
  fi
done

echo "---"
echo "dig version: $(dig -v 2>&1 | head -n 1)"

3. Parsebare Ausgabe mit dig +short und +noall +answer

Der Schlüssel zur Automatisierung von DNS-Abfragen mit dig und host liegt in der richtigen Ausgabeformatierung. dig +short example.com gibt ausschließlich die IP-Adresse zurück, ohne Header, Frage-Sektion oder Statistikzeilen, perfekt zum direkten Einlesen in eine Bash-Variable. Für mehr Kontext, aber immer noch maschinenlesbar, liefert dig +noall +answer example.com nur die Answer-Sektion mit TTL und Record-Typ, aber ohne den restlichen Rauschen.

Diese beiden Modi decken die meisten Automatisierungsfälle ab: +short für einfache Existenz- und Wertprüfungen, +noall +answer wenn TTL-Werte oder mehrere Records pro Domain relevant sind. Wer DNS-Abfragen mit dig und host automatisiert und die Ausgabe später mit awk oder jq weiterverarbeiten will, sollte konsequent bei einem der beiden Formate bleiben, statt beide in einem Skript zu mischen.

#!/usr/bin/env bash
# dig-parse-formats.sh — compare short vs. detailed dig output
set -euo pipefail

DOMAIN="${1:-mironsoft.de}"

echo "=== dig +short (only the value) ==="
dig +short "$DOMAIN" A

echo "=== dig +noall +answer (value + TTL + record type) ==="
dig +noall +answer "$DOMAIN" A

echo "=== Extract just the IP with awk from +noall +answer ==="
dig +noall +answer "$DOMAIN" A | awk '{print $NF}'

4. Domainlisten aus Dateien im Batch abfragen

Sobald mehr als eine Handvoll Domains geprüft werden sollen, lohnt sich eine Domainliste in einer Textdatei, eine Domain pro Zeile, kombiniert mit einer Bash-Schleife. Wichtig ist auch hier das robuste Lesen der Datei: while IFS= read -r domain; do ... done < domains.txt vermeidet Probleme mit führenden oder abschließenden Leerzeichen und respektiert Kommentarzeilen, wenn man sie vorher mit grep -v '^#' herausfiltert.

Für DNS-Abfragen mit dig und host automatisiert im großen Stil bietet dig zusätzlich die Option -f, die eine ganze Datei mit Abfragen in einem einzigen dig-Aufruf verarbeitet, was deutlich schneller ist als hunderte einzelne Prozessaufrufe in einer Bash-Schleife, weil nur eine einzige Verbindung zum Resolver aufgebaut wird.

#!/usr/bin/env bash
# batch-dns-check.sh — check a list of domains for their A record
set -euo pipefail

DOMAIN_FILE="${1:?Usage: batch-dns-check.sh <domain-list-file>}"
declare -A results=()

while IFS= read -r domain; do
  [[ -z "$domain" || "$domain" == \#* ]] && continue
  ip=$(dig +short "$domain" A | head -n 1)
  results["$domain"]="${ip:-NO_RECORD}"
done < "$DOMAIN_FILE"

echo "=== Batch DNS results ==="
for domain in "${!results[@]}"; do
  printf '%-30s -> %s\n' "$domain" "${results[$domain]}"
done

# Faster alternative: dig -f processes the whole file in one dig invocation
echo "=== Same result via 'dig -f' (single resolver round trip) ==="
dig +short -f "$DOMAIN_FILE"

5. Record-Typen gezielt abfragen: A, AAAA, MX, TXT, NS

Neben dem A-Record für IPv4-Adressen gehören AAAA (IPv6), MX (Mailserver), TXT (SPF, DKIM, Domain-Verifizierung) und NS (Nameserver) zu den am häufigsten geprüften Typen. Wer DNS-Abfragen mit dig und host automatisiert, um zum Beispiel eine E-Mail-Konfiguration zu validieren, fragt gezielt dig +short example.com MX ab und prüft, ob der erwartete Mailserver mit korrekter Priorität eingetragen ist.

Für TXT-Records, die oft mehrzeilige oder in Anführungszeichen gesetzte Werte enthalten (etwa SPF-Einträge wie "v=spf1 include:_spf.google.com ~all"), muss ein Skript die umschließenden Anführungszeichen entfernen, bevor der Wert weiterverarbeitet wird. dig +short example.com TXT | tr -d '"' ist hierfür die pragmatische Lösung.

#!/usr/bin/env bash
# check-record-types.sh — query multiple DNS record types for one domain
set -euo pipefail

DOMAIN="${1:?Usage: check-record-types.sh <domain>}"

declare -a RECORD_TYPES=(A AAAA MX TXT NS CNAME)

for record_type in "${RECORD_TYPES[@]}"; do
  echo "--- $record_type ---"
  result=$(dig +short "$DOMAIN" "$record_type")
  if [[ -z "$result" ]]; then
    echo "  (no record)"
  else
    echo "$result" | sed 's/^/  /'
  fi
done

6. DNS-Propagation über mehrere Resolver vergleichen

Nach einer DNS-Änderung stellt sich sofort die Frage, ob und wie schnell sie propagiert ist. Weil verschiedene Resolver unterschiedliche TTL-Caches haben, liefert eine Abfrage gegen den lokalen Resolver oft ein anderes Ergebnis als eine Abfrage gegen einen öffentlichen Resolver wie Google (8.8.8.8) oder Cloudflare (1.1.1.1). Wer DNS-Abfragen mit dig und host automatisiert, um Propagation zu prüfen, fragt deshalb bewusst mehrere Resolver mit der Option @resolver-ip ab und vergleicht die Ergebnisse.

Ein solches Vergleichsskript zeigt sofort, ob eine Änderung überall angekommen ist oder ob ein bestimmter Resolver noch einen veralteten, zwischengecachten Wert liefert. Das ist besonders bei zeitkritischen Migrationen wertvoll, bei denen man wissen muss, ob der alte oder neue Server noch Traffic empfängt.

#!/usr/bin/env bash
# propagation-check.sh — compare A record across multiple public resolvers
set -euo pipefail

DOMAIN="${1:?Usage: propagation-check.sh <domain>}"

declare -A RESOLVERS=(
  [Google]="8.8.8.8"
  [Cloudflare]="1.1.1.1"
  [Quad9]="9.9.9.9"
  [OpenDNS]="208.67.222.222"
)

echo "=== A record for $DOMAIN across resolvers ==="
for name in "${!RESOLVERS[@]}"; do
  ip="${RESOLVERS[$name]}"
  result=$(dig +short "@$ip" "$DOMAIN" A | head -n 1)
  printf '%-12s (%s) -> %s\n' "$name" "$ip" "${result:-NO_ANSWER}"
done

7. Monitoring-Skript: Änderungen erkennen und alarmieren

Für dauerhaftes Monitoring reicht eine einmalige Prüfung nicht aus. Ein Cronjob, der DNS-Abfragen mit dig und host automatisiert und den aktuellen Wert mit dem zuletzt bekannten Wert vergleicht, erkennt unautorisierte oder unerwartete Änderungen sofort. Die Werte werden dazu in einer einfachen Datei oder SQLite-Datenbank gespeichert und bei jedem Lauf abgeglichen.

Bei einer Abweichung sendet das Skript eine Benachrichtigung, etwa über einen Slack-Webhook oder eine E-Mail, und protokolliert Zeitpunkt, alten und neuen Wert. Für kritische Domains, deren MX- oder A-Records sich niemals unangekündigt ändern sollten, ist ein solches Monitoring ein einfacher, aber wirkungsvoller Schutzmechanismus gegen DNS-Hijacking oder versehentliche Fehlkonfiguration durch Dritte.

8. Fehleranalyse: SERVFAIL, NXDOMAIN und Timeouts

Wer DNS-Abfragen mit dig und host automatisiert, muss verschiedene Fehlerantworten unterscheiden können, um im Skript sinnvoll zu reagieren. NXDOMAIN bedeutet, dass die Domain schlicht nicht existiert, oft ein Tippfehler oder eine noch nicht registrierte Domain. SERVFAIL deutet dagegen auf ein Konfigurationsproblem beim autoritativen Nameserver hin, etwa eine fehlerhafte DNSSEC-Signatur oder einen nicht erreichbaren Nameserver.

Ein dritter Fall, Timeouts, entsteht meist durch Netzwerkprobleme zwischen dem Client und dem Resolver, nicht durch die Domain selbst. In einem Bash-Skript prüft man den Status über dig ... | grep -q "status: NOERROR" oder liest direkt den Rückgabewert des Kommandos aus, wobei dig bei Netzwerkfehlern einen von Null verschiedenen Exit-Code liefert, während ein NXDOMAIN dennoch Exit-Code 0 zurückgibt, weil die Abfrage selbst technisch erfolgreich war, nur eben ohne Ergebnis.

9. dig vs. host vs. getent im Vergleich

Die Tabelle in Abschnitt sieben zeigt die zentralen Unterschiede, wichtig ist aber auch der Kontext: getent hosts nutzt die lokale Namensauflösung des Systems inklusive /etc/hosts und der konfigurierten nsswitch.conf-Reihenfolge, während dig und host standardmäßig direkt gegen den DNS-Resolver fragen und lokale Overrides ignorieren. Für Debugging von Anwendungen, die über die Systemauflösung laufen (etwa PHP mit gethostbyname), ist deshalb getent oft aussagekräftiger als ein reiner dig-Aufruf.

Für reine DNS-Diagnose und Automatisierung bleibt dig die erste Wahl, weil es die feingranularsten Optionen für Ausgabeformat, Resolver-Auswahl und Record-Typ bietet. host eignet sich weiterhin gut für schnelle interaktive Prüfungen im Terminal, wo Lesbarkeit wichtiger ist als Skriptbarkeit.

10. Zusammenfassung

DNS-Abfragen mit dig und host automatisieren bedeutet, DNS-Prüfungen von der manuellen Einzelabfrage in ein wiederholbares, skriptbares Werkzeug zu überführen. dig +short liefert die sauberste Ausgabe für einfache Wertprüfungen, dig +noall +answer ergänzt TTL und Record-Typ, und Batch-Verarbeitung mit einer Domainliste oder dig -f skaliert auf hunderte Domains ohne manuellen Aufwand.

Für Migrationen ist der Vergleich mehrerer öffentlicher Resolver entscheidend, um Propagation zu verifizieren. Für den laufenden Betrieb liefert ein Monitoring-Skript, das DNS-Abfragen mit dig und host automatisiert und Änderungen protokolliert, einen einfachen, aber effektiven Schutz gegen unbemerkte DNS-Fehlkonfigurationen und Hijacking-Versuche.

11. FAQ: DNS-Abfragen mit dig und host automatisieren