NIST SP 800-81r3: Richtlijnen voor DNS-beveiliging bij e-mail

Volgens de politie van Singapore heeft een in Singapore gevestigde grondstoffenhandelaar in april 2026 6,6 miljoen USD overgemaakt naar een frauduleuze bankrekening in Oman. De aanval was niet het gevolg van een geavanceerde inbreuk op het netwerk of een directe hack. In plaats daarvan maakten de aanvallers gebruik van een klassieke ‘typosquatting’-truc en verstuurden ze e-mails vanaf een domein waarbij slechts twee letters van plaats waren verwisseld. Het vervalste adres leek vrijwel identiek aan dat van de echte leverancier van het bedrijf.

Dit verwoestende incident maakt duidelijk waarom het beschouwen van het Domain Name System (DNS) als passieve infrastructuur een enorm veiligheidsrisico vormt. Om juist deze tekortkomingen aan te pakken, heeft het National Institute of Standards and Technology (NIST) op 19 maart 2026 de definitieve versie van NIST SP 800-81r3 vastgesteld. Deze publicatie markeert de eerste grote update van de federale DNS-beveiligingsrichtlijnen van het NIST in 13 jaar, waarmee DNS officieel wordt omgevormd van achtergrondinfrastructuur tot een actieve, frontliniebeveiligingsmaatregel. Voor IT- en beveiligingsteams die e-mailauthenticatie beheren, betekent dit een belangrijke verschuiving in de manier waarop met DNS moet worden omgegaan.

Wat is NIST SP 800-81r3?

NIST Special Publication (SP) 800-81 geldt als de toonaangevende referentienorm voor een veilige DNS-implementatie. De vorige versie, Revisie 2, werd al in 2013 gepubliceerd. In de 13 jaar die sindsdien zijn verstreken, is het technologielandschap voor bedrijven volledig veranderd door de opkomst van cloudarchitectuur, de wijdverspreide inzet van ransomware, versleutelde protocollen en Zero Trust-raamwerken.

Het onlangs afgeronde NIST SP 800-81r3-raamwerk, opgesteld door Scott Rose van NIST in samenwerking met de Infoblox-experts Cricket Liu en Ross Gibson, moderniseert deze richtlijnen. Hoewel naleving strikt verplicht is voor Amerikaanse federale instanties om te voldoen aan de recente presidentiële besluiten inzake cyberbeveiliging, fungeert het ook als internationale maatstaf. Europese organisaties kunnen het bijvoorbeeld beschouwen als een fundamentele technische norm voor de NIS2-richtlijn (Network and Information Security 2) van de EU.

NIST SP 800-81r3: Strategie voor de kernarchitectuur

Drie pijlers die DNS in een nieuw licht plaatsen als actieve beveiligingsmaatregel

De fundamentele verandering in deze herziening is eenvoudig: DNS is niet langer een dienst die je eenmaal instelt en vervolgens kunt vergeten. Het moderne raamwerk vereist dat organisaties DNS beschouwen als een dynamisch punt voor beveiligingshandhaving dat bedreigingen actief moet blokkeren, telemetriegegevens moet doorgeven aan de beveiligingsafdeling en voortdurend moet worden gecontroleerd.

Vijf belangrijke wijzigingen in SP 800-81r3

1. Beschermend DNS – Van passieve resolver naar actieve filter

De belangrijkste conceptuele verandering in de nieuwe richtlijnen is de formele introductie van beschermend DNS (PDNS). Een beschermende DNS-dienst fungeert als een actief beveiligingsfilter in plaats van als een eenvoudig hulpmiddel voor het opzoeken van domeinnamen. De dienst controleert alle uitgaande DNS-verzoeken, vergelijkt deze met feeds met informatie over bedreigingen en blokkeert verbindingen met bekende kwaadaardige domeinen of phishing-infrastructuur.

• Flexibiliteit bij de implementatie: NIST beveelt een hybride infrastructuurmodel aan en streeft ernaar schaalbare, cloudgebaseerde PDNS-oplossingen te combineren met lokale DNS-firewall-back-ups om de veerkracht te waarborgen.
• Proactieve risicobeperking: PDNS beperkt risico’s proactief door te voorkomen dat gebruikers en apparaten verbinding maken met gevaarlijke hosts.
• Lookalike-oplichting tegengaan: In het kader van de zaak rond Business Email Compromise (BEC) in Singapore kan een actieve PDNS-laag de resolutie van nieuw geregistreerde lookalike-domeinen volledig blokkeren.

2. Versleutelde DNS – DoT, DoH en DoQ

Oude DNS-verzoeken worden in leesbare tekst over het internet verzonden, waardoor aanvallers het verkeer kunnen afluisteren en zo inzicht kunnen krijgen in de interne middelen of externe samenwerkingsverbanden van een organisatie. De bijgewerkte richtlijn beveelt officieel versleutelde DNS-protocollen aan om de vertrouwelijkheid van verzoeken te waarborgen.

• Ondersteunde protocollen: De update zorgt voor standaardisatie van DNS over Transport Layer Security (DoT), DNS over HTTPS (DoH) en DNS over QUIC (DoQ).
• Bescherming tegen afluisteren: Door deze kanalen te versleutelen, wordt voorkomen dat externe kwaadwillenden systeemverzoeken kunnen afluisteren.
• Verkenningseenheid: Dit voorkomt direct dat aanvallers beveiligingscontroles van uitgaande e-mail kunnen onderscheppen, die zij vaak gebruiken om doelnetwerken in kaart te brengen voordat ze spear-phishingcampagnes lanceren.

3. DNS als handhavingspunt voor het Zero Trust-beleid

In een Zero Trust-architectuur wordt geen enkele gebruiker of apparaat standaard als betrouwbaar beschouwd, en moet elk afzonderlijk toegangsverzoek expliciet worden gevalideerd. De nieuwe richtlijnen verheffen DNS tot een centraal Zero Trust Policy Enforcement Point (PEP).

• Beveiliging vóór het tot stand brengen van de verbinding: Aangezien DNS-resolutie plaatsvindt voordat er een netwerkverbinding tot stand is gebracht, vormt dit de vroegst mogelijke laag om ongeautoriseerde communicatie te blokkeren.
• Contextuele informatie: Query-gegevens bieden essentiële contextuele informatie, waardoor beveiligingsteams het gedrag van apparaten kunnen analyseren op basis van de domeinen die het apparaat probeert te bereiken.
• Infrastructuurisolatie: Als een systeem probeert verbinding te maken met een bekende kwaadaardige command-and-control-server, markeert de DNS-laag het apparaat en wordt de communicatie onmiddellijk verbroken.

4. Een krachtigere DNSSEC-implementatie

DNSSEC waarborgt de integriteit van DNS-gegevens door cryptografische handtekeningen aan records toe te voegen. De bijgewerkte versie bevat essentiële verbeteringen om DNSSEC sterker en efficiënter te maken.

• Moderne cryptografie: NIST belicht overwegingen met betrekking tot moderne DNSSEC-algoritmen en merkt op dat algoritmen zoals ECDSA en Ed448 in veel toepassingen de voorkeur genieten boven RSA, omdat ze kleinere sleutels en handtekeningen opleveren.
• QNAME-minimalisatie: Resolver-servers sturen nu alleen het strikt noodzakelijke deel van een domeinnaamverzoek door naar de volgende schakel in de opzoekketen.
• Compact Denial-of-Existence: Deze functie beperkt de hoeveelheid structurele informatie die aan aanvallers wordt blootgesteld wanneer een server een NXDOMAIN-antwoord (domein bestaat niet) retourneert.

5. DNS-logboekregistratie, SIEM-integratie en OT/IoT-toepassingsgebied

De laatste grote update is vooral gericht op zichtbaarheid en het uitbreiden van de beveiligingsdekking naar niet-traditionele omgevingen.

• SIEM-invoer: Betrouwbare en recursieve DNS-logbestanden moeten rechtstreeks worden ingevoerd in Security Information and Event Management (SIEM)-systemen.
• IP-correlatie: Organisaties moeten DNS-logbestanden vergelijken met lease-gegevens van het Dynamic Host Configuration Protocol (DHCP) om kwaadaardige zoekopdrachten nauwkeurig te kunnen koppelen aan fysieke apparaten.
• OT- en IoT-dekking: Het raamwerk introduceert expliciete beveiligingseisen die zijn afgestemd op apparaten op het gebied van operationele technologie (OT) en het internet der dingen (IoT), die vaak niet over ingebouwde beveiligingsfuncties beschikken.

Waarom SP 800-81r3 van belang is voor DMARC, SPF en DKIM

Als u leiding geeft aan een IT-afdeling, beschouwt u e-mailbeveiliging en DNS-beveiliging wellicht als twee volledig afzonderlijke projecten. Dat is een gevaarlijke vergissing. De realiteit is dat de stabiliteit van uw gehele e-mailauthenticatie slechts zo groot is als die van de onderliggende DNS-infrastructuur waarop deze is gebaseerd.

SPF, DKIM en DMARC zijn DNS-records

Elk e-mailverificatieprotocol is volledig afhankelijk van het DNS-register. Wanneer een externe e-mailserver een bericht van jouw domein ontvangt, voert deze onmiddellijk meerdere DNS-zoekopdrachten uit:

1. Het controleert je SPF TXT-records om te zien of het verzendende IP-adres geautoriseerd is.
2. Het haalt je openbare DKIM-sleutel op via een specifieke DNS-selector om de cryptografische handtekening in de e-mail te verifiëren.
3. Het controleert je DMARC-beleidsrecord om te bepalen wat er moet gebeuren als die controles mislukken.

Als een aanvaller deze opzoekingen manipuleert via DNS-cachevergiftiging of een kapingaanval, stort uw e-mailbeveiliging in. Een vervalst SPF-record kan de malafide server van een aanvaller autoriseren, terwijl een gemanipuleerd DMARC-record ervoor kan zorgen dat uw handhavingsbeleid wordt teruggeschroefd van afwijzing naar geen handhaving. Het nieuwe raamwerk wijst expliciet op deze afhankelijkheid en waarschuwt dat e-mailauthenticatie een geverifieerde DNS-integriteit vereist om betrouwbaar te kunnen functioneren.

DNSSEC beschermt authenticatierecords voor e-mail

Als je DMARC-handhaving implementeert zonder je DNS-zone te beveiligen, laat je een kritieke kwetsbaarheid volledig open. Zonder DNSSEC kan een recursieve resolver niet controleren of een DNS-antwoord tijdens de overdracht is gewijzigd.

In een standaard scenario van cache poisoning voegt een aanvaller valse vermeldingen toe aan de cache van een lokale DNS-server. Als die cache een vervalst, volledig open SPF-record doorgeeft aan een ontvangende e-mailgateway, zal de gateway valse e-mails als volkomen legitiem accepteren. Door je zone te ondertekenen met moderne ECDSA-algoritmen volgens de nieuwe richtlijnen, garandeer je dat ontvangende servers je ongewijzigde, authentieke e-mailbeleidsregels ontvangen.

Het probleem van gelijkende domeinnamen

De zaak rond het grondstoffenbedrijf uit Singapore laat precies zien waar standaard e-mailverificatie tegen haar structurele grenzen aanloopt. De aanvallers in dat incident hebben de domeinnaam van het slachtoffer niet rechtstreeks nagemaakt, noch hebben ze een bestaand DMARC-beleid omzeild. In plaats daarvan hebben ze een geheel aparte, op de oorspronkelijke domeinnaam lijkende domeinnaam geregistreerd.

Omdat ze eigenaar waren van dat gelijknamige domein, konden hun e-mails hun eigen SPF- en DMARC-controles feilloos doorstaan.

Daarom wordt in het bijgewerkte raamwerk benadrukt dat e-mailprotocollen moeten worden gecombineerd met actieve DNS-hygiëne. Terwijl DMARC uw exacte domeinidentiteit beveiligt, biedt een beschermende DNS-laag de nodige bescherming tegen lookalike-domeinen door de toegang van gebruikers te blokkeren nog voordat er enige interactie plaatsvindt.

SP 800-81r3-nalevingschecklist voor e-mailbeveiligingsteams

Gebruik deze praktische, technische checklist om uw infrastructuur af te stemmen op moderne dreigingsmodellen en federale richtlijnen.

1. DNSSEC inschakelen en valideren voor uw domein

• Onderteken uw gezaghebbende DNS-zones met behulp van de aanbevolen ECDSA-sleutelalgoritmen.
• Controleer of uw SPF-, DKIM- en DMARC-TXT-records volledig onder uw DNSSEC-handtekeningen vallen.
• Pas QNAME-minimalisatie toe op uw recursieve resolvers om het lekken van uitgaande informatie te beperken.

2. DMARC niet alleen gebruiken voor monitoring

• Laat uw domein niet voor onbepaalde tijd onbeschermd met een passief monitoringbeleid (p=none).
• Stel een duidelijk stappenplan op om de handhavingsstatus ‘DMARC p=reject’ te bereiken.
• Maak gebruik van een speciaal DMARC Analyzer -platform om de verzamelde telemetriegegevens continu te monitoren en geldige uitgaande e-mailstromen tijdens uw overgang veilig te autoriseren.

3. SPF- en DKIM-records controleren en opschonen

• Controleer uw SPF -configuraties om na te gaan of ze strikt binnen de standaardlimiet van 10 lookups blijven.
• Zorg ervoor dat elke actieve e-mailprovider een unieke DKIM-selectorsleutel gebruikt en trek verouderde of ongebruikte openbare sleutels onmiddellijk in.
• Controleer of alle voor het publiek toegankelijke TXT-records zich volledig binnen DNSSEC-beveiligde zones bevinden, om manipulatie verderop in de keten te voorkomen.

4. Implementeer een beschermende DNS-architectuur

• Implementeer een PDNS-oplossing op bedrijfsniveau met behulp van een hybride implementatiemodel, zodat de feeds met informatie over cyberdreigingen uit de cloud worden ondersteund door lokale beveiligingsmaatregelen.
• Stel expliciete beveiligingswaarschuwingen in voor zoekopdrachten die verwijzen naar nieuw geregistreerde domeinen of bekende typosquatting-varianten van uw merknaam.

5. Overgang naar versleutelde DNS-overdracht

• Zorg ervoor dat de DoT- of DoH-configuraties worden toegepast op alle interne recursieve resolvers van de onderneming om de privacy van zoekopdrachten te waarborgen.
• Geef DoT voorrang binnen beheerde bedrijfsnetwerken om de standaard poortbewaking en firewallfiltering te vereenvoudigen.

6. Centraliseer DNS-telemetrie in uw SIEM

• Leid alle logbestanden van autoritatieve en recursieve DNS-query’s door naar uw centrale SIEM-platform.
• Stel realtime operationele waarschuwingen in voor afwijkende activiteiten, zoals onverwachte wijzigingen in MX-records, plotselinge aanpassingen aan TXT-records of interne klanten die proberen om bekende phishing-infrastructuur op te zoeken.

Toepassingsgebied van de nalevingsregels: voor wie geldt dit?

Laatste woorden

De definitieve vaststelling van NIST SP 800-81r3 maakt een cruciale realiteit duidelijk: sterke e-mailauthenticatie en een veilige DNS-implementatie zijn beveiligingsmaatregelen die onlosmakelijk met elkaar verbonden zijn. Het is simpelweg onmogelijk om een betrouwbare, veilige e-mailomgeving te exploiteren als de onderliggende netwerkdirectory kwetsbaar is voor manipulatie. Het incident in Singapore, waarbij een bedrijf miljoenen dollars verloor als gevolg van e-mailfraude, bewijst dat het niet langer voldoende is om alleen te vertrouwen op basiszichtbaarheid van het domein om een onderneming te beschermen.

Echte beveiliging vereist een meerlaagse verdediging. Om de identiteit van uw domein te beveiligen, moet u verder gaan dan passieve observatie en uw infrastructuur beveiligen met actieve, veerkrachtige protocollen.

Zet vandaag nog de eerste stap: controleer of uw records correct zijn gepubliceerd en beveiligd. Gebruik de gratis DMARC Record Checker en de uitgebreide DNS Record Lookup-tools van PowerDMARC om in minder dan 60 seconden een volledige, realtime statuscontrole van uw implementatie uit te voeren.

Veelgestelde Vragen

Wat is het belangrijkste verschil tussen NIST SP 800-81r2 en SP 800-81r3?

In de vorige versie (Revisie 2), die in 2013 werd gepubliceerd, werd DNS beschouwd als een statisch hulpprogramma dat slechts eenmalig hoefde te worden geconfigureerd. Revisie 3 (voltooid op 19 maart 2026) moderniseert het raamwerk om rekening te houden met Zero Trust, cloud computing en versleutelde gegevensoverdracht. Het doel is om DNS opnieuw te definiëren als een continue, actieve beveiligingsmaatregel die kan worden geïntegreerd met uw SIEM en proactief bedreigingen filtert.

Zou de toepassing van DMARC de BEC-aanval in Singapore, waarmee 6,6 miljoen dollar werd buitgemaakt, hebben kunnen voorkomen?

Nee, DMARC op het legitieme domein kan een aanvaller er niet van weerhouden een volledig afzonderlijk, op het legitieme domein lijkend domein te registreren. In de zaak in Singapore van april 2026 maakten de aanvallers gebruik van een typosquatted domein met twee omgewisselde letters. Omdat zij eigenaar waren van dat valse domein, konden hun e-mails technisch gezien hun eigen DMARC-controles doorstaan. Om dit soort aanvallen te voorkomen, is Protective DNS (PDNS) nodig om de resolutie van op het legitieme domein lijkende domeinen te blokkeren.

Waarom schrijft NIST SP 800-81r3 een overstap naar ECDSA voor DNSSEC voor?

Oudere RSA-algoritmen leiden tot grotere cryptografische sleutels en pakketgroottes, wat de resolutie kan vertragen en systemen kwetsbaar kan maken voor versterkingsaanvallen. De bijgewerkte richtlijnen schrijven een overgang naar ECDSA voor, omdat dit sterkere beveiliging, snellere verwerking en aanzienlijk kleinere sleutellengtes biedt.

Hoe zorgt QNAME-minimalisatie ervoor dat de gegevensprivacy van mijn bedrijf wordt gewaarborgd?

Bij traditionele DNS-opzoekingen wordt de volledige domeinnaam naar elke afzonderlijke gezaghebbende server in de DNS-opzoekingsketen verzonden. QNAME-minimalisatie brengt hier verandering in door alleen het minimale deel van de domeinnaam te verzenden dat nodig is voor die specifieke stap in het resolutieproces.

Wie is wettelijk verplicht om te voldoen aan NIST SP 800-81r3?

SP 800-81r3 is een officiële NIST-richtlijn voor een veilige DNS-implementatie en is met name van belang voor Amerikaanse federale instanties, federale aannemers en gereguleerde organisaties die moeten voldoen aan de federale cyberbeveiligingseisen.

• Over
• Laatste berichten

Yunes Tarada

Expert domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• NIST SP 800-81r3: Richtlijnen voor DNS-beveiliging bij e-mail - 25 juni 2026
• Hoe een DKIM-record splitsen - 5 juni 2026
• compauth=fail: Uitleg over Microsoft Composite Authentication - 1 juni 2026