DNS-Eintraege pruefen: Typen, Bedeutung und Fehleranalyse im Ueberblick

DNS-Eintraege pruefen ist der erste Schritt, wenn eine Website nicht erreichbar ist, E-Mails nicht ankommen oder ein SSL-Zertifikat nicht passt. Das Domain Name System uebersetzt Domainnamen in IP-Adressen und steuert, wohin Anfragen geroutet werden. Wenn hier etwas falsch konfiguriert ist, funktioniert die darueberliegende Anwendung trotz gesundem Server oft nicht.

Was DNS ist und warum es alles verbindet

Das Domain Name System ist die verteilte Infrastruktur, die Hostnamen wie example.de in IP-Adressen uebersetzt. Ohne DNS muessten Nutzende sich jede Zieladresse direkt merken. In der Praxis fragt der lokale Resolver zuerst einen rekursiven Resolver, dieser folgt der Delegationskette ueber Root-Server, TLD-Zone und autoritative Nameserver, bis die finale Antwort aus der Zone der Domain gefunden wird.

Genau deshalb sollte DNS vor fast jedem weiteren Troubleshooting geprueft werden. Wenn der A-Record auf die falsche Adresse zeigt, wenn der MX-Eintrag fehlt oder wenn die Nameserver-Delegation inkonsistent ist, bringen weder Ping-Tests noch Applikations-Logs die richtige Ursache ans Licht. Ein DNS-Fehler sitzt eine Schicht tiefer und muss dort gelesen werden.

Fuer das Grundverstaendnis lohnt sich ein Blick auf RFC 1035 und die Beschreibung der Root-Server bei IANA. Beides zeigt, warum DNS nicht aus einem einzelnen Server besteht, sondern aus einer Hierarchie, in der Delegation, Caching und Autoritaet zusammenspielen.

DNS-Record-Typen im Detail

Jeder DNS-Record hat einen klaren Zweck. Die Kombination aus A, AAAA, MX, TXT, CNAME, NS und SOA deckt bereits die meisten Web-, Mail- und Infrastrukturfragen ab. Wer diese Typen lesen kann, erkennt viele Stoerungen bereits vor dem ersten Blick in Webserver-, MTA- oder Firewall-Logs.

Der A-Record ist der klassische Web-Record. Er verbindet einen Hostnamen mit einer IPv4-Adresse und ist bei Serverwechseln haeufig die erste Fehlerquelle. Der AAAA-Record uebernimmt dieselbe Aufgabe fuer IPv6. Wenn AAAA vorhanden ist, die Anwendung aber kein stabiles IPv6 bedient, entstehen oft Stoerungen, die nur fuer einen Teil der Nutzenden sichtbar sind.

Der MX-Record entscheidet ueber den Mail-Empfang. Die niedrigste Prioritaetszahl wird zuerst angesprochen. Der TXT-Record dient heute nicht mehr nur fuer beliebigen Text, sondern traegt zentrale Mail-Security-Informationen, Domain-Verifikationen und teilweise produktkritische Policies. NS und SOA wiederum sind fuer Delegation und Zonenverwaltung entscheidend. Gerade bei Migrationen zwischen DNS-Providern wird hier viel Autoritaet verloren, wenn alte und neue Nameserver parallel oder inkonsistent konfiguriert bleiben.

Haeufige DNS-Probleme und wie Sie sie erkennen

Website nach dem Relaunch nicht erreichbar? Dann zeigt der A-Record oft noch auf die alte Infrastruktur oder der CNAME verweist auf ein nicht mehr gueltiges CDN-Ziel. E-Mails kommen nicht an? Dann sind MX-Eintraege, SPF oder der autoritative TXT-Record die naechsten Kandidaten. Auch Zertifikatsfehler lassen sich haeufig auf DNS zurueckfuehren, wenn der Hostname technisch zu einem anderen Endpunkt geleitet wird als erwartet.

Ein weiteres Standardproblem ist die uneinheitliche Sicht zwischen resolvender Infrastruktur. Der lokale Rechner sieht noch einen alten Datensatz, waehrend ein Server bereits die neue Antwort liefert. In solchen Faellen lohnt sich der Vergleich von DNS-Abfrage, WHOIS-Abfrage und Erreichbarkeitstest. So laesst sich unterscheiden, ob die Domain bereits korrekt delegiert ist oder ob nur einzelne Resolver noch am alten Cache festhalten.

Auch NS- und SOA-Werte liefern in Stoerungsfaellen mehr Signal, als viele Teams vermuten. Wenn die Delegation noch auf alte Nameserver zeigt oder die Seriennummer der Zone nach einer Aenderung nicht sauber hochgezaehlt wurde, entstehen schwer lesbare Teilfehler. Dann sieht ein Resolver die neue Zone, ein anderer aber weiterhin den alten Stand. Wer das mit einer IP-Adresse-Suche des Zielhosts kombiniert, kann haeufig schon vor dem Login in fremde Systeme erkennen, ob DNS oder Infrastruktur die wahrscheinlichere Ursache ist.

TTL: Warum DNS-Aenderungen nicht sofort sichtbar sind

TTL steht fuer Time to Live und definiert, wie lange Resolver eine Antwort im Cache behalten duerfen. Bei einem TTL von 3600 Sekunden kann ein Resolver die Antwort bis zu eine Stunde lang wiederverwenden. Bei 86400 Sekunden ist eine veraltete Sicht bis zu 24 Stunden moeglich. Wer DNS nur an einer Stelle prueft, uebersieht diesen zeitlichen Aspekt schnell.

Das macht DNS-Migrationen planungsintensiv. Wenn ein Record unmittelbar vor dem Umschalten noch eine sehr hohe TTL hat, verbreitet sich die neue Zieladresse nicht sofort. Sinnvoll ist es deshalb, die TTL vor geplanten Eingriffen rechtzeitig zu senken, damit Caches schneller auslaufen. Nach der Stabilisierung kann die TTL wieder erhoeht werden, um Resolver zu entlasten.

Gerade bei CDN-, Mail- oder Multi-Provider-Setups lohnt sich diese TTL-Perspektive doppelt. Dort greifen oft mehrere zwischengeschaltete Resolver, Health-Checks oder externe Plattformen gleichzeitig auf die Zone zu. Eine Aenderung wirkt dann nicht als einzelner Schalter, sondern als zeitversetzter Rollout ueber viele Caches hinweg. Wer DNS-Antworten richtig lesen will, muss deshalb immer auch den Zeitfaktor mitlesen.

SPF, DKIM und DMARC: Mail-Sicherheit im TXT-Eintrag

SPF definiert, welche Server E-Mails im Namen einer Domain versenden duerfen. DKIM fuegt ausgehenden Nachrichten eine kryptografische Signatur hinzu. DMARC legt fest, wie Empfaengersysteme reagieren sollen, wenn SPF oder DKIM fehlschlagen. Fuer die Standards sind vor allem RFC 7208, RFC 6376 und RFC 7489 relevant.

In der Praxis ist dieser Teil fuer die Zustellbarkeit oft wichtiger als jede optische Mail-Einstellung. Eine Domain kann technisch korrekt aufloesen und dennoch bei grossen Empfaengern im Spam landen, wenn die Mail-Security-Records fehlen oder widerspruechlich formuliert sind. Genau deshalb sollte ein DNS-Tool nicht nur A- und MX-Records zeigen, sondern den TXT-Bereich genauso ernst nehmen.

Wer DNS-Eintraege pruefen: DNS-Abfrage starten sinnvoll nutzen will, sollte nicht nur die nackten Antworten lesen, sondern Delegation, Caching und den fachlichen Kontext der Eintraege zusammendenken. Dann wird aus einer einfachen DNS-Abfrage eine belastbare Grundlage fuer Web-, Mail- und Infrastrukturdiagnose.

Fragen zur DNS-Abfrage