# 🌐 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](crumbpage-06-netzwerk.md), [Services & Ports](crumbpage-10-services-ports.md) > *"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:** ```dns @ 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. ```text 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. ```text 127.0.0.1 localhost 192.168.1.10 internal.server.local ``` ### 3. `/etc/resolv.conf` Die Konfiguration des Resolvers. ```text 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): ```text ;; 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: ```bash # 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](crumbpage-14-environment.md) | [Admin-Vektor Übersicht](crumbforest-admin-vektor.md)