Säker DNS: DNSSEC och DNS över HTTPS (DoH)

Domain Name System (DNS) översätter människoläsbara domännamn till IP-adresser. DNS utformades på 1980-talet utan säkerhet — frågor och svar skickas i klartext via UDP/TCP-port 53 utan autentisering. Detta skapar två huvudsakliga sårbarheter: DNS-cacheförgiftning (insprutning av förfalskade DNS-svar för att omdirigera användare till skadliga servrar) och DNS-avlyssning (att se vilka domäner en användare frågar efter avslöjar personens surfaktivitet). Två standarder hanterar dessa problem: DNSSEC förhindrar förfalskning och DNS över HTTPS (DoH) förhindrar avlyssning.

DNS-cacheförgiftning (Kaminsky-attacken) utnyttjar att DNS-protokollet saknar autentisering. En resolver skickar en fråga till en auktoritativ DNS-server och cachar svaret under TTL-tiden. En angripare som kan gissa transaktions-ID:t (16 bitar, förutsägbart) och källporten (används som ytterligare entropi sedan RFC 5452) kan skicka förfalskade svar som resolvern cachar, så att alla användare som frågar resolvern omdirigeras till angriparens server. När cachen har förgiftats dirigeras användarna till falska servrar även om de har skrivit in rätt domän. DNSSEC förhindrar detta genom att signera DNS-svar digitalt.

DNSSEC lägger till kryptografiska signaturer i DNS-poster, så att resolvrar kan verifiera att svaren kommer från den legitima zonauktoriteten och inte har manipulerats. DNSSEC introducerar nya posttyper: RRSIG (resurspostsignatur, den faktiska signaturen över en postmängd), DNSKEY (den publika nyckel som används för att verifiera signaturer), DS (delegationssignerare, länkar samman nycklarna i föräldra- och barnzonen) och NSEC/NSEC3 (autentiserat nekande av existens — bevisar att ett namn inte finns). DNSSEC skapar en tillitskedja från rotzonen (signerad av ICANN) ned genom toppdomäner och auktoritativa zoner.

DNSSEC använder två typer av signeringsnycklar. Zone Signing Key (ZSK) signerar de enskilda DNS-postmängderna (RRSIG) och byts ut ofta (varje eller var tredje månad) för att ge operativ flexibilitet. Key Signing Key (KSK) signerar DNSKEY-postmängden och utgör tillitsankaret för zonen. KSK byts ut mer sällan (årligen), eftersom föräldrazonen måste uppdateras med den nya DS-posten varje gång KSK ändras — en process som kräver samordning. KSK verifierar ZSK; ZSK signerar data. Denna struktur i två lager balanserar säkerhet (täta byten av ZSK) mot operativ belastning (glesa byten av KSK).

DNSSEC har viktiga begränsningar. DNS-frågor krypteras inte — DNSSEC signerar endast svar för att säkerställa integriteten. En avlyssnare kan fortfarande se alla DNS-frågor, men kan inte förfalska svar. Zone enumeration: NSEC-poster (som bevisar att något inte existerar) gör det möjligt för angripare att gå igenom zonen och kartlägga alla domännamn i den; NSEC3 minskar problemet med hashade namn, men är inte perfekt. Operativ komplexitet: nyckelhantering, signaturers utgång och samordning med föräldrazonen skapar betydande administrativ belastning. DNSSEC-användningen är fortfarande ofullständig — många toppdomäner och registrarer stöder det, men många organisationer har inte implementerat det.

DNS over HTTPS (DoH) krypterar DNS-frågor inuti HTTPS (RFC 8484), vilket döljer frågornas innehåll för nätverksobservatörer. Frågorna skickas till en DoH-kompatibel resolver via en standardiserad HTTPS-URL, vilket gör DNS-trafik omöjlig att skilja från annan HTTPS-trafik. Detta hindrar internetleverantörer, arbetsgivare och angripare med åtkomst till trafikvägen från att se vilka domäner en användare frågar efter – och åtgärdar därmed den integritetslucka som DNSSEC lämnar. DoH flyttar dock förtroendet från nätverkets DNS-resolver till DoH-leverantören (vanligtvis Google 8.8.8.8, Cloudflare 1.1.1.1 eller organisationens egen DoH-resolver). DoH stöds nu inbyggt i de flesta större webbläsare.

DNS over TLS (DoT) (RFC 7858) krypterar DNS-frågor med TLS via en dedikerad TCP-port 853, i stället för att tunnla dem genom HTTPS. DoT ger samma integritetsfördelar som DoH – frågornas innehåll döljs för avlyssnare – men är enklare för nätverksadministratörer att identifiera och filtrera (port 853 jämfört med port 443). Detta är en avvägning: DoT är synligt och kan blockeras av företagsbrandväggar, medan DoH är svårare att blockera utan att även påverka generell HTTPS-trafik. Stub-resolvers (på operativsystemsnivå) använder oftare DoT, medan webbläsare oftare använder DoH.

Krypterad DNS innebär en utmaning för företagsmiljöer som är beroende av DNS-baserad filtrering och sinkholes. När webbläsare använder externa DoH-resolvers kringgås interna DNS-kontroller. Motåtgärder för företag: distribuera en intern DoH/DoT-resolver (Cisco Umbrella, Pi-hole med DoH) och konfigurera alla enheter att använda den; blockera IP-adresser till externa DoH-resolvers i brandväggen (Google 8.8.8.8, Cloudflare 1.1.1.1) på port 443; använd Group Policy för att inaktivera DoH på webbläsarnivå på hanterade slutpunkter; samt använd transparent proxy-regler som fångar upp DNS-over-TLS på port 853. Målet är att dirigera all DNS genom den kontrollerade resolvern utan att helt blockera krypterad DNS.

En fullständig DNS-säkerhetsstrategi kombinerar flera kontroller. DNSSEC för era auktoritativa zoner förhindrar cacheförgiftning av er domän. DNS-baserad filtrering (Cisco Umbrella, Cloudflare Gateway) blockerar skadliga domäner på resolver-nivå. DoH/DoT till en kontrollerad resolver skyddar frågornas integritet utan att filtreringsinsynen går förlorad. DNS-loggning till SIEM-systemet samlar in alla frågor för threat hunting – DNS-loggar avslöjar C2-trafik, dataexfiltrering via DNS-tunnling och aktivitet från malware som använder domängenereringsalgoritmer (DGA). DNS-telemetri är en av de mest värdefulla säkerhetsdatakällorna som finns.

DNS-tunnling kodar data i DNS-frågor och svar för att exfiltrera data eller upprätta C2-kanaler genom nätverk där annan utgående trafik är blockerad. Verktyg som iodine, DNScat och dnscat2 kodar nyttolaster i subdomänetiketter (frågar efter EXFILTRATEDDATA.evil.com) eller TXT-poster. Identifiering: ovanligt långa DNS-frågenamn (>100 tecken), hög frågevolym från en enskild värd, frågor efter icke-existerande överordnade domäner, ovanliga posttyper (TXT, NULL) samt entropianalys av domänetiketter (kodade data har hög Shannon-entropi). Plattformar för DNS-säkerhetsanalys flaggar automatiskt mönster som tyder på tunnling.

DNS Response Policy Zones (RPZ) gör det möjligt för DNS-resolvers att tillämpa lokala åsidosättningsregler på DNS-svar – i praktiken skapas ett lokalt sinkhole på resolver-nivå utan att den globala DNS-infrastrukturen ändras. När en klient frågar efter en känd skadlig domän returnerar RPZ-regeln NXDOMAIN, en omdirigering till en sinkhole-IP-adress eller ett svar som släpps igenom. RPZ-flöden finns tillgängliga från leverantörer av threat intelligence (Spamhaus, SURBL) och kan importeras direkt till BIND- eller Unbound-resolvers. RPZ är ett kraftfullt defensivt verktyg eftersom filtreringen sker på DNS-lagret för alla enheter i nätverket utan någon konfiguration på klientsidan.

I den här lektionen har ni lärt er att DNSSEC lägger till kryptografiska signaturer i DNS-poster med hjälp av KSK/ZSK-nyckelpar för att förhindra cacheförgiftning, men inte krypterar frågor; att DNS over HTTPS (DoH) krypterar DNS-frågor inuti HTTPS för att förhindra avlyssning, men skapar risker för att företagsfiltrering kringgås; samt att DNS-tunnling kodar data i DNS-frågor och kan identifieras genom analys av frågelängd, volym och entropi. Härnäst utforskar vi IPsec, VPN-protokoll och säkerhet för fjärråtkomst.