Internet Systems Consortium (ISC) sendte den 16. september 2026 en sikkerhedsopdatering ud, der lapper 14 sårbarheder i DNS-serveren BIND 9. Den mest alvorlige af dem, CVE-2026-77692, kan crashe en server uden at angriberen behøver logge ind først, og fejlen rammer specifikt trafik krypteret med DNS over HTTPS (DoH). For et system, der er bygget til at gøre DNS-opslag private, er det en ubehagelig kombination: den samme kryptering, der skal skjule dine søgninger for din internetudbyder, kan i praksis vælte den server, som skulle beskytte dig.
BIND har kørt bag store dele af internettets DNS-infrastruktur siden 1980’erne, og selvom ingen kan sige præcis hvor mange servere der bruger softwaren i dag, regnes den fortsat som en af de mest udbredte DNS-motorer i drift. Når ISC finder 14 fejl på én gang, og syv af dem er alvorlige nok til at give denial-of-service, er det derfor ikke bare en teknisk fodnote. Det er en påmindelse om, at privatlivsbeskyttelse via kryptering kun er så stærk som den software, der leverer den.
Hvad er BIND 9, og hvorfor betyder det noget for dit privatliv
BIND (Berkeley Internet Name Domain) er en open source-implementering af DNS-protokollen, udviklet og vedligeholdt af ISC. Softwaren oversætter domænenavne som “shattered.io” til IP-adresser, og den gør det både for almindelige hjemmesider og for de resolvere, internetudbydere og virksomheder stiller op for at besvare DNS-opslag på vegne af deres brugere.
Traditionelt sendes DNS-opslag ukrypteret. Det betyder, at en internetudbyder, en offentlig wifi-administrator eller en anden aktør på netværket kan se hvilke domæner du slår op, selv hvis selve indholdet på siden er krypteret med HTTPS. DNS over HTTPS blev udviklet netop for at lukke det hul: opslaget pakkes ind i en almindelig HTTPS-forbindelse, så det ligner al anden krypteret webtrafik udefra.
Når en BIND-server, der besvarer DoH-forespørgsler, kan crashes med en enkelt forespørgsel uden godkendelse, rammer det altså direkte den infrastruktur, der er bygget til at beskytte brugernes privatliv. En resolver, der er nede, giver ikke bare en fejlmeddelelse, den kan tvinge en klient til at falde tilbage på ukrypteret DNS, hvis den ikke er konfigureret strengt til kun at bruge kryptering.
De 14 sårbarheder: hvad ISC faktisk fandt
ISC offentliggjorde sin liste over rettelser den 16. september 2026, og den samlede pakke er usædvanligt stor til at komme i én runde. De fleste af de 14 fejl falder i kategorien denial-of-service, altså angreb der får serverprocessen “named” til at gå ned eller bruge unormalt meget CPU og hukommelse, i stedet for at give en angriber adgang til data. Det er en vigtig skelnen: ingen af de 14 fejl giver umiddelbart mulighed for at stjæle DNS-svar eller manipulere dem uden videre, men de kan lamme driften.
Fejlene spreder sig over flere dele af BIND’s kodebase: håndtering af DNSSEC-signaturer, behandling af SVCB- og HTTPS-DNS-poster (de relativt nye posttyper, der bruges til at annoncere alternative forbindelsesmuligheder), fortolkning af ondsindede eller fejlformede svar fra andre autoritative servere, og altså specifikt forespørgsler der kommer ind over DNS over HTTPS. ISC skriver, at man ikke har set tegn på aktiv udnyttelse af nogen af sårbarhederne på tidspunktet for offentliggørelsen.
Rettelserne landede i to parallelle udgivelseslinjer: BIND 9.20.29 til dem, der kører den stabile long-term support-gren, og BIND 9.21.26 til dem, der følger udviklingsgrenen. Administratorer, der driver egne DNS-servere eller resolvere, skal opgradere til en af disse versioner (eller nyere) for at være dækket.
CVE-2026-77692: crash uden login via DNS over HTTPS
Den fejl, der har fået mest opmærksomhed, er CVE-2026-77692, som ISC har givet en CVSS-score på 7,5 ud af 10, altså “høj” alvorlighed. Angrebet kræver ingen godkendelse og kan i princippet udføres af hvem som helst, der kan sende en enkelt forespørgsel til en sårbar server.
Mekanikken er relativt simpel, når man kender detaljerne: en angriber sender en DoH-forespørgsel, der indeholder en SIG(0)-signatur, en form for kryptografisk signering af DNS-forespørgsler, som er ugyldig. Umiddelbart efter lukker angriberen forbindelsen, før serveren når at færdiggøre sin validering af signaturen. Den kombination, en ugyldig signatur plus en for tidligt afbrudt forbindelse, får processen “named” til at gå ned. Resultatet er et øjeblikkeligt denial-of-service på præcis den kanal, der skal levere krypterede, private DNS-svar.
Det gør fejlen særligt relevant for privatlivsbevidste brugere og for de tjenester, der specifikt markedsfører sig på krypteret DNS. En resolver, der reklamerer med DoH-support som en privatlivsgevinst, mister den gevinst i det øjeblik den ligger nede, og brugerne enten oplever fejl eller automatisk skifter til en anden, måske mindre privat, DNS-kanal.
De øvrige alvorlige fejl: SVCB, DNSSEC og ressourceudtømning
CVE-2026-77692 er ikke den eneste fejl med høj CVSS-score i denne runde. CVE-2026-81563 har ligeledes fået en score på 7,5 og handler om ressourceudtømning: hvis en DNS-post af typen SVCB eller HTTPS refererer til 14 eller flere ServiceMode-poster i AliasMode, kan behandlingen af den post trække unormalt meget CPU, hvilket i praksis kan bruges til at lamme en server, der cacher eller videresender den slags poster.
To andre fejl, CVE-2026-19662 og CVE-2026-77119, er vurderet til CVSS 5,9, altså “medium”. Blandt de øvrige rettelser nævner ISC problemer med, hvordan BIND håndterer uoverensstemmende NOQNAME-beviser (en del af DNSSEC’s mekanisme til at bevise, at et domæne ikke findes), TKEY-forespørgsler af typen QTYPE, fejlformede svar fra autoritative servere, og negative svar, der er blevet unormalt store, i et tilfælde helt op til 65.536 byte. Fælles for stort set alle 14 fejl er, at de handler om at få serveren til at bruge for meget CPU, hukommelse, eller simpelthen crashe, snarere end at lække data direkte.
Data: de vigtigste sårbarheder fra september-opdateringen
Nedenfor er en oversigt over de sårbarheder fra ISC’s september-runde, hvor der findes en bekræftet CVSS-score. Flere af de resterende 14 fejl er offentliggjort uden en fuldt verificeret score i de kilder, der er tilgængelige på nuværende tidspunkt.
| CVE | CVSS-score | Type | Krypteret DNS-relevans |
|---|---|---|---|
| CVE-2026-77692 | 7,5 (høj) | Uautoriseret crash via DoH | Direkte, rammer DNS over HTTPS-forespørgsler |
| CVE-2026-81563 | 7,5 (høj) | CPU-udtømning via SVCB/HTTPS-poster | Indirekte, kan ramme resolvere der cacher DoH-relevante poster |
| CVE-2026-19662 | 5,9 (medium) | Denial-of-service | Ingen direkte DoH-kobling |
| CVE-2026-77119 | 5,9 (medium) | Denial-of-service | Ingen direkte DoH-kobling |
| Øvrige 10 fejl | Ikke fuldt verificeret | DNSSEC, negative svar, autoritative fejlsvar m.fl. | Varierende, primært driftsstabilitet |
Sådan opdaterer du: kommandoerne du skal køre
Driver du selv en BIND-installation, enten som autoritativ nameserver eller som resolver med DoH-understøttelse, er første skridt at tjekke den kørende version. På de fleste Linux-distributioner kan det gøres sådan:
named -v
# Forventet output bør vise 9.20.29, 9.21.26 eller nyere
# Er versionen ældre, skal pakken opdateres:
sudo apt update && sudo apt install bind9
# eller, afhængigt af distribution:
sudo dnf upgrade bind
Efter opgraderingen bør du genstarte tjenesten og bekræfte, at den kører uden fejl i logfilerne, samt at DoH-lytteren (hvis den er konfigureret) fortsat svarer korrekt på testforespørgsler. ISC’s egen anbefaling er kort og klar: opdater hurtigst muligt, uanset om du kan se tegn på aktivt misbrug eller ej, fordi et proof-of-concept for CVE-2026-77692 i praksis kun kræver én velformet, ondsindet forespørgsel.
Hvem rammes: fra store resolvere til hjemmeservere
Det er ikke muligt at give et præcist tal for, hvor mange servere der reelt kører en sårbar version af BIND lige nu. DNS-infrastruktur er spredt over private netværk, cloud-platforme, internetudbydere, virksomheders interne systemer og registrarer, og langt fra alle offentliggør, hvilken software de bruger. Det, man kan sige med sikkerhed, er, at BIND fortsat er en af de mest udbredte DNS-implementeringer i verden, og at sårbarheden specifikt rammer de installationer, der eksplicit svarer på DoH-forespørgsler, ikke alle BIND-servere generelt.
Store offentlige DoH-udbydere som Cloudflare, Google Public DNS og Quad9 bruger typisk deres egne, ofte proprietære eller kraftigt tilpassede DNS-motorer til deres offentlige resolver-tjenester, og der er ikke offentliggjort oplysninger om, at disse konkrete tjenester skulle være ramt af CVE-2026-77692. Risikoen ligger derfor primært hos de organisationer, universiteter, ISP’er og enkeltpersoner, der selv har sat en BIND-server op med DoH aktiveret, for eksempel som en del af en selvhostet DNS-løsning eller en intern virksomhedsresolver.
Nordisk kontekst
Der findes ingen offentligt dokumenteret bekræftelse på, at dansk statslig DNS-infrastruktur, .dk-registreringen eller navngivne nordiske internetudbydere kører sårbare BIND-installationer med DoH aktiveret. Det betyder ikke, at risikoen er nul, det betyder blot, at der ikke er lavet en offentlig kortlægning af, hvilke danske og nordiske aktører der er berørt. Historisk har flere danske uddannelsesinstitutioner og hostingudbydere kørt BIND som en del af deres DNS-stak, hvilket gør det relevant for danske it-afdelinger at tjekke egne systemer uafhængigt af, om der findes en officiel dansk opgørelse.
Historisk kontekst: BIND’s lange historie med sikkerhedsfejl
BIND er ikke ny på denne front. Softwaren har i over to årtier været genstand for gentagne sikkerhedsopdateringer, netop fordi den er så udbredt og så central for internettets funktion, at enhver fejl i den potentielt rammer et stort antal systemer. Det, der adskiller september 2026-runden, er ikke nødvendigvis alvorligheden af den enkelte fejl, men antallet: 14 sårbarheder på én gang er usædvanligt mange for en enkelt udgivelse, selv for et projekt der jævnligt patcher.
Det afspejler til dels, at DNS-protokollen selv er blevet mere kompleks over tid. Hvor klassisk DNS stort set kun håndterede simple opslag af A- og MX-poster, skal moderne DNS-servere i dag også håndtere DNSSEC-signaturer, SVCB- og HTTPS-poster, samt flere transportlag som DoH og DNS over TLS (DoT). Hvert nyt lag af funktionalitet er også et nyt lag af potentielle fejl, og det er præcis den type kompleksitet, der ligger bag flere af de 14 sårbarheder i denne omgang.
Markedseffekt: tillid til krypteret DNS under pres
DNS over HTTPS har de seneste år vundet indpas som standardfunktion i store browsere, og det har været en del af en bredere bevægelse mod at gøre almindelige brugeres internetadfærd sværere at overvåge på netværksniveau. Når en sårbarhed specifikt rammer den infrastruktur, der leverer den beskyttelse, rejser det et relevant spørgsmål for både virksomheder og privatpersoner: hvor meget tillid kan man lægge i, at en given DoH-udbyder rent faktisk er robust mod denne type angreb?
For udbydere af DNS-tjenester betyder sagen i praksis et pres for hurtigere patch-cyklusser og bedre gennemsigtighed om, hvilken software der ligger bag deres resolvere. Virksomheder, der sælger “krypteret DNS” som en privatlivsfunktion, kan forvente at blive mødt med spørgsmål om, hvordan de har håndteret netop denne opdatering, og om deres infrastruktur overhovedet er baseret på BIND. For konkurrerende DNS-motorer som Unbound, PowerDNS og Knot DNS er episoden potentielt en mulighed for at fremhæve egen sikkerhedshistorik, selvom ingen af de motorer er immune over for lignende fejl i fremtiden.
Sammenligning: BIND over for andre DNS-motorer
BIND er langt fra den eneste DNS-server-software i brug. Flere alternativer har i de senere år vundet frem, delvis netop med argumentet om et mindre og dermed mere overskueligt angrebsflade. Tabellen herunder sammenligner de mest udbredte åbne DNS-implementeringer på centrale parametre.
| DNS-software | Udvikler | Understøtter DoH | Kendt for |
|---|---|---|---|
| BIND 9 | ISC | Ja | Mest udbredte, ældste, bredest featuresæt |
| Unbound | NLnet Labs | Ja | Fokus på resolver-rollen, ofte brugt til selvhostede løsninger |
| PowerDNS | PowerDNS.COM | Ja | Populær hos hostingudbydere og registrarer |
| Knot DNS | CZ.NIC | Delvis, primært via tilføjelser | Høj ydelse på autoritative opslag |
| CoreDNS | CNCF-projekt | Ja | Udbredt i Kubernetes- og cloud-native miljøer |
Ingen af disse alternativer er fri for egne historiske sårbarheder, men de har generelt en mindre kodebase end BIND, hvilket i teorien reducerer antallet af steder, hvor fejl kan opstå. Det gør dem ikke automatisk sikrere i praksis, men det er en del af, hvorfor flere organisationer med et rent DoH-behov vælger et af de smallere alternativer frem for BIND’s fulde featuresæt.
Hvad kan almindelige brugere gøre lige nu
De fleste privatpersoner rammes ikke direkte af denne sårbarhed, fordi de ikke selv driver en DNS-server. Men hvis du bruger en selvhostet DNS-løsning derhjemme, for eksempel som en del af en Pi-hole-opsætning eller en hjemmeserver med DoH aktiveret via BIND, bør du tjekke din version med det samme. Er du usikker på, om din opsætning bruger BIND, kan du typisk se det i konfigurationsfilerne eller ved at spørge den, der har sat løsningen op.
Bruger du i stedet en browserindbygget DoH-funktion, som i Firefox eller Chrome, afhænger din eksponering af, hvilken resolver du har valgt i indstillingerne. De store, kommercielle DoH-udbydere har typisk deres egne driftsteams, der overvåger og patcher løbende, men det skader ikke at holde øje med, om din valgte udbyder udsender en officiel udmelding om sagen.
Tjekliste til it-afdelinger
- Identificér alle interne og eksterne DNS-servere, der kører BIND
- Bekræft versionsnummer på hver installation (mål: 9.20.29, 9.21.26 eller nyere)
- Prioritér servere, der eksplicit besvarer DoH-forespørgsler
- Test funktionalitet efter opgradering, herunder DNSSEC-validering
- Overvåg logfiler for uventede crashes eller genstarter i ugerne efter patch
Fem forudsigelser for krypteret DNS de kommende måneder
Baseret på hvordan lignende sager historisk har udviklet sig, er der en række sandsynlige udviklinger at holde øje med i kølvandet på denne sag.
- Flere sikkerhedsforskere vil teste DoH-implementeringer specifikt. Når en så synlig fejl findes i markedsledende software, plejer det at trigge en bølge af lignende research mod konkurrerende motorer som Unbound, PowerDNS og CoreDNS.
- Store cloud-udbydere vil formentlig præcisere deres software-stak offentligt. Pres fra kunder om gennemsigtighed kan få flere DNS-udbydere til at oplyse, hvilken motor de faktisk kører, noget der historisk ofte har været underkommunikeret.
- ISC vil sandsynligvis stramme sin interne test af nye DNS-posttyper. Flere af de 14 fejl relaterer sig til relativt nye funktioner som SVCB og HTTPS-poster, hvilket peger på et behov for grundigere test, før nye protokolfunktioner rulles ud i produktionskode.
- Forventning om øget interesse for mindre, smallere DNS-motorer. Organisationer med et snævert DoH-behov kan vælge at flytte til software med en mindre kodebase for at reducere angrebsfladen, selvom det ikke fjerner risikoen for fremtidige fejl.
- Flere lande og virksomheder vil formentlig indføre krav om hurtigere patch-vinduer for kritisk DNS-infrastruktur. I takt med at DNS-lag som DoH bliver en integreret del af privatlivsbeskyttelsen for almindelige brugere, øges presset for, at driftsansvarlige patcher inden for dage, ikke uger.
Sådan adskiller denne sag sig fra tidligere DNS-hændelser
DNS-relaterede sikkerhedshændelser er ikke nyt, men de har historisk oftest handlet om cache-forgiftning, altså at en angriber narrer en resolver til at gemme et forkert svar, som så bliver serveret til andre brugere. Denne rundes fejl er markant anderledes: her handler det ikke om at manipulere data, men om at slå selve tjenesten ud, og i det mest alvorlige tilfælde specifikt via den kanal, der er bygget til at kryptere brugerens forespørgsler. Det giver sagen en mere direkte kobling til privatlivsdebatten end en typisk cache-forgiftningssag ville have, fordi konsekvensen ikke er forkerte data, men et fravær af den beskyttelse brugeren troede de havde.
ISC selv beskriver hændelsen relativt afdæmpet, som en samling driftsmæssige denial-of-service-fejl uden tegn på aktiv udnyttelse, snarere end en akut krise. Det ændrer ikke ved, at et proof-of-concept for den mest alvorlige fejl i praksis kun kræver én forespørgsel, hvilket historisk har vist sig at være nok til, at angribere begynder at teste sårbarheden i naturen inden for kort tid efter offentliggørelse.
Kilder og videre læsning
ISC’s fulde oversigt over BIND-sikkerhedsopdateringer ligger på kb.isc.org. Rapporteringen om hændelsen er også dækket af SecurityWeek, The Hacker News og er registreret hos CVE.org. Den bredere diskussion om open source-sikkerhedsprocesser blev også taget op på Openwall oss-security-mailinglisten, mens baggrund om DNS-privatliv generelt kan findes hos Electronic Frontier Foundation.
Ofte stillede spørgsmål om BIND 9-sårbarhederne
Hvad er BIND 9, og hvem bruger det?
BIND 9 er en open source DNS-serversoftware udviklet af Internet Systems Consortium. Den bruges af internetudbydere, hostingselskaber, universiteter og virksomheder til at drive både autoritative nameservere og resolvere.
Er min internetforbindelse i fare på grund af CVE-2026-77692?
Kun hvis du selv driver eller er direkte afhængig af en sårbar BIND-server, der besvarer DoH-forespørgsler. Almindelige brugere, der kun bruger en browsers indbyggede DoH-funktion mod en stor kommerciel udbyder, er ikke automatisk ramt.
Hvilke versioner af BIND 9 er sikre at bruge?
ISC anbefaler at opgradere til BIND 9.20.29 eller nyere på den stabile gren, og BIND 9.21.26 eller nyere på udviklingsgrenen.
Har hackere allerede udnyttet sårbarheden?
ISC oplyser, at man ikke er bekendt med aktiv udnyttelse af nogen af de 14 sårbarheder på tidspunktet for offentliggørelsen den 16. september 2026.
Bruger store DoH-udbydere som Cloudflare eller Quad9 BIND?
Der findes ikke offentliggjorte oplysninger, der bekræfter, at disse konkrete offentlige DoH-tjenester kører en sårbar BIND-installation. De store udbydere anvender typisk egne, tilpassede DNS-motorer til deres offentlige resolver-infrastruktur.
Hvad er forskellen på DoH og almindelig DNS?
Almindelig DNS sender opslag ukrypteret, hvilket gør dem synlige for aktører på netværket, herunder internetudbydere. DNS over HTTPS pakker opslaget ind i en krypteret HTTPS-forbindelse, så det ikke kan læses eller ændres undervejs.
Skal jeg skifte DNS-motor efter denne sag?
Ikke nødvendigvis. Det vigtigste er at holde din nuværende DNS-software opdateret. Et skifte til en anden motor som Unbound eller PowerDNS fjerner ikke risikoen for fremtidige fejl, det ændrer blot hvilken kodebase du er afhængig af.
Hvor kan jeg se den officielle liste over rettelser?
ISC’s fulde oversigt over BIND-sikkerhedsopdateringer, herunder detaljer om hver enkelt CVE, ligger på kb.isc.org/docs/all-bind-advisories.
