Is uw organisatie veilig tegen DNS-gebaseerde cyberaanvallen?

Gepubliceerd: september 2021. Bijgewerkt: augustus 2026. Beoordeeld door het PKI-adviessteam van Encryption Consulting.

Wat zijn DNS-gebaseerde cyberaanvallen en waarom zijn ze belangrijk?

Een cyberaanval via DNS is gericht op het Domain Name System (DNS), het protocol dat een voor mensen leesbare domeinnaam, zoals www.example.com, vertaalt naar het numerieke IP-adres waarmee een browser of applicatie daadwerkelijk verbinding maakt. DNS-resolutie verloopt via een keten van servers: een stub-resolver op het apparaat van de gebruiker vraagt ​​een recursieve resolver om informatie, die op zijn beurt rootservers raadpleegt, vervolgens de relevante top-level domein (TLD)-server (.com, .org, enzovoort) en ten slotte de gezaghebbende naamserver van het domein, die de daadwerkelijke records bevat. Elke schakel in die keten is in de jaren 1980 ontworpen met het oog op beschikbaarheid en snelheid, niet op authenticatie, waardoor niets in het oorspronkelijke protocol voorkomt dat een vervalst antwoord als authentiek wordt geaccepteerd.

Die kloof is belangrijk omdat DNS-resolutie plaatsvindt vóór vrijwel al het andere op het netwerk, vóór een TLS-handshake, vóór een applicatieaanmelding, vóórdat er ook maar één byte van het beoogde verkeer wordt verzonden. Een aanvaller die die eerste opzoeking beheert of manipuleert, kan een slachtoffer ongemerkt doorverwijzen naar een phishingpagina, inloggegevens onderscheppen, gegevens langs firewall-uitgangsregels smokkelen vermomd als gewone opzoekingen, of een service volledig offline halen door de resolvers die ervoor staan ​​te overbelasten. Omdat DNS de basis vormt voor vrijwel alle andere beveiligingsmaatregelen van een organisatie, kan een gecompromitteerde DNS-laag stilletjes de verdediging ondermijnen die er op papier solide uitziet.

Wat zijn de belangrijkste soorten DNS-aanvallen?

DNS-aanvallen vallen in vier operationeel verschillende categorieën uiteen, die elk een ander zwak punt in de resolutieketen uitbuiten.

• DNS-spoofing en cachevergiftiging: Een aanvaller injecteert een vervalst DNS-antwoord in de cache van een resolver, zodat toekomstige zoekopdrachten voor een domein een door de aanvaller beheerd IP-adres retourneren in plaats van het echte adres. De klassieke techniek, die voor het eerst op grote schaal werd gedemonstreerd door beveiligingsonderzoeker Dan Kaminsky in 2008, houdt in dat een aanvaller via een omweg legitieme antwoorden probeert te omzeilen door de 16-bits transactie-ID en de bronpoort van de query te raden voordat de echte gezaghebbende server antwoordt. Zodra de server is vergiftigd, wordt elke client die die resolver gebruikt, stilzwijgend omgeleid totdat de cachevermelding verloopt of wordt verwijderd. Voor een gedetailleerdere uitleg van de mechanismen voor het raden via een omweg en de daaropvolgende verdedigingsmechanismen met betrekking tot bronpoort en 0x20-codering, zie de speciale handleiding van Encryption Consulting. DNS-cachevergiftiging en hiërarchieaanvallen.
• DNS-kaping: In plaats van een cache te manipuleren, neemt de aanvaller de controle over de gezaghebbende kant van de resolutie zelf over, door een registraraccount te compromitteren, nameserver (NS)-records te wijzigen of de DNS-instellingen van een kwetsbare router te misbruiken, zodat de rechtmatige eigenaar van het domein niet langer bepaalt waar zijn eigen naam wordt opgelost.
• DNS-tunneling voor data-exfiltratie en command-and-control (C2): Omdat DNS-query's routinematig netwerkperimeterbeveiligingen passeren die vrijwel al het andere blokkeren, coderen aanvallers gestolen gegevens of C2-instructies in DNS-querynamen en TXT-recordreacties. Daarbij gebruiken ze DNS zelf als een verborgen, traag communicatiekanaal dat niet wordt gecontroleerd door traditionele firewallregels voor uitgaand verkeer.
• Versterking van DDoS- en NXDOMAIN-aanvallen: Een aanvaller verstuurt een kleine, vervalste DNS-query die een veel grotere respons uitlokt. Deze respons wordt vervolgens doorgestuurd naar het IP-adres van het slachtoffer, waardoor de bandbreedte van de aanvaller vele malen wordt vergroot. Een verwante variant, de NXDOMAIN-aanval of "DNS-watermarteling", bombardeert een gezaghebbende DNS-server met query's voor willekeurige, niet-bestaande subdomeinen. Hierdoor wordt de capaciteit van de server uitgeput in plaats van de bandbreedte van de server, aangezien elke query nog steeds een opzoeking vereist, zelfs als het antwoord "domein niet gevonden" is (NXDOMAIN).

Welk DNS-beveiligingsprotocol moet u implementeren?

Geen enkel DNS-beveiligingsprotocol dekt alle bovenstaande aanvallen, omdat elk protocol een ander probleem oplost: integriteit van het antwoord, privacy van de query of certificaatbinding. Drie standaarden, die over elkaar heen zijn gelegd, dichten het grootste deel van de kloof: DNSSEC (Domain Name System Security Extensions), dat DNS-records cryptografisch ondertekent zodat een resolver kan controleren of een antwoord niet is gewijzigd (gedefinieerd in RFC 4033 , RFC 4034 en RFC 4035 ); DoT (DNS over TLS), dat de query zelf versleutelt binnen een TLS-sessie via een speciale poort ( RFC 7858 ); DoH (DNS over HTTPS), dat versleutelde queries transporteert binnen gewoon HTTPS-verkeer op poort 443 ( RFC 8484 ); en DANE (DNS-Based Authentication of Named Entities), dat DNSSEC-ondertekende TLSA-records gebruikt om het certificaat vast te leggen dat een service moet presenteren, als een onafhankelijke controle naast het publieke CA/Web PKI-vertrouwensmodel ( RFC 6698 ).

Protocol	Wat het beschermt	Wat het niet beschermt	Het meest effectief ingezet wanneer
DNSSEC	Integriteit en authenticiteit van DNS-antwoorden; detecteert spoofing en cachevergiftiging.	De privacy van de query wordt gewaarborgd; de query en het antwoord worden nog steeds onversleuteld verzonden.	Je hebt resolvers nodig om vervalste records te weigeren voor elk domein waarvoor je de autoriteit hebt of dat je namens gebruikers oplost.
DoT (DNS over TLS)	Vertrouwelijkheid van de query tijdens de overdracht, op een speciale, gemakkelijk te identificeren poort (853)	Antwoordauthenticiteit; een DoT-resolver kan nog steeds een vervalst of gemanipuleerd record retourneren als deze DNSSEC niet ook valideert.	U beheert beheerde eindpunten of uitgaand netwerkverkeer en wilt DNS-verkeer duidelijk kunnen scheiden voor monitoring binnen de onderneming.
DoH (DNS over HTTPS)	De vertrouwelijkheid van de query wordt geïntegreerd in het reguliere HTTPS-verkeer voor brede ondersteuning van clients en browsers.	Wat betreft de authenticiteit en zichtbaarheid van het antwoord, is DoH opzettelijk moeilijk te onderscheiden van ander HTTPS-verkeer.	Je hebt brede clientondersteuning nodig (browsers, mobiele besturingssystemen) en je kunt clients doorverwijzen naar een vertrouwde, door de organisatie beheerde DoH-resolver.
DANE (TLSA via DNSSEC)	Welk TLS-certificaat een domein moet presenteren, onafhankelijk van het publieke CA-vertrouwensmodel.	Op zichzelf is het niets; DANE zonder een DNSSEC-ondertekende zone kan zelf ook worden vervalst.	U voert services uit (met name SMTP-mailbezorging, per RFC 7672) waar certificaatvervanging een reëel risico vormt en DNSSEC al is geïmplementeerd

Wat is het dreigingsmodel achter DNS-gebaseerde aanvallen?

Het modelleren van DNS-risico's begint met één belangrijk onderscheid: bevindt de aanvaller zich op het netwerkpad of niet? Een aanvaller op het netwerkpad, iemand die een malafide wifi-toegangspunt, een gecompromitteerde router of een netwerksegment beheert waar het verkeer van het slachtoffer daadwerkelijk doorheen loopt, kan elke query en elk antwoord direct zien en herschrijven. Hierdoor is DNS-spoofing triviaal en hoeft er niet gegokt te worden. Een aanvaller buiten het netwerkpad heeft geen inzicht in het werkelijke verkeer en moet in plaats daarvan de legitieme reactie proberen te ontwijken door de transactie-ID en de bronpoortcombinatie te raden voordat het legitieme antwoord arriveert. Dit is precies de techniek waarop klassieke cachevergiftiging is gebaseerd.

Bovenop dat onderscheid komt de resolutieketen zelf: de stub-resolver, de recursieve resolver, de TLD-server en de autoritatieve naamserver vertegenwoordigen elk een aparte vertrouwensgrens. Een inbreuk op een willekeurige hop, zoals een gekaapt registrar-account, een vergiftigde recursieve cache of een malafide autoritatief record, verspreidt zich stroomafwaarts naar elke client die ervan afhankelijk is. De praktische implicatie hiervan is dat DNS standaard als een onbetrouwbaar transportmechanisme moet worden beschouwd. Een antwoord is slechts zo betrouwbaar als de cryptografische keten (de DNSSEC-vertrouwensketen van de root tot de ondertekende zone) die eraan ten grondslag ligt, niet het feit dat het correct op poort 53 is aangekomen. Dit sluit aan bij de bredere indeling van actieve versus passieve aanvallen die wordt behandeld in de gids van Encryption Consulting over cyberbeveiligingsaanvallen , aangezien een DNS-aanvaller in feite een man-in-the-middle-aanval uitvoert tegen de resolutieketen zelf.

Hoe beveiligt u uw DNS-infrastructuur tegen deze aanvallen?

1. Inventariseer en modelleer uw DNS-omgeving op bedreigingen. Maak een lijst van alle gezaghebbende zones, registraraccounts en resolvers waarvan uw organisatie afhankelijk is, en breng vervolgens in kaart welke aanvalsfamilie (spoofing, hijacking, tunneling, amplification) realistisch is tegen elk ervan voordat u beheersmaatregelen kiest.
2. Onderteken zones met DNSSEC en schakel validatie in. Schakel DNSSEC-ondertekening aan de gezaghebbende kant in voor elke zone die u beheert, en controleer of uw recursieve resolvers de handtekeningen daadwerkelijk valideren (stel de DNSSEC OK/AD-bit in) in plaats van ondertekende records ongewijzigd door te geven.
3. Verplaats het transport van query's naar DoT of DoH wanneer privacy een rol speelt. Voor beheerde eindpunten en interne resolvers maakt de speciale poort van DoT het eenvoudig om versleuteld DNS-verkeer te identificeren en te monitoren; voor browsers en onbeheerde clients biedt DoH bredere ondersteuning, mits de clients verwijzen naar een resolver die uw organisatie daadwerkelijk vertrouwt en waarvan ze de gegevens kunnen loggen.
4. Publiceer DANE TLSA-records voor services buiten het standaard Web PKI-pad. Met name de bezorging van SMTP-mail profiteert van DANE, omdat deze zelden wordt beschermd door certificaatvalidatie zoals in browsers.
5. Beperk de stroomtoevoer en verhoog de capaciteit ter bescherming tegen versterking en NXDOMAIN-overstromingen. Implementeer beperkingen op de responsfrequentie, anycast-resolvercapaciteit en BCP 38-achtige bronadresfiltering, zodat vervalste, kleine query's niet kunnen leiden tot grote aanvallen op een derde partij of uw eigen resolvers.
6. Let op indicatoren voor tunnelvorming. Let op abnormaal hoge queryvolumes, ongebruikelijk lange of entropierijke subdomeinen en pieken in TXT-recordquery's. Dit zijn allemaal veelvoorkomende signalen dat DNS-tunneling wordt gebruikt voor data-exfiltratie of als C2-server.
7. Beheer de sleutels die eronder schuilgaan. Alle bovenstaande controles zijn afhankelijk van het correct genereren, roteren en opslaan van DNSSEC-ondertekeningssleutels; beschouw het beheer van Zone Signing Keys (ZSK) en Key Signing Keys (KSK) als een volwaardig onderdeel van het programma, niet als een bijzaak.

Wat zijn de afwegingen op het gebied van prestaties en interoperabiliteit tussen DNSSEC, DoH en DoT?

DNSSEC voegt cryptografische handtekeningen toe aan DNS-reacties, waardoor antwoorden doorgaans de oorspronkelijke UDP-limiet van 512 bytes overschrijden. Dit vereist ondersteuning voor EDNS0 of een terugval naar TCP, en zorgt voor extra CPU-werk bij de resolver voor de validatie van de handtekeningen. Het grootste operationele risico is niet de snelheid, maar de beschikbaarheid: een verkeerd geconfigureerde of verlopen handtekening zorgt ervoor dat een ondertekende zone niet meer bereikbaar is (fail closed) . Het domein wordt dan volledig onoplosbaar voor validerende resolvers, in plaats van slechts onveilig. Dit is een veiligere manier om aanvallen te voorkomen, maar veel minder vergevingsgezind voor operationele teams dan gewone, niet-ondertekende DNS.

DoT vereist een speciale TLS-verbinding op poort 853, wat een extra handshake betekent tenzij sessiehervatting is ingeschakeld. Diezelfde speciale poort maakt het voor restrictieve netwerken (en voor beveiligingstools van bedrijven) gemakkelijk om DoT te identificeren en, indien gewenst, te blokkeren. DoH gaat bewust de andere kant op: door gebruik te maken van de standaard HTTPS-poort 443, mengt het zich met gewoon webverkeer. Dit maximaliseert de compatibiliteit en het bereik van clients, maar maakt het voor perimeterbeveiligingstools moeilijk om DoH-verkeer te onderscheiden van andere HTTPS-verbindingen. Dit is een reële kostenpost voor bedrijven die afhankelijk zijn van inzicht op DNS-niveau voor beveiligingsmonitoring. Noch DoH, noch DoT vervangt DNSSEC, aangezien het versleutelen van de query tijdens de overdracht niets zegt over de vraag of het antwoord erin vervalst is. De richtlijnen van NIST voor veilige DNS-implementatie ( NIST SP 800-81 Rev. 3 ) en de richtlijnen van CISA voor beschermende DNS beschouwen versleuteld transport en DNSSEC-validatie als complementaire lagen, niet als vervanging voor elkaar.

Welke afhankelijkheden voor sleutelbeheer introduceert DNSSEC?

De beveiliging van DNSSEC berust volledig op twee sleutelparen per zone, elk met een ander rotatieritme en impactbereik. De Zone Signing Key (ZSK) ondertekent de daadwerkelijke resource records van de zone en is ontworpen om relatief vaak te worden geroteerd (meestal om de paar maanden), aangezien vervanging alleen het opnieuw ondertekenen van de zone zelf vereist. De Key Signing Key (KSK) ondertekent de DNSKEY-recordset die de ZSK bevat, en de publieke tegenhanger ervan moet worden gepubliceerd als een DS-record (Delegation Signer) in de bovenliggende zone. Dit betekent dat een KSK-rollover gecoördineerde actie vereist van de beheerder of registrar van de bovenliggende zone, en niet alleen van de domeineigenaar. Deze afhankelijkheid maakt KSK-rollovers operationeel veel riskanter: de KSK-rollover van de rootzone in 2018 werd door ICANN zelf uitgesteld, specifiek omdat telemetrie aantoonde dat een aanzienlijk deel van de resolvers de nieuwe sleutel nog niet had overgenomen, en het doorzetten volgens schema het risico met zich meebracht dat de validatie voor die resolvers zou worden verbroken.

Omdat een KSK-compromis of een onjuist uitgevoerde rollover ervoor kan zorgen dat een volledig ondertekend domein offline gaat voor elke validerende resolver op internet, verdient het beheer van DNSSEC-sleutels dezelfde zorgvuldigheid als het beheer van de root-sleutel van een certificeringsinstantie: generatie en opslag in een hardwarebeveiligingsmodule (HSM), gedocumenteerde rolloverprocedures die worden getest voordat ze nodig zijn, en een duidelijke eigendomsstructuur in plaats van een impliciete aanname dat de standaardinstellingen van een DNS-host voldoende zijn.

Hoe zien implementatievoorbeelden van DNSSEC en DANE er in de praktijk uit?

• Gecertificeerde zone met ondertekende validatie-resolvers: Een bedrijf activeert DNSSEC-ondertekening voor zijn gezaghebbende zones via zijn DNS-hostingprovider, publiceert het resulterende DS-record bij zijn registrar en bevestigt afzonderlijk dat de recursieve resolvers die zijn eigen medewerkers en diensten gebruiken, daadwerkelijk handtekeningen valideren. Het ondertekenen van een zone beschermt immers bezoekers, maar validatie beschermt de eigen gebruikers van de organisatie tegen vervalste antwoorden elders op het internet.
• DANE voor SMTP-mailbezorging: Een mailbeheerder publiceert TLSA-records voor elke mail exchange (MX) hostnaam onder een DNSSEC-ondertekende zone, conform RFC 7672, zodat ontvangende mailservers het exacte certificaat kunnen verifiëren dat een verzendende server moet presenteren. Dit sluit een pad voor downgrading en interceptie af dat het openbare CA-model alleen openlaat voor mailbezorging tussen servers.
• Bedrijfsbeheerd DoH-resolverprofiel: In plaats van elke browser standaard zijn eigen openbare DoH-resolver te laten gebruiken (wat de DNS-beveiligingsfiltering van het bedrijf volledig zou omzeilen), configureert een organisatie een groepsbeleid of MDM-profiel dat beheerde browsers naar een specifieke, door de organisatie vertrouwde DoH-resolver verwijst. Dit zorgt voor behoud van zowel de privacy van versleutelde query's als gecentraliseerd inzicht.

Welke verdedigingsmechanismen stoppen elk type DNS-aanval?

Gebruik deze tabel als een checklist om mee te beginnen. In de praktijk worden meerdere rijen tegelijk gelaagd in plaats van dat er per aanval één controle wordt gekozen.

Aanvalstype	Mechanisme	Primaire verdediging
DNS-spoofing / cachevergiftiging	Een aanvaller die niet direct met het transactiepad te maken heeft, raadt de transactie-ID en de bronpoort om een ​​vervalst record te injecteren voordat het echte antwoord binnenkomt.	DNSSEC-validatie; randomisatie van bronpoort en query-ID
DNS-kaping	De aanvaller compromitteert een registrar-account of wijzigt NS/autoritatieve records om de resolutie bij de bron om te leiden.	Registrar MFA en registervergrendeling; DNSSEC-ondertekende zone; monitoring op onverwachte NS/recordwijzigingen
DNS-tunneling (exfiltratie / C2)	De aanvaller codeert gegevens of commando's in DNS-querynamen en TXT-reacties om de uitgaande firewallregels te omzeilen.	Monitoring van querylengte en entropie; beschermende DNS-/DNS-firewallfiltering; beperking van ongebruikelijke recordtypen bij uitgaand verkeer
Versterking van DDoS / NXDOMAIN-flood	Een kleine, vervalste query leidt tot een grote, teruggekoppelde respons, of een overvloed aan willekeurige subdomeinen overspoelt de resolvercapaciteit.	Beperking van de responssnelheid; anycast-capaciteit; BCP 38-filtering op bronadres; caching en capaciteitsoptimalisatie van de resolver

Beperkingen

• DNSSEC beschermt de integriteit van het antwoord, niet de vertrouwelijkheid van de vraag; een passieve waarnemer op het netwerk kan nog steeds zien welke domeinen u oplost, zelfs bij een volledig ondertekende en gevalideerde zoekopdracht.
• Het ministerie van Volksgezondheid en Telecommunicatie beschermt de query tijdens de overdracht, maar doet niets om te voorkomen dat een gezaghebbende zone zelf wordt gemanipuleerd, vervalst of gekaapt stroomopwaarts. Dat hiaat is de taak van DNSSEC, niet van hen.
• DANE werkt alleen als de zone die het TLSA-record publiceert, DNSSEC-ondertekend is; DANE bovenop een niet-ondertekende zone kan zelf worden vervalst en biedt geen echte bescherming.
• Het fail-closed ontwerp van DNSSEC biedt meer bescherming tegen aanvallen, maar is operationeel minder flexibel. Een verlopen handtekening of een verbroken vertrouwensketen kan een domein volledig onbereikbaar maken in plaats van alleen onveilig.
• Versleutelde DNS naar een openbare resolver kan de DNS-beveiligingsmaatregelen van een bedrijf volledig omzeilen als de eindpunten niet centraal geconfigureerd zijn om een ​​vertrouwde resolver te gebruiken. Dit creëert een blinde vlek in de monitoring in plaats van er een te dichten.
• Geen van deze protocollen voorkomt phishing op applicatieniveau, waarbij simpelweg een domein met een vergelijkbare naam wordt geregistreerd in plaats van de DNS-resolutie zelf aan te vallen; voor dat risico zijn aparte domeinbewaking en gebruikersbewustmakingsmaatregelen nodig.

Wat zou Encryption Consulting aanbevelen?

Behandel DNSSEC-sleutelbeheer met dezelfde discipline als het beheer van root-sleutels van certificeringsinstanties, omdat het operationeel gezien hetzelfde probleem is: een klein aantal langlevende cryptografische sleutels die, als ze verloren gaan, gecompromitteerd worden of onjuist worden behandeld tijdens de rollover, het vertrouwen in een heel domein kunnen ondermijnen in plaats van het alleen maar te verzwakken. We raden doorgaans aan om te beginnen met een PKI-assessment om vast te stellen wie momenteel daadwerkelijk verantwoordelijk is voor het genereren, roteren en rolloveren van DNSSEC-sleutels, aangezien het antwoord in de meeste organisaties "degene is die de standaardinstellingen van de DNS-host heeft geconfigureerd", en niet een gereguleerd proces. Vervolgens profiteren ZSK- en KSK-privésleutels van hetzelfde HSM-ondersteunde beheer dat Encryption Consulting aanbeveelt voor CA-root-sleutels, beschikbaar via HSM-as-a-Service in plaats van alleen softwarematige sleutelopslag bij de DNS-provider.

Voor organisaties die al certificaatlevenscyclusautomatisering toepassen via PKI-as-a-Service , biedt het uitbreiden van diezelfde governance-discipline – gedefinieerde rotatieschema's, auditregistratie en rolscheiding – naar DNSSEC- en DANE TLSA-records een oplossing voor een hiaat dat certificaatlevenscyclusbeheer alleen niet dekt: een geldig uitgegeven certificaat biedt geen bescherming als een aanvaller het DNS-record dat ernaar verwijst, kan kapen. Aangezien DNS-gebaseerde aanvallen slechts één symptoom zijn van een breder probleem in plaats van een geïsoleerde kwestie, is een adviesgesprek over encryptie het juiste startpunt om DNS-risico's in kaart te brengen in samenhang met de rest van de cryptografische infrastructuur.

Conclusie

DNS-gebaseerde cyberaanvallen slagen omdat het protocol dat aan vrijwel elke internetverbinding ten grondslag ligt, nooit is ontworpen om zijn eigen antwoorden te authenticeren. Spoofing en cachevergiftiging, kaping, tunneling en amplification floods exploiteren elk een ander punt in de resolutieketen, waardoor er geen enkele oplossing is die het gat dicht. DNSSEC authenticeert antwoorden, DoH en DoT beschermen de privacy van de query en DANE pint certificaten onafhankelijk van het publieke CA-model, maar elk van deze beschermingen is afhankelijk van hoe goed de onderliggende sleutels, met name de Zone Signing Key en Key Signing Key van DNSSEC, worden gegenereerd, geroteerd en beheerd. Organisaties die DNS-sleutelbeheer net zo serieus nemen als het beheer van certificeringssleutels, dichten het grootste gat dat in dit artikel wordt beschreven; organisaties die het aan de standaardinstellingen van een DNS-host overlaten, ontdekken het gat meestal pas nadat een aanvaller het al heeft gevonden.

FAQ

Is DNSSEC voldoende om de DNS van mijn organisatie te beveiligen? Nee. DNSSEC beschermt de integriteit en authenticiteit van DNS-antwoorden en voorkomt spoofing en cachevergiftiging, maar het versleutelt de query zelf niet, voorkomt geen DNS-tunneling en biedt geen bescherming tegen DDoS-aanvallen met versterking. Beschouw het als één noodzakelijke laag van meerdere, niet als een compleet DNS-beveiligingsprogramma op zich.

Wat is nu eigenlijk het echte verschil tussen DoH en DoT? Beide versleutelen DNS-query's, maar DoT (RFC 7858) gebruikt een speciale TLS-verbinding op poort 853, waardoor versleuteld DNS-verkeer gemakkelijk te identificeren en te monitoren is aan de netwerkrand. DoH (RFC 8484) daarentegen tunnelt query's binnen standaard HTTPS op poort 443, waardoor ze opgaan in het normale webverkeer voor bredere clientondersteuning, ten koste van de zichtbaarheid voor de gehele organisatie.

Kan DNS-tunneling daadwerkelijk data langs een firewall smokkelen? Ja. Omdat DNS-query's vrijwel universeel de netwerkperimeter mogen passeren, coderen aanvallers gestolen data of command-and-control-instructies in querynamen en TXT-recordreacties, waardoor ze de uitgaande regels omzeilen die bijna elk ander protocol blokkeren. Om dit te detecteren is het nodig om het queryvolume, de lengte en de entropie te monitoren, en niet alleen poorten te blokkeren.

Heb ik DANE nodig als ik al DNSSEC en een openbare certificeringsinstantie gebruik? DANE voegt een onafhankelijke, door DNSSEC ondersteunde controle toe op welk TLS-certificaat een domein moet presenteren. Dit is vooral belangrijk voor diensten zoals SMTP-mailbezorging, die geen certificaatvalidatie zoals in browsers mogelijk maken. Het is niet overal vereist waar DNSSEC wordt ingezet, maar het vult een belangrijk gat voor server-naar-serverprotocollen dat het openbare CA/Web PKI-model niet volledig dekt.

Hoe vaak moeten DNSSEC-sleutels worden geroteerd? De Zone Signing Key (ZSK) wordt doorgaans om de paar maanden geroteerd, omdat het opnieuw ondertekenen van de zone een laag risico met zich meebrengt. De Key Signing Key (KSK) wordt daarentegen veel minder vaak geroteerd, vaak jaarlijks of zelfs nog minder vaak, omdat hiervoor een nieuw DS-record bij de bovenliggende zone of registrar moet worden gepubliceerd en moet worden bevestigd dat de validerende resolvers de wijziging hebben overgenomen voordat de oude sleutel wordt ingetrokken.

Referenties

• RFC 4033, DNS-beveiliging: Inleiding en vereisten. https://www.rfc-editor.org/rfc/rfc4033
• RFC 4034, Bronrecords voor de DNS-beveiligingsuitbreidingen: https://www.rfc-editor.org/rfc/rfc4034.html
• RFC 4035, Protocolwijzigingen voor de DNS-beveiligingsuitbreidingen: https://www.rfc-editor.org/rfc/rfc4035
• RFC 7858, Specificatie voor DNS over Transport Layer Security (TLS): https://www.rfc-editor.org/rfc/rfc7858
• RFC 8484, DNS-query's via HTTPS (DoH): https://www.rfc-editor.org/rfc/rfc8484.html
• RFC 6698, Het DNS-gebaseerde authenticatieprotocol voor benoemde entiteiten (DANE) TLS: TLSA: https://www.rfc-editor.org/rfc/rfc6698.html
• RFC 7672, SMTP-beveiliging via opportunistische DANE TLS: https://www.rfc-editor.org/rfc/rfc7672
• NIST SP 800-81 Rev. 3, Handleiding voor de implementatie van een beveiligd domeinnaamsysteem (DNS): https://csrc.nist.gov/pubs/sp/800/81/r3/final
• CISA, beschermende DNS-resolver (Domain Name System): https://www.cisa.gov/resources-tools/services/protective-domain-name-system-dns-resolver
• Akamai, wat is NXDOMAIN DDoS? (DNS-watermartelaanval): https://www.akamai.com/glossary/what-is-nxdomain-ddos