Netzwerk

DNS-Checker: Einträge, TTL und Fehler verstehen

ToolMellow · Aktualisiert am 6. Oktober 2026

Eine DNS-Abfrage fordert bei einem Resolver einen bestimmten Eintragstyp für einen bestimmten Namen an. Mit dem DNS-Checker von ToolMellow können Sie zurückgegebene Adressen, Aliase, Mailrouten oder Texteinträge prüfen, ausgewählte Anbieter vergleichen und eine Beobachtung mit Zeitangabe speichern. Beginnen Sie mit dem genauen DNS-Namen und dem Eintragstyp für Ihre Aufgabe.

Das Tool fragt Cloudflare und Google Public DNS über die verfügbaren ToolMellow-Abfragestandorte ab. Die Ergebnisse beschreiben diese Anfragen; sie zeigen nicht, was jeder Nutzer, jedes Gerät oder jeder Resolver sieht. Dieser Leitfaden erklärt die Bedienung, die Ergebnisinterpretation und die Untersuchung abweichender Werte. Alle folgenden Namen, Adressen und Eintragswerte sind Beispiele und keine Live-Messungen.

DNS-Checker

So führen Sie eine DNS-Abfrage aus

Öffnen Sie den DNS-Checker und warten Sie, bis die Verbindungskonfiguration geladen ist. Geben Sie einen Namen wie www.example.com ein, wählen Sie einen Eintragstyp, einen oder beide Anbieter und die verfügbaren Abfragestandorte. Klicken Sie auf DNS prüfen, um die Anfrage zu senden. Das Laden der Seite oder Bearbeiten des Namens fragt die Einträge nicht automatisch ab.

Lesen Sie Anbieter, Standort, Status und Zeitangabe, bevor Sie Werte interpretieren. Wenn Sie den benötigten Wert kennen, tragen Sie ihn im optionalen Feld ein und wählen Exakte Übereinstimmung oder Enthält. DNS-Bericht herunterladen speichert die aktuelle Beobachtung als dns-results.json; behalten Sie die Datei für einen Vorher-Nachher-Vergleich.

Jede Prüfung verwendet einen DNS-Namen und einen Eintragstyp. Führen Sie getrennte A- und AAAA-Abfragen aus, wenn Sie beide Adressfamilien untersuchen.
Standardmäßig sind A, beide Anbieter und der ToolMellow-Hauptstandort ausgewählt. Verfügbare Standorte stammen aus der aktuellen Dienstkonfiguration.
Eine Änderung von Name, Typ, Anbieter oder Standort löscht das alte Ergebnis. Ein anderer erwarteter Wert oder Vergleichsmodus vergleicht das aktuelle Ergebnis erneut lokal.

Den DNS-Eintragstyp passend zur Aufgabe wählen

DNS-Einträge beantworten unterschiedliche Fragen. Eine A-Abfrage fordert nicht alle Einträge einer Domain an, und eine MX-Abfrage verschickt keine Testmail. Die Auswahl unterstützt neun Typen. Der Vergleich erwarteter Werte unterstützt die acht unten genannten Typen für Vorwärtsabfragen; PTR-Ergebnisse können geprüft und heruntergeladen werden, ihr Vergleich mit einem erwarteten Wert ist aber nicht verfügbar.

Den DNS-Eintragstyp passend zur Aufgabe wählen
Typ	Inhalt	Praktische Bedeutung
A	IPv4-Adressdaten	Prüfen Sie die zurückgegebene IPv4-Adresse des angefragten Namens; das testet nicht die Website an dieser Adresse.
AAAA	IPv6-Adressdaten	Prüfen Sie IPv6 getrennt von A; ein funktionierendes IPv4-Ziel beweist keine funktionierende IPv6-Verbindung.
CNAME	Zielname eines Alias	Prüfen Sie den Alias und seine zurückgegebene Schreibweise. Ein DNS-Alias erzeugt selbst keine HTTP-Weiterleitung.
MX	Präferenz und Zielname eines Mailservers	Lesen Sie Präferenz und Hostnamen. Ein vorhandener Eintrag beweist keine erfolgreiche Mailzustellung.
TXT	In DNS gespeicherter Text	Prüfen Sie Verifizierungs- oder Maildaten beim genau vom Anbieter genannten Eintragsnamen.
NS	Nameserver-Namen	Prüfen Sie die zurückgegebenen Namen; diese sind vom gewählten rekursiven Anbieter der Abfrage zu unterscheiden.
SOA	Autoritätsmetadaten der Zone	Prüfen Sie Zonenmetadaten und den Kontext negativer Antworten; die Abfragezeit ist nicht die Änderungszeit des Eintrags.
CAA	Autorisierungsdaten für Zertifizierungsstellen	Prüfen Sie veröffentlichte Autorisierungen; das ist kein Test der Zertifikats- oder HTTPS-Gültigkeit.
PTR	Namenszeiger für Reverse-DNS	Geben Sie den vollständigen Namen des Reverse-DNS-Eintrags ein. Eine wörtliche IP-Adresse und der Erwartungswertvergleich werden hier nicht unterstützt.

RFC 1035: DNS-Implementierung und Eintragsformate RFC 3596: DNS-Erweiterungen für IPv6 RFC 8659: Zertifizierungsstellen-Autorisierung

Den richtigen DNS-Namen eingeben, einschließlich TXT-Namen und IDNs

Verwenden Sie den Namen, unter dem der DNS-Eintrag liegt, ohne URL-Schema, Pfad, Mailadresse oder Port. Die Basisdomain und ihr Name www sind verschiedene Eingaben. Verifizierungshinweise können eine Subdomain oder einen Namen mit Unterstrichpräfix verlangen; TXT an der Basisdomain zu suchen findet nicht automatisch TXT bei diesen anderen Namen.

Der Checker entfernt Leerraum an den Rändern, erkennt unterstützte Unicode-Punktvarianten, entfernt einen abschließenden Wurzelpunkt, wandelt unterstützte internationale Namen mit Nodes domainToASCII in ASCII um und schreibt den Namen klein. Er verlangt mindestens zwei Labels mit jeweils höchstens 63 ASCII-Zeichen nach der Umwandlung und insgesamt höchstens 253. Gewöhnliche Labels erlauben Buchstaben, Ziffern und innere Bindestriche. Unterstützte Dienstlabels mit Unterstrichpräfix werden akzeptiert, beliebige innere Unterstriche dagegen nicht.

Den richtigen DNS-Namen eingeben, einschließlich TXT-Namen und IDNs
Beispieleingabe	Verwendung	Eingabedetail
`example.com`	Einträge der Basisdomain	Wählen Sie den benötigten Typ; alle Typen oder Subdomains werden nicht aufgelistet.
`www.example.com.`	Einträge des www-Namens	Der abschließende Wurzelpunkt wird akzeptiert und aus dem normalisierten Abfragenamen entfernt.
`_dmarc.example.com`	DMARC-bezogene TXT-Beobachtung	Wählen Sie TXT. Diese Abfrage bewertet weder die vollständige DMARC-Policy-Ermittlung noch das Alignment der Nachricht.
`selector._domainkey.example.com`	DKIM-bezogene TXT-Beobachtung	Ersetzen Sie selector durch den Selektor Ihres Maildienstes.
`bücher.example`	Internationaler Name	Unterstützte IDNs werden in einen ASCII-kompatiblen Abfragenamen umgewandelt; prüfen Sie den normalisierten Namen im Ergebnis.
`10.113.0.203.in-addr.arpa`	Name eines PTR-Eintrags	Die IPv4-Oktette sind in diesem Reverse-DNS-Beispiel umgekehrt angeordnet; der Erwartungswertvergleich ist nicht verfügbar.
`https://example.com/path`, `203.0.113.10`, `*.example.com`	Abgelehnte Eingabeformen	Verwenden Sie einen DNS-Namen. Für eine wörtliche IP-Adresse nutzen Sie die separaten IP- oder Reverse-DNS-Tools.

RFC 5891: Internationalisierte Domainnamen Node.js: URL-domainToASCII-Umwandlung RFC 1035: DNS-Implementierung und Eintragsformate RFC 6376: DKIM-Signaturen und Schlüsselabfrage mit Selektor RFC 9989: DMARC-Policy-Ermittlung und Alignment

Rekursive Anbieter und autoritative Nameserver haben unterschiedliche Rollen

Ein autoritativer Nameserver veröffentlicht die Daten einer DNS-Zone. Ein rekursiver Resolver beschafft Antworten für seine Clients und kann zwischengespeicherte Informationen wiederverwenden. Die Auswahl von Google Public DNS oder Cloudflare bestimmt den rekursiven Dienst dieser Beobachtung; sie bedeutet nicht, dass er Ihre Zone hostet oder der autoritative Nameserver Ihrer Domain ist.

ToolMellow sendet Anfragen vom eigenen Server oder einer konfigurierten Messstelle an feste HTTPS-Endpunkte des Anbieters und liest dessen JSON-Antworten. Dieses vom Anbieter definierte JSON-Format unterscheidet sich von den für DNS über HTTPS standardisierten binären DNS-Nachrichten. Die Abfrage ändert nicht die DNS-Einstellungen Ihres Geräts, fragt keinen frei eingegebenen Nameserver ab und verfolgt nicht jede Delegation ab der Wurzel.

RFC 1034: Domainnamen, Auflösung und Caching RFC 8484: DNS-Abfragen über HTTPS Google Public DNS: JSON-API für DNS über HTTPS Cloudflare 1.1.1.1: JSON-Anfragen für DNS über HTTPS

Eintragsnamen, TTL und Beobachtungsdaten zusammen lesen

Eine Antwortzeile enthält Eintragsname, Typ, zurückgegebene TTL in Sekunden und Textdaten. Lesen Sie auch den Namen: Eine rekursive Antwort kann eine Aliaskette und die Adresse des Aliasziels enthalten. Ein zusätzlicher CNAME oder anderer Typ ersetzt den angefragten Typ nicht. Öffnen Sie Authority-Einträge, wenn eine negative Antwort oder ein Verweis auf andere Server Kontext benötigt.

Jedes Anbieter- und Standortergebnis enthält Beobachtungszeit und Dauer. Die Zeit beschreibt diese Abfrage, nicht die letzte DNS-Änderung durch den Administrator. Die Dauer umfasst Anfrageweg, HTTP und Verarbeitung; sie ist keine reine DNS-Geschwindigkeitsmessung für Ihre Verbindung. Fehlen wegen eines Anfragefehlers Einträge oder Flags, behandeln Sie diese Angaben als nicht verfügbar und erfinden keine Werte.

RFC 1035: DNS-Implementierung und Eintragsformate RFC 2308: Negatives Caching von DNS-Abfragen

DNS-Status verstehen, ohne fehlende Daten und Fehler gleichzusetzen

Eine gültige negative Antwort und eine nicht abgeschlossene Anfrage erfordern unterschiedliche Folgeschritte. In ToolMellow enthält die positive NOERROR-Klassifikation eine Antwort des angefragten Typs. Andere erfolgreiche DNS-Antworten werden anhand ihres SOA-, CNAME- oder NS-Kontexts eingeordnet. Die Tabelle erklärt den sichtbaren Status, ohne jede leere Antwort als nicht vorhandene Domain zu behandeln.

Eine gekürzte Antwort ist unvollständig, selbst wenn ein Teil den erwarteten Text enthält. Bei Kürzung oder Betriebsfehlern ist der Erwartungswertvergleich nicht schlüssig. Ein Anbieter kann erfolgreich antworten, während der andere fehlschlägt; behalten Sie beide Ergebnisse, statt den Fehler als Beweis für einen fehlenden Eintrag zu werten.

DNS-Status verstehen, ohne fehlende Daten und Fehler gleichzusetzen
Status oder Bedingung	Bedeutung in diesem Checker	Sinnvoller Folgeschritt
NOERROR	Die erfolgreiche Antwort enthält Daten des angefragten Typs	Prüfen Sie relevante Werte, Namen und TTL; DNS-Erfolg testet nicht den Zieldienst.
NXDOMAIN	Der Resolver meldet, dass der angefragte DNS-Name nicht existiert	Prüfen Sie Schreibweise und vorgesehenen Namen. Das ist keine Abfrage der Registrierbarkeit einer Domain.
NODATA	Keine Antwort des angefragten Typs; SOA steht im Authority-Teil der erfolgreichen Antwort	Prüfen Sie, ob der Name diesen Typ haben sollte. Ein fehlender AAAA-Eintrag bedeutet keine fehlende Domain.
ALIAS_ONLY	Nach der SOA-Prüfung wird CNAME ohne den angefragten Typ zurückgegeben	Prüfen Sie Alias und Ziel; eine A-Antwort mit nur CNAME liefert nicht den erwarteten A-Wert.
REFERRAL	Nach vorherigen Klassifikationen fehlt die angefragte Antwort, aber NS steht in Authority	Prüfen Sie Authority-Einträge; das ist keine vollständige Antwort zum angefragten Eintrag.
EMPTY_ANSWER	Keine angefragte Antwort und kein erkannter SOA-, CNAME- oder NS-Kontext	Bewahren Sie die Details auf; nennen Sie das nicht eigenständig NXDOMAIN.
SERVFAIL oder REFUSED	Der DNS-Server meldet einen Fehler oder eine Ablehnung	Untersuchen Sie Anbieter und Domainkonfiguration; der Status allein benennt keine einzelne Ursache.
HTTP-Fehler, Zeitüberschreitung, fehlerhaftes Antwortformat oder Messstellenfehler	Die Beobachtung konnte nicht zuverlässig abgeschlossen werden	Lesen Sie die Verbindungshinweise und wiederholen Sie gezielt bei Bedarf; ein fehlender Eintrag ist nicht bewiesen.
Gekürzt / TC	Der Anbieter meldet eine unvollständige Antwort	Behandeln Sie den Vergleich als nicht schlüssig und behalten Sie das Teilantwort-Flag.

RFC 2308: Negatives Caching von DNS-Abfragen Google Public DNS: JSON-API für DNS über HTTPS Cloudflare 1.1.1.1: JSON-Anfragen für DNS über HTTPS

Was DNS-TTL nach einer Änderung bedeutet

TTL beschreibt eine Cache-Lebensdauer in Sekunden. Ein rekursiver Resolver kann die verbleibende Dauer zwischengespeicherter Daten zurückgeben; zwei ansonsten gleiche Antworten können daher verschiedene TTLs zeigen. Die Zahl ist kein Countdown bis zum Einsatz Ihres neuen Werts bei allen Resolvern weltweit.

Positive Antworten, negative Antworten und Delegationsdaten können getrennte Cache-Historien besitzen. Eine jetzt gesenkte TTL verkürzt die einer bereits gespeicherten Kopie zugewiesene Lebensdauer nicht rückwirkend. Manche Resolver dürfen außerdem nach definierten Resilienzregeln abgelaufene Daten ausliefern. Eine neue Abfrage liefert deshalb eine weitere Beobachtung, keinen Nachweis für die Aktualität jedes Caches.

Bestätigen Sie bei einer geplanten Änderung Namen und Werte beim DNS-Hoster, behalten Sie alte und neue Beobachtungen und wiederholen Sie relevante Prüfungen in sinnvollen Abständen. Planen Sie mit den Änderungshinweisen des Hosters und dem früheren Cache-Kontext. Eine pauschale Angabe von 24 oder 48 Stunden beschreibt nicht jede DNS-Änderung.

RFC 2181, Abschnitt 8: Lebensdauer RFC 2308: Negatives Caching von DNS-Abfragen RFC 8767: Ausliefern abgelaufener DNS-Daten

Warum Anbieterübereinstimmung keine weltweite DNS-Verbreitung beweist

Google und Cloudflare können wegen unterschiedlicher Cache-Beobachtungen oder Auflösungsverfahren verschiedene Antworten liefern. Auch standortabhängige autoritative Antworten können eine Rolle spielen. Vergleichen Sie zuerst denselben normalisierten Namen und Typ zu den aufgezeichneten Zeiten, danach Status, Namen, Werte und TTL. Ein Unterschied bestimmt nicht automatisch die richtige Antwort.

Jede Prüfung erlaubt höchstens vier ausgewählte konfigurierte Abfragestandorte; verfügbar sind aber nur die tatsächlich in der Oberfläche aufgeführten Standorte. Wird einer angeboten, werden beide Anbieter von dort abgefragt. Eine angegebene Region ist keine unabhängig bestätigte Geografie, wenn ihr Verifizierungsflag false ist. Leiten Sie aus Anbieterzahl oder Auswahlgrenze kein weltweites Messstellennetz ab.

Übereinstimmung belegt nur Übereinstimmung zwischen diesen Beobachtungen. Ihr Gerät, ein anderes Netz oder ein privater Unternehmensresolver kann anderes sehen, besonders bei lokalen Caches oder netzabhängigen DNS-Ansichten. Nutzen Sie einen Dienst mit passender Standortabdeckung oder die Diagnostik Ihres Netzes, wenn Sie diese zusätzlichen Perspektiven benötigen.

RFC 1034: Domainnamen, Auflösung und Caching RFC 8767: Ausliefern abgelaufener DNS-Daten

Erwartete Werte wörtlich mit Exakte Übereinstimmung oder Enthält vergleichen

Der Vergleich prüft Answer-Werte des angefragten und für den Vergleich unterstützten Typs. Exakte Übereinstimmung verlangt Gleichheit des gesamten zurückgegebenen Texts mit dem erwarteten Text; Enthält verlangt die erwartete Teilzeichenfolge darin. Beide unterscheiden Groß- und Kleinschreibung. Ein passender Wert genügt für ein passendes Anbieter- und Standortergebnis, auch wenn weitere Werte abweichen. Das beweist nicht die Gleichheit der gesamten Eintragsmenge mit Ihrer vorgesehenen Konfiguration.

Der Vergleich entfernt weder Leerraum, Anführungszeichen noch abschließende Punkte, normalisiert keine IPv6-Schreibweisen und analysiert keine DNS-Policy-Syntax. Reguläre Ausdrücke werden nicht unterstützt. Hostnamenvergleiche im DNS-Protokoll können Großschreibung ignorieren, während dieser Zeichenfolgenvergleich sie unterscheidet. Nutzen Sie für wörtliche Gleichheit die zurückgegebene Darstellung und prüfen Sie den vollständigen Text, bevor Sie eine kurze Teilzeichenfolge als Beleg nehmen.

NXDOMAIN und NODATA ergeben normalerweise eine Abweichung vom erwarteten Wert, wenn der angefragte Wert fehlt; sie sind gültige negative Beobachtungen, keine Anfragefehler.
Fehlgeschlagene oder gekürzte Ergebnisse sind nicht schlüssig. Der Vergleich ist außerdem für leeren Erwartungstext, mehr als 4096 JavaScript-Zeichenfolgeneinheiten oder PTR nicht verfügbar.
Der erwartete Text bleibt in diesem Tab und dem heruntergeladenen Bericht. Er wird nicht mit der DNS-Abfrage versandt. Eine Textübereinstimmung allein beweist weder DNSSEC-Validierung noch Domaininhaberschaft.

Erwartete Werte wörtlich mit Exakte Übereinstimmung oder Enthält vergleichen
Beispiel für zurückgegebene Daten	Erwarteter Text	Lehre aus dem Vergleich
A: `203.0.113.10`	`203.0.113.10`	Exakte Übereinstimmung passt zu diesem Wert; weitere A-Antworten können andere Adressen enthalten.
CNAME: `target.example.com.`	`target.example.com`	Der abschließende Punkt verhindert exakte Gleichheit; Enthält findet die Teilzeichenfolge.
MX: `10 mail.example.com.`	`mail.example.com`	Präferenz und abschließender Punkt verhindern exakte Gleichheit; Enthält prüft nur ein Textfragment.
TXT: `"verification=sample-token"`	`verification=sample-token`	Mit zurückgegebenen Anführungszeichen unterscheidet sich der exakte Text; Enthält kann das Fragment finden.
CNAME: `Target.example.com.`	`target.example.com.`	Die Großschreibung unterscheidet den wörtlichen Vergleich, auch wenn DNS-Namensgleichheit andere Regeln besitzt.
TXT: `"part-one" "part-two"`	`part-onepart-two`	Die Funktion verbindet keine zitierten Textteile und interpretiert keine vollständige Policy.

RFC 4343: Groß- und Kleinschreibung bei DNS-Namen

Das DNSSEC-Flag für authentifizierte Daten mit seiner Quelle lesen

Die Anzeige Authentifiziert gibt das AD-Flag des ausgewählten rekursiven Resolvers wieder. Dieser Resolver behauptet authentifizierte Daten; ToolMellow prüft weder DNSSEC-Signaturen noch die Vertrauenskette eigenständig. Sich auf diese Aussage zu verlassen setzt auch Vertrauen in den Resolver und den Antwortkanal voraus.

Nicht authentifiziert bedeutet, dass der Anbieter AD nicht gesetzt hat. Unsignierte Daten können ebenfalls so angezeigt werden; das Flag allein beweist daher keine defekte oder bösartige Domain. Auch SERVFAIL erfordert eine Untersuchung statt einer automatischen DNSSEC-Diagnose. Der Checker fordert DNSSEC-bezogene Antwortdaten mit aktivierter Anbieterprüfung an, führt aber weder ein vollständiges DNSSEC-Audit noch einen DNS-Leak-Test des Browsers durch.

RFC 4035: DNSSEC und Aussagen über authentifizierte Daten Google Public DNS: JSON-API für DNS über HTTPS Cloudflare 1.1.1.1: JSON-Anfragen für DNS über HTTPS

Website-DNS vor Hosting und HTTPS untersuchen

Zeigt eine Website auf ein altes Ziel, prüfen Sie den genauen von Besuchern verwendeten Hostnamen. Vergleichen Sie A und AAAA getrennt und prüfen Sie CNAME für einen Alias wie www. Nehmen Sie für Basisdomain und www keine identische Konfiguration an. Vergleichen Sie die Antwort mit den vom Hoster vorgesehenen Einträgen, einschließlich eines erforderlichen Aliasziels.

Ein plausibler DNS-Wert ist ein Teil der Website-Diagnose. HTTP-Weiterleitungen, Routing virtueller Hosts, Zertifikatsgültigkeit und Anwendungsantworten erfordern eigene Prüfungen. CNAME ist ein DNS-Alias; Besucher zu einer anderen URL zu schicken ist HTTP-Verhalten. CAA betrifft die Autorisierung von Zertifizierungsstellen; ein vorhandener CAA-Eintrag bestätigt kein gültiges Zertifikat der aktuellen Website.

RFC 1035: DNS-Implementierung und Eintragsformate RFC 8659: Zertifizierungsstellen-Autorisierung

TXT-Verifizierung, SPF, DKIM und DMARC beim richtigen Namen abfragen

Kopieren Sie zur Domainverifizierung den Eintragsnamen aus den Diensthinweisen und wählen Sie TXT. Vergleichen Sie den gesamten zurückgegebenen Eintrag mit dem benötigten Token und berücksichtigen Sie sichtbare Anführungszeichen und Textteile. Das gefundene Token ist ein hilfreicher Beleg; der anfragende Dienst verwendet aber sein eigenes Verfahren zur Eigentumsverifizierung.

SPF-Policies verwenden TXT bei der relevanten Maildomain. Die DKIM-Schlüsselsuche nutzt einen selektorspezifischen Namen wie selector._domainkey.example.com; beziehen Sie den Selektor vom Maildienst, statt ihn zu raten. Eine DMARC-bezogene Prüfung beginnt häufig mit TXT bei _dmarc.example.com. Moderne DMARC-Policy-Ermittlung und Identifier-Alignment enthalten weitere Regeln, die eine einzelne TXT-Beobachtung nicht auswertet.

MX beschreibt die Mailzustellungspfade, während diese TXT-basierten Verfahren andere Rollen besitzen. Der Checker folgt nicht allen SPF-include-Verweisen, validiert keine signierte Nachricht, bewertet nicht die vollständige DMARC-Policy-Ermittlung, analysiert keine DMARC-Berichte und testet keine Zustellung. Ein vorhandener Eintrag oder ein passendes Textfragment ersetzt diese Prüfungen nicht.

RFC 7208, Abschnitt 3.1: SPF-Policies in TXT RFC 6376: DKIM-Signaturen und Schlüsselabfrage mit Selektor RFC 9989: DMARC-Policy-Ermittlung und Alignment

Abfrage-Datenschutz verstehen und einen nützlichen DNS-Bericht teilen

Angefragter Name und Typ gelangen über den ToolMellow-Broker oder die gewählte Messstelle zum ausgewählten öffentlichen Resolver. Der Resolver sieht die Netzadresse der Messstelle; ToolMellow leitet Besucher-Client-IP-Header nicht an ihn weiter. Die Hosting-Infrastruktur erhält weiterhin übliche Anfragemetadaten. HTTPS macht nicht die gesamte Aktivität anonym und beweist keine Null-Logging-Policy; auch der Name selbst kann sensibel sein.

Der Erwartungstext wird lokal verglichen und kann als expectedComparison in dns-results.json stehen. Prüfen Sie vor dem Teilen Namen, zurückgegebene Daten und Erwartungstext, insbesondere Verifizierungstoken. Senden Sie die relevante Beobachtung an den vorgesehenen Empfänger, statt jeden exportierten Wert als öffentlich publizierbar anzusehen.

Geben Sie für eine Supportanfrage den genauen Namen und Typ, die geplante Konfiguration, Anbieter und Standort, Beobachtungszeit, Status, relevante Answer- und Authority-Daten sowie gekürzte oder fehlgeschlagene Ergebnisse an. Der heruntergeladene Bericht ist eine Momentaufnahme; das Tool speichert keine serverseitige Eintragshistorie und exportiert nicht Ihre gesamte DNS-Zone.

Fehlende oder unerwartete DNS-Antworten schrittweise untersuchen

Prüfen Sie zuerst normalisierten Eintragsnamen und gewählten Typ anhand der DNS-Hosting-Hinweise. Trennen Sie dann negative Antworten von fehlgeschlagenen Anfragen, lesen Sie Aliase und Authority-Details und vergleichen Sie beide Anbieterbeobachtungen. Haben Sie einen Erwartungswert genutzt, prüfen Sie vollständigen Antworttext und Vergleichsmodus, bevor Sie eine abweichende Konfiguration annehmen.

Speichern Sie nach einer Änderung einen Bericht und führen Sie gezielte Folgeprüfungen durch. Das Tool wiederholt Abfragen nicht automatisch, und wiederholte Anfragen leeren nicht sämtliche Caches. Nutzen Sie Verbindung erneut versuchen bei angebotenen Konfigurationsproblemen, beachten Sie Hinweise zu Anfragelimits und starten Sie bei Bedarf eine neue Abfrage. Abbrechen stoppt ausstehende Clientarbeit und gibt die Abbruchsignale an die abfrageverarbeitenden Dienste weiter, kann aber eine bereits gesendete Abfrage nicht rückgängig machen.

Verwenden Sie separate IP- oder Reverse-DNS-Tools, wenn Sie mit einer Adresse beginnen, und lokale DNS-Diagnostik des Betriebssystems, wenn es um den Resolverweg dieses Geräts geht. Der Checker erfasst nicht alle Subdomains, bietet keine Auswahl von SRV, DS, DNSKEY oder ANY, überträgt keine Zone und prüft keine Registrierbarkeit. Wählen Sie die passende Diagnostik, bevor Sie aus einer erfolgreichen Antwort weitergehende Schlüsse ziehen.

Häufige Fragen

Wie prüfe ich alle DNS-Einträge einer Domain?

Führen Sie separate Abfragen für aufgabenrelevante Namen und unterstützte Typen aus. ToolMellow verwendet einen Namen und Typ pro Anfrage; es erfasst nicht alle Subdomains, überträgt keine Zone und liefert kein vollständiges Inventar aller Einträge.

Warum zeigen Google und Cloudflare unterschiedliche DNS-Ergebnisse?

Cache-Historien und Auflösungsverfahren können sich unterscheiden, und autoritative Antworten können standortabhängig sein. Vergleichen Sie denselben normalisierten Namen und Typ, Zeiten, Status, Eintragsnamen, Werte und TTL. Der Unterschied allein identifiziert nicht die richtige Antwort.

Zeigt die TTL das Ende der DNS-Verbreitung an?

Nein. Die zurückgegebene TTL informiert über die Cache-Lebensdauer der beobachteten Daten. Positive und negative Caches, Delegationen und Regeln für abgelaufene Antworten können andere Beobachtungen beeinflussen. Sie bestimmt keinen weltweiten Abschlusszeitpunkt.

Was unterscheidet NXDOMAIN und NODATA?

NXDOMAIN meldet, dass der angefragte Name nicht existiert. NODATA bedeutet, dass der angefragte Typ keine Antwort besitzt; der Checker erkennt dies anhand von SOA in Authority bei erfolgreicher Antwort. Ein Name kann A-Einträge haben, ohne AAAA-Daten zurückzugeben.

Warum scheitert Exakte Übereinstimmung bei meinem TXT oder CNAME?

Die Funktion vergleicht den gesamten zurückgegebenen Text unter Beachtung der Groß- und Kleinschreibung. Anführungszeichen, Leerraum, abschließende Punkte, MX-Präferenztext und Darstellung können zählen. Prüfen Sie den ganzen Wert; Enthält testet nur eine Teilzeichenfolge und validiert keinen vollständigen Eintrag oder eine Policy.

Bedeutet eine Übereinstimmung, dass alle DNS-Einträge richtig sind?

Nein. Ein passender Answer-Wert des angefragten unterstützten Typs genügt für ein passendes Anbieter- und Standortergebnis. Andere Werte können abweichen. Wörtliche Gleichheit beweist weder Inhaberschaft, DNSSEC-Validierung, Mailzustellung noch weltweiten Konsens.

Kann ich eine IP-Adresse für eine PTR-Abfrage eingeben?

Nutzen Sie für eine wörtliche Adresse die separaten IP- oder Reverse-DNS-Tools. Dieser DNS-Checker benötigt einen vollständigen Reverse-DNS-Eintragsnamen, etwa das Beispiel 10.113.0.203.in-addr.arpa. Der PTR-Erwartungswertvergleich ist nicht verfügbar.

Wie prüfe ich SPF, DKIM und DMARC?

Wählen Sie TXT bei der relevanten SPF-Domain, dem vom Anbieter gelieferten DKIM-Selektornamen unter _domainkey oder dem passenden _dmarc-Namen. Diese Abfragen lesen veröffentlichten Text; sie bewerten nicht sämtliche SPF-Abhängigkeiten, eine DKIM-Nachrichtensignatur oder die vollständige DMARC-Ermittlung und das Alignment.

Bedeutet Nicht authentifiziert, dass meine Domain unsicher ist?

Nicht authentifiziert bedeutet, dass der Anbieter AD nicht gesetzt hat. Auch unsignierte Daten können dieses Ergebnis erzeugen. ToolMellow validiert DNSSEC nicht eigenständig; diese Anzeige allein beweist keine unsichere Domain.

Testet der Checker den DNS-Server meines Geräts?

Er fragt ausgewählte öffentliche Anbieter von verfügbaren ToolMellow-Standorten aus ab. Dieser Weg kann von Resolver und Caches Ihres Geräts, Browsers oder privaten Netzes abweichen. Nutzen Sie dafür lokale Diagnostik.

Beweist die Übereinstimmung zweier Anbieter weltweite Verbreitung?

Sie belegt nur Übereinstimmung zwischen abgeschlossenen Beobachtungen. Zwei Anbieter von einem angebotenen Standort aus bilden kein weltweites Messstellennetz. Verfügbare Standorte und Angaben zur Regionsbestätigung bestimmen den Berichtsumfang.

Wird mein Erwartungswert an DNS-Anbieter geschickt?

Nein. Der erwartete Text bleibt im Browsertab und kann im heruntergeladenen Bericht stehen. Tatsächlicher DNS-Name und Typ gelangen über den Dienst zum ausgewählten Resolver. Prüfen Sie Verifizierungstoken und weitere Berichtsdaten vor dem Teilen.