DNS troubleshooting: nslookup, dig, DoH

Kort: DNS-problemen behoren tot de meest voorkomende en moeilijkst te diagnosticeren oorzaken van uitval - omdat "DNS werkt voor mij" niet betekent dat het werkt voor je klanten. Hier is een overzicht van praktische tools en procedures.

Meest voorkomende DNS-problemen

• Domeinregistratie verlopen - de hele DNS stopt met werken.
• Verkeerd A/AAAA-record - na servermigratie vergeten te updaten.
• Ontbrekende CNAME / MX - email werkt niet, terwijl web wel werkt.
• TTL niet voorbereid op snelle wijzigingen - caches van providers serveren nog oude data.
• DNSSEC-fout - validators wijzen ongetekende of fout getekende records af.
• Geo-DNS-storing - resolver van een bepaalde regio krijgt verkeerd antwoord.

nslookup: het eenvoudigste commando

Beschikbaar op alle OS zonder installatie. Gebruikt de standaard DNS-server van het systeem, maar kan expliciet als tweede argument worden opgegeven.

$ nslookup epulz.io
Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:      epulz.io
Address:   87.197.115.180

# Expliciet Cloudflare DNS gebruiken
$ nslookup epulz.io 1.1.1.1

# Specifiek recordtype
$ nslookup -type=MX gmail.com 8.8.8.8
$ nslookup -type=TXT _dmarc.epulz.io 1.1.1.1

dig: gedetailleerde DNS-query voor Unix

dig (Domain Information Groper) is aanzienlijk gedetailleerder en flexibeler. Onderdeel van het pakket bind-utils of dnsutils.

$ dig epulz.io

;; QUESTION SECTION:
;epulz.io.                      IN      A

;; ANSWER SECTION:
epulz.io.               300     IN      A       87.197.115.180

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: ...

Sleutelvelden:

• TTL (300) = seconden die de resolver het antwoord mag cachen.
• ANSWER SECTION = het resultaat.
• SERVER = welke DNS-resolver antwoordde.
• Query time = duur - handig bij debuggen van trage DNS.

Praktische commando's

# Beknopt antwoord (alleen IP)
$ dig +short epulz.io
87.197.115.180

# Alle records
$ dig epulz.io ANY

# Trace van de hele DNS-hiërarchie (vanaf root nameservers)
$ dig +trace epulz.io

# Reverse lookup
$ dig -x 87.197.115.180

# Specifieke resolver
$ dig @8.8.8.8 epulz.io
$ dig @1.1.1.1 epulz.io
$ dig @9.9.9.9 epulz.io

# DNSSEC-validatie
$ dig +dnssec epulz.io

DNS-over-HTTPS (DoH): wanneer je geen UDP/53 hebt

In sommige netwerken (corporate firewalls, mobiele data met blokkering) is de traditionele DNS-poort 53 geblokkeerd. DoH pakt DNS-queries in HTTPS-requests - gaan overal door waar 443 werkt.

# Cloudflare DoH-endpoint
$ curl -s "https://cloudflare-dns.com/dns-query?name=epulz.io&type=A" \
       -H "Accept: application/dns-json" | jq

# Google DoH
$ curl -s "https://dns.google/resolve?name=epulz.io&type=MX" | jq

Een online DoH-client met mooie UI hebben we ook op - geen installatie nodig.

Procedure voor "domein werkt niet"

1. Controleer de registratie. whois yourdomain.com of via de registrar. Als verlopen, kan niets anders worden gerepareerd.
2. Controleer NS-records. dig NS yourdomain.com @8.8.8.8. Worden de nameservers die verantwoordelijk zijn voor het domein teruggegeven? Komen ze overeen met wat je in het registrarpaneel hebt?
3. Controleer A-record. dig yourdomain.com @8.8.8.8. Geeft het de juiste IP terug?
4. Test vanuit extern netwerk (mobiele data, VPN, online tool). Je hebt mogelijk zelf oude data in cache.
5. Controleer TTL. Als je net een record hebt gewijzigd, wacht minstens de oorspronkelijke TTL (standaard 1-24 uur).
6. Controleer DNSSEC. Als je het gebruikt, kan de signature-keten kapot zijn. dig +dnssec yourdomain.com toont de ad-flag bij succes.

DNS-propagatie: hoe lang duurt het?

"DNS-propagatie" is een enigszins misleidende term. DNS propageert niet naar jou toe - je resolvers downloaden het antwoord en cachen het volgens TTL. Pas na het verlopen van TTL proberen ze een nieuwe query.

Praktische gevolgen:

• Plan je een migratie? Verlaag de TTL naar 60-300 seconden minstens 48 uur van tevoren.
• Het oude IP blijft geldig voor sommige clients lang na de wijziging. Schakel de oude server niet onmiddellijk uit.
• Cloud providers (Cloudflare, AWS Route 53) hebben snelle TTL en cache invalidation, maar de eindclient moet nog steeds wachten op de TTL van zijn eigen resolver.

Conclusie

DNS is de infrastructuurlijm die iedereen vanzelfsprekend vindt - totdat het stopt met werken. Regelmatige monitoring van DNS-records (A, NS, MX, hun TTL en DNSSEC-validatie) onthult het probleem voordat een klant het telefonisch meldt.

Monitoring van DNS en WHOIS-verloop

ePulz.io volgt A/AAAA/MX/NS-records en het verloop van de domeinregistratie. 7 dagen gratis.

Monitoring starten →