Hoe u "DNS-server reageert niet" oplost

Wat de foutmelding betekent

Elke verbinding begint met een opzoeking. Uw apparaat stuurt de hostnaam naar een resolver, meestal uw router, uw provider, of een openbare dienst zoals 1.1.1.1, en wacht op een IP-adres. Komt er binnen de time-out geen antwoord, dan probeert het besturingssysteem het opnieuw, probeert de secundaire server, en geeft uiteindelijk op. Windows draait dan zijn probleemoplosser, die meldt dat de DNS-server niet reageert.

De formulering wijst naar de server, maar is eigenlijk een uitspraak over een pad. Elk van het volgende levert dezelfde melding op: de resolver is offline, de resolver is online maar onbereikbaar vanaf uw netwerk, een firewall laat poort 53 niet door, het adres dat op uw adapter is ingesteld is verkeerd, of de router ertussenin stopte met doorsturen. Stilte ziet er in alle vijf gevallen hetzelfde uit.

Onderscheid het eerst van zijn buren voordat u begint. Een resolver die antwoordt met "geen zo'n naam" geeft NXDOMAIN, behandeld in DNS_PROBE_FINISHED_NXDOMAIN. Een resolver die traag maar correct antwoordt, is opnieuw een ander probleem, en heeft hieronder zijn eigen onderdeel. Deze fout is het geval waarin er helemaal niets terugkomt.

Waarom het gebeurt

• De router stopte met doorsturen. Consumentenrouters draaien een kleine DNS-forwarder die vaker vastloopt dan de rest van het apparaat, zodat het netwerk online lijkt en alleen naamopzoekingen falen.
• De ingestelde DNS-server is verkeerd. Een statisch adres dat is overgebleven van een oud netwerk, of een server die buiten dienst is gesteld.
• De resolver van de provider heeft een storing of is overbelast en laat queries vallen in plaats van te antwoorden.
• Een firewall of beveiligingspakket blokkeert poort 53. Sommige producten onderscheppen DNS zelf en falen dicht wanneer hun eigen dienst niet draait.
• Een VPN is half verbonden. De tunnel drukte zijn interne resolvers op uw adapter en viel toen weg, waardoor adressen overbleven die alleen binnen de tunnel bereikbaar zijn.
• IPv6 is ingesteld maar niet bruikbaar. Het systeem geeft de voorkeur aan een IPv6-resolver, krijgt er geen route naartoe, en wacht de time-out uit voordat het terugvalt.
• De Windows DNS Client-service is gestopt of de cache ervan is corrupt.
• Malware of een ongewenste app veranderde de resolver naar een adres dat het beheert en dat vervolgens verdwijnt.
• Het netwerk vereist een captive-portal-login die nog niet heeft plaatsgevonden, zodat alle uitgaande DNS wordt ingeslikt.

Hoe u het oplost

Ga eerst na of het netwerk zelf online is voordat u aan DNS-instellingen komt. ping 1.1.1.1 gebruikt helemaal geen naamresolutie. Mislukt dat ook, dan heeft u een connectiviteitsprobleem, geen DNS-probleem. Slaagt dat wel terwijl ping example.com mislukt, dan is DNS bevestigd als het kapotte onderdeel en gelden de stappen hieronder.

Windows

1. Wis de cache en herstart de clientservice:

   ipconfig /flushdns
   net stop dnscache
   net start dnscache

2. Bekijk wat uw adapter gebruikt: ipconfig /all | findstr /C:"DNS Servers"
3. Stel in plaats daarvan een openbare resolver in: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
4. Test die specifieke server rechtstreeks: nslookup example.com 1.1.1.1
5. Zet de stack terug als niets helpt, en start opnieuw op:

   netsh int ip reset
   netsh winsock reset

6. Vink IPv6 uit op de adapter als de machine geen werkende IPv6 heeft, en test opnieuw.

macOS

1. Wis de cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Lees de resolvers die in gebruik zijn: scutil --dns | grep nameserver
3. Vervang ze: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Ga terug naar wat DHCP uitdeelt: sudo networksetup -setdnsservers Wi-Fi empty

Linux

1. Controleer de status en wis: resolvectl status, dan sudo resolvectl flush-caches
2. Bevraag expliciet één server om te zien of die überhaupt antwoordt: dig @1.1.1.1 example.com +short
3. Wijzig de resolver op de verbinding in plaats van /etc/resolv.conf te bewerken, dat meestal automatisch wordt gegenereerd:

   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"

4. Herstart de stub-resolver als die vastzit: sudo systemctl restart systemd-resolved

Router

1. Herstart de stroomvoorziening en wacht tot de WAN-verbinding terug is voordat u test.
2. Zet in de beheerpagina de WAN-DNS-servers op een openbaar paar in plaats van "automatisch verkrijgen" als de resolver van de provider de verdachte is.
3. Werk de firmware bij. Bugs in de DNS-forwarder zijn een veelvoorkomende reden waarom een router elke paar weken opnieuw moet worden opgestart.
4. Omzeil hem als test: verbind een telefoon met mobiele data en los dezelfde naam op. Lukt dat daar wel, dan wijst de fout naar uw eigen netwerk.

Browser

1. Chrome, Edge en Firefox kunnen DNS over HTTPS naar een eigen provider sturen, los van uw systeeminstellingen. Faalt de browser terwijl dig slaagt, zet dan secure DNS uit in de privacyinstellingen van de browser en test opnieuw.
2. Wis Chrome's interne cache op chrome://net-internals/#dns.

Wanneer de opzoeking traag is in plaats van kapot

Niet elke DNS-klacht is een mislukking. Laden pagina's uiteindelijk wel, maar met een seconde of twee vertraging voordat er iets gebeurt, dan antwoordt de resolver wel, alleen laat, en de oplossingen hierboven veranderen daar weinig aan. Meet het voordat u gokt:

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

Alles in enkele of lage dubbele milliseconden vanuit een warme cache is normaal. Enkele honderden milliseconden, of een cijfer dat wild verschilt tussen runs, betekent dat de resolver ver weg is, overbelast, of vastloopt op zijn eerste server en terugvalt op een tweede. Dat is een andere diagnose met andere oplossingen, uiteengezet in hoe u een trage DNS-opzoeking oplost.

Controleer het van buitenaf

Tot nu toe gaat alles ervan uit dat de fout dicht bij u ligt, wat meestal ook zo is. Bevestig dat eerst voordat u er een middag aan besteedt. Vraag een resolver die niets met uw netwerk te maken heeft of de naam wordt opgelost:

dig @8.8.8.8 example.com +short
dig @9.9.9.9 example.com +short
nslookup example.com 1.1.1.1

Een antwoord van die servers terwijl uw eigen resolver stil blijft, bewijst dat het domein prima is en het probleem bij u ligt. Blijven ze allemaal stil, dan verschuift de aandacht naar de eigen nameservers van het domein, die down kunnen zijn of onbereikbaar vanaf een deel van het internet.

De bereikbaarheid van een nameserver is niet overal gelijk. Voer de DNS-querycontrole uit om dezelfde opzoeking te versturen vanaf controlepunten in verschillende landen en de antwoorden naast elkaar te vergelijken. Krijgen sommige locaties wel een resultaat en andere een time-out, dan kijkt u naar een routerings- of providerprobleem dat een regio treft, niet naar een kapot record, en geen enkele hoeveelheid cache wissen op uw laptop laat u dat zien.

Wanneer uw eigen nameserver stil valt

Een nameserver die stil valt, haalt een site net zo volledig offline als een dode webserver, en doet dat zonder ook maar één regel in uw toegangslog achter te laten. Niemand bereikt u om het te melden, want ze kunnen u helemaal niet bereiken. HostTracker voert geplande controles uit vanaf 300+ controlepunten in 158 steden over 13 monitortypes, zodat een naam die in één regio stopt met resolven, wordt opgevangen door de controlepunten daar in plaats van door een e-mail van een klant. De rest van dit onderdeel staat in het onderdeel over oplossingen, en als de vraag is of een recente DNS-wijziging al overal is doorgekomen, dan is dat hoe u DNS-propagatie controleert.