Bygg ditt försvar mot DNS-cacheförgiftningsattacker

Key Takeaways

• DNS-cacheförgiftning förfalskar en resolvers cachade DNS-poster så att sökningar efter en riktig domän returnerar en angriparkontrollerad IP-adress, utan att vidröra offrets enhet.
• Tekniken blev allmänt känd efter att säkerhetsforskaren Dan Kaminsky avslöjade en kritisk brist i en resolver år 2008 (CVE-2008-1447), vilket tvingade fram en branschomfattande, samordnad patch för alla DNS-leverantörer.
• Det är fortfarande en aktiv risk. ISC avslöjade BIND 9-cacheförgiftningsbrister (CVE-2025-40778 och CVE-2025-40780) i oktober 2025, och forskare rapporterade en DNS-förgiftningskampanj av hotgruppen Evasive Panda i slutet av 2025.
• Ingen enskild kontroll stoppar det. Randomisering av källportar begränsar gissningsfönstret, DNSSEC autentiserar svar kryptografiskt och DoH/DoT krypterar sökvägen för frågesökningen så att angripare på sökvägen inte kan läsa eller manipulera den.
• DNSSEC-distributionen är fortfarande ojämn. APNIC Labs mätte den globala DNSSEC-valideringen till ungefär 36 procent år 2025, vilket är en förbättring jämfört med ett decennium sedan men som fortfarande gör att de flesta resolvers inte kan kryptografiskt verifiera vad de cachar.

Publicerad: maj 2022. Uppdaterad: augusti 2026. Granskad av Encryption Consultings säkerhetsteam.

Vad är DNS-cacheförgiftning och hur fungerar det?

DNS-cacheförgiftning är en attack som injicerar ett förfalskat svar i en DNS-resolvers cache så att framtida sökningar efter en legitim domän returnerar en angriparkontrollerad IP-adress istället för den riktiga. Domain Name System (DNS) översätter läsbara domännamn till IP-adresser. En rekursiv resolver, den servertyp som drabbas mest av denna attack, gör den översättningen åt en klient och cachar svaret tillfälligt så att den inte behöver upprepa sökningen vid varje begäran.

DNS-upplösning bygger på två serverroller. Auktoritativa namnservrar innehar de officiella posterna för de domäner de är konfigurerade att svara för. Rekursiva resolvrar utför sökningen åt en klient, frågar auktoritativa servrar efter behov och cachade svaret. Den här artikeln fokuserar på attacker mot rekursiva resolvrar, eftersom en förgiftad rekursiv cache påverkar varje klient som frågar den.

I den klassiska attacken lurar en off-path-angripare (en som inte kan se legitim DNS-trafik direkt) en resolver att utfärda en fråga till en auktoritativ namnserver och skyndar sig sedan att injicera ett förfalskat svar innan det riktiga anländer. För att accepteras måste det förfalskade svaret matcha frågans käll- och destinations-IP, käll- och destinationsport (historiskt fixerad till port 53) och ett 16-bitars transaktions-ID (TxID). Med en fixerad port behövde en angripare bara gissa 16-bitars TxID, ett utrymme som är tillräckligt litet för att brute force-använda ungefär 65 536 förfalskade svar, och tekniker som födelsedagsattacken skulle kunna begränsa detta ytterligare.

Cacheförgiftning kontra DNS-förfalskning: De två termerna beskriver samma underliggande mål (att få en resolver eller klient att acceptera ett falskt DNS-svar) men skiljer sig åt i omfattning. DNS-förfalskning är den bredare kategorin och täcker alla förfalskade DNS-svar, inklusive man-in-the-middle-avlyssning på ett lokalt nätverk. DNS-cacheförgiftning hänvisar specifikt till att få det förfalskade svaret att finnas kvar i en resolvers cache, så att den fortsätter att leverera felaktiga svar till varje efterföljande klient tills cacheposten upphör att gälla.

Vad är historien bakom DNS-cacheförgiftning? Landmärkeshändelser och aktuella incidenter

DNS-cacheförgiftning är inte en enskild incident, det är en långvarig attackteknik med en historia av banbrytande avslöjanden och pågående utnyttjande i verkliga livet. Tre händelser definierar dess tidslinje.

1. 2008, Kaminsky-sårbarheten (CVE-2008-1447). Säkerhetsforskaren Dan Kaminsky upptäckte en brist i hur DNS-resolvrar hanterade TxID-slumpmässighet som gjorde storskalig cacheförgiftning praktisk mot nästan alla DNS-implementeringar som användes. Avslöjandet hanterades genom en samordnad patchrelease från flera leverantörer snarare än en vanlig rådgivning från en enda leverantör, vilket fortfarande citeras som en av de tidigaste storskaliga samordnade avslöjandeinsatserna inom internetinfrastruktursäkerhet. Randomisering av källportar blev en nästan universell standard som ett direkt resultat.
2. Oktober 2025, BIND 9-cacheförgiftningsfel (CVE-2025-40778 och CVE-2025-40780). Internet Systems Consortium (ISC) avslöjade sårbarheter i BIND 9, en av de mest spridda DNS-resolverimplementeringarna, som möjliggjorde cacheförgiftning genom oönskade resursposter. Proof-of-concept-kod publicerades kort därefter, och säkerhetsforskare uppskattade att hundratusentals internetvända BIND-resolverar körde sårbara versioner vid tidpunkten för avslöjandet. Detta visar att cacheförgiftning inte bara är ett problem från 2008, utan brister på implementeringsnivå som gör att det fortsätter att dyka upp i nuvarande DNS-programvara.
3. Sent 2025, DNS-förgiftningskampanjen Evasive Panda. Kasperskys Securelist-forskare rapporterade att den Kina-kopplade hotgruppen Evasive Panda använde DNS-förgiftning tillsammans med "adversary-in-the-middle"-tekniker för att omdirigera riktade användare mot skadlig infrastruktur som levererade MgBot-bakdörren. Detta är ett dokumenterat exempel på cacheförgiftning som används operativt av en aktör kopplad till en nation, inte bara en teoretisk protokollsvaghet.
4. Pågående, DNSSEC och krypterad transportrespons. DNSSEC (DNS Security Extensions), standardiserat i IETF RFC 4033 till RFC 4035, signerar kryptografiskt DNS-poster så att en validerande resolver kan upptäcka ett förfalskat svar istället för att lita på vilket svar som än kommer först. DNS över HTTPS (DoH, RFC 8484) och DNS över TLS (DoT, RFC 7858) krypterar själva frågan och stänger av en annan attackyta: avlyssning på sökvägen och manipulering. Dessa tre försvar, randomisering av källportar, DNSSEC och DoH/DoT, är den nuvarande bästa praxisbaslinjen, och ingen av dem ensamma är tillräcklig.

Vilka tekniker och system påverkas av DNS-cacheförgiftning?

Varje lager av DNS-cachning i en modern upplösningskedja är tekniskt sett exponerat för förgiftning, inte bara den rekursiva upplösaren som de flesta föreställer sig.

• OS stub-upplösare. Klientoperativsystemet underhåller sin egen DNS-cache och vidarebefordrar frågor uppåt snarare än att lösa dem iterativt. En förgiftad stub-cache påverkar en enda enhet men förbises ofta vid företags-DNS-övervakning.
• DNS-vidarebefordrare. Forwarders, som vanligtvis är inbyggda i Wi-Fi-routrar för hem och små kontor, underhåller sin egen cache och skickar frågor till en uppströms rekursiv resolver. En förgiftad routercache påverkar alla enheter i det nätverket.
• Rekursiva resolvrar, inklusive ISP- och publika resolvrar. Detta är det klassiska målet, eftersom en förgiftad post här serveras till varje klient som frågar efter den tills postens TTL löper ut.
• Företags-DNS-infrastruktur. Interna DNS-servrar som matchar företagsnätverk, VPN-klienter och molnarbetsbelastningar är värdefulla mål, eftersom en förgiftad intern post kan omdirigera autentiseringstrafik, kontroller av programuppdateringar eller API-anrop.
• Auktoritär DNS-programvara. BIND 9-fallet år 2025 visade att sårbarheter i själva resolverprogramvaran, inte bara protokollbrister, kan öppna upp cacheförgiftning igen även efter att källportsrandomisering och DNSSEC-stöd finns.

Vilken är effekten av en lyckad DNS-cacheförgiftningsattack?

En lyckad DNS-cacheförgiftningsattack ger angriparen kontroll över vart offrets trafik faktiskt går, utan att offret ändrar något på sin egen enhet.

• Omdirigering av trafik. Användare som skriver ett legitimt domännamn skickas i tysthet till en server som kontrolleras av angriparen istället.
• Stöld av autentiseringsuppgifter. Omdirigerad trafik till en övertygande liknande inloggningssida kan samla in användarnamn, lösenord och sessionstokens.
• Mannen-i-mitten-positionering. En angripare som kontrollerar DNS-upplösning för ett mål kan fånga upp och, i vissa konfigurationer, modifiera trafik mellan klienten och den avsedda destinationen.
• Leverans av skadlig kod. Förgiftade register kan peka programuppdateringskontroller eller nedladdningslänkar mot angriparens infrastruktur, vilket dokumenterats i Evasive Panda-kampanjen.
• Erosion av förtroendeankare som är beroende av DNS. Validering av certifikatdomäner, CAA-postkontroller och e-postautentisering (SPF, DKIM, DMARC) är alla beroende av att DNS-svar är tillförlitliga. En förgiftad resolver som används under domänkontrollvalidering kan, under specifika omständigheter, undergräva integriteten hos det valideringssteget.

Hur upptäcker man DNS-cacheförgiftning?

Detektion kombinerar DNS-specifik övervakning med samma avvikelsedetekteringsdisciplin som används på andra ställen i nätverket.

1. Övervaka oväntade TTL- eller IP-ändringar. En plötslig förändring av en välkänd domäns upplösta IP-adress, eller en ovanligt kort TTL på en post som normalt sett sällan ändras, är en vanlig indikator på förgiftning.
2. Aktivera DNSSEC-valideringsloggning. En validerande resolver loggar och avvisar svar som misslyckas med signaturvalidering, vilket är en direkt signal på ett försök till förfalskning.
3. Var uppmärksam på onormal frågevolym mot en enda namnserver. En topp i frågor eller frågefel mot en auktoritativ server kan indikera att en angripare försöker "fästa" en resolver till en enda, lättare förfalskad namnserver.
4. Dubbelkolla upplösningsresultaten från flera perspektiv. Att jämföra vad interna resolvers, publika resolvers och tredjepartsövervakningstjänster returnerar för samma domän kan avslöja en lokal förgiftningshändelse som en enda utsiktspunkt skulle missa.
5. Spåra resolver- och vidarebefordrare-programvaruversioner mot rekommendationer. BIND 9-bristerna från 2025 kunde utnyttjas specifikt i opatchade versioner, så versionsspårning mot leverantörsmeddelanden (ISC, i BINDs fall) är en detekterings- och förebyggande kontroll på samma gång.

Hur åtgärdar och förhindrar du DNS-cacheförgiftning? En numrerad checklista

Ingen enskild kontroll stänger helt av DNS-cacheförgiftning. Det nuvarande bästa försvaret är flerskiktat.

1. Bekräfta att slumpmässig källport är aktiv. Modern resolverprogramvara möjliggör detta som standard, men det är värt att bekräfta på alla äldre eller specialkonfigurerade DNS-infrastrukturer. Detta ökar gissningsutrymmet som en off-path-angripare står inför från 16 bitar till ungefär 32 bitar.
2. Distribuera DNSSEC på auktoritativa zoner som du kontrollerar. Genom att signera dina egna domäner kan alla validerande resolver upptäcka ett förfalskat svar för din domän. Detta skyddar din organisations domäner redan innan alla resolver på internet validerar.
3. Aktivera DNSSEC-validering på resolvrar som du använder. Att enbart signera hjälper inte om de resolvers som din organisation använder inte validerar signaturer. Båda sidorna av DNSSEC, signering och validering, måste vara på plats.
4. Flytta intern och klient-DNS-trafik till DoH eller DoT. Kryptering av frågesökvägen förhindrar att angripare på sökvägen läser eller manipulerar DNS-trafik mellan klienten och resolvern.
5. Uppdatera DNS-server och resolverprogramvara enligt ett definierat schema. BIND 9-cacheförgiftningsbristerna från 2025 är en direkt påminnelse om att patchning av resolver-programvara är en kontroll av cacheförgiftning, inte bara allmän hygien.
6. Begränsa vilka namnservrar dina domäner använder och övervaka dem. Färre, välövervakade auktoritativa namnservrar minskar attackytan som en off-path-angripare kan rikta in sig på med "pinning"-tekniker för frågefel.
7. Lägg till CAA-poster i dina DNS-zoner. CAA-poster (Certification Authority Authorization) begränsar vilka certifikatutfärdare som kan utfärda för din domän, vilket minskar effekten om DNS-förtroendet undergrävs tillfälligt under certifikatutfärdandet.
8. Logga och varna kontinuerligt för DNS-avvikelser. Mata in resolverloggar, DNSSEC-valideringsfel och TTL/IP-ändringsvarningar i övervakningen så att ett förgiftningsförsök upptäcks snabbt snarare än att upptäckas efter påverkan.

Vad har ändrats i DNS-säkerhet sedan den här artikeln publicerades? Uppdateringslogg

Denna artikel publicerades först i maj 2022 och uppdaterades väsentligt i augusti 2026. Sedan den ursprungliga publiceringen har följande händelser förändrat DNS-säkerhetslandskapet:

• ISC avslöjade och patchade BIND 9-cacheförgiftningssårbarheterna CVE-2025-40778 och CVE-2025-40780 i oktober 2025, vilket visade att implementeringsbrister, inte bara svagheter på protokollnivå, fortfarande möjliggör cacheförgiftning i allmänt distribuerad resolverprogramvara.
• Säkerhetsforskare dokumenterade hur den Kina-kopplade Evasive Panda-gruppen använde DNS-förgiftning operativt, tillsammans med "adversary-in-the-middle"-tekniker, för att leverera MgBot-bakdörren, vilket flyttade cacheförgiftning från en teoretisk protokollrisk till en aktivt utnyttjad teknik i nationsstatskopplade kampanjer.
• Global DNSSEC-validering ökade till ungefär 36 procent år 2025 enligt APNIC Labs mätningar, vilket är en betydande framsteg från de låga ensiffriga tal som artikeln ursprungligen citerade, men det innebär fortfarande att de flesta resolvers inte kan kryptografiskt verifiera vad de cachar.
• DNS över HTTPS och DNS över TLS gick från nya förslag till att bli vanliga standardinställningar i större webbläsare och operativsystem, och lade till ett försvarslager för krypterad transport som den ursprungliga 2022-versionen av den här artikeln inte täckte.
• CA/Browser Forums övergång till kortare giltighetsperioder för TLS-certifikat (ett tak på 200 dagar från och med mars 2026, som skärps till 47 dagar i mars 2029) ökar hur ofta domänkontrollvalidering körs, vilket ökar insatserna för DNS-integriteten under det valideringsfönstret.

Vilket försvar mot DNS-cacheförgiftning bör du implementera först?

Varje försvar tar upp en annan del av problemet. Använd den här tabellen för att sekvensera utplaceringen snarare än att behandla en enskild rad som tillräcklig på egen hand.

Försvarsmekanism	Vad den skyddar mot	Implementeringskomplexitet
Randomisering av källportar	Off-path TxID-gissning (den klassiska attacken i Kaminsky-stil)	Låg, standard i modern resolverprogramvara
DNSSEC (signerar dina zoner)	Förfalskade svar för dina egna domäner, validerade kryptografiskt av resolvers som kontrollerar signaturer	Medel till hög, kräver nyckelhantering och zonsignering
DNSSEC (validering på dina resolvers)	Acceptera förfalskade svar för alla signerade domäner du frågar efter	Medel, mestadels en ändring av resolverkonfigurationen
DNS via HTTPS (DoH)	Avlyssning på vägen och manipulering av själva DNS-frågan	Medel, behöver klient- och resolversupport
DNS över TLS (DoT)	Samma som DoH, krypterad frågetransport	Medel, behöver klient- och resolversupport
0x20-kodning	Lägger till begränsad extra slumpmässighet via versaler och gemener, endast delvis mildrande	Lågt men inkonsekvent auktoritativt serverstöd
DNS-övervakning och avvikelsedetektering	Upptäcker förgiftningsförsök och oväntade journalförändringar efter att de inträffat	Medel till hög, behöver loggning och varningsinfrastruktur

Begränsningar av DNS-cacheförgiftningsförsvar

Ingen kontroll på den här listan är en komplett lösning i sig själv, och organisationer bör planera för djupgående försvar snarare än en enda mirakellösning.

• DNSSEC skyddar endast domäner som är signerade, och endast när den frågande resolvern faktiskt validerar. Med global validering fortfarande runt en tredjedel av resolvrar från och med 2025, kontrolleras inte den mesta DNS-trafiken världen över kryptografiskt.
• DoH och DoT skyddar frågan under överföring, men de autentiserar inte innehållet i svaret på samma sätt som DNSSEC gör. En angripare som komprometterar själva resolvern, snarare än nätverkssökvägen, stoppas inte enbart av kryptering.
• Randomisering av källportar ökar kostnaden för en attack, det gör den inte omöjlig, och implementeringsbuggar i resolverprogramvara (som med 2025 BIND 9-bristerna) kan öppna upp förgiftningsvägar oavsett portrandomisering.
• Klientsidiga stub-resolvrar och konsumentroutrar är ofta den svagaste länken, eftersom härdning av företags-DNS ofta stannar vid den rekursiva resolvern och inte omfattar alla vidarebefordrare i nätverket.

Vad skulle krypteringskonsulter rekommendera?

Vi behandlar DNS-integritet som ett problem med förtroendeankare, inte bara ett nätverksproblem. DNS-svar matas direkt in i beslut som är viktiga för kryptografiskt förtroende, inklusive validering av domänkontroll för utfärdande av TLS-certifikat och CAA-tillämpning. Vår grundläggande rekommendation för kunder är att följa checklistan ovan i den ordningen: bekräfta att randomisering av källportar redan är på plats (det är nästan alltid på aktuell programvara), prioritera sedan DNSSEC-signering på externt vända zoner, validering på interna resolvrar och DoH eller DoT för klienttrafik, i den ordningen. Patchkadens för DNS-serverprogramvara bör spåras med samma disciplin som alla andra internetanslutna tjänster, med tanke på hur nyligen BIND 9-bristerna visade att resolverprogramvaran i sig fortfarande är en aktiv attackyta.

Eftersom DNS-upplösning ligger till grund för validering av domänkontroll, bör organisationer som hanterar sin egen certifikatutfärdarinfrastruktur eller förlitar sig på publika certifikatutfärdare behandla DNS-härdning som en del av sin PKI-förtroendekedja, inte som ett separat arbetsflöde. Om ert team utvärderar hur DNS-baserad validering, CAA-tillämpning och certifikatutfärdande passar ihop, kan vårt PKI-as-a-Service- team och vår krypteringsrådgivning hjälpa till att bedöma var DNS-integritetsluckor kan försvaga certifikatförtroendet i er miljö. Encryption Consulting är ISO/IEC 27001:2022- och SOC 2-certifierat, och vi rekommenderar att du pratar med en rådgivare snarare än att behandla detta som en engångskonfigurationschecklista, eftersom både resolverprogramvara och DNS-hotaktivitet fortsätter att förändras.

Slutsats

DNS-cacheförgiftning har varit en känd, utnyttjande svaghet långt innan Kaminsky-avslöjandet 2008 gjorde den omöjlig att ignorera, och den har inte försvunnit. BIND 9-bristerna från 2025 och Evasive Panda-kampanjen visar båda att detta är en aktuell, verklig risk, inte ett löst problem från en gammal lärobok. Randomisering av källportar är tabellinsatser. DNSSEC och krypterad DNS-transport (DoH/DoT) är det nuvarande bästa praxis-lagret ovanpå, och ingetdera är valfritt om DNS-integritet är viktig för din organisations säkerhetsställning, inklusive domänvalideringen som dina TLS-certifikat är beroende av. Bygg det lagerbaserade försvaret som beskrivs ovan, uppdatera resolver-programvaran enligt ett verkligt schema och övervaka de avvikelser som signalerar ett pågående försök.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan DNS-cacheförgiftning och DNS-förfalskning? DNS-förfalskning är den breda kategorin av förfalskning av ett DNS-svar, inklusive lokala nätverks-man-in-the-middle-attacker. DNS-cacheförgiftning är en specifik typ av förfalskning där det förfalskade svaret lagras i en resolvers cache, så det fortsätter att påverka varje klient som frågar den resolvern tills den cachade posten upphör att gälla, inte bara den klient som var måltavla i den initiala attacken.

Kan DNSSEC ensamt stoppa DNS-cacheförgiftningsattacker? Nej. DNSSEC skyddar bara domäner som är signerade, och det hjälper bara om den frågande resolvern faktiskt validerar signaturer. Med global DNSSEC-validering som fortfarande täcker ungefär en tredjedel av resolvrar från och med 2025, förblir osignerade domäner och icke-validerande resolvrar exponerade oavsett DNSSEC:s existens som standard.

Hur vet jag om min DNS-resolver har blivit förgiftad? Var uppmärksam på om en välkänd domän plötsligt konverteras till en okänd IP-adress, en ovanligt kort TTL på en post som normalt sett sällan ändras, DNSSEC-valideringsfel i resolverloggar eller användarrapporter om certifikatvarningar på webbplatser som normalt laddas utan dem. Att dubbelkolla lösningsresultat mellan interna, offentliga och tredjepartsresolverar är det snabbaste sättet att bekräfta en lokal förgiftningshändelse.

Ersätter DNS över HTTPS (DoH) och DNS över TLS (DoT DNSSEC? Nej, de löser olika problem. DoH och DoT krypterar DNS-frågan under överföring, vilket förhindrar avlyssning och manipulering längs vägen. DNSSEC signerar kryptografiskt själva DNS-svaret, vilket hindrar en resolver från att acceptera en förfalskad post även om den anländer via en annars säker kanal. Organisationer behöver båda, inte den ena istället för den andra.

Hur ofta bör vi granska vår DNS-infrastruktur för risk för cacheförgiftning? Som ett minimum bör vi granska DNS-server- och resolverprogramvaruversioner mot leverantörsrekommendationer varje gång en säkerhetsuppdatering släpps, och köra en fullständig konfigurationsgranskning (randomisering av källportar, DNSSEC-signerings- och valideringsstatus, CAA-poster, stöd för krypterad transport) minst två gånger om året eller efter varje ändring av DNS-infrastrukturen.

Referensprojekt

• ISC:s kunskapsbas, ”CVE-2008-1447: Problem med DNS-cacheförgiftning (Kaminsky-buggen)”: https://kb.isc.org/docs/aa-00924
• ISC:s kunskapsbas, ”CVE-2025-40778: Cacheförgiftningsattacker med oönskade RR:er”: https://kb.isc.org/docs/cve-2025-40778
• IETF RFC 4033 till RFC 4035, “Introduktion till och krav för DNS-säkerhet” och relaterade DNSSEC-specifikationer: https://datatracker.ietf.org/doc/html/rfc4033
• IETF RFC 8484, “DNS-frågor över HTTPS (DoH)”: https://datatracker.ietf.org/doc/html/rfc8484
• IETF RFC 7858, “Specifikation för DNS över Transport Layer Security (TLS)”: https://datatracker.ietf.org/doc/html/rfc7858
• APNIC Labs, ”Mot en branschledande praxis för DNSSEC-automation” (2025 års DNSSEC-valideringsmätningar): https://blog.apnic.net/2026/02/25/towards-an-industry-best-practice-for-dnssec-automation/
• Kaspersky Securelist, ”Evasive Panda APT förgiftar DNS-förfrågningar för att leverera MgBot”: https://securelist.com/evasive-panda-apt/118576/