Er is iets stuk. De site laadt niet, mail bounct, of je hebt een uur geleden een record gewijzigd en er gebeurt niets. Negen van de tien keer zit het antwoord in de DNS — je moet alleen weten waar je moet kijken.
DNS is het adresboek van internet: het maakt van example.com een IP waarmee je browser echt verbinding kan maken. Als het hapert, lijkt alles erachter kapot terwijl de server prima werkt. Laten we doornemen hoe je het goed leest.
De records die je moet kennen
Je hoeft ze niet allemaal uit je hoofd te kennen. Dit zijn degene die langskomen:
| Record | Wat het doet | Wanneer het bijt |
|---|---|---|
| A | Koppelt een naam aan een IPv4-adres | Site wijst naar de verkeerde/oude server |
| AAAA | Hetzelfde, maar IPv6 | IPv6-gebruikers bereiken je niet |
| MX | Waar de e-mail van het domein heen gaat | Mail bounct of verdwijnt |
| TXT | Vrije tekst — SPF, DKIM, verificatie | Mail belandt in spam; verificatie faalt |
| NS | Welke nameservers gezaghebbend zijn | Het hele domein lost verkeerd op |
| CNAME | Een alias die de ene naam naar de andere wijst | Een subdomein lost niet op |
| SOA | Beheermetadata van de zone | Zelden — maar noemt de primaire NS |
| CAA | Welke CA's je certificaten mogen uitgeven | Certificaatuitgifte wordt geweigerd |
Onze DNS-lookuptool bevraagt alle tien typen die hij ondersteunt — A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV en PTR — tegen de resolver van jouw keuze: Google (8.8.8.8), Cloudflare (1.1.1.1) of Quad9 (9.9.9.9), en toont de ruwe dig-achtige uitvoer met TTL's intact. Je leest precies wat een sysadmin in een terminal ziet.
Zie je een A-record dat naar een onbekend IP wijst? IP WHOIS vertelt je in seconden van wie het is.
TTL: het getal dat iedereen negeert tot het ertoe doet
Elk record draagt een TTL — time to live, in seconden. Het is hoe lang resolvers het antwoord mogen cachen voordat ze opnieuw vragen. Een TTL van 3600 betekent: „vertrouw dit een uur."
Dit ene getal verklaart de meeste „mijn DNS-wijziging werkt niet"-paniek. Een simpel voorbeeld: je herstelt om 12:00 een A-record, maar de TTL ervan is 86400 (een volle dag). Resolvers die je domein om 11:30 hebben bevraagd, blijven bijna 24 uur langer het oude IP teruggeven — dus voor sommige gebruikers „verhuist" de site pas de volgende dag. Er ging niets stuk; je hebt ze alleen verteld dat ze dat antwoord een dag mochten cachen.
De vuistregel die wij volgen: verlaag de TTL een dag van tevoren voordat je een record wilt wijzigen. Zet hem op 300 seconden, wacht tot de oude hoge TTL verloopt, en maak dan de wijziging. Nu verspreidt de omschakeling zich in minuten in plaats van een dag. Zet hem daarna weer hoog, zodat resolvers niet voortdurend je nameservers opnieuw bevragen.
„Ik heb het gewijzigd — waarom is het niet live?"
Omdat DNS geen verversknop heeft. Er is geen centrale server om naar te pushen. Je gezaghebbende nameserver heeft de nieuwe waarde meteen — maar elke resolver die de oude al cachte, blijft die serveren tot zijn TTL afloopt. En verschillende resolvers, in verschillende landen, verlopen op verschillende momenten.
Precies daarom hebben we de DNS-propagatiechecker gebouwd zoals hij is. In plaats van één resolver te vragen en het daarbij te laten, vuurt hij dezelfde query parallel af op 15 publieke resolvers verspreid over de wereld — Google en Cloudflare in de VS, Quad9 in Zwitserland, Mullvad in Zweden, CZ.NIC in Tsjechië, Alibaba en DNSPod in China, en meer. Je ziet het nieuwe record regio voor regio oplichten terwijl de caches verlopen. Als alle 15 het eens zijn, ben je echt gepropageerd.
Vuistregel: „propagatie" is niet het internet dat traag is. Het zijn caches die de TTL respecteren die jij hebt ingesteld.
Wanneer de resolver zelf het probleem is
Soms zijn de records overal correct en lost de site toch traag op. Dat wijst op resolverlatentie, niet op recordwaarden.
Onze DNS-responstijdtool meet precies dat: hij draait dig tegen diezelfde 15 resolvers, meerdere keren per stuk, en rapporteert de minimum-, maximum- en gemiddelde querytijd per resolver. Zitten je gebruikers in Duitsland en antwoorden je nameservers Frankfurt in 8 ms maar Sydney in 280 ms, dan is dat een echt, meetbaar signaal — misschien tijd voor een anycast-DNS-provider.
Wie de zone beheert: WHOIS en nameservers
Zien de NS-records er verkeerd uit, dan wordt de vraag wie ze heeft ingesteld. Domain WHOIS geeft je de registrar, de registratie- en verloopdatums, de statuscodes van het domein, of DNSSEC aan staat en — cruciaal — de nameservers die de registry op naam heeft.
Eén ding is het waard te weten, want goedkopere tools doen het fout: veel nieuwere extensies zoals .tools, .app en .dev draaien helemaal geen traditionele WHOIS-server. Bevraag ze op de oude manier en je krijgt niets terug. Onze lookup valt automatisch terug op RDAP — de moderne JSON-gebaseerde vervanger — zodra hij een dunne of ontbrekende WHOIS-respons detecteert, zodat een .tools-domein hetzelfde gestructureerde resultaat teruggeeft als een .com. We liepen hier trouwens tegenaan op ons eigen domein. De fix werd een feature.
Komen de nameservers bij de registry niet overeen met wat je bij je DNS-host hebt ingesteld, dan heb je je bug gevonden: het domein wijst compleet ergens anders heen, en geen enkele recordwijziging helpt tot de NS-delegatie is gerepareerd.
Een snelle checklist als DNS „niet werkt"
- Zoek het record op dat je wijzigde met de lookuptool. Staat de nieuwe waarde er überhaupt?
- Check de TTL. Hoog? Je wacht gewoon op het verlopen van de cache.
- Doe een propagatiecheck. Gemengde resultaten over regio's = caches verlopen nog; overal consistent = het is live.
- Verifieer de NS-records tegen je DNS-host met WHOIS. Een delegatiemismatch is vaker de echte boosdoener dan je zou denken.
- Nog steeds traag? Meet de responstijd van de resolver voordat je je app de schuld geeft.
Kort samengevat
De meeste DNS-„storingen" zijn geen storingen. Het zijn TTL's die precies doen wat jij ze opdroeg, of een delegatie die ergens heen wijst dat je was vergeten. Lees de records, respecteer de TTL, en check de propagatie over meer dan één resolver voordat je iets concludeert. Begin met een lookup — het antwoord staat meestal gewoon in de uitvoer.
— het checkbox.tools-team