Wie Sie DNS-Einträge nachschlagen

DNS ist das System, das Domainnamen in IP-Adressen übersetzt. Wenn etwas schiefläuft, eine Website lädt nicht, eine E-Mail kommt nie an, ein SSL-Zertifikat schlägt fehl, ist das Prüfen der DNS-Einträge fast immer der erste Schritt der Fehlersuche. Zu verstehen, was jeder Eintragstyp tut, wie Anfragen durch das System fließen und wo man hinschaut, wenn die Ergebnisse nicht übereinstimmen, verwandelt mysteriöse Ausfälle in lösbare Probleme.

Eine kurze Geschichte des DNS

Vor DNS teilten sich alle Computer im frühen Internet eine einzige Datei namens HOSTS.TXT, die vom Stanford Research Institute gepflegt wurde. Jede Site lud die Datei regelmäßig herunter, um die IP-Adressen der anderen Maschinen zu erfahren. Das System funktionierte, solange das Netzwerk ein paar hundert Hosts hatte. Es skalierte nicht.

1983 veröffentlichte Paul Mockapetris RFC 882 und RFC 883, die ein hierarchisches verteiltes Namensystem beschrieben: das Domain Name System. Die Spezifikationen wurden 1987 zu RFC 1034 (Konzepte und Funktionen) und RFC 1035 (Implementierung und Spezifikation) verfeinert, die bis heute die grundlegenden Dokumente sind. Statt einer riesigen Datei wurde der Namensraum in Zonen aufgeteilt, jede von ihren eigenen autoritativen Servern verwaltet, mit einer kleinen Anzahl von Root-Servern an der Spitze des Baums.

DNS wurde seither stetig erweitert. AAAA-Einträge (RFC 3596, 2003) brachten IPv6-Unterstützung. DNSSEC (RFCs 4033 bis 4035, 2005) fügte kryptografische Signaturen zum Schutz vor Spoofing hinzu. DNS-over-TLS (RFC 7858, 2016) und DNS-over-HTTPS (RFC 8484, 2018) verschlüsselten Anfragen, damit Lauscher und Middleboxen sie weder sehen noch manipulieren können. Jede Schicht des Systems wahrt Abwärtskompatibilität, weshalb ein vierzig Jahre altes Protokoll noch immer das moderne Web antreibt.

DNS-Eintragstypen

Es gibt Dutzende von DNS-Eintragstypen, aber eine Handvoll deckt die große Mehrheit der realen Abfragen ab. Zu wissen, was jeder tut, beschleunigt die Triage.

A, AAAA, CNAME und MX beantworten die meisten alltäglichen Fragen. TXT, NS, SOA und CAA tauchen bei Konfigurations- und Sicherheitsaudits auf. SRV und NAPTR sind wichtig für VoIP, XMPP und andere Service-Discovery-Protokolle. PTR ist wichtig für Mailserver, da die meisten Spamfilter Absender ohne gültiges Reverse-DNS ablehnen.

So fragen Sie DNS-Einträge ab

1. Geben Sie eine Domain ein: Tippen Sie einen beliebigen Domainnamen (zum Beispiel example.com) in das Lookup-Tool. Sie können auch eine Subdomain wie mail.example.com eingeben, wenn Sie speziell die Einträge dieses Labels wünschen.
2. Wählen Sie einen Eintragstyp: Wählen Sie A, AAAA, MX, TXT, CNAME, NS, SOA oder CAA. Das Tool unterstützt auch das gleichzeitige Abfragen aller gängigen Typen für einen schnellen Überblick.
3. Prüfen Sie die Ergebnisse, die Antwort listet jeden passenden Eintrag mit seinem Wert, dem TTL (wie lange Resolver ihn zwischenspeichern dürfen) und allen zusätzlichen Feldern wie MX-Priorität oder SOA-Seriennummern auf.
4. Vergleichen Sie mit den Erwartungen: Wenn Sie gerade einen Eintrag geändert haben, prüfen Sie, ob der neue Wert erscheint. Wenn Sie eine fremde Partei debuggen, vergleichen Sie das Gesehene mit dem, was sie behauptet konfiguriert zu haben.

Reale Probleme mit DNS debuggen

Website lädt nicht? Prüfen Sie die A- und AAAA-Einträge. Fehlen sie, ist die Domain nicht verbunden; zeigen sie auf eine alte IP, trifft der Verkehr auf einen Server, der die Site nicht mehr hostet. Bestätigen Sie auch, dass die NS-Einträge mit den vom Registrar gelisteten Nameservern übereinstimmen, denn eine Diskrepanz bedeutet, dass die ganze Zone aus einer veralteten Quelle ausgeliefert wird.

E-Mail kommt nicht an? Prüfen Sie zuerst die MX-Einträge; fehlende oder falsche MX-Einträge bedeuten, dass nichts zugestellt werden kann. Prüfen Sie dann die TXT-Einträge für SPF (v=spf1), DKIM (default._domainkey oder ähnlich) und DMARC (_dmarc.example.com). Moderne Mailanbieter weisen Nachrichten zurück oder isolieren sie, wenn diese Checks fehlschlagen, sodass ein fehlender Eintrag Ihre Nachrichten leise in den Spam schicken kann.

SSL-Zertifikatfehler? Prüfen Sie, dass der A-Eintrag auf den Server zeigt, auf dem das Zertifikat installiert ist. Steht die Site hinter einem CDN, sollte der A-Eintrag zum CDN-Edge auflösen, nicht zum Origin. Prüfen Sie auch CAA-Einträge; ein CAA, der nur eine Zertifizierungsstelle listet, blockiert alle anderen vom Ausstellen, selbst wenn der Domain-Eigentümer erwartet, dass sie funktionieren.

Domain-Verifikation schlägt fehl? Google Workspace, Microsoft 365, Cloudflare und die meisten SaaS-Plattformen verlangen das Hinzufügen eines TXT-Eintrags zum Nachweis des Domain-Besitzes. Schlagen Sie die TXT-Einträge nach, um zu bestätigen, dass die exakte Zeichenkette vorhanden ist, einschließlich aller Anführungszeichen oder Präfixe, die die Plattform forderte.

DNS-Propagation fühlt sich langsam an? Nach dem Ändern von Einträgen liefern Resolver weltweit weiterhin gecachte Werte aus, bis das TTL abläuft. Das TTL einen Tag vor einer geplanten Änderung auf 300 Sekunden zu senken, macht den Wechsel viel schneller. Das Lookup-Tool zeigt das aktuelle TTL neben jedem Eintrag, sodass Sie vorhersagen können, wie lange veraltete Werte noch verbleiben.

SPF, DKIM und DMARC

Drei TXT-basierte Einträge schützen E-Mail vor Spoofing. SPF listet, welche Server für Ihre Domain Mail senden dürfen. DKIM veröffentlicht einen öffentlichen Schlüssel, mit dem Empfänger die kryptografische Signatur jeder Nachricht prüfen. DMARC sagt Empfängern, was zu tun ist, wenn SPF oder DKIM fehlschlägt: nichts, isolieren oder ablehnen. Alle drei leben im DNS, alle drei werden bei jeder eingehenden Nachricht abgefragt, und ein Tippfehler in einem davon kann die Zustellbarkeit lahmlegen. Ein DNS-Lookup-Tool ist der schnellste Weg, zu lesen, was tatsächlich veröffentlicht ist, getrennt davon, was die Konfigurationsoberfläche behauptet.

Zertifikatsausstellung und CAA

Wenn Sie ein TLS-Zertifikat anfordern, fragt die Zertifizierungsstelle DNS ab, um die Kontrolle zu verifizieren. Die meisten verwenden die dns-01-Challenge: Sie bitten Sie, einen bestimmten TXT-Eintrag unter _acme-challenge zu veröffentlichen, und prüfen dann, ob er erschienen ist. CAA-Einträge fügen eine weitere Schicht hinzu; sie erklären, welche Stellen Zertifikate für die Domain ausstellen dürfen. Eine falsch konfigurierte CAA kann legitime Erneuerungen blockieren, prüfen Sie CAA also immer dann, wenn ein Let's-Encrypt-Cronjob plötzlich stoppt.

Häufige Fallstricke

• Rekursive mit autoritativen Antworten verwechseln, der Resolver Ihres ISP kann eine gecachte Kopie ausliefern, die Stunden hinter der Realität liegt. Das Lookup-Tool verwendet den DNS-over-HTTPS-Endpunkt von Cloudflare, der autoritative Server direkt abfragt und ISP-Caches umgeht.
• TTL ignorieren, wenn das TTL eines Eintrags 86400 Sekunden (24 Stunden) beträgt, können Änderungen einen ganzen Tag brauchen, um überall sichtbar zu sein. Planen Sie TTL-Senkungen einen Tag vor jedem Wechsel.
• CNAME am Apex, CNAME-Einträge sind an der Wurzel einer Zone (example.com selbst) nicht erlaubt. Anbieter bieten ALIAS- oder ANAME-Einträge als Workaround an, aber sie sind kein Standard-DNS, also variiert das Verhalten.
• Mehrere SPF-Einträge stapeln, SPF verlangt genau einen TXT-Eintrag, der mit v=spf1 beginnt. Zwei SPF-Einträge führen dazu, dass empfangende Server das Ergebnis als PermError markieren, was die Zustellbarkeit untergräbt.
• Den abschließenden Punkt vergessen, in Zonendateien werden Namen ohne abschließenden Punkt als relativ zur Zone behandelt, sodass ein fehlender Punkt mail.example.com in mail.example.com.example.com verwandelt.
• IPv4- und IPv6-A-Einträge vermischen, A ist nur für IPv4. Eine IPv6-Adresse in einen A-Eintrag (statt AAAA) zu setzen, ist ein Konfigurationsfehler, den manche Oberflächen nicht abfangen.
• CNAME-Ketten, die zurückschleifen, ein CNAME, der auf einen anderen CNAME zeigt, der wieder zurückzeigt, erzeugt eine Auflösungsschleife. Resolver kappen die Kette nach etwa acht Hops und geben auf.
• Caching auf mehreren Schichten, Browser, Betriebssystem, Router und Resolver cachen DNS unabhängig. Nur einen davon zu leeren, reicht selten; greifen Sie zum Lookup-Tool, um die Kette komplett zu umgehen.
• Wildcards verbergen fehlende Einträge, ein Wildcard-A-Eintrag (*.example.com) trifft jede Subdomain ohne expliziten Eintrag, was Fehlkonfigurationen verbergen kann.
• Nur einem Resolver vertrauen, Propagation ist uneinheitlich. Fragen Sie mehrere Resolver (1.1.1.1, 8.8.8.8, 9.9.9.9) ab, wenn Sie eine globale Änderung verifizieren.

Andere Wege, DNS abzufragen

Das browserbasierte Lookup-Tool ist der schnellste Pfad für die meisten Checks, aber Kommandozeilentools bieten reicheres Detail, wenn Sie es brauchen.

Jedes hat Kompromisse. dig +trace läuft den DNS-Baum von den Wurzeln aus durch und zeigt jeden Schritt, was unbezahlbar ist, um zu beweisen, wo eine Kette bricht. nslookup ist überall verfügbar und reicht für schnelle Sanity-Checks. Das Web-Tool gewinnt bei Geschwindigkeit und dadurch, dass es überhaupt kein Terminal braucht.

Datenschutz und DNS

Normale DNS-Anfragen reisen im Klartext, was bedeutet, dass Ihr ISP und jeder im Netzwerk jede besuchte Domain sehen kann. Zwei verschlüsselte Varianten lösen das: DNS-over-HTTPS (DoH) verpackt Anfragen in HTTPS, und DNS-over-TLS (DoT) verpackt sie in TLS auf einem dedizierten Port. Das Lookup-Tool verwendet den DoH-Endpunkt von Cloudflare, sodass Ihre Anfrage an den Resolver im Transit verschlüsselt ist. Die Domain, nach der Sie fragen, bleibt für den Resolver selbst beobachtbar; wenn das ein Anliegen ist, betreiben Sie Ihren eigenen Resolver (Unbound, Pi-hole) oder nutzen Sie einen kostenpflichtigen, datenschutzfokussierten Dienst, der verspricht, nichts zu protokollieren.

Browserbasierte Lookups speichern Ihre Anfragen nie auf unseren Servern. Die Anfrage geht direkt vom Browser zum DoH-Resolver und die Antwort wird clientseitig gerendert. Es gibt kein Protokoll, das vorgeladen werden könnte, keine Analyse darüber, welche Domains Sie geprüft haben, und nichts, was bei einem zukünftigen Leck austreten könnte. Für eine Aufgabe, die so routiniert ist wie DNS-Debugging, ist das genau das Datenschutzniveau, das die Arbeit verdient.