DNS-Server antwortet nicht: so behebst du es unter Windows, Windows Server, macOS und Linux

Kurz gesagt: „DNS-Server antwortet nicht“ heißt, dein Rechner hat Namensabfragen an den DNS-Server geschickt, der an seinem Netzwerkadapter eingetragen ist, und keine Antwort bekommen. Deshalb kann er einen Namen wie example.com nicht in eine IP-Adresse übersetzen. Prüf, ob die Verbindung ohne DNS funktioniert, leere den DNS-Cache, trag zwei funktionierende öffentliche Resolver am Adapter ein und setz Winsock und den TCP/IP-Stack erst dann zurück, wenn das alles nicht hilft. Auf einem Windows Server, den du per Remotedesktop erreichst, lies vorher die Warnung in Lösung 5: Das Zurücksetzen von TCP/IP kann die statische IP des Servers löschen.

Die Windows-Netzwerkdiagnose formuliert es so: Der Computer scheint richtig konfiguriert zu sein, aber „das Gerät oder die Ressource (DNS-Server) antwortet nicht“; manchmal heißt es auch, der DNS-Server sei möglicherweise nicht verfügbar. nslookup (engl.) meldet DNS request timed out. und timeout was 2 seconds., und Chrome zeigt DNS_PROBE_FINISHED_BAD_CONFIG, oder DNS_PROBE_FINISHED_NO_INTERNET, wenn er gar keinen Resolver erreicht. Ob es heißt, der DNS-Server antwortet nicht, kann nicht erreicht werden oder ist nicht verfügbar: Alle Varianten beschreiben dasselbe. Die Website ist vielleicht in Ordnung, aber der Server, der ihren Namen übersetzen soll, antwortet dir nicht.

Meldet der Browser nur, die IP-Adresse (früher hieß es: die DNS-Adresse) des Servers sei nicht gefunden worden, entscheidet der Code darunter. Steht dort DNS_PROBE_FINISHED_NXDOMAIN, hat ein DNS-Server geantwortet, und das Problem ist dieser eine Name, nicht dein Resolver. Diesen Fall behandelt DNS_PROBE_FINISHED_NXDOMAIN (engl.).

Liegt es an DNS oder an der ganzen Verbindung?

Vier Befehle in PowerShell zeigen dir, welches Problem du hast:

# 1. Verlässt überhaupt Verkehr die Maschine, ohne DNS?
ping 1.1.1.1
Test-NetConnection 1.1.1.1 -Port 443        # falls ping gefiltert wird

# 2. Welche DNS-Server nutzt Windows?
Get-DnsClientServerAddress | Where-Object ServerAddresses

# 3. Den eingetragenen Server fragen, dann direkt einen öffentlichen Resolver
Resolve-DnsName example.com -DnsOnly
Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly

• Schritt 1 scheitert: Das ist kein DNS-Problem. Die Maschine hat keinen funktionierenden Weg nach draußen. Prüf Kabel oder WLAN, den Router und in ipconfig /all, ob es eine IPv4-Adresse und ein Standardgateway gibt. Eine Adresse, die mit 169.254. beginnt, heißt, der Adapter hat nie eine per DHCP bekommen.
• Der öffentliche Resolver antwortet, der eingetragene nicht: Der DNS-Server an deinem Adapter ist das Problem. Das ist der häufigste Fall. Weiter mit Lösung 1 und 2.
• Beide laufen in ein Timeout: Irgendetwas zwischen dir und jedem Resolver verwirft DNS: ein VPN-Client, eine Sicherheitssuite, eine Firewall-Regel oder ein Netz, das nur seinen eigenen Resolver erlaubt. Versuch Resolve-DnsName example.com -Server 1.1.1.1 -TcpOnly. Klappt TCP, die normale Abfrage (UDP) aber nicht, verwirft ein Filter UDP-Port 53. Weiter mit Lösung 4.

Eine zweite Meinung von außerhalb deines Netzes klärt, ob die Domain selbst in Ordnung ist: Das Tool DNS-Lookup (engl.) fragt unseren Resolver in Amsterdam. Wird der Name dort aufgelöst, auf deinem Rechner aber nicht, liegt der Fehler beim DNS-Server, den dein Rechner nutzt.

Ursachen, sortiert danach, wie oft sie schuld sind

Lösung 1: Router neu starten und DNS-Cache leeren

Zu Hause ist der DNS-Server an deinem Adapter meist der Router selbst, der die Anfragen an deinen Provider weiterreicht. Hängt diese Weiterleitung, zeigt jedes Gerät im Haus diesen Fehler, während reiner IP-Verkehr weiter funktioniert. Starte den Router neu, warte, bis er vollständig wieder da ist, und leere dann den Windows-Cache aus einer PowerShell mit Administratorrechten:

ipconfig /flushdns
Clear-DnsClientCache     # derselbe Schritt auf PowerShell-Art

Das Leeren verwirft zwischengespeicherte Antworten, auch fehlgeschlagene Abfragen, die Windows sich während des Ausfalls gemerkt hat. Einen stummen Server zum Antworten bringt es nicht; scheitert Schritt 3 oben also weiterhin, mach weiter. Alle Varianten für andere Systeme stehen in DNS-Cache leeren (engl.). Oft wird auch ipconfig /registerdns empfohlen. Das registriert den eigenen Namen deines Rechners neu in einer DNS-Zone, was in einem Active-Directory-Netz zählt und für diesen Fehler nichts bewirkt.

Lösung 2: funktionierende DNS-Server am Adapter eintragen

Die DNS-Server des Adapters zu ersetzen behebt die meisten Fälle. Nimm zwei verschiedene Anbieter, damit ein einzelner Ausfall nicht beide lahmlegt. Das Beispiel trägt Cloudflare (1.1.1.1) und Quad9 (9.9.9.9) ein, dazu ihre IPv6-Adressen. Starte PowerShell als Administrator:

# den Namen des aktiven Adapters finden (Ethernet, WLAN, Ethernet 2 ...)
Get-NetAdapter | Where-Object Status -eq 'Up'

# DNS-Server für IPv4 und IPv6 setzen
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('1.1.1.1','9.9.9.9','2606:4700:4700::1111','2620:fe::fe')
Clear-DnsClientCache
Resolve-DnsName example.com

# rückgängig machen: zurück zu den Servern, die DHCP verteilt
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ResetServerAddresses

So gesetzte Server überschreiben, was DHCP für diesen Adapter vergibt. 9.9.9.9 von Quad9 sperrt außerdem Domains, die als schädlich bekannt sind; für denselben Dienst ohne diesen Filter nimm 9.9.9.10 und 2620:fe::10. In den grafischen Einstellungen findest du denselben Schalter unter Windows 11 bei Einstellungen → Netzwerk und Internet → deine Verbindung → DNS-Serverzuweisung → Bearbeiten → Manuell, unter Windows 10 und Windows Server über ncpa.cpl → Adapter → Eigenschaften → Internetprotokoll, Version 4 (TCP/IPv4).

Lösung 3: auch die IPv6-DNS-Server prüfen

Get-DnsClientServerAddress zeigt pro Adapter zwei Zeilen, eine für IPv4 und eine für IPv6. Router und Provider können IPv6-DNS-Server verteilen, die nicht antworten, und Windows probiert sie trotzdem. Nennt die IPv6-Zeile Adressen, die mit Resolve-DnsName example.com -Server <adresse> in ein Timeout laufen, ersetzt der Befehl aus Lösung 2 sie bereits, weil er beide Adressfamilien auf einmal setzt.

Schalte IPv6 nicht ab, um das Problem loszuwerden. Microsoft rät davon ab, weil Teile von Windows erwarten, dass es da ist. Ersetze stattdessen die kaputten Server.

Lösung 4: VPN-Clients, Proxys und Sicherheitssoftware

Ein VPN-Client fügt einen virtuellen Adapter mit eigenen DNS-Servern hinzu und oft eine Regel, die jede Abfrage in den Tunnel schickt. Ist der Tunnel nur halb verbunden oder sein Server ausgefallen, gehen die Abfragen ins Leere. Trenn das VPN vollständig und wiederhole die Tests. Zwei Befehle zeigen, was es zurückgelassen hat:

Get-DnsClientServerAddress          # nach dem VPN-Adapter und seinen Servern suchen
Get-DnsClientNrptPolicy             # Regeln, die bestimmte Namen an bestimmte DNS-Server schicken

Der zweite Befehl listet die Name Resolution Policy Table (NRPT), mit der VPNs und Firmenrichtlinien bestimmte Domains an bestimmte Server leiten. Ein übrig gebliebener Eintrag eines deinstallierten VPNs kann die Auflösung dieser Namen kaputt machen. Sicherheitssuiten mit Webfilter und manche „Privatsphäre“-Werkzeuge klinken sich auf dieselbe Weise in DNS ein. Pausiere oder aktualisiere sie für den Test, und lässt die Deinstallation das Netz kaputt zurück, räumt Lösung 5 auf, was übrig ist.

Hotel-, Büro- und Schulnetze sperren DNS oft für alles außer ihrem eigenen Resolver. In so einem Netz macht Lösung 2 die Sache schlimmer: Setz die Server mit -ResetServerAddresses auf DHCP zurück. Betreibst du ein VPN auf einem entfernten Windows-Server, zeigt die Anleitung zum VPN auf einem RDP-Server (engl.), wie du das DNS des Tunnels setzt, ohne dich selbst auszusperren.

Lösung 5: Winsock und den TCP/IP-Stack zurücksetzen

Stimmen die Server und scheitern die Abfragen trotzdem, setz den Netzwerkstack zurück. Öffne die Eingabeaufforderung als Administrator:

ipconfig /all > %USERPROFILE%\ip-before.txt
netsh winsock reset
netsh int ip reset C:\resetlog.txt
ipconfig /flushdns
shutdown /r /t 0

netsh winsock reset baut den Winsock-Katalog neu auf und entfernt Layered Service Provider von Drittanbietern, also die Hooks, die VPNs und Sicherheitssoftware installieren. netsh int ip reset schreibt die TCP/IP-Einstellungen in der Registry neu, was Microsoft als gleichwertig mit dem Entfernen und Neuinstallieren von TCP/IP beschreibt. Beide brauchen den Neustart am Ende. Die erste Zeile sichert deine aktuellen Einstellungen in ip-before.txt in deinem Benutzerordner, damit du sie wiederherstellen kannst.

Auf einem physischen PC kann ein kaputter oder frisch aktualisierter Netzwerktreiber dasselbe Symptom auslösen: Begann der Fehler direkt nach einem Update, setz den Treiber im Geräte-Manager auf die vorherige Version zurück oder installier ihn neu.

Auf einem Windows Server VPS über Remotedesktop

Remotedesktop verbindet sich mit der IP-Adresse des Servers, ein DNS-Ausfall auf dem Server sperrt dich also nicht aus. Er legt aber den Browser, Windows Update und alles andere lahm, was Namen auflöst. Du kannst ihn aus der Sitzung heraus beheben, solange du das Netzwerk selbst intakt lässt:

1. 1Herausfinden, ob die Adresse statisch ist

   Führ ipconfig /all aus. Steht in der Zeile DHCP aktiviert (englisch DHCP Enabled) ein Nein, ist die Adresse statisch. Notier dir IPv4-Adresse, Subnetzmaske, Standardgateway und DNS-Server.

2. 2Nur die DNS-Server ändern

   Set-DnsClientServerAddress aus Lösung 2 unterbricht die Sitzung nicht. Den Adapter neu starten oder deaktivieren, netsh int ip reset und „Netzwerk zurücksetzen“ tun es, also lass sie über RDP weg, solange du keinen anderen Zugang hast.

3. 3Bist du ausgesperrt, nimm die Konsole

   Öffne die VNC-Konsole im VMHeaven-Panel. Sie zeigt den Bildschirm des Servers, auch wenn sein Netzwerk ausgefallen ist. Melde dich an, schalte DHCP ab, falls ein Zurücksetzen es eingeschaltet hat, und trag die gesicherten Werte wieder ein, mit der Präfixlänge, die zu deiner Maske passt (24 entspricht 255.255.255.0):

   Set-NetIPInterface -InterfaceAlias 'Ethernet' -AddressFamily IPv4 -Dhcp Disabled
   New-NetIPAddress -InterfaceAlias 'Ethernet' -IPAddress 203.0.113.20 -PrefixLength 24 -DefaultGateway 203.0.113.1
   Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('1.1.1.1','9.9.9.9')

Zwei Ursachen gibt es nur auf Servern. Zeigt der Adapter 127.0.0.1 oder ::1, soll der Server DNS selbst beantworten, meist weil die Rolle DNS-Server für Active Directory installiert wurde. Ist dieser Dienst gestoppt, scheitert jede Abfrage: Prüf ihn mit Get-Service DNS und starte ihn mit Start-Service DNS. Und hat jemand die Windows Defender Firewall so eingestellt, dass sie ausgehenden Verkehr blockiert, zeigt Get-NetFirewallProfile | Select-Object Name, DefaultOutboundAction den Wert Block, und DNS braucht eine ausgehende Regel für UDP- und TCP-Port 53.

Verbindet sich Remotedesktop selbst nicht, ist das ein anderes Problem, das Remotedesktop verbindet sich nicht (engl.) behandelt. Jeder Windows VPS von VMHeaven hat die VNC-Konsole im Panel, eine missglückte Netzwerkänderung kostet dich also ein paar Minuten, nicht den Server.

Auf einem Mac

Unter macOS gelten dieselben Lösungen, im Terminal. Schau zuerst, welche DNS-Server genutzt werden und wie deine Netzwerkdienste heißen:

scutil --dns | grep nameserver
networksetup -listallnetworkservices

Trag dann zwei öffentliche Resolver für den Dienst ein, über den du verbunden bist, und leere den Cache. Ersetze Wi-Fi durch den Namen aus der Liste, etwa Ethernet (auf einem deutschen macOS kann der WLAN-Dienst auch WLAN heißen):

sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 9.9.9.9
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

sudo networksetup -setdnsservers Wi-Fi empty kehrt zu den Servern zurück, die der Router verteilt. In den Systemeinstellungen findest du dasselbe Feld unter Netzwerk, deiner Verbindung, Details, DNS.

Auf einem Linux-Server: der Resolver antwortet nicht

Linux meldet denselben Fehler als Temporary failure in name resolution, oder dig gibt communications error to … timed out aus, gefolgt von no servers could be reached. Trenne eine kaputte Resolver-Einstellung von blockiertem DNS-Verkehr:

cat /etc/resolv.conf               # was Programme nutzen; 127.0.0.53 = systemd-resolved
resolvectl status                  # welche DNS-Server, pro Schnittstelle
resolvectl query example.com       # eine Abfrage über systemd-resolved
dig @1.1.1.1 example.com +short    # den lokalen Resolver komplett umgehen
sudo ufw status verbose            # Standard sollte "allow (outgoing)" lauten

Ein Resolver, der schweigt, sieht in dig so aus. Ersetze 192.0.2.1 durch den Server aus resolvectl status oder /etc/resolv.conf:

dig @192.0.2.1 example.com +tries=1 +time=2; echo "exit status $?"

;; communications error to 192.0.2.1#53: timed out

; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> @192.0.2.1 example.com +tries=1 +time=2
; (1 server found)
;; global options: +cmd
;; no servers could be reached
exit status 9

Exit-Status 9 ist bei dig „keine Antwort vom Server“. Ein Name, den es nicht gibt, endet mit Status 0, weil ein Server sehr wohl mit NXDOMAIN geantwortet hat; genau das ist die Grenze zwischen diesem Fehler und einem fehlenden Namen.

Antwortet dig @1.1.1.1 und die normale Abfrage nicht, sind die eingetragenen Server falsch oder nicht erreichbar. Ubuntu nutzt systemd-resolved; eine schlichte Debian-Installation oft nicht, dann fehlt resolvectl, und die Server stehen direkt in /etc/resolv.conf. Mit systemd-resolved setzt eine Drop-in-Datei globale Server, ohne netplan anzufassen:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNS=1.1.1.1 9.9.9.9\n' | sudo tee /etc/systemd/resolved.conf.d/dns.conf
sudo systemctl restart systemd-resolved
resolvectl flush-caches

Läuft auch dig @1.1.1.1 in ein Timeout, ist ausgehendes DNS blockiert oder der Server hat kein Netz. Eine ufw-Richtlinie, die ausgehenden Verkehr verbietet, braucht sudo ufw allow out 53. Maschinen ohne systemd-resolved, netplan-Details und Docker-Container behandelt Temporary failure in name resolution (engl.). Fehlt dig, installier bind9-dnsutils.

Wenn dein eigener DNS-Server nicht antwortet

Betreibst du BIND, Unbound, dnsmasq oder PowerDNS auf einem VPS und Clients melden, dass er nicht antwortet, teste ihn von außen mit dig @203.0.113.10 example.com und prüf dann auf dem Server:

sudo ss -lntup 'sport = :53'      # wer auf Port 53 lauscht, und auf welcher Adresse
sudo ufw allow 53                  # öffnet Port 53 für TCP und UDP
sudo journalctl -u named -n 50     # BIND; für die anderen unbound, dnsmasq oder pdns

• Er lauscht nur auf 127.0.0.1. Trag die öffentliche Adresse in der eigenen Konfiguration des Servers ein (listen-on in BIND, interface: in Unbound).
• Er startet nicht, mit „address already in use“. Der Stub-Listener von systemd-resolved belegt Port 53 auf 127.0.0.53 und 127.0.0.54. Schalte den Stub ab und lass /etc/resolv.conf auf die Datei zeigen, die die Upstream-Server direkt auflistet:

sudo mkdir -p /etc/systemd/resolved.conf.d
printf '[Resolve]\nDNSStubListener=no\n' | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf
sudo systemctl restart systemd-resolved
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• TCP ist zu. Große Antworten, DNSSEC eingeschlossen, werden über TCP wiederholt. Öffne beide Protokolle auf Port 53 (engl.), was ufw allow 53 erledigt.
• Er antwortet, aber mit REFUSED. Das ist eine Antwort, kein Schweigen. Ein autoritativer Server lehnt Namen ab, die er nicht hostet. Wolltest du einen Resolver für dich selbst betreiben, erlaube deine eigenen Adressen (allow-recursion in BIND, access-control in Unbound) und sonst niemanden: Offene Resolver werden für DNS-Amplification-Angriffe missbraucht.

Soll der Server im Internet für deine Domain antworten, muss er beim Registrar außerdem als einer der Nameserver der Domain eingetragen sein. Die Anleitung Was sind Nameserver? (engl.) geht diese Delegation Schritt für Schritt durch. Ist das erledigt, fragt der DNS-Propagation-Checker (engl.) den eigenen Nameserver der Domain direkt, neben zwölf öffentlichen Resolvern; ein Server, der schweigt, erscheint dort als „No answer within 2 seconds“.

So kommt der Fehler nicht wieder

• Trag auf jeder Maschine zwei Resolver von zwei verschiedenen Anbietern ein.
• Setz DNS auf Servern dort, wo das System es verwaltet (am Adapter, in netplan oder in einer Drop-in-Datei für resolved), nicht in einer generierten Datei, die überschrieben wird.
• Sichere vor jedem Zurücksetzen des Netzwerks die Ausgabe von ipconfig /all bzw. ip addr und ip route, und stell sicher, dass du Konsolenzugang hast.
• Nimm auf einem Server eine regelmäßige Abfrage in dein Monitoring auf, damit ein toter Resolver als Alarm auffällt statt eine Woche später als gescheiterte Updates.

Ohne Monitoring-System reicht eine Cron-Zeile. Füge sie mit crontab -e hinzu:

*/5 * * * * dig example.com +time=2 +tries=2 | grep -q 'status: NOERROR' || logger -t dns-check "Abfrage von example.com fehlgeschlagen"

Sie prüft auf eine NOERROR-Antwort statt auf den Exit-Status von dig und fängt so auch das SERVFAIL ab, das systemd-resolved zurückgibt, wenn zum Beispiel gar kein DNS-Server eingetragen ist. Fehlschläge landen im Systemlog, wo journalctl -t dns-check sie auflistet.

Einen entfernten Windows-Desktop, den du ohne Ticket selbst reparieren kannst, bieten die Windows-RDP-Tarife: Administratorzugang, deine eigene IPv4-Adresse und die Konsole im Panel für die Momente, in denen RDP nicht reicht.

Häufige Fragen