Privat DNS til VPS-netværk: sådan fungerer det, og hvornår du har brug for det

Du starter en tredje server, vil have maskinerne til at nå hinanden via navn i stedet for IP, og søger på "private DNS VPS". Tre resultater kommer tilbage, og de er ikke enige. Det ene er en Android-indstilling, der krypterer din telefons opslag. Det andet er en cPanel-guide til at brande navneservere på et domæne. Det tredje er et AWS-dokument om private hosted zones. Den 20. juli 2026 Cloudflare gjorde Internal DNS alment tilgængelig og beskrev det som "nogle gange også omtalt som privat DNS", så forvekslingen kommer nu også fra infrastrukturleverandører.

Begrebet er overbelastet. Denne artikel adskiller de forskellige betydninger og fokuserer derefter på VPS-netværksbetydningen: en intern DNS-zone til kommunikation mellem servere. Til sidst kan du identificere, hvilket system du har brug for, afgøre om din serverpark kræver privat DNS, og undgå almindelige designfejl.

TL;DR

• "Privat DNS" dækker mindst tre urelaterede systemer: en intern DNS-zone til et servernetværk, Androids DNS-over-TLS-krypteringsfunktion og cPanels brandede navneservere. Denne artikel bruger begrebet i den første betydning: en intern DNS-zone til et VPS-netværk.
• En privat DNS-zone på en VPS er et netværksafgrænset internt navnerum, der knytter værtsnavne som db.internal.example.com til private IP-adresser. Dens poster offentliggøres ikke i offentligt DNS.
• For en håndfuld servere med stabile IP-adresser er /etc/hosts faktisk nok. En intern DNS-server tjener sig først ind, når serverparken vokser, IP-adresser skifter ofte, eller tjenester kræver pålidelig navneopslagning.
• Brug til de fleste VPS-netværk i produktion et underdomæne, du selv ejer, for eksempel internal.example.com. Brug kun navnerummet .internal til en isoleret opsætning, hvor navnekollisioner på tværs af netværk, certifikathåndtering via en privat CA og særlig DNSSEC-behandling er acceptable. Undgå .local, som mDNS reserverer.

Hvad denne artikel ikke dækker

Denne artikel holder sig til VPS-netværksbetydningen af privat DNS. Den dækker ikke urelaterede forbruger- og hostingbrandanvendelser:

• Konfiguration af Androids indstilling for privat DNS eller DNS-over-TLS på en telefon.
• Opsætning af private navneservere i cPanel til et hostingbrand.
• En komplet installationsvejledning til BIND 9, Unbound, dnsmasq eller CoreDNS. Implementeringen holder sig her på referenceniveau, ikke trin-for-trin-konfiguration.
• Krypterede forbrugerresolvere som 1.1.1.1 eller NextDNS, ud over at skelne dem fra netværksbetydningen.

Hvad betyder "privat DNS" egentlig?

"Privat DNS" er ikke ét system. Begrebet dækker mindst tre urelaterede: en netværksbegrænset DNS-zone, der slår interne værtsnavne op inde i et VPS- eller VPC-netværk, Androids DNS-over-TLS-krypteringsfunktion og cPanels specialbrandede autoritative navneservere. Denne artikel handler om det første, den interne zone, dine servere forespørger for at finde hinanden. Der findes også en fjerde, løsere brug: krypterede offentlige resolvere, der markedsføres som "private".

De fire betydninger deler et navn og intet andet:

Cloudflares annoncering af almen tilgængelighed for Internal DNS er et aktuelt managed eksempel på den første betydning og en af grundene til, at forvekslingen nu bliver synlig: en infrastrukturleverandør bruger nu "privat DNS" som synonym for internt DNS i sin lanceringstekst. Systemet, den beskriver, en Gateway Resolver plus Internal Authoritative DNS til Enterprise-kunder, hører til samme kategori som det, du selv bygger på en VPS-park, bare som managed løsning.

Afsnitskonklusion: de vigtigste systemer, der kaldes "privat DNS", deler en etiket, ikke en funktion. Find ud af, hvilken betydning der menes, før du følger en opsætningsguide.

Hvordan fungerer privat DNS på et VPS-netværk?

En privat DNS-zone på en VPS er et netværksafgrænset navnerum, der leveres af en resolver, dine servere er sat op til at bruge. Den knytter interne værtsnavne som db.internal.example.com til private IP-adresser i et interval, du selv styrer. Posterne offentliggøres ikke i offentligt DNS, selvom forespørgslerne kan løbe gennem en privat tunnel eller et managed DNS-kontrolplan, før de når resolveren. Netop den adskillelse er kernen i forskellen mellem privat og offentligt DNS: protokollen er den samme, men zonens synlighed og adgangsomfang er forskellige.

Tre dele udfører arbejdet. En autoritativ server eller zonekilde rummer den interne zone og dens poster. En resolver besvarer de forespørgsler, dine servere sender. Og zonens A- og AAAA-poster knytter interne værtsnavne til private adresser, så app.internal.example.com peger på applikationslaget, og db.internal.example.com peger på databasen. Andre posttyper kan levere aliasser eller serviceoplysninger. Når zonen og resolverstien er sat rigtigt op, besvarer resolveren den interne forespørgsel lokalt i stedet for at sende den mod den offentlige DNS-rod.

Cloudplatformene knytter dette til netværket i stedet for maskinen, hvilket er en nyttig referencemodel. AWS Route 53 private hosted zones virker kun, når VPC'en har både enableDnsHostnames og enableDnsSupport sat til true, og resolveren svarer fra den private zone for enhver VPC, du knytter til den. Google Clouds private zoner er begrænset til autoriserede VPC-netværk, og i standardopslagsrækkefølgen i en VPC tjekkes de før offentligt DNS, medmindre en udgående serverpolitik ændrer stien. Læs det som illustrationer af mønstret, ikke som platformsvejledninger: en selvadministreret intern DNS-server er den samme idé, bare kørt på din egen VPS.

At holde zonen ude af offentligt DNS er kun det halve arbejde. Bind DNS-tjenesten til en privat grænseflade, eller begræns UDP- og TCP-port 53 til dit private netværk eller VPN. Udstil ikke den rekursive tjeneste for det offentlige internet; en åben resolver kan misbruges i DNS-forstærkningsangreb.

Private og offentlige zoner bruger den samme model for DNS-poster og caching. Poster bærer en TTL, og cachende resolvere genbruger normalt et svar, indtil den TTL udløber, selvom resolverspecifikke indstillinger kan ændre den reelle cachetid. Den adfærd gennemgår vi i vores guide til at pege et domæne mod en VPS, herunder grundlaget for DNS-propagering og TTL, så det forklares ikke igen her.

Hvornår har dit VPS-netværk reelt brug for privat DNS?

For to eller tre statiske servere er /etc/hosts faktisk nok. En intern DNS-server tjener sig ind, når serverparken vokser, IP-adresser skifter jævnligt, eller applikationer kræver pålidelig service discovery. Den egentlige udløser er driftsmæssig kompleksitet, ikke et fast antal servere.

/etc/hosts er en statisk oversigt fra værtsnavn til IP, som allerede findes på enhver Linux-maskine. Den kræver hverken dæmon eller zonefil, men forældede eller uens kopier er reelle fejlkilder. Tilføj hver servers private IP til filen, hold kopierne synkroniserede, og maskinerne kan finde hinanden via navn. For en lille, stabil serverpark er det det rigtige svar, og at gribe til BIND 9 i stedet tilføjer blot en dæmon at vedligeholde uden nogen gevinst.

Det holder op med at skalere i tre situationer. Når du hyppigt tilføjer og fjerner servere, bliver det manuelt slid at holde en statisk fil konsistent på hver vært. Når IP-adresser ændrer sig gennem autoskalering, genopbygninger eller udbyderens omfordelinger, forældes filen lydløst. Og når containere eller isolerede runtimes ikke arver værtens poster, er tilknytningen ikke længere universel. Enhver af dem er den egentlige udløser. Antallet af servere alene er et groft pejlemærke, ikke det reelle signal.

Afsnitskonklusion: udløseren er driftsmæssig udskiftning, ikke antallet af servere. En fastfrosset park på ti maskiner kan sagtens leve med /etc/hosts; en park på tre maskiner, der genopbygges hver nat, bør nok ikke.

Byg på en Linux VPS med root-adgang, NVMe og AMD EPYC-kraft.

Se Linux-planer

Hvilken DNS-server bør du køre: BIND 9, Unbound, dnsmasq eller CoreDNS?

Vælg efter formen på din serverpark. dnsmasq passer til små netværk, der vil have letvægts-DNS og, hvor det er relevant, DHCP fra samme dæmon. Unbound er en slank validerende rekursiv resolver, der også kan besvare en beskeden lokal zone. BIND 9 giver brede autoritative og rekursive evner med den største konfigurationsflade. CoreDNS passer til container- og Kubernetes-parker, hvor DNS er en del af service discovery.

Udvælgelseslogikken er kort. Har du brug for en lille resolver baseret på en hosts-lignende fil, eller uddeler du allerede DHCP-lejemål, fjerner dnsmasq en bevægelig del. Har du mest brug for en validerende resolver, der videresender udad og besvarer en beskeden intern zone, giver Unbound netop det smallere funktionssæt uden en fuld BIND 9-udrulning. Har du brug for fuld autoritativ kontrol, delegering og den største mængde dokumentation at læne dig op ad klokken tre om natten, er BIND 9 det konservative valg trods den bredere konfigurationsflade. Er DNS allerede en del af en container- eller Kubernetes-stak til service discovery, møder CoreDNS den, hvor den er. Tommelfingerreglen er at køre det mindste, der dækker formen på din serverpark.

I en produktionspark bør du ikke gøre én DNS-instans til den eneste vej til hvert internt navn. Kør mindst to DNS-instanser der kan besvare zonen, placer dem i adskilte fejldomæner, hvor det er praktisk muligt, og konfigurer klienterne til at nå begge. Ellers kan ét DNS-udfald få sunde tjenester til at se døde ud.

Hvad skal dit interne domæne hedde: .internal, .local eller et underdomæne?

Brug til de fleste VPS-netværk i produktion et underdomæne, du selv ejer, for eksempel internal.example.com. Brug kun navnerummet .internal til en isoleret opsætning, hvor navnekollisioner på tværs af netværk, certifikathåndtering via en privat CA og særlig DNSSEC-behandling er acceptable. Undgå .local, som mDNS reserverer.

Problemet med .local er konkret. RFC 6762 giver navne, der ender på .local, særlig behandling under Multicast DNS, så en unicast-zone i BIND 9 eller Unbound med samme endelse kan kollidere med mDNS-adfærd på Apple-enheder og andre mDNS-aktiverede systemer. Brug et andet navnerum i stedet for at læne dig op ad klientspecifikke nødløsninger.

Pro-tip: Har du arvet en intern .local-zone, så behandl den som teknisk gæld. Nogle klienter sender .local-forespørgsler til mDNS i stedet for til din unicast-DNS-server, hvilket kan give klientafhængige eller tilsyneladende sporadiske fejl.

ICANN's bestyrelse har permanent reserveret .internal fra delegering i den offentlige DNS-rod i juli 2024 efter en tidligere SSAC-anbefaling. Navne herunder vil per design ikke kunne slås op via det globale DNS. Det medfører afvejninger: .internal-navne er ikke globalt unikke, offentlige certifikatmyndigheder forventes ikke at udstede certifikater til dem, og DNSSEC-validerende resolvere, der læner sig op ad det globale tillidsanker, vil ikke kunne slå dem op. Har du brug for HTTPS på .internal, så planlæg at drive en privat CA.

Hold to ting adskilt her. ICANN's reservation er endelig. Adskilt fra den blev et aktivt Internet-Draft, draft-davies-internal-tld-06offentliggjort den 6. maj 2026 for at dokumentere navnerummet og sammenligne det med privat adressering efter RFC 1918. Det er stadig et Internet-Draft under udarbejdelse og ikke en udgivet RFC, så beskriv .internal som et ICANN-reserveret topdomæne til privat brug, ikke som en IETF-standard.

For de fleste VPS-parker er et underdomæne under et domæne, du selv styrer, det sikreste standardvalg. ISC anbefaler et hierarki af underdomæner, for eksempel et internt underdomæne under dit eget domæne, frem for at vedligeholde adskilte og ufuldstændige interne og offentlige udgaver af den samme overordnede zone. Den præference er ikke et spørgsmål om stil; den forhindrer fejlen i næste afsnit.

Afsnitskonklusion: beslutningen om navnerum lever længe. Et underdomæne, du selv styrer, er standarden i de fleste produktionsmiljøer, fordi det bevarer global entydighed og fungerer med offentlig PKI. Brug .internal, når et isoleret privat navnerum passer bedre, og du accepterer dets afvejninger omkring DNSSEC, certifikater og kollisioner.

Split-horizon-DNS og de fejl, der ødelægger det

Split-horizon-DNS giver det samme værtsnavn forskellige svar alt efter, hvem der spørger: den private IP indefra, den offentlige IP udefra. Det går oftest galt på grund af NXDOMAIN fælden inden for samme domæne, alternative resolvere, der omgår den tiltænkte visning, og container-DNS-stier, der ikke når den forventede upstream. At få det rigtigt afhænger af tre ting på én gang, ikke af én.

NXDOMAIN-fælden er præcis den fejl, som ISC advarer direkte imod. Hvis dine interne servere er autoritative for det overordnede domæne, men deres udgave af zonen ikke indeholder en offentlig post som www-værten, får en intern klient, der slår det navn op, NXDOMAIN tilbage, selvom den offentlige zone har posten. Den interne zone er autoritativ og falder ikke tilbage på offentligt DNS for det overordnede domæne. Netop derfor er tilgangen med underdomænehierarki fra navngivningsafsnittet det design, ISC foretrækker.

Pro-tip: Før du peger dine servere mod en split-horizon-opsætning inden for samme domæne, så test indefra netværket et opslag på et kendt offentligt navn i det domæne. Et NXDOMAIN-svar på et navn, der slår fint op udefra, er signaturen på denne fælde.

Tre yderligere faldgruber er lette at overse. En alternativ resolver, der er konfigureret på en vært eller en container, kan omgå opdelingen; afhængigt af resolverens implementering kan den blive forespurgt efter et timeout eller parallelt, så svarene kan variere. Containere på Dockers standardbro får ved opstart en kopi af værtens DNS-konfiguration, mens containere på brugerdefinerede netværk forespørger Dockers indbyggede resolver på 127.0.0.11. Den resolver videresender eksterne opslag til de DNS-servere, der er konfigureret for værten eller containeren, så split-DNS-adfærden afhænger af Docker- og værtskonfigurationen og ikke kun af containerens egen resolverfil. Hvis en intern tjeneste ligger bag en reverse proxy som Nginx Proxy Manager, kan certifikatvalidering slå fejl, når certifikatet ikke dækker det anmodede værtsnavn, eller når den udstedende CA ikke er betroet af klienten. At bruge et andet certifikat internt er ikke i sig selv en fejl. Det er huller i konfigurationen, ikke fejl i værktøjerne.

Fjernklienter kan ramme den samme fejl, når en selvhostet VPN ikke skubber eller ruter DNS-forespørgsler til den tiltænkte interne resolver.

Der er også en sikkerhedsdimension. Hvis interne værtsnavne og private IP-adresser siver ud i offentlige DNS-poster, har du blotlagt en del af din interne navngivnings- og adresseringsplan for enhver, der spørger. Split-horizon findes blandt andet for at holde det kort internt, og en fejlkonfigureret offentlig zone ophæver det lydløst.

Afsnitskonklusion: split-horizons fejl er konfigurationsfælder, ikke mangler ved værktøjerne. Korrekthed afhænger af navngivningsdisciplin, af at vide hvilken resolver hver klient faktisk forespørger, og af at afgrænse zonen rigtigt, ikke af én enkelt indstilling.

LÆS

Sådan peger du et domæne til VPS: En hurtig vejledning

Konklusion: at vælge det rigtige design til privat DNS

Du kan nu identificere, hvilket "privat DNS"-system du egentlig mener. I VPS-netværk er det den interne DNS-zone, ikke Androids DNS-over-TLS-indstilling eller brandede autoritative navneservere. Er din serverpark lille og stabil, er /etc/hosts et forsvarligt valg. Er den ikke det, så brug et underdomæne, du selv ejer, som standardnavnerum, vælg den mindste DNS-server, der passer til parken, og hold adgang, redundans og intern kontra offentlig zoneafgrænsning eksplicit. Brug kun .internal, når et isoleret navnerum passer bedre, og du accepterer dets afvejninger omkring certifikater, DNSSEC og kollisioner.

Ofte stillede spørgsmål