DNS‑logs som spor

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

DNS-logs viser, hvilke domænenavne en enhed bad om at få oversat til IP-adresser, og hvornår. Det gør dem nyttige til at se, hvilke tjenester en computer har været i kontakt med, fx en privat cloudtjeneste, en fildelingstjeneste eller et domæne, der bruges i et phishingangreb. Hvem der ejede et .dk-domæne, og hvordan dets DNS så ud tidligere, står i .dk-domæner og DNS-historik. Men et DNS-opslag er ikke et besøg, og fravær af et opslag er ikke bevis for, at en tjeneste ikke blev brugt. Cache, baggrundsprocesser og krypteret DNS i browsere gør DNS til en kilde, der skal fortolkes forsigtigt og næsten altid sammen med andre.

Haster det? DNS-opslag logges ofte slet ikke historisk, og de logs, der findes i en DNS-tjeneste eller et EDR-produkt, har begrænset opbevaring. Ved akut behov: akut forensisk sikring; hastesager koster ekstra.

Hvordan et opslag forløber

Når et program skal forbinde til et domæne, spørger enheden først sin egen DNS-cache. Findes svaret ikke dér, går forespørgslen til den konfigurerede resolver, typisk virksomhedens DNS-server, en domænecontroller, routeren eller en ekstern DNS-tjeneste. Resolveren svarer fra sin egen cache eller spørger videre ude på internettet. Svaret har en levetid, TTL, og indtil den udløber, bliver det genbrugt uden nyt opslag.

Konsekvensen er, at den samme tjeneste kan bruges mange gange i løbet af en time med kun ét eller få opslag i loggen, og at opslag fra flere enheder bag en videresendende router kan optræde med routerens adresse.

Hvor DNS-logs findes

Virksomhedens interne DNS-server · Klientens IP-adresse, domænenavn, posttype, svar og tidspunkt, hvis logning er slået til
Beskyttende DNS-tjeneste i cloud · Klient eller netværk, domæne, kategori, blokeret eller tilladt
Firewall med DNS-inspektion · Domæner set i trafikken og evt. blokeringer
EDR-agent på endpointet · Opslag pr. proces på enheden
Enhedens egen cache · Kun de nuværende poster, flygtig

På Windows DNS Server er detaljeret forespørgselslogning ikke slået til som standard; den skal aktiveres som debuglog eller analytisk log. Serverens auditlog for ændringer i zoner og indstillinger er derimod slået til som standard, men den indeholder ikke klienternes opslag. Tilsvarende kræver de fleste resolvere på Linux, at forespørgselslogning konfigureres. Mange virksomheder har derfor ingen historisk DNS-log, medmindre de bruger en beskyttende DNS-tjeneste eller et EDR-produkt, der logger opslag.

EDR-data er særligt værdifulde, fordi de kobler opslaget til den proces, der lavede det. Det gør det muligt at skelne mellem et opslag fra browseren og et fra en baggrundstjeneste. Se EDR-telemetri som bevis.

Hvad DNS kan vise

Kontakt med en tjeneste: Opslag på domæner, der hører til en bestemt cloudtjeneste, viser, at noget på enheden ville forbinde til tjenesten.
Første kontakt: Det første opslag på et sjældent domæne kan datere, hvornår en tjeneste, et program eller et phishingdomæne første gang dukkede op.
Mønstre: Regelmæssige opslag med faste intervaller kan pege på et program, der kører i baggrunden, fx synkronisering eller fjernadgang.
Usædvanlige posttyper og lange navne: Kan pege på, at DNS bruges som transportkanal. Det er et fund, der skal undersøges videre, ikke en konklusion.

Hvad DNS ikke kan vise

Hvilken side eller fil. DNS kender kun domænenavnet, ikke stien, indholdet eller hvad der blev hentet eller sendt.
Om forbindelsen blev oprettet. Et opslag kan følges af en blokering eller slet ingen forbindelse.
Hvem der sad ved enheden. Det kræver andre kilder.
Brugerens hensigt. Browsere slår domæner op på forhånd for at gøre sider hurtigere, og sider indeholder elementer fra mange domæner. Et opslag på et domæne kan skyldes en reklame, et indlejret element eller en forudindlæsning.

Netop forskellen mellem system- og brugeraktivitet er en klassisk fejlkilde; se Systemet eller brugeren?.

Krypteret DNS

Moderne browsere og styresystemer kan sende DNS-forespørgsler krypteret over HTTPS eller TLS direkte til en ekstern resolver. Så ser virksomhedens DNS-server dem slet ikke. Om det sker, afhænger af browserens indstillinger, styresystemets politik og om virksomheden har blokeret det. Chrome og Edge skifter som standard kun til krypteret DNS, hvis den DNS-server, enheden allerede bruger, understøtter det, og de slår funktionen fra på administrerede enheder. Firefox har krypteret DNS slået til som standard i nogle lande og slår den fra, når den finder virksomhedspolitikker. En bruger kan dog selv vælge en ekstern resolver, medmindre en politik forhindrer det.

Fravær af opslag i den interne DNS-log er derfor kun meningsfuldt, hvis det er dokumenteret, at enhederne faktisk brugte den interne resolver i perioden. Kontrollér browserpolitikker, og se efter forbindelser til kendte krypterede DNS-tjenester i firewallloggen. Firewallen kan vise forbindelserne, men ikke hvilke domæner de handlede om; se Firewall-logs teknisk.

Eksempel på en fortolkning

Antag, at DNS-loggen viser et opslag fra en bestemt intern IP-adresse på et domæne, der hører til en privat fildelingstjeneste, kl. 14.03. Det kan formuleres som en observation: Enheden med denne adresse bad om at få domænet oversat på dette tidspunkt. Før det kan blive mere, skal flere spørgsmål besvares. Hvilken enhed havde adressen? Blev der oprettet en forbindelse bagefter, og hvor meget data gik der hver vej? Hvilken proces lavede opslaget? Var der en bruger logget ind? Og findes der en uskyldig forklaring, fx at tjenestens app er installeret og synkroniserer i baggrunden, eller at en kollega delte et link i en mail, som mailsikkerheden tjekkede?

Først når flere uafhængige kilder peger samme vej, kan opslaget bære en del af en konklusion. Står det alene, er det et udgangspunkt for videre undersøgelse.

Sikring

Find ud af, hvor DNS logges, og om der er tale om forespørgsler, svar eller begge.
Eksportér logs for perioden fra DNS-servere, beskyttende DNS-tjenester, firewall og EDR.
Gem konfigurationen: logniveau, videresendere, om klienter kunne bruge andre resolvere, og browserpolitikker for krypteret DNS.
Notér hvilken IP-adresse klienterne optræder med. Står alle opslag med routerens eller en videresenders adresse, kan de ikke kobles til en enhed uden flere kilder.
Sikr enhedens DNS-cache, hvis enheden kører og er relevant. Den er kortlivet.
Beregn hashværdier for eksporterne.

Korrelation

DNS bliver stærkest sammen med andre kilder: et opslag efterfulgt af en forbindelse til den returnerede adresse i firewallloggen, en upload i proxyloggen og en fil, der blev åbnet på enheden. Eksempelvis kan en mistanke om upload til en privat cloud undersøges ved at finde opslag på tjenestens domæner, forbindelser med stor udgående datamængde og spor på endpointet; se Upload til privat cloud.

Kobling mellem klientens interne IP-adresse og en enhed kræver DHCP-loggen for samme tidspunkt.

Fejlkilder

Cache betyder, at gentagen brug ikke giver gentagne opslag.
CDN’er og fælles infrastruktur gør, at mange tjenester deler domæner og adresser. Et opslag på et CDN-domæne siger ikke, hvilken tjeneste der blev brugt.
Opslag kan komme fra sikkerhedsprodukter, der tjekker links i mails, ikke fra brugeren.
Tidszoner og tidsopløsning varierer mellem kilder.

Hvad DNS-logs kan og ikke kan bevise

DNS-logs kan vise, at en enhed eller et netværk forsøgte at nå en tjeneste på bestemte tidspunkter. De kan understøtte en tidslinje og pege på, hvor andre logs skal undersøges. De kan ikke vise indhold, datamængder eller brugerhandlinger. Den grundlæggende gennemgang af netværkslogs for ikke-teknikere findes i Firewall-, VPN- og loginlogs.

Dokumentation

Angiv kilde, logniveau, tidszone, periode, eksportmetode og hashværdier. Beskriv, om klienterne kunne gå uden om den loggede resolver, og hvilke enheder der optrådte med en fælles adresse. Skeln i teksten mellem opslag, forbindelse og brugerhandling.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: DHCP, Wi-Fi og NAC: hvilken enhed havde IP-adressen? · Firewall-logs teknisk: sessioner, NAT og tidsstempler

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik