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

```powershell
.\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:

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

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

```powershell
.\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.:

```powershell
C:\Tools\dig.ps1
```

### 2. Profil öffnen (bei Bedarf anlegen)

```powershell
# 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:

```powershell
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

```powershell
. $PROFILE
```

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

```powershell
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:

```powershell
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):

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

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

```powershell
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)

```bash
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)

```powershell
.\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.