
Hinter dieser Anzeige verbirgt sich ein Ausfall der Namensauflösung: Das Betriebssystem (genauer: der lokale Resolver) schickt eine Anfrage an einen rekursiven DNS-Server, erhält aber innerhalb der erwarteten Zeit keine gültige Antwort. Anders als bei „NXDOMAIN“ (Domain existiert nicht) scheitert hier nicht die Suche nach einem Namen, sondern die Erreichbarkeit/Antwortfähigkeit des Diensteanbieters für DNS. Aus Sicht des Systems bleibt die Zuordnung von name.tld zu einer IP offen – Verbindungen zu Webservern, Mailservern oder APIs, die Hostnamen benötigen, können deshalb nicht aufgebaut werden.
Wie äußert sich der Fehler im Alltag – und warum wirkt er manchmal „zufällig“?
Typisch ist, dass alle Webseiten-Aufrufe gleichzeitig stocken oder nach einiger Zeit mit einem DNS-Hinweis abbrechen, während reine IP-Zugriffe weiterhin möglich wären. Je nach Software erscheint die Meldung unterschiedlich: Browser sprechen von „DNS-Server nicht erreichbar“, „Sichere DNS-Abfrage fehlgeschlagen“ oder zeigen interne Codes wie DNS_PROBE_FINISHED_NO_INTERNET, wohingegen Tools zur Namensauflösung ein Timeout melden. Verwirrend kann sein, dass einige Apps trotzdem funktionieren: Manche Programme nutzen eigenes DNS (z. B. DoH/DoT über den App-Anbieter) und sind daher vom System-DNS entkoppelt. Umgekehrt kann der Fehler nur im Browser auftreten, wenn dieser eine gesonderte, „sichere“ DNS-Variante verwendet, die gerade nicht antwortet, während das System-DNS intakt ist.
Wo entsteht die Störung – und welche Auslöser sind typisch (rein beschreibend)?
Auf dem Endgerät können veraltete Netzwerk-Stacks, defekte Caches oder restriktive Sicherheits-/Filterregeln die DNS-Antworten blockieren. Im lokalen Netz fallen häufig DNS-Proxys im Router auf: Sie leiten Anfragen weiter, brechen aber bei Überlastung, Firmware-Fehlern oder Captive-Portal-Vorgeschalten ab. Auf Provider-Seite betrifft es die rekursiven Resolver (Wartung, Überlast, Fehlkonfiguration); dann kommt es regional zu zeitgleichen Ausfällen. Domänenspezifisch kann ein Fehler eher „selektiv“ wirken – etwa falsche Zoneneinträge, fehlschlagende DNSSEC-Validierung oder inkonsistente NS-Server, bei denen nur einzelne Ziele betroffen sind. Auch VPNs, Split-Tunneling, Unternehmens-Policy-Filter oder systemweite DoH/DoT-Vorgaben verändern, welcher Resolver angesprochen wird; widersprüchliche Profile führen dann zu scheinbar sporadischen Fehlern.
Abgrenzung zu ähnlichen DNS-Meldungen – warum das wichtig ist
„NXDOMAIN“ bedeutet: Der DNS-Server antwortet korrekt, findet den Namen aber nicht. „SERVFAIL“ heißt: Der Server antwortet, kann die Anfrage intern nicht erfolgreich verarbeiten (z. B. Validierungsfehler). „REFUSED“ signalisiert eine bewusste Ablehnung (Policy/Access-Control). „TIMEOUT“ und genau die Formulierung „Der DNS-Server antwortet nicht“ deuten dagegen auf keine oder verspätete Antwort hin. Diese Unterscheidung zeigt, wo das Problem liegt: Entweder beim Zielnamen (Daten), beim Server (Dienst) oder auf dem Weg dorthin (Erreichbarkeit).
Welche Auswirkungen hat das technisch?
Ohne Namensauflösung verzögern sich Verbindungsaufbauten durch wiederholte Retries deutlich, bevor Anwendungen aufgeben. Caches können alte Ergebnisse noch kurz liefern, deshalb treten Effekte nicht immer sofort ein. Dienste, die rein IP-basiert kommunizieren, bleiben funktionsfähig; moderne Web-Dienste (CDNs, SNI, Zertifikatsprüfungen) sind jedoch fast immer DNS-abhängig. So erklärt sich, warum Nutzer „Internet weg“ wahrnehmen, obwohl die physische Verbindung steht – gestört ist die Übersetzungsschicht zwischen Namen und Adressen, nicht zwingend die Leitung selbst.


