Orthevs Orthevs Fathom new horizons
Μενού

Wiki workshop · Γερμανικά

Beispiel-Dokumentation: DNS over TLS

DoT-Konfiguration mit Port 853, Zertifikatsbezug und Privacy-Grenzen wird modelliert.

Γλώσσα περιεχομένου · ΓερμανικάΜέγεθος · 12.0 KBexamples/20-dns-over-tls-model/docs/de/README.md
Παραδείγματα workshop σε ZIP
Πρόοδος μάθησης στη web app

Σημειώστε κεφάλαια ως αναγνωσμένα, δείτε την πρόοδο ανάγνωσης και ολοκληρώστε πρακτικές ενότητες αφού ενεργοποιήσετε την προαιρετική web app. Η πρόοδος του workshop υπολογίζεται από τα κεφάλαια όλων των σελίδων τεκμηρίωσης. Οι επιλογές μένουν σε αυτή τη συσκευή· δεν υπάρχει λογαριασμός ή συγχρονισμός με server. Δεν απαιτείται εγκατάσταση. Η ανάκληση στις Ρυθμίσεις απορρήτου διαγράφει την πρόοδο.

Πρόοδος ανάγνωσης0%
0%
0 / 12 κεφάλαια που διαβάστηκαν
Άλλη γλωσσική έκδοσηΑγγλικά ↗Ελληνικά ↗

Beispiel-Dokumentation: DNS over TLS

1. Ziel

DoT-Konfiguration mit Port 853, Zertifikatsbezug und Privacy-Grenzen wird modelliert.

01 / 12

2. Was gemacht wird

Das Beispiel erzeugt lokale Evidence unter work/, validiert Zonendateien und prüft optionale Tool-Ausgaben, wenn DNS-Werkzeuge installiert sind.

02 / 12

3. Warum es gemacht wird

DNS-Fehler wirken oft wie Applikations- oder Netzwerkfehler. Nur mit RCODE, SOA, TTL, Delegation, Resolverpfad und Cache-Zustand lässt sich die Ursache belastbar bestimmen.

03 / 12

4. Typische Kommandos

bash
dig example.test SOA +norecurse 2>/dev/null || true
dig www.example.test A +dnssec 2>/dev/null || true
dig example.test NS +trace 2>/dev/null || true
named-checkzone example.test zones/db.example.test 2>/dev/null || true
04 / 12

5. Erfolg prüfen

  • Artefakte sind syntaktisch gültig.
  • Evidence liegt unter work/evidence/.
  • RCODE, RRtype und Zone sind benannt.
  • TTL, Cache oder Delegation sind bei Bedarf eingeordnet.
  • Keine produktiven Secrets werden verwendet.
05 / 12

6. Typische Fehler

  • Zonendatei ohne SOA oder NS.
  • CNAME mit anderen Records am selben Owner Name.
  • Glue fehlt bei in-zone Nameservern.
  • DNSSEC-SERVFAIL wird mit Netzwerkfehler verwechselt.
  • TTL- und negative Cache-Wirkung wird unterschätzt.
06 / 12

7. Sicherheitsaspekte

DNS ist Infrastruktur. Fehlerhafte Resolver-ACLs, offene Transfers, unsichere Dynamic Updates oder schwache DNSSEC-Prozesse können breite Auswirkungen haben.

07 / 12

8. Realistischer Einsatz

Das Beispiel passt zu Provider-Changes, internen Zonen, Kubernetes DNS, Split-Horizon-Designs, Mail-DNS, Resolver-Betrieb und Incident Response.

08 / 12

9. Workshop-Durchführung

  1. Lernziel lesen.
  2. Artefakte öffnen.
  3. run.sh ausführen.
  4. Evidence prüfen.
  5. DNS-Rolle benennen.
  6. RCODE und RRtype erklären.
  7. TTL und Rollback bewerten.
  8. Ergebnis reviewen.
09 / 12

10. Review-Matrix

Prüffeld Erwartung
Rolle Stub, rekursiv oder authoritative ist benannt.
Zone Zone, Owner Name und RRtype sind klar.
Antwort RCODE und Sections sind verstanden.
Betrieb TTL, Cache und Rollback sind dokumentiert.
Sicherheit Secrets und produktive Zonen sind ausgeschlossen.
10 / 12

Offizielle Referenzen

  • RFC 1034: https://datatracker.ietf.org/doc/html/rfc1034
  • RFC 1035: https://datatracker.ietf.org/doc/html/rfc1035
  • RFC 8499: https://www.rfc-editor.org/info/rfc8499/
  • RFC 6891 EDNS(0): https://datatracker.ietf.org/doc/html/rfc6891
  • RFC 4033 DNSSEC: https://datatracker.ietf.org/doc/html/rfc4033
  • RFC 9364 DNSSEC BCP: https://www.rfc-editor.org/info/rfc9364/
  • ISC BIND 9 Documentation: https://bind9.readthedocs.io/
  • CoreDNS Documentation: https://coredns.io/manual/toc/
11 / 12

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.

12 / 12

DNS · Orthevs Academy

31 modules ως ενιαία διαδρομή μάθησης.

Η σειρά παραμένει αμετάβλητη: από τη βασική δομή του lab μέσω τεχνικών θεμελίων και λειτουργικών μοντέλων έως το τελικό troubleshooting. Τα τεχνικά ονόματα καταλόγων διατηρούνται σκόπιμα.

Πρακτικά modules

Το Orthevs ως εφαρμογή

Εγκατάσταση του Orthevs

Η web app του Orthevs μπορεί να εγκατασταθεί σε υποστηριζόμενες κινητές συσκευές και browsers υπολογιστή.

iPhone και iPad

Ανοίξτε το Orthevs στο Safari. Πατήστε Κοινή χρήση και μετά Προσθήκη στην οθόνη αφετηρίας. Ενεργοποιήστε το Άνοιγμα ως web app, αν εμφανίζεται, και πατήστε Προσθήκη.

Android

Για τη web app, ανοίξτε το μενού του browser και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στην αρχική οθόνη. Επιβεβαιώστε την εγκατάσταση.

Browser υπολογιστή

Ανοίξτε το μενού του browser ή το εικονίδιο εγκατάστασης στη γραμμή διευθύνσεων και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στο Dock.

Η εγκατάσταση της web app εξαρτάται από τον browser. Αν δεν εμφανιστεί διάλογος εγκατάστασης, ακολουθήστε τα βήματα του browser που αναφέρονται παραπάνω.