# DNS Fundamentals: Die Architektur der Namensauflösung

TL;DR / Management Summary Ohne das DNS (Domain Name System) wäre das Internet für Menschen unbenutzbar. Es übersetzt menschenlesbare Namen (z.B. wiki.de) in maschinenlesbare IP-Adressen (z.B. 1.2.3.4). Ein Senior Admin versteht die hierarchische Struktur (Root -> TLD -> Domain -> Host) und weiß, dass in einer Active Directory Umgebung das DNS das eigentliche Rückgrat der Identität und Dienstfindung ist.

# 1. Die hierarchische Struktur

Von der Wurzel zum Blatt.

DNS ist wie ein umgedrehter Baum aufgebaut:

1. Root Zone ( . ): Die 13 weltweiten Root-Server-Cluster.
2. Top-Level Domain (TLD): .de, .com, .org, .internal.
3. Second-Level Domain: meinefirma.
4. Subdomain / Host: www, mail, pve01.

• FQDN (Fully Qualified Domain Name): Der vollständige Pfad inklusive Punkt am Ende, z.B. srv01.it.firma.de..

# 2. Der Auflösungs-Prozess

Wer fragt wen?

Wenn Sie google.de in den Browser tippen:

1. Resolver (Ihr PC): Fragt den konfigurierten DNS-Server (z.B. OPNsense).
2. Iterative Suche:
   • OPNsense fragt Root: “Wer kennt .de?”.
   • Root antwortet: “Frag die DENIC Server”.
   • OPNsense fragt DENIC: “Wer kennt google.de?”.
   • DENIC antwortet: “Frag die Google Name-Server”.
3. Ergebnis: Der Name-Server von Google liefert die IP 142.250... zurück.

# 3. Deep Dive: DNS Caching & TTL

Zeit ist Geld.

Damit nicht bei jedem Klick die weltweite Kette abgefragt werden muss, nutzen wir Caching.

• TTL (Time To Live): Der Besitzer der Domain legt fest, wie viele Sekunden die Antwort gültig ist.
• Best Practice:
  • Standard: 3600 - 86400 Sek (1h bis 1 Tag).
  • Vor Migrationen: TTL auf 60 Sek senken, damit IP-Wechsel sofort greifen.

# 4. Day-2 Operations: DNS in der Domäne

Active Directory Abhängigkeit.

In einer Windows-Domäne (Artikel 487) registrieren sich Server selbstständig im DNS via SRV-Records.

• Wichtig: Clients müssen zwingend den Domain-Controller als DNS-Server nutzen. Ein direkter Eintrag von 8.8.8.8 am Client macht das Einloggen in die Domäne unmöglich.

# 5. Troubleshooting & “War Stories”

Wenn die Namen lügen.

# Top 3 Fehlerbilder

1. Symptom: “Website not found”, aber Ping auf IP geht.

   • Check: nslookup wiki.de.
   • Ursache: DNS-Server am Client falsch oder Firewall blockiert UDP Port 53.

2. Symptom: Ping auf Host liefert alte IP zurück.

   • Ursache: Veralteter lokaler Cache.
   • Lösung: ipconfig /flushdns (Windows) oder systemd-resolve --flush-caches (Linux).

3. Symptom: Sporadische DNS-Hänger.

   • Ursache: Zu viele Forwarder-Ebenen oder langsame Antwortzeiten der Root-Server.

# “War Story”: Die “.local” Falle

Ein Unternehmen nutzte seit 15 Jahren firma.local als interne Domain. Das Ereignis: Einführung von Apple MacBooks im Unternehmen. Plötzlich waren interne Server für die Macs nicht mehr erreichbar. Die Ursache: Das Protokoll mDNS (Bonjour) nutzt .local exklusiv für die lokale Ad-hoc Suche. Die Macs weigerten sich, eine .local Adresse über den DNS-Server aufzulösen. Lehre: Nutzen Sie niemals .local für echte DNS-Zonen. Verwenden Sie Subdomains Ihrer echten Firmendomain (z.B. int.firma.de) oder reservierte Suffixe wie .home.arpa.

# 6. Monitoring & Reporting

DNS-Health Dashboard.

# DNS Latency

Überwachen Sie die Antwortzeit Ihres internen DNS-Resolvers (Artikel 579).

• KPI: dns_query_time_ms. Ziel: < 10ms für Cache-Treffer, < 100ms für externe Anfragen.

# 7. Fazit & Empfehlung

DNS ist das Navigationssystem Ihres Netzwerks.

• Empfehlung: Nutzen Sie einen validierenden Resolver (wie Unbound in OPNsense) mit aktiviertem DNSSEC.
• Wichtig: Dokumentieren Sie alle manuellen Einträge (Static Overrides) in Ihrem IPAM (Artikel 731). Ein “versteckter” Host-Eintrag in der Firewall ist bei einer Migration die perfekte Fehlerquelle.

# Anhang: Cheatsheet (DNS Tools)

# Referenzen

• RFC 1034: Domain Names - Concepts and Facilities
• RFC 1035: Domain Names - Implementation and Specification
• ICANN: Beginner’s Guide to Domain Names