DNS — Auflösung, Records & TTL

Worum geht’s

„Es geht nicht — aber pingen kann ich die IP.” Klassiker: das Netz ist intakt, nur die Namensauflösung hakt. DNS übersetzt Namen wie www.firma.de in IP-Adressen und steuert nebenbei, wohin E-Mails gehen (MX) und welche Mail-Server senden dürfen (SPF/TXT). Wer Records, TTL und den Auflösungsweg versteht, findet solche Fehler in Minuten.

Konzept

DNS ist ein verteiltes, hierarchisches System. Eine rekursive Auflösung läuft so: dein Stub-Resolver fragt den rekursiven Resolver (z. B. 1.1.1.1), der hangelt sich über Root → TLD → autoritativen Nameserver zur Antwort und cached sie.

Wichtige Record-Typen:

• A / AAAA — Name → IPv4 / IPv6.
• CNAME — Alias auf einen anderen Namen (nie auf einer Apex-Domain mit anderen Records).
• MX — Mailserver für eine Domain, mit Priorität (kleinste Zahl = bevorzugt).
• NS — zuständige Nameserver der Zone.
• TXT — Freitext, u. a. SPF, DKIM, DMARC zur Mail-Authentifizierung.
• PTR — Reverse: IP → Name.

Die TTL (Time To Live, in Sekunden) sagt, wie lange ein Resolver einen Record cachen darf. Hohe TTL = schnell & stabil, aber Änderungen brauchen lange. Vor einer Migration TTL absenken (z. B. auf 300 s), damit der Umzug schnell sichtbar wird.

Beispiel-Fall

Gegeben: Mails an @firma.de kommen nicht an. Du prüfst die DNS-Records.

1. MX abfragen: firma.de liefert 10 mail.firma.de. Priorität 10, also der Hauptserver.
2. A des Mailservers: mail.firma.de → 203.0.113.25. Existiert — gut.
3. TXT/SPF prüfen: v=spf1 ip4:203.0.113.25 -all. Der sendende Server steht drin, -all lehnt alles andere hart ab. Konsistent.
4. TTL beachten: Der MX hat TTL 3600. Wurde er gerade geändert, kann ein alter Wert noch bis zu einer Stunde im Cache stehen — das erklärt „bei manchen geht’s, bei manchen nicht”.
5. Verdikt: Records stimmen; das Problem ist Caching nach einer kürzlichen Änderung. Lösung: warten bis TTL abgelaufen, künftig vor Änderungen TTL senken.

Anwenden

Selbsttest

Praxis-Challenge