DNS_PROBE_FINISHED_NXDOMAIN: wat het betekent en hoe u het oplost

Wat de foutmelding betekent

NXDOMAIN is een DNS-responscode, afkorting voor non-existent domain. Een resolver geeft die terug nadat hij de keten heeft afgelopen van de root tot de zone die uw hostnaam zou moeten bevatten, en daar niets vond. Chrome toont DNS_PROBE_FINISHED_NXDOMAIN. Firefox zegt dat hij geen verbinding met de server kan maken. Safari zegt dat hij de server niet kan vinden. Alle drie melden hetzelfde antwoord.

NXDOMAIN is niet hetzelfde als een resolverfout, en dat verschil bepaalt waar u moet zoeken. Is uw resolver onbereikbaar of geeft hij een time-out, dan krijgt u in plaats daarvan een melding "DNS-server reageert niet". Antwoordt de zone wel maar is hij kapot, bijvoorbeeld een DNSSEC-keten die niet valideert, dan krijgt u meestal SERVFAIL. NXDOMAIN is een definitief antwoord: de naam is niet gepubliceerd.

Eén eigenschap van NXDOMAIN weegt zwaarder dan alle andere tijdens het oplossen van problemen. Negatieve antwoorden worden gecachet. Volgens RFC 2308 cachet een resolver het resultaat "geen zo'n naam" voor het interval uit het SOA-record van de zone, doorgaans tussen 5 en 60 minuten. Een domein dat twee minuten geleden begon te werken, kan op uw machine nog steeds falen, en geen enkele herlaadactie verandert daar iets aan totdat het cache-item verloopt of u het wist.

Waarom het gebeurt

• Een typefout in de hostnaam. Verreweg de meest voorkomende oorzaak, en degene die iedereen als laatste controleert.
• Het domein is niet geregistreerd, of het is verlopen. Een verlopen domein wordt meestal binnen enkele uren na het einde van de respijtperiode uit de zone gehaald.
• Geen nameserverdelegatie. Het domein bestaat bij de registrar maar heeft geen NS-records die naar een DNS-provider wijzen, dus heeft de bovenliggende zone niets om een resolver naar te verwijzen.
• Het record is verwijderd of hernoemd. Een ontbrekend A- of CNAME-record voor www geeft NXDOMAIN voor www.example.com terwijl het kale domein nog werkt.
• Een wijziging heeft uw resolver nog niet bereikt. Nieuwe records duren tot de TTL van het vorige record om overal te verschijnen.
• Een gecachet negatief antwoord op uw apparaat, in uw browser, of bij de resolver van uw provider.
• Een regel in het hosts-bestand die de naam ergens naartoe wijst dat niet meer bestaat, of een overgebleven regel van een oude test.
• VPN-, proxy- of filtersoftware die zelf DNS beantwoordt en de naam blokkeert of niet kan oplossen.
• Een hostnaam die alleen op een privénetwerk bestaat waarmee u nu niet verbonden bent, zoals een intern .local- of bedrijfsdomein.

Hoe u het oplost

Typ het adres eerst opnieuw in, en werk dan van uw browser naar buiten toe, richting uw netwerk. Test na elke stap in plaats van ze allemaal achter elkaar uit te voeren.

Browser

1. Open dezelfde URL in een privévenster. Laadt hij daar wel, dan is een extensie of een cookie in het spel, niet DNS.
2. Wis Chrome's eigen resolvercache op chrome://net-internals/#dns, en leeg daarna de socketpools op chrome://net-internals/#sockets. Chrome houdt een cache apart van het besturingssysteem bij, dus een OS-flush alleen verandert vaak niets.

Windows

1. Leeg de resolvercache: ipconfig /flushdns
2. Vernieuw de netwerklease, wat ook DNS-servers oppikt die via DHCP worden uitgedeeld:

   ipconfig /release
   ipconfig /renew

3. Herstart de cachingservice als een flush niet blijft hangen:

   net stop dnscache
   net start dnscache

4. Controleer C:\Windows\System32\drivers\etc\hosts op een regel met de domeinnaam en verwijder deze als hij verouderd is.
5. Stel een openbare resolver in: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
6. Reset de netwerkstack als laatste redmiddel, en herstart daarna: netsh winsock reset

macOS

1. Leeg de cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Bekijk welke servers in gebruik zijn: scutil --dns | grep nameserver
3. Wijs de interface naar een openbare resolver: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Inspecteer /etc/hosts en verwijder elke regel voor het domein.

Linux

1. Bij systemd-resolved: sudo resolvectl flush-caches, bevestig daarna de gebruikte servers met resolvectl status.
2. Bij dnsmasq: sudo systemctl restart dnsmasq. Bij nscd: sudo systemctl restart nscd.
3. Lees /etc/resolv.conf om te zien welke resolver u bevraagt, en /etc/hosts voor een verouderde override.
4. Wijzig met NetworkManager de resolver op de verbinding zelf:

   nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
   nmcli con up "Wired connection 1"

Router

1. Start de router opnieuw op. De meeste consumentenrouters draaien een kleine doorstuurresolver met een eigen cache, en een herstart wist die.
2. Kijk in de beheerpagina van de router naar de WAN- of DHCP-DNS-servers. Wijzen die naar een oude interne server of een filterdienst, vervang ze dan.
3. Test met een telefoon op mobiele data in plaats van wifi. Wordt de naam daar wel opgelost, dan zit de fout binnen uw eigen netwerk.

Als u de eigenaar van het domein bent

NXDOMAIN op uw eigen site is een publicatieprobleem, en er zijn maar een paar plekken waar het vandaan kan komen. Controleer eerst de registratiestatus en de vervaldatum. Bevestig daarna de delegatie, de stap die mensen overslaan:

dig NS example.com +short
dig example.com +trace

Een leeg NS-antwoord betekent dat de bovenliggende zone geen delegatie heeft, dus kan geen enkele resolver uw DNS-provider bereiken, ongeacht welke records u daar heeft aangemaakt. De uitvoer van +trace toont de doorverwijzingsketen en de exacte stap waar hij stopt. Is de delegatie in orde, bevraag dan rechtstreeks de nameserver van uw provider om te bevestigen dat het record bestaat in de zone die u aan het bewerken bent:

dig @ns1.example-dns.net www.example.com A

Als u een ontbrekend record toevoegt, blijft het oude negatieve antwoord elders gecachet zolang het SOA-minimum toestaat, geef het dus die tijd voordat u concludeert dat de oplossing niet werkte.

Controleer het van buitenaf

Elke oplossing hierboven verandert alleen uw eigen machine. Geen enkele vertelt u of de naam voor anderen wel oplost, en dat wilt u als eerste weten. Voer de query uit tegen twee openbare resolvers en vergelijk:

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

nslookup example.com 8.8.8.8

Geeft uw standaardresolver niets terug en 1.1.1.1 wel een adres, dan bestaat het record en houdt uw resolver een verouderd negatief antwoord vast of filtert hij de naam. Geeft elke resolver niets terug, dan ontbreekt het record werkelijk.

Twee resolvers dekken nog steeds maar één uitkijkpunt, en DNS-antwoorden verschillen vaker per regio dan mensen verwachten. Voer de DNS-querycontrole uit om de naam vanaf controlepunten in meerdere landen tegelijk op te lossen en te lezen wat elk teruggaf. Een verdeeld resultaat, waarbij sommige locaties wel en andere niet antwoorden, wijst op een wijziging die zich nog verspreidt of op een nameserver van één provider die vanaf een deel van het internet onbereikbaar is. Dat aflezen over de tijd heet DNS-propagatie, met een eigen handleiding over hoe u DNS-propagatie controleert.

Een naam betrappen die stopt met resolven

Een record dat verdwijnt, laat geen spoor achter aan uw kant. Niets logt het, omdat er nooit een verzoek binnenkomt, en het enige teken is een verkeersgrafiek die daalt. De oplossing is in elk geval een opzoeking die volgens een schema loopt vanaf ergens anders dan uw kantoor. HostTracker bewaakt websites sinds 2004 en voert nu controles uit vanaf 300+ controlepunten in 158 steden, met waarschuwingen via e-mail, sms, spraakoproep, Slack, Telegram en meer wanneer een naam stopt met resolven of met het verkeerde adres begint te antwoorden. De andere handleidingen in dit onderdeel staan in de fix-cluster, en de twee die het dichtst bij deze staan zijn DNS-server reageert niet, voor wanneer de resolver helemaal niet antwoordt, en hoe u een trage DNS-opzoeking oplost, voor wanneer hij wel antwoordt maar er te lang over doet.