20 DNS over TLS
Dieses Beispiel ist Teil des DNS-Workshops und folgt dem Format der Kubernetes-Beispiele: ein Haupt-README, Detaildokumentation in Deutsch und Englisch sowie kleine prüfbare Artefakte.
1. Ziel
DoT-Konfiguration mit Port 853, Zertifikatsbezug und Privacy-Grenzen wird modelliert.
Das Beispiel arbeitet mit Dokumentationszonen wie example.test, 192.0.2.0/24 und 2001:db8::/32. Es verändert keine produktive Zone und schreibt Laufzeitergebnisse ausschließlich nach work/.
2. Voraussetzungen
- Linux, WSL, VM oder vergleichbare Testumgebung.
python3für JSON/YAML/TOML- und Zonendatei-Validierung.- Optional
dig,named-checkzoneundnamed-checkconffür zusätzliche Evidence. - Keine produktiven Domains, Provider-APIs, TSIG-Secrets oder Zonenschlüssel verwenden.
3. Dateien
README.mddocs/de/README.mddocs/en/README.mdrun.shunbound/dot.conf
4. Ausführung
cd examples/20-dns-over-tls-model
chmod +x run.sh
./run.sh
find work -maxdepth 3 -type f | sort
5. Erwartetes Ergebnis
run.shendet mit Exit-Code0.- Zonendateien haben SOA und NS.
- CNAME-Konflikte werden als Fehler erkannt, wenn sie nicht bewusst als Negativbeispiel markiert sind.
- JSON/YAML/TOML sind syntaktisch gültig.
- Alle Laufzeitartefakte entstehen unter
work/.
6. Erklärung
DNS-Arbeit muss sauber zwischen Stub Resolver, rekursivem Resolver, authoritative Server, Zone, Delegation, Cache und Transport unterscheiden. Dieses Beispiel isoliert genau einen Ausschnitt davon und macht die Reviewfragen nachvollziehbar.
7. Typische Fehler
| Fehler | Ursache | Diagnose |
|---|---|---|
NXDOMAIN |
Name existiert nicht oder falsche Zone | SOA und Authority Section prüfen |
NOERROR ohne Antwortdaten |
NODATA oder falscher RRtype | RRset und QTYPE prüfen |
SERVFAIL |
DNSSEC, Upstream oder Resolverfehler | +dnssec, Logs und Validierung prüfen |
REFUSED |
ACL, Recursion oder Transfer verboten | Serverrolle und ACL prüfen |
| alte Antwort | Cache oder TTL | TTL, Resolvercache und SOA prüfen |
8. Sicherheitsaspekte
- Keine produktiven Zonen, TSIG-Secrets oder DNSSEC-Keys in Labs verwenden.
- Open Resolver und unkontrollierte Zonentransfers vermeiden.
- DNSSEC schützt Herkunft und Integrität, aber nicht Vertraulichkeit.
- DoT und DoH ändern Transport- und Privacy-Eigenschaften, ersetzen aber keine korrekten Zonendaten.
9. Review und Evidence
work/evidence/
tooling.txt
zone-checks.txt
result.txt
risk-note.md
cleanup.md
10. Erweiterungsmöglichkeiten
- Beispiel mit echtem lokalen BIND oder CoreDNS ausführen.
- DNSSEC-Signatur mit Lab-Schlüsseln ergänzen.
- Query-Logs und Monitoring-Metriken hinzufügen.
- Incident-Runbook in eine Teamübung überführen.
Beispielanhang: Evidence, Betrieb und Transfer
Dieser Zusatzteil macht das Beispiel als Trainingsbaustein vollständig. Er beschreibt, wie aus einem lokalen DNS-Modell eine belastbare Analyse entsteht, ohne produktive Domains oder Provider-Zugänge zu berühren.
B.1 Scope bestimmen
Scope bestimmen ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.2 Artefakte validieren
Artefakte validieren ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.3 DNS-Rolle benennen
DNS-Rolle benennen ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.4 RCODE interpretieren
RCODE interpretieren ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.5 TTL bewerten
TTL bewerten ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.6 Delegation prüfen
Delegation prüfen ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.7 Security-Grenzen festhalten
Security-Grenzen festhalten ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.8 Rollback formulieren
Rollback formulieren ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.9 Evidence bereinigen
Evidence bereinigen ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.10 Cleanup durchführen
Cleanup durchführen ist notwendig, weil DNS-Fehler oft erst durch die Kombination aus Zone, Resolverpfad, Cache und Transport erklärbar werden. Die Bewertung muss klar sagen, ob ein Artefakt nur erklärt, lokal prüft oder auf einer echten Zone angewendet würde.
| Frage | Erwartung |
|---|---|
| Was ist betroffen? | Stub, Resolver, authoritative Server, Zone, Delegation, Cache, DNSSEC oder Transport ist genannt. |
| Was ist belegt? | Eine Datei oder Ausgabe unter work/evidence/ zeigt den Befund. |
| Was bleibt offen? | Voraussetzungen für echte Zonen oder Provider sind als Grenze dokumentiert. |
Reviewpunkte:
- keine produktiven Zonen
- keine echten TSIG- oder DNSSEC-Schlüssel
- keine Provider-API-Tokens
- keine ungeprüften TTL- oder Delegationsänderungen
- Cleanup durch Entfernen von
work/möglich
B.11 Abschluss
Ein Beispiel ist abgeschlossen, wenn das Skript erfolgreich läuft, alle Artefakte syntaktisch gültig sind, die DNS-Rolle benannt ist und die Evidence keine vertraulichen Daten enthält.