kruemel/OZM-Keks-Handbuch-v1
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2305f0bbcbe3be629cb72ebe306f1290c5fef232
OZM-Keks-Handbuch-v1/crumbpage-15-dns.md

7.1 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:

  • Iterativ: "Ich kenne die Antwort nicht, aber hier ist die IP vom Server, der es weiß." (Verhalten der Root/TLD Server).
  • Rekursiv: "Ich frage für dich nach und gebe dir das fertige Ergebnis." (Verhalten deines lokalen Resolvers/ISPs).

🔧 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. Oft für SPF, DKIM, Verification. IN TXT "v=spf1 ..."

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).

# Standard Abfrage (A Record)
dig example.com

# Bestimmten Record-Typ abfragen
dig example.com MX

# Bestimmten Nameserver befragen (Bypass lokaler Resolver)
dig @8.8.8.8 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 | Admin-Vektor Übersicht