DNS Server antwortet nicht: Vollständige Fehlerbehebungsanleitung

Ein "DNS-Server antwortet nicht"-Fehler bedeutet, dass Ihr Betriebssystem eine Auflösungsanfrage an einen DNS-Resolver gesendet hat und innerhalb des Timeout-Fensters keine Antwort erhalten hat — sodass der Browser nie die IP-Adresse erhalten hat, die zum Aufbau einer TCP-Verbindung benötigt wird. Das Ergebnis ist ein fehlgeschlagener Seitenaufruf, selbst wenn Ihre physische Netzwerkverbindung vollständig funktioniert. Die Ursache kann an jeder Stelle in der Auflösungskette liegen: Ihr lokaler Stub-Resolver, der rekursive Resolver bei Ihrem ISP, ein vorgelagerter autoritativer Server oder ein falsch konfiguriertes Netzwerkgerät zwischen Ihnen und einem dieser Punkte.

Dieser Leitfaden führt durch jede Ebene dieser Kette — vom 30-Sekunden-Router-Neustart bis zum Low-Level-Treibertausch — mit genauen Befehlen für Windows, macOS und Linux, plus einem Vergleich öffentlicher Resolver und einer Entscheidungsmatrix, die Ihnen hilft, den Fehler schnell zu isolieren.

Was bei der DNS-Auflösung tatsächlich passiert

Bevor Sie den Fehler beheben, verhindert das Verstehen des Auflösungspfads verschwendeten Aufwand. Wenn Sie example.com in einen Browser eingeben:

1. Das Betriebssystem prüft seinen lokalen DNS-Cache (und die hosts-Datei).
2. Wenn kein gecachter Eintrag vorhanden ist, leitet der Stub-Resolver die Anfrage an den rekursiven Resolver weiter, der auf der Netzwerkschnittstelle konfiguriert ist (normalerweise Ihr Router oder ein vom ISP zugewiesener Server).
3. Der rekursive Resolver durchläuft die DNS-Hierarchie — Root-Server, TLD-Nameserver, autoritative Nameserver — und gibt den endgültigen A– oder AAAA-Eintrag zurück.
4. Das Betriebssystem speichert das Ergebnis für die Dauer der TTL des Eintrags im Cache und übergibt die IP an den Browser.

Ein „antwortet nicht”-Fehler tritt typischerweise in Schritt 2 oder 3 auf. Der Stub-Resolver hat ein UDP-Paket an Port 53 gesendet und Stille erhalten. Diese Stille hat eine überraschend große Anzahl von Ursachen.

Ursachen des Fehlers „DNS-Server antwortet nicht”

Ausfälle auf der DNS-Resolver-Seite

• Der konfigurierte rekursive Resolver ist vorübergehend überlastet oder offline.
• Die DNS-Infrastruktur Ihres ISP wird mit einem DDoS-Angriff angegriffen oder befindet sich in Wartung.
• Die IP-Adresse des Resolvers hat sich geändert, aber Ihr Gerät hält noch den alten Wert.

Lokale Netzwerk- und Hardwareprobleme

• Router-Firmware-Fehler, die das DNS-Relay beschädigen (häufig bei Consumer-Geräten nach langen Betriebszeiten).
• Ein DHCP-Lease, der eine veraltete oder ungültige DNS-Serveradresse übermittelt hat.
• Ein defektes Ethernet-Kabel oder ein schwaches Wi-Fi-Signal, das speziell auf UDP-Port 53 Paketverluste verursacht.

Fehlkonfigurationen auf Host-Ebene

• Ein beschädigter oder vergifteter lokaler DNS-Cache, der veraltete negative Antworten enthält.
• Eine manuell eingegebene DNS-Adresse, die falsch ist oder nicht mehr erreichbar ist.
• Ein hosts-Datei-Eintrag, der mit der erwarteten DNS-Antwort in Konflikt steht.

Störungen durch Sicherheitssoftware

• Firewalls oder Endpoint-Security-Tools, die ausgehenden UDP/TCP-Port 53 blockieren oder DNS-Anfragen zur Inspektion abfangen und dann verwerfen.
• VPN-Clients, die DNS-Datenverkehr durch einen Tunnel-Endpunkt umleiten, der derzeit nicht erreichbar ist.
• Kindersicherungssoftware, die als lokaler DNS-Proxy fungiert und lautlos abstürzt.

Treiber- und Betriebssystemprobleme

• Ein veralteter oder beschädigter NIC-Treiber, der UDP-Datagramme fehlerhaft verarbeitet.
• Der Windows DNS-Client-Dienst (Dnscache) in einem hängenden Zustand.
• Ein macOS mDNSResponder-Prozess, der übermäßig viel Speicher verbraucht hat und nicht mehr reagiert.

Schritt-für-Schritt-Lösungen: Geordnet nach Aufwand und Wahrscheinlichkeit

Arbeiten Sie diese der Reihe nach durch. Jeder Schritt dauert weniger als fünf Minuten und schließt eine bestimmte Ebene des Problems aus.

Schritt 1: Zuerst den Umfang des Problems überprüfen

Bevor Sie Einstellungen ändern, führen Sie eine schnelle Diagnose durch, um zu bestätigen, dass DNS tatsächlich der Fehlerpunkt ist und nicht die allgemeine Konnektivität:

# Windows — ping a known IP directly (bypasses DNS entirely)
ping 8.8.8.8

# Windows — attempt a DNS lookup explicitly
nslookup example.com

# macOS / Linux
ping -c 4 8.8.8.8
dig example.com

Wenn ping 8.8.8.8 erfolgreich ist, aber nslookup example.com fehlschlägt, ist die DNS-Auflösung definitiv das Problem. Wenn ping 8.8.8.8 ebenfalls fehlschlägt, liegt das Problem tiefer — wahrscheinlich Routing oder physische Konnektivität — und DNS ist ein Symptom, nicht die Ursache.

Schritt 2: Router und Modem neu starten

Ein Neustart löscht den internen DNS-Relay-Cache des Routers, setzt DHCP-Leases zurück und stellt die WAN-Verbindung mit frischen DNS-Serverzuweisungen von Ihrem ISP wieder her.

1. Ziehen Sie das Netzkabel sowohl vom Modem als auch vom Router ab.
2. Warten Sie volle 30 Sekunden (Kondensatoren brauchen Zeit zum Entladen).
3. Schalten Sie zuerst das Modem ein; warten Sie, bis es vollständig synchronisiert ist (stabile WAN-Leuchte).
4. Schalten Sie dann den Router ein; warten Sie, bis er seine Startsequenz abgeschlossen hat.
5. Verbinden Sie Ihr Gerät erneut und führen Sie den nslookup-Test aus Schritt 1 erneut durch.

Sonderfall: Wenn Ihr Router seit Wochen ohne Neustart läuft, hat sein DNS-Relay (dnsmasq oder ähnliches) möglicherweise einen vollen Cache oder einen Speicherleck. Einige von ISPs bereitgestellte Router haben bekannte Fehler, bei denen das DNS-Relay nach einer bestimmten Betriebszeit aufhört, Anfragen weiterzuleiten. Ein Neustart ist die schnellste Lösung.

Schritt 3: Den lokalen DNS-Cache leeren

Veraltete oder beschädigte Cache-Einträge veranlassen das Betriebssystem, schlechte Ergebnisse zurückzugeben oder Lookup-Fehler zu erzeugen, bevor eine Anfrage das Gerät überhaupt verlässt.

Windows:

ipconfig /flushdns

Sie sollten sehen: Successfully flushed the DNS Resolver Cache.

macOS (versionsspezifisch — verwenden Sie den richtigen Befehl für Ihr Betriebssystem):

# macOS Ventura, Monterey, Big Sur, Catalina
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Mojave and earlier
sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches
# Verify the cache was cleared
sudo systemd-resolve --statistics | grep "Current Cache Size"

Linux (nscd):

sudo service nscd restart

Schritt 4: Zu einem zuverlässigen öffentlichen DNS-Resolver wechseln

Wenn der DNS-Resolver Ihres ISP das Problem ist, ist der Wechsel zu einem gut gewarteten öffentlichen Resolver die schnellste Abhilfe. Die folgende Tabelle vergleicht die am häufigsten verwendeten Optionen:

Cloudflare 1.1.1.1 misst in unabhängigen Benchmarks konsistent die niedrigste globale durchschnittliche Anfrage-Latenz. Quad9 ist die bessere Wahl, wenn Sie passives Malware-Domain-Blocking ohne Verwaltung eines separaten DNS-Filters wünschen.

DNS unter Windows 10/11 ändern:

1. Öffnen Sie Einstellungen > Netzwerk & Internet > Adapteroptionen ändern.
2. Klicken Sie mit der rechten Maustaste auf Ihren aktiven Adapter und wählen Sie Eigenschaften.
3. Wählen Sie Internetprotokoll Version 4 (TCP/IPv4) und klicken Sie auf Eigenschaften.
4. Wählen Sie Folgende DNS-Serveradressen verwenden.
5. Geben Sie die gewählten primären und sekundären Resolver-IPs ein.
6. Klicken Sie auf OK und führen Sie dann ipconfig /flushdns aus, um veraltete Cache-Einträge zu löschen.

Für IPv6-Netzwerke wiederholen Sie den Vorgang für Internetprotokoll Version 6 (TCP/IPv6) mit den IPv6-Adressen des Resolvers (z. B. Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

DNS unter macOS ändern:

1. Öffnen Sie Systemeinstellungen > Netzwerk.
2. Wählen Sie Ihre aktive Verbindung und klicken Sie auf Details.
3. Gehen Sie zum Tab DNS.
4. Entfernen Sie vorhandene Einträge mit der –-Schaltfläche und fügen Sie dann Ihre gewählten Resolver-IPs mit + hinzu.
5. Klicken Sie auf OK und Anwenden.

DNS unter Linux ändern (NetworkManager):

# Edit the connection (replace "Wired connection 1" with your connection name)
nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"

Schritt 5: Den DNS-Client-Dienst neu starten (Windows)

Der Windows DNS-Client-Dienst (Dnscache) speichert aufgelöste Namen im Cache und verwaltet den Stub-Resolver. Wenn er in einen hängenden Zustand gerät, schlagen alle DNS-Anfragen lautlos fehl.

net stop dnscache
net start dnscache

Alternativ über die Dienste-Konsole: Drücken Sie Win + R, geben Sie services.msc ein, suchen Sie DNS-Client, klicken Sie mit der rechten Maustaste und wählen Sie Neu starten. Beachten Sie, dass bei einigen Windows 11-Builds die Neustart-Option in der GUI ausgegraut ist — verwenden Sie stattdessen die Befehlszeilenmethode.

Schritt 6: Firewall oder Sicherheitssoftware vorübergehend deaktivieren

Drittanbieter-Firewalls und Endpoint-Protection-Suites fangen manchmal DNS-Datenverkehr zur Inspektion ab und verwerfen aufgrund eines Regelkonflikts oder Engine-Fehlers die Pakete vollständig.

Windows Defender Firewall (nur temporärer Test):

netsh advfirewall set allprofiles state off

Sofort nach dem Test wieder aktivieren:

netsh advfirewall set allprofiles state on

macOS:

Navigieren Sie zu Systemeinstellungen > Datenschutz & Sicherheit > Firewall und deaktivieren Sie sie zu Testzwecken.

Wenn das Deaktivieren der Firewall das Problem löst, lassen Sie sie nicht deaktiviert. Öffnen Sie stattdessen den Regeleditor der Firewall und suchen Sie nach Regeln, die ausgehenden Datenverkehr auf UDP-Port 53 und TCP-Port 53 blockieren. Fügen Sie explizite Erlaubnisregeln für Ihre gewählten DNS-Resolver-IPs hinzu.

VPN-Clients verdienen hier besondere Aufmerksamkeit. Viele VPN-Anwendungen installieren einen lokalen DNS-Proxy auf 127.0.0.1:53 und leiten alle Anfragen durch den Tunnel. Wenn der VPN-Server nicht erreichbar ist, schlägt jede DNS-Anfrage fehl. Trennen Sie die VPN-Verbindung, testen Sie DNS, verbinden Sie sich dann erneut und überprüfen Sie die DNS-Leak-Einstellungen des VPN-Clients.

Schritt 7: Einen anderen Browser ausprobieren

Bestimmte Browser-Erweiterungen — insbesondere Werbeblocker, Datenschutz-Tools und Sicherheits-Plugins — fangen DNS-over-HTTPS (DoH)-Anfragen ab oder ändern das Verhalten des System-Resolvers. Wenn DNS in einem Browser funktioniert, aber nicht in einem anderen, liegt das Problem auf Erweiterungsebene, nicht auf Betriebssystemebene.

Testen Sie zuerst in einem privaten/Inkognito-Fenster (Erweiterungen sind normalerweise deaktiviert). Wenn das das Problem löst, deaktivieren Sie Erweiterungen einzeln, um den Verursacher zu identifizieren. Wenn das Problem in allen Browsern weiterhin besteht, liegt der Fehler auf der Betriebssystem- oder Netzwerkebene.

Schritt 8: Netzwerktreiber aktualisieren oder zurücksetzen

Ein beschädigter NIC-Treiber kann zu unregelmäßiger UDP-Paketverarbeitung führen, was sich als intermittierende DNS-Fehler manifestiert, selbst wenn TCP-Verbindungen funktionieren.

Windows — Aktualisierung über den Geräte-Manager:

1. Drücken Sie Win + X und wählen Sie Geräte-Manager.
2. Erweitern Sie Netzwerkadapter.
3. Klicken Sie mit der rechten Maustaste auf Ihren Adapter und wählen Sie Treiber aktualisieren > Automatisch nach Treibern suchen.
4. Starten Sie nach der Installation neu.

Windows — Kürzlich aktualisierten Treiber zurücksetzen:

Wenn der DNS-Fehler unmittelbar nach einem Windows-Update aufgetreten ist, könnte der neue Treiber die Regression sein. Klicken Sie im Geräte-Manager mit der rechten Maustaste auf den Adapter und wählen Sie Eigenschaften > Treiber > Vorheriger Treiber.

macOS: NIC-Treiber sind in macOS gebündelt. Installieren Sie alle ausstehenden Systemupdates über Systemeinstellungen > Allgemein > Softwareaktualisierung.

Linux:

# Check current driver module
lspci -k | grep -A 3 "Network controller"

# Update kernel (which includes driver updates) on Debian/Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic

Schritt 9: Physische Netzwerkverbindungen überprüfen

Wenn Sie eine kabelgebundene Verbindung verwenden, verursacht ein beschädigtes Ethernet-Kabel intermittierende Paketverluste, die UDP-basierte Protokolle wie DNS unverhältnismäßig stark beeinträchtigen (das keine eingebaute Neuübertragung auf der Anwendungsebene hat).

• Stecken Sie beide Enden des Ethernet-Kabels neu ein.
• Tauschen Sie das Kabel gegen ein bekannt funktionierendes aus.
• Testen Sie einen anderen Port am Router oder Switch.
• Überprüfen Sie die Link-Anzeige-LEDs der NIC — ein stabiles grünes oder bernsteinfarbenes Licht bestätigt die physische Verbindung; ein blinkendes oder fehlendes Licht weist auf ein Layer-1-Problem hin.

Schritt 10: Windows-Netzwerk-Problembehandlung ausführen

Windows enthält eine automatisierte Diagnose, die häufige DNS-Fehlkonfigurationen erkennen und beheben kann, einschließlich des Zurücksetzens des DNS-Clients und des Leerens des Caches.

Navigieren Sie zu Einstellungen > System > Problembehandlung > Weitere Problembehandlungen > Internetverbindungen und führen Sie den Assistenten aus. Er versucht automatische Reparaturen und berichtet, was er gefunden hat. Obwohl er nicht jedes Szenario abdeckt, ist er eine nützliche Überprüfung, die weniger als eine Minute dauert.

Schritt 11: Hosts-Datei überprüfen und bearbeiten

Eine beschädigte oder böswillig modifizierte hosts-Datei kann DNS für bestimmte Domains überschreiben und Auflösungsfehler verursachen, die identisch mit einem DNS-Serverfehler aussehen.

Windows — mit erhöhten Rechten öffnen:

notepad C:WindowsSystem32driversetchosts

macOS / Linux:

sudo nano /etc/hosts

Suchen Sie nach Einträgen, die gängige Domains auf 0.0.0.0 oder 127.0.0.1 umleiten. Sicherheitssoftware, Werbeblocker und Malware modifizieren alle diese Datei. Entfernen Sie verdächtige Einträge, speichern Sie und leeren Sie den DNS-Cache.

Schritt 12: TCP/IP- und Winsock-Stack zurücksetzen (Windows)

Wenn mehrere Netzwerkkomponenten falsch konfiguriert sind, ist ein vollständiges Stack-Reset schneller als die Suche nach einzelnen Einstellungen:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /flushdns
ipconfig /renew

Starten Sie den Computer nach Ausführung aller fünf Befehle neu. Dies setzt die TCP/IP-Registrierungsparameter und den Winsock-Katalog auf ihren Standardzustand zurück, ohne Ihre Netzwerkadaptertreiber zu beeinflussen.

Schritt 13: Router auf Werkseinstellungen zurücksetzen

Verwenden Sie dies als letztes Mittel, bevor Sie Ihren ISP kontaktieren. Ein Werksreset löscht alle benutzerdefinierten Konfigurationen — Wi-Fi-SSIDs, Passwörter, Port-Weiterleitungsregeln und alle benutzerdefinierten DNS-Einstellungen — und stellt den Router in seinen Auslieferungszustand wieder her.

Die meisten Router haben einen versenkten Reset-Knopf. Halten Sie ihn mit einer Nadel 10–15 Sekunden lang gedrückt, bis die Status-LEDs durchlaufen. Nachdem der Router neu gestartet ist, konfigurieren Sie Ihr Netzwerk von Grund auf neu. Wenn DNS unmittelbar nach dem Reset funktioniert, war eine falsch konfigurierte Router-Einstellung die Ursache.

Schritt 14: Ihren ISP kontaktieren

Wenn alle oben genannten Schritte fehlschlagen und das Problem alle Geräte in Ihrem Netzwerk betrifft, liegt das Problem fast sicher vor Ihrem Router — entweder in der rekursiven Resolver-Infrastruktur des ISP oder auf dem WAN-Link selbst. Kontaktieren Sie den technischen Support Ihres ISP mit den folgenden Informationen bereit:

• Ergebnisse von nslookup example.com sowohl mit dem DNS Ihres ISP als auch mit einem öffentlichen Resolver wie 8.8.8.8.
• Ob das Problem intermittierend oder dauerhaft ist.
• Ob der Wechsel zu einem mobilen Hotspot (Umgehung Ihres ISP vollständig) das Problem löst.

Dieser letzte Test ist die endgültige ISP-Isolierungsprüfung.

DNS-Konfiguration für Server-Administratoren

Wenn Sie eine VPS Hosting-Umgebung oder einen Dedizierten Server verwalten, bekommen DNS-Fehler zusätzliche Dimensionen. Ein falsch konfigurierter Resolver auf einem Server betrifft jede darauf laufende Anwendung — Webserver, E-Mail-Zustellung, Paketmanager und Monitoring-Agenten sind alle auf zuverlässige Namensauflösung angewiesen.

Resolver-Konfiguration auf Linux-Servern überprüfen:

cat /etc/resolv.conf

Eine gesunde Datei sollte mindestens zwei nameserver-Zeilen enthalten, die auf zuverlässige Resolver zeigen:

nameserver 1.1.1.1
nameserver 8.8.8.8

Auf Systemen, die systemd-resolved verwenden, ist /etc/resolv.conf ein Symlink. Das direkte Bearbeiten hat keine Wirkung. Verwenden Sie stattdessen resolvectl:

resolvectl status
resolvectl dns eth0 1.1.1.1 8.8.8.8

Auflösungslatenz von einem Server aus testen:

dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Wenn die Anfragezeiten konsistent 200ms überschreiten, ist der Resolver geografisch weit entfernt oder unter Last. Wechseln Sie zu einem Resolver mit einem Point-of-Presence näher am Rechenzentrum Ihres Servers.

Für Server, die cPanel VPS-Umgebungen betreiben, wird die DNS-Konfiguration auch über die Basic cPanel & WHM Setup-Seite in WHM verwaltet. Stellen Sie sicher, dass die dort aufgeführten Resolver mit dem übereinstimmen, was in /etc/resolv.conf steht, um Split-Brain-Auflösungsprobleme zu vermeiden.

DNS und Domain-Registrierung: Die vorgelagerte Verbindung

Ein „DNS-Server antwortet nicht”-Fehler bei Ihrer eigenen Domain — anstatt der einer anderen Person — lässt sich oft auf die Nameserver-Konfiguration auf Registrar-Ebene zurückführen. Wenn Sie kürzlich eine Domain registriert oder Nameserver über die Domain-Registrierung geändert haben, dauert die Propagierung bis zu 48 Stunden. Während dieses Zeitfensters halten einige Resolver weltweit noch die alten NS-Einträge.

Verwenden Sie einen Propagierungsprüfer oder fragen Sie mehrere geografisch verteilte Resolver direkt ab:

# Query authoritative nameservers directly, bypassing cache
dig +trace example.com

# Check what specific resolvers currently return
dig @1.1.1.1 example.com NS
dig @8.8.8.8 example.com NS
dig @208.67.222.222 example.com NS

Abweichungen zwischen Resolver-Antworten während der Propagierung sind normal. Wenn die Antworten nach 48 Stunden noch inkonsistent sind, sind die NS-Einträge beim Registrar wahrscheinlich falsch konfiguriert.

DNS absichern: DNSSEC und DNS-over-HTTPS

Standard-DNS-Anfragen werden im Klartext über UDP-Port 53 übertragen, was sie anfällig für DNS-Spoofing und Cache-Poisoning-Angriffe macht. Zwei komplementäre Technologien adressieren dies:

DNSSEC fügt kryptografische Signaturen zu DNS-Einträgen hinzu, sodass Resolver überprüfen können, dass eine Antwort authentisch ist und nicht manipuliert wurde. Es schützt die Integrität der Daten, verschlüsselt die Anfrage selbst jedoch nicht.

DNS-over-HTTPS (DoH) und DNS-over-TLS (DoT) verschlüsseln die gesamte DNS-Anfrage und verhindern so Abhören und Manipulation auf dem Übertragungsweg. Moderne Browser unterstützen DoH nativ. Um es systemweit unter Windows 11 zu aktivieren, navigieren Sie zu Einstellungen > Netzwerk & Internet > [Ihr Adapter] > DNS-Serverzuweisung > Bearbeiten und setzen Sie die Verschlüsselung auf Nur verschlüsselt (DNS over HTTPS).

Für Server konfigurieren Sie systemd-resolved zur Verwendung von DoT:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

sudo systemctl restart systemd-resolved

Wenn Sie E-Mail-Hosting betreiben oder Ihren eigenen Mailserver verwalten, ist eine korrekte DNS-Konfiguration — insbesondere SPF-, DKIM- und DMARC-Einträge — entscheidend für die Zustellbarkeit. DNS-Fehler auf einem Mailserver unterbrechen nicht nur das ausgehende Surfen; sie verursachen verzögerte oder zurückgewiesene E-Mails und fehlgeschlagene TLS-Zertifikatsvalidierung.

SSL-Zertifikate und DNS-Abhängigkeit

Die Ausstellung und Erneuerung von TLS-Zertifikaten hängt vollständig von DNS ab. Zertifizierungsstellen, die Domain-Validierung (DV) über die DNS-01 ACME-Challenge durchführen, müssen den _acme-challenge-TXT-Eintrag Ihrer Domain auflösen. Wenn DNS zum Zeitpunkt der Erneuerung defekt ist, schlagen automatisierte Tools wie Certbot lautlos fehl, und Ihre SSL-Zertifikate laufen ab — und nehmen HTTPS mit sich.

Richten Sie Monitoring sowohl für die DNS-Auflösungsgesundheit als auch für den Zertifikatsablauf ein. Eine einfache cron-basierte Prüfung:

# Check days until certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | openssl x509 -noout -dates

Entscheidungsmatrix: Die DNS-Fehlerebene isolieren

Verwenden Sie diese Matrix, um die Fehlerebene zu identifizieren, bevor Sie Zeit mit Lösungen verbringen, die auf Ihre Situation nicht zutreffen.

Technische Checkliste der wichtigsten Erkenntnisse

• Führen Sie zuerst ping 8.8.8.8 aus. Wenn es fehlschlägt, ist DNS nicht Ihr primäres Problem — beheben Sie zuerst Routing oder physische Konnektivität.
• Leeren Sie immer den lokalen DNS-Cache nach dem Ändern von Resolver-Einstellungen; veraltete Einträge verbergen, ob die Lösung funktioniert hat.
• Wechseln Sie zu Cloudflare 1.1.1.1 oder Quad9 9.9.9.9 als erste Resolver-Änderung — beide sind schneller und zuverlässiger als die meisten ISP-Resolver.
• Unter Windows, wenn die Dienste-GUI die DNS-Client-Neustart-Option ausgraut, verwenden Sie net stop dnscache && net start dnscache von einer erhöhten Eingabeaufforderung aus.
• Bearbeiten Sie auf Linux-Servern niemals /etc/resolv.conf direkt auf systemd-resolved-Systemen — Änderungen werden beim Netzwerk-Neustart überschrieben. Verwenden Sie resolvectl oder nmcli.
• VPN-Clients sind häufig ein stiller Verursacher. Testen Sie immer mit getrenntem VPN, bevor Sie eskalieren.
• Für Ihre eigenen Domains umgeht dig +trace alle Caches und zeigt genau, was die autoritativen Server zurückgeben — verwenden Sie es, bevor Sie ein Resolver-Problem annehmen.
• Aktivieren Sie DNSSEC-Validierung und DNS-over-TLS/HTTPS auf Produktionsservern, um eine ganze Klasse von Spoofing-basierten DNS-Fehlern zu eliminieren.
• Überwachen Sie auf Servern sowohl die DNS-Auflösungsgesundheit als auch den SSL-Zertifikatsablauf gemeinsam — ein DNS-Fehler führt Tage später lautlos zu einem Fehler bei der Zertifikatserneuerung.

Häufig gestellte Fragen

Warum schlägt DNS fehl, obwohl ich eine funktionierende Internetverbindung habe?

Die DNS-Auflösung verwendet UDP-Pakete an Port 53, was von den TCP-Verbindungen getrennt ist, die Ihr Browser zum Laden von Seiten verwendet. Eine Firewall-Regel, ein abgestürztes DNS-Relay auf Ihrem Router oder ein ausgefallener Resolver kann Port 53 speziell blockieren, während der gesamte andere Datenverkehr unbeeinträchtigt bleibt. Führen Sie ping 8.8.8.8 aus, um die IP-Konnektivität zu bestätigen, dann nslookup example.com, um zu bestätigen, dass DNS der isolierte Fehler ist.

Ist es sicher, dauerhaft Google oder Cloudflare DNS anstelle des Resolvers meines ISP zu verwenden?

Ja, für die meisten Benutzer und Anwendungsfälle. Sowohl Google Public DNS als auch Cloudflare 1.1.1.1 unterstützen DNSSEC-Validierung und bieten höhere Verfügbarkeits-SLAs als typische ISP-Resolver. Der Kompromiss ist, dass Ihre DNS-Anfragen von einem Drittanbieter-Infrastrukturanbieter statt von Ihrem ISP verarbeitet werden. Cloudflare veröffentlicht eine strenge Richtlinie zur Nicht-Protokollierung von Anfragen; Google behält anonymisierte Logs bis zu 48 Stunden.

Was ist der Unterschied zwischen dem Leeren des DNS-Caches und dem Ändern des DNS-Servers?

Das Leeren des Caches löscht lokal gespeicherte Auflösungsergebnisse und zwingt das Betriebssystem, neue Anfragen an den konfigurierten Resolver zu senden. Das Ändern des DNS-Servers leitet um, wohin diese Anfragen gesendet werden. Wenn Ihr Cache einen vergifteten oder veralteten Eintrag enthält, behebt das Leeren das Problem, ohne Ihren Resolver zu ändern. Wenn Ihr Resolver selbst ausgefallen oder langsam ist, behebt das Ändern der Serveradresse das Problem, ohne den Cache zu berühren. In der Praxis ist es nach einem DNS-Fehler der sauberste Ansatz, beides zusammen zu tun.

Warum gelingt nslookup, aber der Browser zeigt immer noch einen DNS-Fehler?

Browser verwenden zunehmend ihre eigene DNS-over-HTTPS-Implementierung, die den Betriebssystem-Resolver vollständig umgeht. Wenn der vom Browser konfigurierte DoH-Endpunkt nicht erreichbar ist, kann er fehlschlagen, selbst wenn der System-Resolver einwandfrei funktioniert. Überprüfen Sie die Datenschutz- oder Sicherheitseinstellungen des Browsers auf eine Option „Sicheres DNS” oder „DNS over HTTPS” und deaktivieren Sie sie entweder oder verweisen Sie auf einen erreichbaren DoH-Anbieter.

Wie diagnostiziere ich DNS-Probleme auf einem Linux VPS ohne GUI?

Verwenden Sie dig, nslookup und resolvectl von der Befehlszeile aus. Führen Sie dig @1.1.1.1 example.com aus, um einen bestimmten Resolver direkt zu testen und dabei die lokale Konfiguration vollständig zu umgehen. Führen Sie resolvectl status aus, um zu sehen, welchen Resolver das System derzeit verwendet und ob DNSSEC aktiv ist. Überprüfen Sie /etc/resolv.conf, um die konfigurierten Nameserver zu bestätigen, und verifizieren Sie, dass die Datei kein defekter Symlink ist mit ls -la /etc/resolv.conf.