Egen DNS-Server Med Kryptering: Unbound i 12 Trin [2026]

Hver gang din computer slår et domænenavn op, ser din internetudbyder med. Almindelig DNS sendes ukrypteret, og selv når du bruger en offentlig resolver som Cloudflare eller Quad9, ligger dine opslag stadig hos en tredjepart uden for dansk eller europæisk jurisdiktion. Løsningen er at køre din egen DNS-over-HTTPS-server. Denne guide viser dig, hvordan du sætter Unbound op fra bunden, aktiverer kryptering med TLS og forbinder dine enheder til din egen resolver på under en time.

Guiden er bygget som et komplet projekt. Du starter med en tom server, og du ender med en fungerende, krypteret og DNSSEC-valideret resolver, som dine egne enheder peger på. Undervejs får du 12 nummererede trin, otte kopierbare kodeblokke, tre datatabeller og et samlet konfigurationseksempel, du kan bruge som skabelon. Sidst i artiklen finder du en fejlfindingstabel med otte typiske problemer og de faldgruber, de fleste nybegyndere rammer, før de får sat serveren korrekt op.

Hvorfor køre din egen dns server i 2026?

Almindelig DNS er stadig ukrypteret de fleste steder. Når din browser spørger “hvad er IP-adressen på example.com”, flyver spørgsmålet af sted i klartekst, og din udbyder eller alle på samme netværk kan læse med. DNS-over-HTTPS (DoH) løser det ved at pakke DNS-opslaget ind i en almindelig HTTPS-forbindelse på port 443, samme port som resten af din webtrafik bruger. Det gør opslagene svære at filtrere fra og umulige at læse undervejs.

Vi har tidligere testet de store offentlige DoH-udbydere som Cloudflare, Quad9 og Mullvad, og de er alle et fremskridt i forhold til ukrypteret DNS. Problemet er, at du stadig overlader dine opslag til en fremmed virksomhed. For danske og nordiske brugere, der tager databeskyttelse alvorligt, er den logiske næste udvikling at hoste resolveren selv. Så bestemmer du, hvor loggen, om nogen, opbevares, og du fjerner et helt lag af tillid til tredjepart.

Unbound er den mest udbredte gratis, open source-resolver til formålet. Fra version 1.12 har programmet indbygget understøttelse af DNS-over-HTTPS, uden at du behøver et separat proxy-lag. Dokumentationen fra NLnet Labs, opdateret i juli 2026 og dækkende version 1.25.2, beskriver DoH-implementeringen som et krav om TLS, der udelukkende kører over HTTP/2. Det er præcis den kombination, vi bygger op i denne guide.

Der er også en driftsmæssig side af sagen, som ofte overses. Kører du selv resolveren, er det dig, der bestemmer TTL-værdier, cache-størrelse og hvilke domæner der eventuelt skal blokeres på netværksniveau. Offentlige resolvere optimerer nødvendigvis efter deres egne millioner af brugere, ikke efter dit specifikke netværk. En selvhostet Unbound-instans kan tunes til præcis den belastning, dit hjem eller din virksomhed genererer, og du undgår at dele en fælles cache-pulje med resten af internettet.

Der er også et bredere digitalt suverænitetsargument i spil. Danske og nordiske virksomheder har det seneste år lagt mere vægt på, hvor deres data reelt behandles, og hvilken lovgivning der gælder for den infrastruktur, de er afhængige af. En DNS-resolver er en lille, men konstant strøm af data om, hvilke tjenester en organisation bruger, hvornår, og hvor ofte. At flytte den strøm fra en amerikansk eller anden ikke-europæisk udbyder til en server, du selv driver på europæisk jord, er et konkret, målbart skridt i den retning, uafhængigt af hvilken position man i øvrigt har til debatten om digital suverænitet.

Dns-lækager: hvorfor en vpn alene ikke er nok

Et af de mest udbredte misforståelser om digitalt privatliv er, at en VPN automatisk løser DNS-problemet. Sådan fungerer det ikke altid. Er en VPN-klient dårligt konfigureret, kan operativsystemet stadig sende DNS-opslag uden om VPN-tunnellen og direkte til udbyderens standard-DNS, et fænomen kendt som DNS-lækage. Din IP-trafik er krypteret og skjult, men din browserhistorik kan stadig læses via DNS-opslagene, som forlader maskinen ukrypteret ved siden af.

Løsningen er at eksplicit pege VPN-forbindelsens DNS-indstilling mod en resolver, du selv kontrollerer, i stedet for at stole på, at klientsoftwaren håndterer det korrekt. Har du allerede sat din egen WireGuard-server op, er næste logiske skridt at lade WireGuard-klienterne bruge din nye Unbound-instans som DNS-server frem for en offentlig tredjepart. Så forbliver hele kæden, fra tunnel til navneopløsning, inden for infrastruktur du selv ejer og kan revidere.

Sådan virker dns over https, og hvorfor unbound

Der findes tre almindelige måder at kryptere DNS-opslag på: DNS-over-TLS (DoT), DNS-over-HTTPS (DoH) og det ældre, ukrypterede plain DNS. Forskellen ligger i, hvilken port trafikken kører på, og hvor let den er at skelne fra anden trafik. DoT bruger sin egen dedikerede port, 853, hvilket gør det nemt for et netværk at blokere protokollen selektivt. DoH derimod deler port med al anden HTTPS-trafik, så et opslag ligner enhver anden hjemmesidevisning udefra.

Protokol	Port	Kryptering	Synlig for udbyder
Plain DNS	53	Nej	Ja, fuldt læsbar
DNS-over-TLS (DoT)	853	Ja	Kan blokeres pr. port
DNS-over-HTTPS (DoH)	443	Ja	Gemt i almindelig HTTPS-trafik

Unbound er det, man kalder en rekursiv resolver. I stedet for at videresende dit opslag til en anden virksomheds server, går Unbound selv ud og spørger internettets rod-servere og de autoritative navneservere direkte, som beskrevet i RFC 8484, standarden bag DNS-over-HTTPS. Det betyder, at ingen enkelt tredjepart ser hele dit opslagsmønster, kun de enkelte trin i kæden. Kombineret med DNSSEC-validering, som Unbound understøtter ude af boksen, får du både privatliv og integritet i dine DNS-svar. Diskussioner på Pi-hole-forummet, senest opdateret i august 2026, peger stadig på det samme grundproblem: usikrede DNS-opslag er godkendte af protokollen, men ikke krypterede, og derfor synlige for enhver, der lytter på linjen.

Rekursiv resolver mod forwarder: forskellen der betyder noget

Mange hjemmenetværk kører allerede en form for lokal DNS, men langt de fleste af dem er forwardere, ikke rekursive resolvere. En forwarder tager imod dit opslag og sender det videre til en anden resolver, typisk udbyderens eller en offentlig tjeneste, og returnerer bare svaret. En ren Unbound-installation som den, vi bygger i denne guide, går derimod selv ud i DNS-hierarkiet, fra rodserverne og ned til den autoritative navneserver for det konkrete domæne. Forskellen lyder teknisk, men den er afgørende for privatliv: med en forwarder ser en enkelt tredjepart stadig hele dit opslagsmønster, mens den rekursive model spreder informationen ud over flere uafhængige parter, der hver kun ser en brøkdel af kæden.

Selvhostet unbound mod offentlige doh-udbydere

Det er værd at sætte de to tilgange op mod hinanden, før du beslutter dig. Offentlige DoH-udbydere er nemmere at komme i gang med, kræver ingen server og har typisk høj oppetid, fordi de driftes af store organisationer med global infrastruktur. Til gengæld sender du hvert eneste opslag til en virksomhed, hvis logningspolitik du må tage for gode varer, og som juridisk kan være underlagt et andet lands lovgivning end dansk eller europæisk ret. En selvhostet Unbound-instans kræver mere opsætning og løbende vedligeholdelse, men giver dig fuld kontrol over logning, jurisdiktion og ydeevne, uden at nogen ekstern part nogensinde ser den samlede liste af domæner, du besøger.

Egenskab	Offentlig DoH-udbyder	Selvhostet Unbound
Opsætningstid	Under 5 minutter	30-60 minutter
Kontrol over logning	Afhænger af udbyderens politik	Fuld kontrol, du sætter reglerne
Jurisdiktion	Ofte uden for EU	Din egen server, din jurisdiktion
Tilpasning af cache og TTL	Ikke muligt	Fuldt konfigurerbar
Vedligeholdelse	Ingen, udbyderen står for drift	Løbende opdateringer og overvågning

Forudsætninger: dette skal du bruge

Du behøver ikke avanceret hardware for at køre en DoH-resolver. En billig VPS eller en Raspberry Pi derhjemme er nok. Her er de komponenter, guiden bygger på.

Komponent	Version/krav	Formål
Operativsystem	Ubuntu Server 24.04 LTS eller Debian 12	Vært for Unbound
Unbound	1.19 eller nyere (dokumenteret op til 1.25.2)	DNS-resolver med indbygget DoH
RAM	Minimum 512 MB	Cache og procesdrift
Domænenavn	Valgfrit, men anbefalet	Gyldigt TLS-certifikat
Certbot	Seneste version fra distributionens repo	Gratis Let’s Encrypt-certifikat
Root/sudo-adgang	Påkrævet	Konfiguration og portbinding
Docker (valgfrit)	24.x eller nyere	Alternativ containeriseret opsætning

Har du allerede et hjemmenetværk med Pi-hole eller AdGuard Home kørende på port 53, skal du planlægge at flytte Unbound til en anden port, typisk 5335, så de to tjenester ikke støder sammen. Vi kommer tilbage til den del i trin 11. Hvis du bruger en VPS hos et europæisk driftsselskab, bør du desuden sikre dig, at udgående port 443 og indgående trafik på samme port ikke er blokeret af en firewall på forhånd.

Beslutningen om hvor serveren skal stå, er ikke ligegyldig. Kører du Unbound på en Raspberry Pi eller en gammel bærbar derhjemme, er din DNS-opløsning afhængig af, at din hjemmeforbindelse er oppe, hvilket typisk er fint til privat brug. Vil du derimod have en resolver, der også virker, når du er ude af huset, eller som flere enheder uden for hjemmenetværket skal bruge, giver en lille VPS hos en europæisk udbyder mere mening. Prisen for en minimal VPS med 512 MB til 1 GB RAM ligger typisk i den lave ende af skalaen hos de fleste udbydere, og det er rigeligt til en Unbound-instans, der betjener en håndfuld enheder.

Trin 1-3: installer unbound og hent root hints

Start med at opdatere systemet og installere Unbound fra din distributions pakkearkiv. På Debian og Ubuntu er kommandoen den samme.

sudo apt update && sudo apt upgrade -y
sudo apt install unbound unbound-anchor -y

# Bekræft installeret version
unbound -V

Da Unbound skal fungere som rekursiv resolver, skal den kende internettets rod-servere. Hent den officielle root hints-fil direkte fra IANA/InterNIC, og placer den, hvor Unbound forventer den.

sudo wget https://www.internic.net/domain/named.root -O /var/lib/unbound/root.hints
sudo chown unbound:unbound /var/lib/unbound/root.hints

# Generér DNSSEC trust anchor
sudo unbound-anchor -a /var/lib/unbound/root.key
sudo chown unbound:unbound /var/lib/unbound/root.key

Opret derefter en grundkonfigurationsfil i mappen unbound.conf.d, så du holder din tilpassede opsætning adskilt fra standardfilerne, hvilket gør fremtidige opdateringer nemmere at håndtere.

sudo nano /etc/unbound/unbound.conf.d/recursive.conf

Trin 4: grundlæggende rekursiv konfiguration

Indsæt følgende basiskonfiguration. Den binder Unbound til localhost på standard DNS-port 53 og aktiverer DNSSEC-validering med den trust anchor, du hentede i sidste trin.

server:
    interface: 127.0.0.1
    port: 53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    root-hints: "/var/lib/unbound/root.hints"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    cache-min-ttl: 300
    prefetch: yes

Genstart tjenesten, og test at den grundlæggende opløsning virker, før du går videre til kryptering.

sudo systemctl restart unbound
sudo systemctl enable unbound
dig @127.0.0.1 example.com

Får du et svar med en IP-adresse tilbage, opløser Unbound allerede DNS korrekt. Fejler dette trin, skal du løse det, før du fortsætter, ellers arver DoH-laget den samme fejl. Et typisk vellykket svar fra dig ser sådan ud i terminalen, med svartid og en tydelig IP-adresse i ANSWER-sektionen.

;; ANSWER SECTION:
example.com.        86151   IN      A       93.184.216.34

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 04 21:12:03 CEST 2026

Læg mærke til den lave forespørgselstid på få millisekunder. Det er cachen, der arbejder: første opslag på et nyt domæne tager typisk 50-150 millisekunder, fordi Unbound skal gå hele vejen gennem DNS-hierarkiet, mens efterfølgende opslag på samme domæne besvares fra cache på under 5 millisekunder, indtil TTL’en udløber.

Trin 5: skaf et tls-certifikat med certbot

DNS-over-HTTPS kræver et gyldigt TLS-certifikat, ligesom en almindelig hjemmeside gør. Har du allerede sat op et gratis certifikat med Certbot til andre formål, kan du genbruge samme flow her. Peg dit domæne mod serverens IP-adresse, og kør Certbot i standalone-tilstand, hvis port 80 er ledig.

sudo apt install certbot -y
sudo systemctl stop unbound
sudo certbot certonly --standalone -d dns.dit-domaene.dk
sudo systemctl start unbound

# Certifikaterne ligger nu her:
# /etc/letsencrypt/live/dns.dit-domaene.dk/fullchain.pem
# /etc/letsencrypt/live/dns.dit-domaene.dk/privkey.pem

Certbot fornyer normalt certifikatet automatisk via en systemd-timer, men da Unbound holder port 443 optaget, skal du tilføje et pre- og post-hook, der stopper og genstarter tjenesten omkring fornyelsen. Det gør du med flagene --pre-hook og --post-hook i din fornyelseskonfiguration under /etc/letsencrypt/renewal/.

Trin 6-7: aktivér dns-over-https og dnssec i unbound

Nu kommer kernen i opsætningen. Opret en ny konfigurationsfil, der udvider serveren med en HTTPS-lytter på port 443, peger på dit certifikat og definerer et endpoint til selve DoH-forespørgslerne. Konfigurationen herunder følger den officielle DoH-dokumentation fra Unbound-projektet, som er den mest pålidelige kilde at vende tilbage til, hvis en fremtidig version ændrer syntaksen.

sudo nano /etc/unbound/unbound.conf.d/doh.conf

server:
    interface: 0.0.0.0@443
    interface: ::0@443
    tls-service-key: "/etc/letsencrypt/live/dns.dit-domaene.dk/privkey.pem"
    tls-service-pem: "/etc/letsencrypt/live/dns.dit-domaene.dk/fullchain.pem"
    https-port: 443
    http-endpoint: "/dns-query"
    tls-ciphers: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
    module-config: "validator iterator"

Linjen module-config: "validator iterator" aktiverer DNSSEC-valideringsmodulet sammen med det almindelige opløsningsmodul. Kombineret med trust anchor-filen fra trin 3 betyder det, at Unbound nu både krypterer transporten via TLS og verificerer, at selve DNS-svarene ikke er blevet manipuleret undervejs. Gem filen, og genstart tjenesten.

sudo unbound-checkconf
sudo systemctl restart unbound

Kommandoen unbound-checkconf validerer syntaksen i alle dine konfigurationsfiler, før tjenesten overhovedet forsøger at genstarte. Spring aldrig dette trin over. En fejl i en produktionskonfiguration opdager du hellere her end via en nede-server klokken tre om natten.

Trin 8-9: test, verificér og åbn firewall

Med konfigurationen på plads skal du bekræfte, at DoH-endpointet rent faktisk svarer korrekt udefra. Brug curl med en DNS-JSON-forespørgsel, eller test lokalt med dig mod den krypterede port.

# Test DoH-endpointet direkte
curl -s -H 'accept: application/dns-json' \
  'https://dns.dit-domaene.dk/dns-query?name=example.com&type=A'

# Test almindelig opløsning lokalt på serveren
dig @127.0.0.1 example.com

Får du et JSON-svar med en gyldig IP-adresse tilbage fra curl-kaldet, virker DoH-laget. Husk at åbne de nødvendige porte i din firewall, inden du tester fra en ekstern klient. Både TCP-port 443 til DoH og UDP/TCP-port 53, hvis du stadig vil tillade almindelig DNS internt på serveren.

sudo ufw allow 443/tcp
sudo ufw allow from 10.0.0.0/8 to any port 53
sudo ufw status verbose

Bind kun port 53 til dit interne netværk, aldrig til hele internettet. En åben rekursiv resolver på port 53 er en klassisk konfigurationsfejl, der kan misbruges til DNS-forstærkningsangreb mod tredjeparter.

Vil du desuden bekræfte, at DNSSEC-valideringen reelt fanger manipulerede svar, kan du teste mod et domæne, der bevidst har en ugyldig DNSSEC-signatur. IETF og flere DNS-organisationer stiller testdomæner til rådighed netop til formålet.

# Gyldigt DNSSEC-domæne: skal returnere svar med "ad"-flag
dig @127.0.0.1 +dnssec example.com

# Forventet output indeholder en linje som:
# ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1

Flaget ad i svaret, kort for “authenticated data”, er beviset på, at Unbound rent faktisk validerede signaturen kryptografisk og ikke bare videresendte svaret blindt. Mangler flaget, selvom du har konfigureret module-config: "validator iterator", er trust anchor-filen sandsynligvis forkert eller udløbet, og du bør køre unbound-anchor igen.

Trin 10: konfigurér klienter til din nye resolver

Når serveren svarer korrekt, skal dine enheder pege på den i stedet for udbyderens standard-DNS eller en offentlig resolver. Fremgangsmåden varierer efter platform.

Windows 11: Gå til Indstillinger > Netværk og internet > din forbindelse > DNS-serverkryptering, og indtast din DoH-adresse i formatet https://dns.dit-domaene.dk/dns-query.
Android: Under Indstillinger > Netværk og internet > Privat DNS, vælg “Værtsnavn for privat DNS-udbyder” og indtast domænet uden protokolpræfiks.
iOS: Kræver en DoH-konfigurationsprofil, som du kan generere med et værktøj som Apple Configurator, eller installere via en mobile-konfigurationsfil (.mobileconfig).
Firefox: Under Indstillinger > Privatliv & sikkerhed > DNS over HTTPS, vælg “Brug udbyder” og indsæt din server-URL som brugerdefineret udbyder.
Chrome: Under Indstillinger > Privatliv og sikkerhed > Sikkerhed > Brug sikker DNS, vælg tilpasset og indtast samme URL.

Test altid opsætningen på en klientenhed efter ændringen. Slå eksempelvis flytrafik fra og til, eller besøg en side, du ikke har åbnet for nylig, så du undgår at teste mod en allerede cachet DNS-post.

Vær opmærksom på, at nogle klienter kræver en genstart af netværksstakken, ikke bare selve indstillingen, før ændringen slår fuldt igennem. På Windows kan det være nødvendigt at rydde den lokale DNS-cache med ipconfig /flushdns, mens Android og iOS typisk anvender den nye resolver med det samme, så snart profilen er gemt. Kør en trafikanalyse i browserens udviklerværktøjer, eller brug en simpel DNS-lækagetest online, for at bekræfte at opslagene reelt går til din egen server og ikke længere til udbyderens standardindstilling.

Firefox har en indbygget sikkerhedsmekanisme, der er værd at kende, før du undrer dig over, hvorfor din custom DoH-server pludselig ikke bliver brugt. Browseren tjekker et såkaldt canary-domæne, use-application-dns.net, og hvis netværkets almindelige DNS ikke kan finde det domæne, antager Firefox, at en netværksadministrator bevidst har blokeret det for at signalere “brug ikke DoH her”, og slår automatisk funktionen fra. Sørger du for, at din Unbound-instans løser almindelige domæner korrekt, herunder dette canary-domæne, undgår du problemet helt. Du kan verificere status direkte i browseren under about:networking#dns, hvor det fremgår, om DoH aktivt er i brug.

Trin 11: kæd unbound sammen med pi-hole eller adguard home

Mange kører allerede en reklame- og sporingsblokerer som Pi-hole eller AdGuard Home derhjemme, og begge lytter typisk på port 53. Løsningen er at flytte Unbound til port 5335 og lade blokeringsværktøjet fungere som det første lag, der derefter sender ufiltrerede opslag videre til din krypterede Unbound-instans.

server:
    interface: 127.0.0.1@5335
    access-control: 127.0.0.1/32 allow

# Test at Unbound svarer på den nye port
dig @127.0.0.1 -p 5335 google.com

I AdGuard Home-webgrænsefladen sætter du derefter dine upstream-servere til 127.0.0.1:5335 og angiver en bootstrap-server, for eksempel 9.9.9.9 eller 1.1.1.1, som kun bruges til at slå selve navnet på din upstream-resolver op, hvis det ikke allerede er en ren IP-adresse. Resultatet er en kæde, hvor reklamer og sporingsdomæner blokeres først, og alt det resterende DNS-trafik derefter krypteres og valideres af din egen Unbound-instans.

Trin 12: kør unbound som docker-container (alternativ)

Foretrækker du en containeriseret opsætning frem for at installere Unbound direkte på værten, findes der aktivt vedligeholdte Docker-images med indbygget DoH-understøttelse. Det gør opdateringer og gendannelse enklere, især hvis du allerede kører andre tjenester i Docker.

docker run -d \
  --name unbound \
  -p 443:443 \
  -p 53:53/udp \
  -v /etc/unbound/unbound.conf.d:/etc/unbound/unbound.conf.d \
  -v /etc/letsencrypt:/etc/letsencrypt:ro \
  --restart unless-stopped \
  madnuttah/unbound

Monter din eksisterende konfigurationsmappe og dine Let’s Encrypt-certifikater som read-only volumener, så containeren bruger nøjagtig den samme opsætning, du allerede har testet. Fordelen ved denne metode er, at en opdatering af Unbound blot kræver et nyt image i stedet for en systempakke-opgradering, hvilket er praktisk, hvis du kører flere tjenester på samme vært.

Ulempen er, at du mister lidt af den finkornede kontrol, systemd giver dig over genstartslogik og logrotation, medmindre du selv sætter det op omkring containeren. Kører du i forvejen en Docker Compose-stak til andre selvhostede tjenester, er det oftest bedst at føje Unbound til den samme docker-compose.yml-fil, så hele setuppet starter og genstarter samlet, og du undgår at holde styr på en enkeltstående container ved siden af resten af infrastrukturen.

Hvem har mest gavn af at selvhoste dns over https

Ikke alle behøver dette projekt, og det er værd at være ærlig om det. Den typiske hjemmebruger, der bare vil undgå at udbyderen logger hvert eneste besøgt domæne, får det meste af gevinsten allerede ved at skifte til en offentlig DoH-udbyder som Cloudflare eller Quad9. Der er tre grupper, hvor selvhosting giver et mærkbart ekstra lag.

Udviklere og administratorer, der allerede driver anden infrastruktur, og som ønsker samme kontrolniveau over DNS som over resten af stakken, inklusive muligheden for at debugge opslag direkte i loggen.
Mindre danske og nordiske virksomheder, der er omfattet af NIS2-kravene om leverandørstyring, og som ønsker at minimere antallet af eksterne databehandlere, en enkelt selvhostet DNS-tjeneste kan fjerne fra listen.
Privatlivsbevidste brugere, der allerede kører andre selvhostede tjenester som Pi-hole, en VPN-server eller en password manager, og som ser DNS som det sidste manglende stykke i et sammenhængende, selvkontrolleret setup.

Er du derimod en enkelt bruger, der sjældent rejser og ikke har andre selvhostede tjenester i forvejen, kan den løbende vedligeholdelse hurtigt veje tungere end gevinsten. I det tilfælde er en offentlig DoH-resolver stadig et solidt og markant sikrere valg end ukrypteret standard-DNS fra din internetudbyder. Overvej opsætningen som en investering af tid nu mod uafhængighed senere, snarere end en engangsopgave, der skal give øjeblikkeligt afkast.

Sikkerhedshærdning af din doh-server

En fungerende DoH-server er ikke nødvendigvis en sikker en. Begræns adgangen med access-control-direktiver, så kun kendte netværk eller IP-ranges må sende rekursive forespørgsler, medmindre du bevidst driver en offentlig resolver. Brug moderne cifre som TLS_AES_256_GCM_SHA384 og TLS_CHACHA20_POLY1305_SHA256, som opfylder nutidens TLS 1.3-standard, og undgå ældre cipher-suiter, der stadig accepteres af mange standardopsætninger.

Skjul serverens identitet og versionsnummer med hide-identity: yes og hide-version: yes, så et scan udefra ikke afslører præcis hvilken Unbound-version du kører. Hold desuden systemet opdateret med automatiske sikkerhedsopdateringer, og overvej at logge kun aggregerede metrics frem for hvert enkelt opslag, hvis privatliv er hele formålet med projektet. Til sidst bør du rotere din trust anchor-fil periodisk med unbound-anchor, så DNSSEC-valideringen forbliver korrekt, selv hvis rodnøglerne ændres. Læs mere om det officielle Unbound-projekt og dets vedligeholdelse hos NLnet Labs.

Overvej også hvem der overhovedet skal kunne administrere serveren. Kør SSH med nøglebaseret login frem for adgangskode, sæt fail2ban op til at blokere gentagne loginforsøg, og luk enhver port, der ikke aktivt bruges af Unbound eller din firewall-styring. En DNS-server, der i øvrigt er sat perfekt op med kryptering og DNSSEC, giver dig ikke meget privatliv, hvis selve serveren kan overtages via en glemt, åben administrationsport. Betragt DoH-opsætningen som ét lag i en bredere hærdning af hele maskinen, ikke som en isoleret opgave.

Almindelige faldgruber, du skal undgå

Portkonflikt med eksisterende DNS-tjenester: Kører du allerede Pi-hole, AdGuard Home eller systemd-resolved på port 53, fejler Unbound stille, medmindre du flytter den til en anden port som beskrevet i trin 11.
Manglende firewall-regler: Glemmer du at åbne port 443 udadtil, virker alt lokalt, men ingen eksterne klienter kan nå din server, hvilket typisk fejlfindes forkert som et Unbound-problem.
Udløbet certifikat efter Certbot-fornyelse: Uden korrekte pre- og post-hooks stopper certifikatfornyelsen ikke Unbound først, og fornyelsen fejler, fordi porten allerede er optaget.
Åben rekursiv resolver: Binder du Unbound til 0.0.0.0 på port 53 uden adgangskontrol, kan din server misbruges i DNS-forstærkningsangreb mod andre.
Forkerte rettigheder på root hints-filen: Kører Unbound-processen som en dedikeret bruger, men filen ejes af root, nægter tjenesten at starte med en kryptisk fejlmeddelelse om manglende læserettigheder.
Test mod cachede resultater: Ændrer du DNS-indstillinger på en klient og tester med en side, browseren allerede har besøgt, ser det ud som om intet er sket, selvom opsætningen faktisk virker.

Fejlfinding: 8 typiske problemer og løsninger

Selv med forudsætningerne på plads støder de fleste brugere på mindst ét af følgende problemer i løbet af den første uge. Tabellen samler de mest almindelige fejl fra denne guide sammen med den hurtigste vej til en løsning, så du slipper for at grave dig gennem lange forumtråde for at finde svaret. De fleste af dem skyldes enten en portkonflikt eller en fil med forkerte rettigheder, så tjek altid de to ting først, uanset hvad fejlmeddelelsen konkret siger.

Problem	Sandsynlig årsag	Løsning
Unbound starter ikke	Syntaksfejl i konfigurationsfil	Kør `unbound-checkconf` og ret den rapporterede linje
“Address already in use” på port 53	systemd-resolved eller anden DNS-tjeneste bruger porten	Deaktivér den anden tjeneste, eller flyt Unbound til port 5335
DoH-endpoint svarer ikke udefra	Firewall blokerer port 443	Åbn TCP 443 med `ufw` eller din cloud-udbyders sikkerhedsgruppe
Certbot-fornyelse fejler	Port 80/443 optaget af Unbound under fornyelse	Tilføj pre-hook og post-hook, der stopper/starter Unbound
DNSSEC-validering fejler for alle domæner	Forkert eller manglende trust anchor-fil	Kør `unbound-anchor -a /var/lib/unbound/root.key` igen
“Permission denied” ved opstart	Forkerte filrettigheder på root hints eller certifikater	Kør `chown unbound:unbound` på de relevante filer
Klient kan ikke bruge privat DNS på Android	Ugyldigt eller selvsigneret certifikat	Brug et Let’s Encrypt-certifikat i stedet for selvsigneret
Langsomme opslag efter opsætning	Manglende cache-tuning eller prefetch deaktiveret	Aktivér `prefetch: yes` og juster `cache-min-ttl`

Avancerede tips til drift i produktion

Når grundopsætningen kører stabilt, kan du finjustere yderligere. Overvej at sætte num-threads til antallet af CPU-kerner på din server for bedre gennemløb under høj belastning, og brug msg-cache-size samt rrset-cache-size til at give Unbound mere hukommelse til caching, hvis serveren betjener flere klienter samtidig. Til overvågning kan du aktivere Unbounds indbyggede statistikmodul med statistics-interval og eksportere tallene til et værktøj som Prometheus via en simpel exporter, så du kan følge cache hit-rate og forespørgselsvolumen over tid.

To yderligere funktioner er værd at kende, selvom de ikke er nødvendige for en grundopsætning. Den ene er split-horizon DNS via local-zone og local-data-direktiver, som lader dig give interne enheder på dit netværk et andet svar end resten af verden, praktisk hvis du kører interne services under et domæne, du også ejer offentligt. Den anden er ratelimit, som begrænser, hvor mange forespørgsler et enkelt domæne kan generere pr. sekund. Det beskytter din server mod at blive misbrugt som et led i et forstærkningsangreb, selv hvis en adgangskontrolfejl skulle opstå et andet sted i konfigurationen.

Hvis du driver resolveren for mere end din egen husstand, bør du også overveje redundans. Sæt en sekundær Unbound-instans op på en anden fysisk lokation eller VPS, og lad klienterne konfigureres med begge adresser, så en enkelt servernedetid ikke betyder tabt DNS-opløsning. Til sidst kan du eksperimentere med DNS-over-QUIC, som er ved at blive understøttet af flere resolvere, men indtil videre er DoH med Unbound det mest modne og bredt kompatible valg for et selvhostet setup i 2026.

Vedligeholdelse: sådan holder du serveren kørende over tid

En DNS-server er ikke et projekt, du sætter op én gang og glemmer. Sæt en fast rutine for opdateringer, gerne via distributionens automatiske sikkerhedsopdateringer, og hold øje med Let’s Encrypt-certifikatets udløbsdato, selv med automatisk fornyelse aktiveret. Et enkelt mislykket cron-job kan efterlade dig med et udløbet certifikat, og alle dine klienter mister DNS-opløsning uden varsel, fordi TLS-håndtrykket fejler.

Det er også værd at tænke på DNS-serveren som en del af et bredere selvhostet privatlivssetup frem for et isoleret projekt. Har du allerede en selvhostet password manager som Vaultwarden, følger den samme logik: du fjerner en afhængighed af en ekstern tredjepart og tager kontrollen over dine egne data tilbage. Kombinerer du din egen DNS-server, din egen VPN og din egen password manager, ender du med en infrastruktur, hvor ingen enkelt udbyder kender hele dit digitale mønster. Vil du læse mere om de grundlæggende principper bag den slags beslutninger, har vi samlet dem på vores temaside om privatliv.

Komplet konfigurationseksempel

Her er den samlede konfiguration fra guiden, sat sammen i én fil, så du har et fuldt fungerende udgangspunkt at kopiere og tilpasse med dit eget domænenavn og dine egne certifikatstier.

server:
    # Grundlæggende rekursiv opløsning
    interface: 127.0.0.1
    port: 53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    root-hints: "/var/lib/unbound/root.hints"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    cache-min-ttl: 300
    prefetch: yes
    access-control: 127.0.0.1/32 allow
    access-control: 10.0.0.0/8 allow

    # DNS-over-HTTPS
    interface: 0.0.0.0@443
    interface: ::0@443
    tls-service-key: "/etc/letsencrypt/live/dns.dit-domaene.dk/privkey.pem"
    tls-service-pem: "/etc/letsencrypt/live/dns.dit-domaene.dk/fullchain.pem"
    https-port: 443
    http-endpoint: "/dns-query"
    tls-ciphers: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
    module-config: "validator iterator"

Gem filen, kør unbound-checkconf for at fange eventuelle tastefejl, og genstart tjenesten. Du har nu en komplet, krypteret og DNSSEC-valideret DNS-server, som du selv kontrollerer fra ende til anden.

Herfra er projektet i drift, ikke afsluttet. Sæt en påmindelse i kalenderen til at tjekke certifikatets status om tre måneder, gennemgå adgangskontrollisten en gang imellem, og hold øje med, om nye enheder i husstanden eller på kontoret rent faktisk bruger din nye resolver frem for udbyderens standard-DNS. De 12 trin ovenfor er grundstenen, resten handler om vedligeholdelse.

Ofte stillede spørgsmål

Er det lovligt at køre sin egen DNS-server i Danmark?
Ja. Der er ingen juridiske hindringer for at drive en privat DNS-resolver, hverken til eget brug eller for en mindre gruppe. Du har blot selv ansvaret for driften og for at overholde almindelige regler om databehandling, hvis du logger forespørgsler fra andre end dig selv.

Skal jeg have et domænenavn for at bruge DNS-over-HTTPS?
I praksis ja, fordi et gyldigt TLS-certifikat fra en udsteder som Let’s Encrypt kræver et domænenavn. Du kan bruge et gratis subdomæne fra en dynamisk DNS-udbyder, hvis du ikke vil købe et fuldt domæne.

Kan jeg køre Unbound på en Raspberry Pi?
Ja, Unbound er let nok til at køre fint på en Raspberry Pi 4 eller nyere, selv sammen med Pi-hole på samme enhed, så længe du følger portadskillelsen beskrevet i trin 11.

Hvad er forskellen på Unbound og AdGuard Home?
AdGuard Home er primært en blokeringstjeneste med en indbygget forenklet DNS-server, mens Unbound er en fuldgyldig rekursiv resolver bygget til opløsning, caching og DNSSEC-validering. De to supplerer hinanden bedst, når de kædes sammen frem for at erstatte hinanden.

Gør DNS-over-HTTPS mig helt anonym online?
Nej. DoH skjuler dine DNS-opslag fra din netværksudbyder, men din browsing kan stadig spores via IP-adresse, cookies og fingerprinting. Vil du have anonymitet på netværksniveau, bør du kombinere din egen resolver med et værktøj som Tor Browser eller en pålidelig VPN.

Kan jeg bruge min egen DoH-server sammen med WireGuard?
Ja, og det er faktisk en solid kombination. Sætter du din egen WireGuard-VPN-server op, kan du pege VPN-klienternes DNS-indstilling direkte mod din Unbound-instans, så al trafik, inklusive DNS, forbliver inden for din egen infrastruktur.

Hvorfor logger min server stadig forespørgsler, selvom jeg ikke har bedt om det?
Unbound logger som standard kun fejl og advarsler, ikke selve forespørgslerne. Ser du detaljeret forespørgselslogning, har du sandsynligvis aktiveret log-queries: yes i en konfigurationsfil, som du bør slå fra igen, hvis formålet er maksimalt privatliv.

Hvor ofte skal jeg opdatere Unbound?
Følg din distributions almindelige sikkerhedsopdateringer, og tjek NLnet Labs’ officielle projektside for større versionsspring et par gange om året. DNS-software er et yndet mål for angreb, så hold den opdateret på linje med resten af din serverinfrastruktur.

Kan jeg blande DoH og almindelig DNS på samme server?
Ja. Konfigurationseksemplet i denne guide gør netop det: Unbound lytter både på port 53 til lokalt netværk og på port 443 til krypterede DoH-forespørgsler udefra, styret af to separate interface-linjer i samme konfiguration.

Hvad sker der, hvis min server går ned?
Dine klienter mister DNS-opløsning, medmindre du har konfigureret en sekundær resolver som reserve. De fleste operativsystemer og browsere lader dig angive mere end én DoH-adresse, så et fald i din primære server ikke lukker hele netværket ude fra internettet.

Hvad koster det at drive sin egen DNS-over-HTTPS-server?
Den løbende omkostning er typisk prisen på en lille VPS, hvis du ikke allerede har hardware kørende derhjemme, plus eventuelt et domænenavn, hvis du ikke bruger et gratis dynamisk DNS-subdomæne. Selve softwaren, Unbound, Certbot og Let’s Encrypt-certifikatet, er gratis og open source.