dns_skripte/README.md

dig.ps1 — dig-artiger DNS-Lookup für PowerShell

Ein PowerShell-Skript, das die wichtigsten dig-Aufrufe unter Windows nachbildet. Intern wird Resolve-DnsName verwendet.

Aufrufe

.\dig.ps1 example.com                 # A-Record (Default)
.\dig.ps1 MX example.com              # type name
.\dig.ps1 example.com MX              # name type (Reihenfolge egal)
.\dig.ps1 example.com MX -s 1.1.1.1   # gegen bestimmten Server (@-frei)
.\dig.ps1 example.com MX "@1.1.1.1"   # gegen bestimmten Server (@ gequotet)
.\dig.ps1 -x 8.8.8.8                  # Reverse-Lookup (PTR)
.\dig.ps1 example.com TXT +short      # nur die Werte ausgeben

Unterstützt: Record-type, name, @server bzw. -s server, die Option +short sowie -x für Reverse-Lookups.

DNS-Server angeben: @server muss gequotet werden

PowerShell deutet ein Argument mit führendem @ als Splatting-Operator und bricht schon beim Parsen ab (Der Splat-Operator "@" kann nicht … verwendet werden), bevor das Skript überhaupt startet. Für die @server-Syntax daher Anführungszeichen verwenden:

.\dig.ps1 example.com MX "@8.8.8.8"

Oder die @-freie Alternative -s / -server nutzen:

.\dig.ps1 example.com MX -s 8.8.8.8
.\dig.ps1 example.com MX -server 8.8.8.8

dig-Funktion anlegen

Damit sich das Skript wie unter Linux einfach mit dig … (statt .\dig.ps1 …) aufrufen lässt, wird eine Funktion im PowerShell-Profil angelegt.

1. Skript ablegen

Kopiere dig.ps1 an einen festen Ort, z. B.:

C:\Tools\dig.ps1

2. Profil öffnen (bei Bedarf anlegen)

# Existiert das Profil schon?
Test-Path $PROFILE

# Falls nicht: anlegen
if (-not (Test-Path $PROFILE)) {
    New-Item -ItemType File -Path $PROFILE -Force
}

# Profil im Editor öffnen
notepad $PROFILE

3. Funktion eintragen

Füge folgende Zeilen in die Profildatei ein und passe den Pfad an:

function dig {
    & "C:\Tools\dig.ps1" @args
}

@args reicht alle Argumente unverändert an das Skript weiter, sodass die dig-Syntax 1:1 erhalten bleibt.

4. Profil neu laden

. $PROFILE

Danach steht dig in jeder neuen PowerShell-Sitzung zur Verfügung:

dig example.com MX @1.1.1.1
dig -x 8.8.8.8 +short

Ausführungsrichtlinie (ExecutionPolicy)

Wird die Ausführung von Skripten blockiert, kann sie für den aktuellen Benutzer erlaubt werden:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

RemoteSigned erlaubt lokal erstellte Skripte; aus dem Internet geladene Skripte müssen signiert sein.

„Das Skript ist nicht digital signiert"

Wurde dig.ps1 aus diesem Git-Repo geladen, markiert Windows die Datei mit einer „Mark of the Web" (Herkunft: Internet/Netzwerk). Unter RemoteSigned wird die Ausführung dann mit dem Hinweis blockiert, dass das Skript nicht digital signiert ist.

Empfohlene Lösung — die Markierung gezielt bei dieser Datei entfernen (Policy bleibt sicher):

Unblock-File -Path C:\Tools\dig.ps1

Einmalig ohne Policy-Änderung ausführen — umgeht die Prüfung nur für diesen Aufruf:

powershell -ExecutionPolicy Bypass -File C:\Tools\dig.ps1 example.com MX

Hinweise

• Das Skript benötigt das Modul DnsClient (Resolve-DnsName), das unter Windows standardmäßig vorhanden ist.
• Die Standardausgabe orientiert sich am dig-Format mit QUESTION- und ANSWER SECTION.
• Mit +short werden nur die reinen Antwortwerte ausgegeben (eine pro Zeile).

---

dnssec_check — DNSSEC-Status prüfen

Prüft für eine hinterlegbare Liste von Domains, ob DNSSEC aktiviert und gültig signiert ist, und testet vorab, ob der abgefragte Resolver überhaupt validiert. Es gibt zwei funktionsgleiche Varianten:

Datei	Plattform	Werkzeug
dnssec_check	Linux/macOS (Bash)	dig (Paket bind9-dnsutils)
dnssec_check.ps1	Windows (PowerShell 5.1+)	Resolve-DnsName (Modul DnsClient)

Status-Werte

Status	Bedeutung
aktiv	Domain ist DNSSEC-signiert und wird vom validierenden Resolver korrekt ausgeliefert
inaktiv	Domain ist nicht signiert (kein DNSSEC)
fail	DNSSEC vorhanden, aber Validierung schlägt fehl (SERVFAIL)

Der Test ist nur aussagekräftig gegen einen validierenden Resolver (z. B. der interne BIND mit dnssec-validation auto;). Beide Skripte führen daher zuerst einen Selbsttest aus: dnssec-failed.org muss scheitern, isc.org muss signiert auflösen. Schlägt der Selbsttest fehl, wird gewarnt.

Bash (Linux/macOS)

sudo apt install bind9-dnsutils      # falls dig fehlt
chmod +x dnssec_check
./dnssec_check                       # hinterlegte Liste, Resolver 127.0.0.1
./dnssec_check -r 192.168.1.10       # anderer Resolver
./dnssec_check --self-check          # nur Resolver-Validierung prüfen
./dnssec_check isc.org citeq.de      # nur diese Domains

PowerShell (Windows)

.\dnssec_check.ps1                       # hinterlegte Liste, Resolver 127.0.0.1
.\dnssec_check.ps1 -Resolver 192.168.1.10
.\dnssec_check.ps1 -SelfCheck            # nur Resolver-Validierung prüfen
.\dnssec_check.ps1 isc.org citeq.de      # nur diese Domains

Hinweis: Resolve-DnsName liefert das AD-Header-Flag nicht zurück. Die PowerShell-Variante wertet daher das Vorhandensein von RRSIG-Records aus. Ob der Resolver wirklich validiert, klärt der Selbsttest.

Domains hinterlegen

Die zu prüfenden Domains stehen direkt im Skript:

• Bash: Array DOMAINS=( … ) im Kopf
• PowerShell: $DefaultDomains = @( … ) im Kopf

Exit-Code (für Monitoring / cron / Scheduled Task)

0 = kein fail, 1 = mindestens eine Domain fail. Der reine Selbsttest gibt 0 (validiert), 1 (validiert nicht) bzw. 2 (Resolver nicht erreichbar) zurück.