20 DNS-beveiligingschecks die elk domein moet doorstaan

De meeste inbreuken op domeinen beginnen niet met een gestolen wachtwoord, maar met een DNS-misconfiguratie die niemand heeft opgemerkt. Een domein doorstaat een serieuze DNS-beveiligingsreview als de DNSSEC-keten valideert, het CAA-record bepaalt welke CA's certificaten mogen uitgeven, de SPF-, DKIM- en DMARC-records correct zijn afgebakend en worden afgedwongen, en de nameservers en zone geen dangling records of open zonetransfers bevatten. Hieronder vind je 20 concrete checks die je op elk domein kunt uitvoeren, ingedeeld per categorie en met voorbeelden die je zo kunt kopiëren.

Waarom een DNS-beveiligingschecklist belangrijk is

DNS ligt onder alles: e-mailbezorging, de uitgifte van TLS-certificaten en het resolven van je website. Eén verouderd CNAME-record of een ontbrekend CAA-record kan een aanvaller in staat stellen een subdomein over te nemen of een frauduleus certificaat voor je domein te laten uitgeven, zonder ooit aan je servers te komen. Met een vaste checklist vang je de saaie maar ingrijpende problemen op die bij ad-hocaudits over het hoofd worden gezien.

DNSSEC-checks (1–2)

1. DNSSEC is ingeschakeld en de chain of trust valideert. DNS Security Extensions (DNSSEC) ondertekenen je zone, zodat resolvers kunnen verifiëren dat records onderweg niet zijn gemanipuleerd. Controleer of het DS-record van je domein bij de registrar overeenkomt met de DNSKEY die in je zone is gepubliceerd. Een mismatch levert SERVFAIL op bij elke validerende resolver, waardoor je site ongemerkt onbereikbaar wordt voor beveiligingsbewuste netwerken. Controleer dit met dig +dnssec yourdomain.com of via onze DNS-lookuptool.

2. NSEC3 wordt gebruikt in plaats van gewone NSEC. Met standaard NSEC-antwoorden kan iedereen door je zone "lopen" en elke recordnaam erin opsommen, waarmee je een aanvaller gratis verkenningsinformatie geeft. NSEC3 hasht de namen in denial-of-existence-antwoorden, zodat het opsommen van je zone niet triviaal is. Ondersteunt je DNS-provider het, kies dan voor NSEC3.

CAA-record controleren (3)

3. Een CAA-record beperkt welke Certificate Authorities certificaten voor je domein mogen uitgeven. Zonder een Certificate Authority Authorization-record (CAA) kan elke publieke CA een certificaat voor je domein uitgeven als die wordt misleid of gecompromitteerd. Publiceer er een om de uitgifte af te schermen:

yourdomain.com.  IN  CAA  0 issue "letsencrypt.org"
yourdomain.com.  IN  CAA  0 issuewild ";"
yourdomain.com.  IN  CAA  0 iodef "mailto:security@yourdomain.com"

Dit voorbeeld staat alleen Let's Encrypt toe om standaardcertificaten uit te geven, blokkeert alle wildcarduitgifte en vertelt CA's waar ze pogingen tot overtreding moeten melden. Wil je meer weten over hoe uitgifte en de vertrouwensketen precies werken, lees dan SSL-certificaten uitgelegd.

E-mailauthenticatie controleren: SPF, DKIM en DMARC (4–7)

4. SPF heeft precies één TXT-record en blijft onder de limiet van 10 lookups. Sender Policy Framework (SPF) is gedefinieerd in RFC 7208. Twee SPF-TXT-records op hetzelfde domein is op zichzelf al een foutsituatie, en meer dan 10 mechanismen die een DNS-lookup veroorzaken (include, a, mx, ptr, exists, redirect) leveren een permanente fout op waardoor de hele check kan mislukken. Valideer je record met de SPF-generator en lees zo maak je een veilig SPF-record als je het aantal lookups moet terugbrengen.

5. DKIM-sleutels zijn minimaal 2048-bit en gebruiken geen rsa-sha1. DomainKeys Identified Mail (DKIM, RFC 6376) ondertekent uitgaande mail, zodat ontvangers kunnen controleren dat die niet is gewijzigd. RFC 8301 heeft het rsa-sha1-algoritme verouderd verklaard en raadt RSA-sleutels van 2048 bits of meer aan. 1024-bit-sleutels zijn legacy en moeten worden vervangen.

6. DMARC is gepubliceerd met handhaving, niet alleen voor monitoring. Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) gebruikt een p=-tag met de waarde none, quarantine of reject. Een domein dat voor onbepaalde tijd op p=none blijft staan, krijgt wel rapportages maar geen daadwerkelijke bescherming tegen spoofing. Stap over op quarantine of reject zodra je rua-aggregaatrapporten een schone SPF/DKIM-alignment laten zien. Maak of controleer een record met de DMARC-generator.

7. De DMARC-alignmentmodus komt overeen met wat je wilt. De tags adkim/aspf bepalen of de SPF- en DKIM-domeinen exact moeten overeenkomen met het domein in de From:-header (s, strict) of alleen hetzelfde organisatiedomein moeten delen (r, relaxed, de standaard). Relaxed alignment volstaat voor de meeste configuraties, maar controleer het als je vanaf veel subdomeinen verstuurt.

Nameservers en zonehygiëne controleren (8–14)

8. NS-records komen overeen tussen de registrar en de zone. Als de nameservers bij je registrar niet overeenkomen met wat daadwerkelijk in de zone wordt geserveerd, kan de resolutie inconsistent of gesplitst raken, afhankelijk van welk record een resolver vertrouwt.

9. Glue records zijn correct voor in-bailiwick-nameservers. Zijn je nameservers subdomeinen van het domein zelf (bijv. ns1.yourdomain.com), dan heeft de bovenliggende zone glue records nodig die rechtstreeks naar hun IP-adressen verwijzen. Anders kan de resolutie in een lus raken of mislukken.

10. Zonetransfers (AXFR) zijn beperkt tot geautoriseerde secundaire servers. Een open zonetransfer geeft je volledige DNS-zone aan iedereen die erom vraagt. Test dit van buitenaf:

dig axfr yourdomain.com @ns1.yourdomain.com

Krijg je hiermee van buiten je infrastructuur je volledige set records terug, sluit het dan direct af. Een transfer mag alleen slagen voor je eigen geregistreerde secundaire servers.

WarningEen open AXFR-antwoord is een van de snelste manieren voor een aanvaller om al je subdomeinen, mailservers en interne hostnamen in kaart te brengen. Behandel elke geslaagde externe zonetransfer als een kritieke bevinding.

11. Er zijn geen dangling records die naar opgeheven resources verwijzen. Een CNAME die nog naar een verwijderde cloudopslagbucket, load balancer of SaaS-endpoint verwijst, is een klassieke route voor subdomain takeover. Controleer elk CNAME- en A-record tegen wat er daadwerkelijk nog is ingericht. Onze gids over DNS-recordtypes is een handig naslagwerk om tijdens zo'n audit na te gaan wat elk record hoort te doen.

12. Wildcardrecords zijn bewust ingesteld en geen restanten. Een *.yourdomain.com-record vangt elk niet-geregistreerd subdomein op. Daardoor kunnen phishing-lookalikes ongemerkt naar je infrastructuur resolven of typfouten legitiem lijken. Verwijder wildcards die je niet bewust hebt geconfigureerd.

13. TTL's zijn afgestemd en niet op de standaardwaarden gelaten. De time to live (TTL) bepaalt hoe lang resolvers een record cachen. Is die te hoog, dan kun je tijdens een incident niet snel failoveren; is die te laag, dan veroorzaak je onnodige querybelasting. Een paar honderd tot een paar duizend seconden is voor de meeste records een redelijke basis, die je verlaagt voorafgaand aan geplande wijzigingen.

14. Nameservers zijn geografisch en topologisch gespreid. Draaien al je gezaghebbende nameservers op één netwerk of bij één provider, dan haalt één storing je hele domein offline. Spreid ze over onafhankelijke netwerken of ASN's.

Operationele checks en monitoring (15–20)

15. Reverse DNS (PTR) is ingesteld voor elk IP-adres dat mail verstuurt. Veel ontvangende mailservers weigeren mail van IP-adressen zonder bijbehorend PTR-record of markeren die als spam, en het is een basaal signaal tegen spoofing.

16. Transfer lock en 2FA zijn ingeschakeld bij de registrar. Een transfer lock voorkomt dat je domein zonder toestemming naar een andere registrar wordt verhuisd, en tweefactorauthenticatie (2FA) op het account voorkomt overnames via credential stuffing.

17. Toegang tot de DNS-provider wordt beheerd en gelogd. Iedereen met schrijfrechten op je zone kan verkeer of e-mail omleiden. Gebruik rollen met minimale rechten en controleer of wijzigingen aan records in een auditlog worden vastgelegd.

18. Certificate Transparency-logs worden gemonitord op frauduleuze uitgifte. Elk publiek vertrouwd certificaat wordt vastgelegd in Certificate Transparency-logs (CT). Door de CT-logs voor je domein in de gaten te houden, zie je direct wanneer er zonder jouw medeweten een certificaat is uitgegeven, zelfs door een goedgekeurde CA.

19. Verloopdata van domein en DNSSEC-sleutels worden proactief bijgehouden. Een verlopen domein of een niet-geroteerde DNSSEC-ondertekeningssleutel haalt allebei een live site offline. Lees onze gids over hoe je een verlopend domein bemachtigt voor wat er gebeurt als je de termijn mist.

20. De DNS-gezondheid wordt volgens schema gecontroleerd, niet alleen na een incident. Voer regelmatig een volledige lookupronde uit (A, AAAA, MX, TXT, NS, CAA) op je live zone, in plaats van alleen wanneer er iets kapotgaat. Combineer dit met uptime- en certificaatmonitoring, zodat een storing op DNS-niveau direct zichtbaar wordt. Lees websitemonitoring uitgelegd om te zien hoe dat samenhangt.

Overzichtstabel DNS-beveiligingschecks

TipVoer checks 3, 4, 6 en 10 als eerste uit: CAA, SPF, DMARC en open zonetransfers zijn de punten op deze lijst met de grootste impact die je het snelst oplost.

Alle 20 checks handmatig doorlopen voor meerdere domeinen wordt al snel een tijdrovende klus, zeker als je records beheert bij verschillende registrars en providers. Met de DNS-functies van InfraNest controleer en beheer je records, DNSSEC en je CAA-beleid vanuit één dashboard. Begin met een snelle ronde met de gratis DNS-lookuptool op elk domein waarvoor je verantwoordelijk bent.