DNS problemen oplossen met dig, nslookup en meer

DNS is het telefoonboek van het internet: het vertaalt een domeinnaam zoals jouwdomein.nl naar het IP-adres van de server erachter. Gaat daar iets mis, dan is je website of e-mail ineens onbereikbaar terwijl er ogenschijnlijk niets is veranderd. In dit artikel leer je de meest voorkomende DNS problemen oplossen: van een domein dat niet resolvet en een verkeerd IP-adres na een serverwissel tot trage propagatie en de foutmeldingen NXDOMAIN en SERVFAIL. Je diagnosticeert elk probleem zelf met de gratis tools dig en nslookup, zodat je precies weet waar het misgaat en hoe je het herstelt.

Hoe DNS werkt, en waarom er dingen misgaan

Je domein heeft een verzameling DNS-records die bij je nameservers staan. Die nameservers zijn autoritatief: zij hebben het laatste woord over jouw zone. Elk record heeft een eigen taak. Het A-record koppelt je domein aan een IPv4-adres, de NS-records wijzen naar de nameservers die de baas zijn over je zone, het MX-record bepaalt welke mailserver je e-mail ontvangt, en een CNAME-record laat de ene naam naar een andere naam verwijzen.

De rest van het internet praat niet rechtstreeks met jouw nameservers. Daartussen zitten resolvers: de DNS-servers van je provider, van je bedrijf of publieke resolvers zoals die van Google (8.8.8.8) en Cloudflare (1.1.1.1). Zo'n resolver zoekt een record een keer op en bewaart het antwoord in zijn cache voor de duur van de TTL. TTL staat voor time to live: het aantal seconden dat een antwoord bewaard mag blijven voordat het opnieuw wordt opgehaald.

Daar komt bijna elk DNS-probleem vandaan. Er zijn namelijk twee soorten antwoorden. Het autoritatieve antwoord komt rechtstreeks van je eigen nameservers en is altijd actueel. Het antwoord uit de cache komt van een resolver die misschien nog de oude waarde vasthoudt tot de TTL verloopt. Bij het oplossen van DNS problemen draait bijna alles om het verschil tussen die twee: klopt de waarde bij de bron al, en zit het internet er alleen nog achteraan te lopen?

dig en nslookup: je twee belangrijkste tools

Om DNS-problemen te diagnosticeren vraag je records rechtstreeks op. Daarvoor gebruik je dig (op macOS en Linux) of nslookup (standaard aanwezig op Windows). Vervang jouwdomein.nl in de voorbeelden hieronder door je eigen domein.

dig gebruiken (macOS en Linux)

dig geeft je gedetailleerde controle. De belangrijkste varianten:

dig jouwdomein.nl A +short          # snel het IPv4-adres opvragen
dig jouwdomein.nl                    # volledige uitvoer met status en secties
dig @8.8.8.8 jouwdomein.nl +short    # wat een publieke resolver nu teruggeeft (mogelijk uit cache)
dig @ns1.ljpc.network jouwdomein.nl +short   # het autoritatieve antwoord, rechtstreeks van de nameserver
dig MX jouwdomein.nl +short          # de mailservers
dig NS jouwdomein.nl +short          # de nameservers van je domein
dig +trace jouwdomein.nl             # volg de delegatie vanaf de root omlaag

Kijk in de volledige uitvoer naar twee dingen. De regel met status: vertelt of de opvraging slaagde (NOERROR) of faalde (NXDOMAIN of SERVFAIL). De ANSWER SECTION bevat de gevonden records. Zie je de records wel bij @ns1.ljpc.network maar nog niet bij @8.8.8.8, dan klopt je zone al en is het puur een kwestie van wachten tot de cache verloopt.

nslookup gebruiken (Windows)

Op Windows werkt nslookup vergelijkbaar. Open de opdrachtprompt en gebruik:

nslookup jouwdomein.nl                   # het IP-adres via je standaardresolver
nslookup -type=MX jouwdomein.nl          # de mailservers
nslookup -type=NS jouwdomein.nl          # de nameservers
nslookup jouwdomein.nl 8.8.8.8           # vraag het expliciet aan een specifieke resolver
nslookup jouwdomein.nl ns1.ljpc.network  # vraag het autoritatieve antwoord op

De melding "Non-authoritative answer" is normaal: die betekent alleen dat het antwoord uit de cache van een resolver komt en niet rechtstreeks van je nameserver. Wil je het autoritatieve antwoord, vraag het dan direct aan je nameserver, zoals in de laatste regel hierboven.

Autoritatief versus uit de cache

Wil je niet zelf vanaf de commandoregel werken, dan is whatsmydns.net een handige online tool. Die bevraagt je record vanaf tientallen locaties wereldwijd en laat in een oogopslag zien waar de nieuwe waarde al is doorgekomen en waar nog niet. Precies wat je wilt weten bij een wijziging die nog aan het propageren is.

De meest voorkomende DNS-problemen oplossen

Je domein resolvet helemaal niet (NXDOMAIN)

Krijg je NXDOMAIN terug, dan zegt DNS dat de naam niet bestaat. Loop deze punten na:

1. Staat de domeinnaam nog geregistreerd en is hij niet verlopen? Een verlopen domein kan uit DNS vallen.
2. Wijzen de nameservers bij je registrar naar de juiste servers? Controleer met dig NS jouwdomein.nl +short of daar de verwachte nameservers staan.
3. Bestaat de opgevraagde naam eigenlijk wel? Vraag je bijvoorbeeld www.jouwdomein.nl op terwijl daar helemaal geen record voor is aangemaakt, dan bestaat die naam niet en is NXDOMAIN terecht.
4. Test met dig +trace jouwdomein.nl waar de keten breekt. Loopt de trace netjes van de root naar je nameservers, dan zit de delegatie goed.

Verkeerd IP-adres na een serverwissel

Je hebt het A-record naar een nieuwe server gezet, maar bezoekers of jijzelf komen nog op de oude server uit. In vrijwel alle gevallen is dit caching. Op meerdere plekken kan nog het oude adres staan: in de cache van je resolver, in de DNS-cache van je besturingssysteem en soms in je browser.

Stel eerst vast waar het misgaat. Vergelijk het autoritatieve antwoord met dat van een publieke resolver:

dig @ns1.ljpc.network jouwdomein.nl +short   # dit hoort het nieuwe IP te zijn
dig @8.8.8.8 jouwdomein.nl +short            # dit kan nog het oude IP zijn

Geeft je nameserver het nieuwe adres en een publieke resolver nog het oude, dan is je zone in orde en is het wachten tot de TTL verloopt. Zie je lokaal het oude adres terwijl publieke resolvers al bij zijn, leeg dan je eigen DNS-cache (zie verderop). Plan je een verhuizing vooruit, verlaag dan de TTL van het record een dag van tevoren, bijvoorbeeld naar 300 seconden, zodat de wisseling daarna snel doorkomt.

E-mail komt nog bij de oude server aan (MX wijst verkeerd)

Na een migratie van je e-mail kan post nog een tijdje bij de oude mailserver binnenkomen. Dezelfde oorzaak, ander record. Verzendende mailservers gebruiken het MX-record en houden dat vast tot hun cache verloopt. Controleer de huidige waarde met dig MX jouwdomein.nl +short en vergelijk het autoritatieve antwoord met dat van een publieke resolver, net als bij het A-record. Zolang de oude waarde nog ergens in een cache zit, blijft een deel van je e-mail naar de oude server gaan. Verlaag daarom ook hier de TTL ruim voor de verhuizing en houd de oude mailbox nog even bereikbaar tot alle caches zijn ververst.

Je wijziging is nog niet zichtbaar (propagatie duurt lang)

Propagatie is eigenlijk een misleidend woord. Er wordt niets actief rondgestuurd of gepusht. Je nameserver heeft de nieuwe waarde meteen, maar resolvers elders geven het oude antwoord terug tot hun bewaartermijn, de TTL, is verlopen. Daarna halen ze de nieuwe waarde vanzelf op.

Hoe lang dat duurt, hangt dus af van de TTL en van hoe lang geleden een resolver het record voor het laatst ophaalde. In de praktijk is een wijziging vaak binnen enkele minuten tot een paar uur overal zichtbaar, maar reken op maximaal 24 tot 48 uur voordat echt elke resolver bij is. Volg de voortgang wereldwijd via whatsmydns.net, of vraag het record op bij verschillende publieke resolvers met dig @8.8.8.8 jouwdomein.nl +short en dig @1.1.1.1 jouwdomein.nl +short.

SERVFAIL: de resolver komt er niet uit

SERVFAIL betekent dat de resolver geen geldig antwoord kon samenstellen. Anders dan NXDOMAIN gaat het niet om een naam die niet bestaat, maar om iets dat onderweg misgaat. De twee bekendste oorzaken:

• Een DNSSEC-probleem. Als een zone is ondertekend maar de handtekeningen verlopen zijn of het DS-record bij de registry niet meer klopt, weigert een validerende resolver het antwoord met SERVFAIL. Test dit met dig +cd jouwdomein.nl. De vlag +cd (checking disabled) zet DNSSEC-validatie uit. Werkt de opvraging daarmee ineens wel, dan wijst dat sterk op DNSSEC.
• Onbereikbare of onjuist gedelegeerde nameservers. Reageren je nameservers niet, of wijst de delegatie bij je registrar naar servers die je zone niet kennen, dan levert dat ook SERVFAIL op. Vraag de nameservers rechtstreeks op met dig @ns1.ljpc.network jouwdomein.nl om te zien of de bron zelf antwoordt.

Snelle diagnose per symptoom

DNS-cache legen op je eigen apparaat

Zie je lokaal nog een oude waarde terwijl de rest van het internet al bij is, dan zit het antwoord vast in de cache van je eigen computer. Die leeg je zo:

• Windows: open de opdrachtprompt en voer ipconfig /flushdns uit.
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
• Linux met systemd-resolved: sudo resolvectl flush-caches.

Dit wist alleen de cache op je eigen apparaat, niet die van je provider of van publieke resolvers. Houdt je browser vast aan het oude adres, sluit hem dan volledig af en open hem opnieuw.

DNS beheren bij LJPc hosting

Bij LJPc hosting beheer je je DNS-records in Plesk, het controlepaneel van je hostingpakket. Sla je daar een wijziging op, dan wordt die direct doorgevoerd op onze nameservers ns1.ljpc.network, ns2.ljpc.network en ns3.ljpc.network. Vanaf dat moment geven onze nameservers meteen de nieuwe waarde terug.

Zie je elders toch nog even de oude waarde, dan komt dat puur door de caching bij tussenliggende resolvers, precies zoals hierboven beschreven. Wil je zeker weten dat het aan onze kant goed staat, vraag het dan rechtstreeks op met dig @ns1.ljpc.network jouwdomein.nl. De standaard-TTL is bij ons een uur. Plan je een migratie, verlaag de TTL van de betrokken records dan een dag van tevoren zodat de overstap snel zichtbaar is. Kom je er niet uit, dan kijkt onze support met je mee.

Kom je er met deze stappen niet uit, neem dan contact op met support. Vermeld welk domein en welk record het betreft en wat dig of nslookup teruggeeft, dan is het snel te herleiden.