kruemel/OZM-Keks-Handbuch-v1
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
9193d3380aa8368f30136e32dfa8235c3775b1df
OZM-Keks-Handbuch-v1/crumbpage-15-dns.md
Krümel Branko 431c747972 docs: fresh breadcrumbs for paths 15-17 - no more getting lost! 🍞🌲 
Updated admin-vektor index and fixed linear navigation links. The Crystal Owl approves. 🦉
2025-12-11 23:38:58 +01:00

10 KiB
Raw Blame History

🌐 Crumbpage 15: DNS - The Phonebook of the Internet

Subtitle: Namensauflösung verstehen und beherrschen
Pfad: 15 von X
Schwierigkeit: ⭐⭐⭐⭐ (4/5)
Zeit: ~4 Stunden
Voraussetzungen: Netzwerk Basics, Services & Ports

"It’s not DNS. There’s no way it’s DNS. It was DNS." 🕵️‍♂️

📋 Was du in diesem Pfad lernst

✓ Geschichte: Von HOSTS.TXT zu BIND
✓ Theorie: Rekursion vs. Iteration, Zones & Records
✓ Server: BIND9 Konfiguration & Zonefiles
✓ Client: Resolver, nsswitch.conf & hosts
✓ Debugging: dig, host & Logfiles

🎯 Lernziele

Nach diesem Pfad kannst du:

  • Den Unterschied zwischen autoritativen und rekursiven Servern erklären
  • Eine Zonefile Syntax (SOA, NS, A, MX, CNAME) lesen und schreiben
  • Client-seitige DNS-Probleme diagnostizieren (/etc/resolv.conf)
  • Mit dig komplexe Abfragen durchführen und Antworten analysieren

🌱 Grundkonzepte & Geschichte

Konzept 1: Die Geschichte (Old School Wissen)

Vor 1983: Das Internet (damals ARPANET) war klein. Es gab eine zentrale Datei: HOSTS.TXT.

  • Verwaltet vom NIC (Network Information Center) am SRI (Stanford).
  • Jeder Admin musste diese Datei via FTP herunterladen.
  • Problem: Nicht skalierbar. Namenskollisionen. Traffic.

1983 - Die Lösung: Paul Mockapetris entwarf DNS (RFC 882, 883).

  • Hierarchisch: Root (.) -> Top-Level (.com, .de) -> Second-Level.
  • Dezentral: Verantwortung wird delegiert.
  • Datenbank: Verteiltes System statt einer Textdatei.

Konzept 2: Die Infrastruktur

Die Hierarchie: Ein FQDN (Fully Qualified Domain Name) wird von rechts nach links gelesen: www.example.com.

  1. Root (.): Die Wurzel aller DNS-Anfragen. Verwaltet von der IANA. Es gibt 13 Root-Server-Identitäten (A-M).
  2. TLD (.com): Top-Level-Domain. Verwaltet von Registries (z.B. Verisign).
  3. SLD (example): Second-Level-Domain. Deine Domain.
  4. Subdomain (www): Hostname in deiner Zone.

Abfrage-Typen (Erklärt für 8-80 Jährige):

  • Iterativ (Die 80-jährige Bibliothekarin): Du fragst: "Wo ist das Buch über Ameisen?" Sie sagt: "Ich weiß es nicht, aber geh in den 2. Stock zu Frau Müller, die ist zuständig für Biologie." Du gehst zu Frau Müller. Sie sagt: "Geh zu Regal 4." Du gehst zu Regal 4. (Du musst die Arbeit machen).
  • Rekursiv (Das 8-jährige Kind): Das Kind fragt: "Warum ist der Himmel blau?" Du (als Server) googelst es, liest drei Wikipedia-Artikel, fasst es zusammen und sagst dem Kind einfach: "Wegen der Lichtbrechung." (Das Kind wartet nur auf die fertige Antwort).
    • Dein PC stellt rekursive Anfragen (will Ergebnisse).
    • Root-Server antworten nur iterativ (schicken dich weiter).

Konzept 3: Der Weg der Anfrage (Und warum es dauert)

Wie kommt facebook.com auf deinen Bildschirm?

  1. Client (Stub Resolver): Chrome fragt das OS. OS schaut in den Cache. Nix da?
  2. Router (Forwarder): Anfrage geht an die FritzBox. Die weiß es auch nicht -> ab zum Provider.
  3. ISP Recursor: Der DNS-Server der Telekom/Vodafone. Der macht die Arbeit.
    • Fragt Root (.) -> "Geh zu .com Servern".
    • Fragt TLD (.com) -> "Geh zu facebook.com Nameservern".
    • Fragt Authoritative (ns1.facebook.com) -> "Hier ist die IP!".
  4. Rückweg & Cache: Der ISP merkt sich die Antwort für die dauer der TTL (Time To Live).
    • TTL = 86400 (24h): Wenn Facebook die IP ändert, bekommt der ISP das erst morgen mit.
    • Kaskade: Browser cachet, OS cachet, Router cachet, ISP cachet. Änderungen können dauern!

🔧 Server & Zonen (Theorie & BIND)

Der De-Facto Standard im Unix-Umfeld ist BIND (Berkeley Internet Name Domain). Auch wenn es modernere Alternativen gibt (Unbound, Knot), ist BIND "das Original".

Zonendateien (Zone Files)

Das Herzstück. Textdateien, die die Records enthalten.

Wichtige Resource Records (RR):

Typ Erklärung Beispiel
SOA Start of Authority. Der wichtigste Record. Definiert Zonen-Parameter (Serial, Refresh, TTL). @ IN SOA ns1.example.com. admin.example.com. ...
NS Name Server. Wer ist autoritativ für diese Zone? IN NS ns1.example.com.
A Address. Hostname -> IPv4. www IN A 192.0.2.1
AAAA Quad-A. Hostname -> IPv6. www IN AAAA 2001:db8::1
CNAME Canonical Name. Alias auf einen anderen Namen (nicht IP!). ftp IN CNAME www.example.com.
MX Mail Exchange. Wo gehen Mails hin? Mit Priorität. IN MX 10 mail.example.com.
PTR Pointer. Reverse DNS (IP -> Name). Wichtig für Mailserver. 1 IN PTR www.example.com.
TXT Text. Beliebiger Text. Essentiell für SPF (Wer darf Mail senden?) & DKIM (Krypto-Signatur für Mails). IN TXT "v=spf1 ..."
CAA Certificate Authority Authorization. Wer darf TLS-Zertifikate für mich ausstellen? Schutz gegen falsche Ausstellung. IN CAA 0 issue "letsencrypt.org"

Spezialfall: Glue Records (Das Henne-Ei-Problem) Wenn dein Nameserver HINTER der Domain liegt, die er auflösen soll (z.B. Zone example.com, Nameserver ns1.example.com), gibt es ein Problem: Um example.com zu finden, muss ich ns1.example.com fragen. Um ns1.example.com zu finden, muss ich example.com auflösen. 🤯 Lösung: Die übergeordnete Zone (.com) speichert nicht nur den Namen des NS, sondern auch direkt dessen IP ("Glue" / Klebstoff).

Anatomie eines SOA Records:

@   IN  SOA     ns1.example.com. hostmaster.example.com. (
        2023120801 ; Serial (YYYYMMDDnn) - Immer erhöhen bei Änderungen!
        3H         ; Refresh (Wie oft Slaves fragen)
        1H         ; Retry (Wenn Refresh fehlschlägt)
        1W         ; Expire (Wann Slaves aufgeben)
        1D )       ; Minimum TTL (Negatives Caching)

🔌 Client & Anbindung (Linux/Unix)

Wie weiß dein Server, wen er fragen muss?

1. /etc/nsswitch.conf

Der "Dispatch Manager". Regelt die Reihenfolge der Namensauflösung.

hosts:      files dns

Bedeutet: Erst in lokalen Files (/etc/hosts) schauen, dann DNS fragen.

2. /etc/hosts

Die moderne HOSTS.TXT. Nützlich für lokales Testing oder overrides.

127.0.0.1       localhost
192.168.1.10    internal.server.local

3. /etc/resolv.conf

Die Konfiguration des Resolvers.

nameserver 8.8.8.8
nameserver 1.1.1.1
search example.com
domain example.com

⚠️ Achtung: Wird heute oft von Systemdiensten (systemd-resolved, NetworkManager) überschrieben. Prüfe, ob es ein Symlink ist!

🛠 Tools & Logs

Dig (Domain Information Groper)

Das Werkzeug der Wahl für Profis. Vergiss nslookup (deprecated/inkonsistent).

Dig Deep Dive: MX Analyse

dig gmail.com MX liefert dir die Wahrheit über Mailserver. Schauen wir uns den Output an (vereinfacht):

;; QUESTION SECTION:
;gmail.com.                     IN      MX              (Was haben wir gefragt?)

;; ANSWER SECTION:    (Die Antwort!)
gmail.com.        306   IN      MX      5 gmail-smtp-in.l.google.com.
gmail.com.        306   IN      MX      10 alt1.gmail-smtp-in.l.google.com.
|                 |     |       |       |  |
|                 |     |       |       |  Target Server
|                 |     |       |       Priority (Niedriger = Wichtiger)
|                 |     |       Record Type
|                 |     Class (Internet)
|                 TTL (Sekunden bis Cache verfällt)
Domain Name

;; ADDITIONAL SECTION: (Kostenloser Service!)
gmail-smtp-in.l.google.com. 78  IN      A       142.250.153.27
(Der Server liefert die IPs der Mailserver gleich mit, damit du nicht nochmal fragen musst -> Optimierung!)

Warum mehrere Einträge? (Die Logik dahinter)

  1. Redundanz (Failover): Mailserver sind kritisch. Der Absender versucht es immer erst beim Server mit der niedrigsten Zahl (im Beispiel 5). Ist dieser tot (Timeout/Connection Refused), wird der nächste (10) probiert.
  2. Lastverteilung: Haben zwei Server die gleiche Zahl, wird die Last zufällig zwischen ihnen aufgeteilt.

Weitere nützliche Befehle:

# Standard Abfrage (A Record)
dig example.com

# Trace vom Root bis zur Antwort (Sehr lehrreich!)
dig +trace example.com

# Reverse Lookup (IP -> Name)
dig -x 192.0.2.1

Logs

DNS Fehler sind oft still. Logs sind dein Freund.

  • Syslog: /var/log/syslog oder /var/log/messages (such nach named).
  • Query Log: Kann in BIND aktiviert werden (vorsicht: riesig!).

Häufige Fehlercodes

  • NOERROR: Alles gut (auch wenn Antwort leer ist -> NOERROR mit 0 Answers bedeutet "Name existiert, aber nicht dieser Record-Typ").
  • NXDOMAIN: Non-Existent Domain. Der Name existiert nicht.
  • SERVFAIL: Serverfehler. Config falsch, DNSSEC broken, oder Upstream down.
  • REFUSED: Server verweigert Antwort (z.B. falsche ACL für Rekursion).

🎓 Hands-On Übungen

Übung 1: Manuelle Auflösung "Spielen"

Aufgabe: Verfolge den Pfad einer Domain von der Root an.

Schritte:

  1. Finde die Root-Server: dig . NS
  2. Nimm einen davon (z.B. a.root-servers.net) und frag nach .de: dig @a.root-servers.net de. NS
  3. Nimm einen TLD-Server und frag nach einer Domain: dig @[TLD-SERVER-IP] crumbforest.de NS
  4. Frag den autoritativen Server nach der IP.

Übung 2: Record Analyse

Aufgabe: Analysiere die Mail-Setup von gmail.com.

Befehl: dig gmail.com MX

Frage: Warum gibt es mehrere Einträge mit unterschiedlichen Zahlen (Preference)?

💭 Reflexion

Was war neu für mich?

[Deine Notizen]

Warum ist "It was DNS" ein Meme? Weil DNS eine kritische Infrastruktur ist. Wenn DNS ausfällt, geht scheinbar nichts mehr, obwohl die Leitungen stehen. Ping auf IPs geht, Browser geht nicht.

🦉 Crystal Owl's Weisheit

"Ein guter Admin kennt seine Zonen. Ein sehr guter Admin vergisst nie, die Serial zu erhöhen."

Krümel-Tipp:
Wenn du Änderungen an einer Zone machst und nichts passiert:
1. Hast du die Serial erhöht?
2. Hast du `rndc reload` (bei BIND) ausgeführt?
3. Cached dein Client oder Resolver noch die alte Antwort (TTL)?

Version: 1.0
Status: Theory Draft
Tags: #DNS #BIND #Netzwerk #Theorie

Navigation:
← Zurück: Environment | Weiter: VPN →