Defaults.Exposed › Rettelser › Nameserver-opsætning (mangfoldighed & SOA)

Sådan retter du Nameserver-opsætning (mangfoldighed & SOA)

Dine nameservere er telefonbogen, der fortæller hele internettet, hvor din hjemmeside og e-mail befinder sig. Sidder de alle på ét netværk og det går ned, forsvinder din virksomhed fra internettet på samme øjeblik — ingen side, ingen e-mail, ingenting — og en sjusket clock-indstilling på de servere kan efterlade ændringer du foretager hængende i dagevis.

Det korte svar for din virksomhed: Befinder alle nameservere til dit domæne sig på ét netværk, tager en enkelt driftsforstyrrelse eller et angreb på det netværk din hjemmeside OG din e-mail offline på samme tid — du fortsætter med at betale medarbejdere og annoncer, mens ingen kunder kan nå dig. Desuden kan fejlkonfigurerede SOA-timere efterlade dine DNS-ændringer (en ny server, et skiftet e-mail-udbyder, en nødomdirigerering) på vej i dage frem for timer.

Hvad dette kan koste dig

• Det enkeltnetværk alle dine nameservere sidder på har en dårlig eftermiddag — en driftsforstyrrelse eller et DDoS-angreb — og din hjemmeside og e-mail forsvinder på samme tid. Kunder får fejlsider, din salgs-indbakke bouncer, og der er intet din webperson kan gøre andet end at vente på, at et andet netværk kommer sig.
• Et større kundes sikkerhedsteam kører et leverandørtjek, ser alle dine nameservere hos én udbyder uden redundans, og noterer dit domæne som et enkelt fejlpunkt — friktion på en kontrakt du ellers ville have vundet.
• Du skifter til en ny webhost eller skifter e-mailudbyder, men en forkert 'refresh'-timer i din SOA-record betyder, at andre DNS-servere fortsætter med at udlevere din gamle adresse i dage — så nogle kunder lander på en død side, og din e-mail deler sig i to.
• En sikkerhedshændelse tvinger dig til hurtigt at omdirigere trafik, men dine SOA-timere fortæller verden om at cache dine gamle records i en uge, så den ændring du foretog for en time siden stadig ikke er nået halvdelen af internettet, mens problemet fortsætter.
• Dine to nameservere er teknisk to navne, men de peger på det samme rack på det samme netværk — så den redundans du tror du har, er en illusion, og en enkelt fejl tager stadig alt ned.

Hvorfor det betyder noget. Ethvert besøg på din hjemmeside og enhver e-mail sendt til dig starter med et opslag mod dine nameservere. De er fundamentet hele din online tilstedeværelse hviler på. Har det fundament ingen redundans, slår en enkelt fejl alt ud på én gang; er dets tidsværdier forkerte, er enhver ændring du foretager langsom til at træde i kraft — præcis når du har råd til det mindst.

Hvad dette er på klart dansk

Inden nogen kan nå din hjemmeside eller sende dig en e-mail, skal deres computer stille et simpelt spørgsmål: “Hvor bor dette domæne egentlig?” De servere der svarer på det spørgsmål, er dine nameservere. De er telefonbogsposten for hele din online tilstedeværelse — den allerførste ting enhver besøgende og enhver e-mail rører, inden din side eller din indbakke overhovedet er involveret.

Denne side dækker to dele af at få den telefonbog rigtigt:

1. Mangfoldighed — har du mindst to nameservere, og sidder de på genuint separate dele af netværket, så en enkelt driftsforstyrrelse ikke kan bringe dem alle til tavshed på én gang?
2. SOA-recorden — en lille “start of authority”-record der indeholder tidsværdierne der kontrollerer, hvor længe resten af internettet stoler på og cacher dine DNS-svar. Sætter du timerne forkert, tager enhver ændring du foretager, længere om at nå verden.

Ingen af dem er glamourøse. Begge er fundamenter. Når de er rigtige, tænker du aldrig over dem; når de er forkerte, finder du ud af det på det værst mulige tidspunkt.

Hvad dette kan koste dig

• Alt offline på én gang. Befinder alle dine nameservere sig på ét netværk og det netværk har en driftsforstyrrelse eller rammes af et DDoS-angreb, mørklægges din hjemmeside og din e-mail på samme tid. Det er ikke teoretisk — en enkelt DNS-udbyder under angreb har taget store, velressourcerede virksomheder offline det meste af en dag. Med redundans på tværs af netværk kan en enkelt fejl overleves; uden er det totalt.

• En handel tabt på et leverandørtjek. Et større kundes sikkerheds- eller indkøbsteam kører et tjek inden underskrift, ser alle dine nameservere koncentreret hos én udbyder uden fallback, og flagger dit domæne som et enkelt fejlpunkt.

• Ændringer der ikke tager fat. Du skifter webhost, skifter e-mailudbyder, eller skal hurtigt omdirigere trafik. En forkert “refresh”- eller “expire”-timer i din SOA-record betyder, at andre DNS-servere fortsætter med at udlevere dit gamle svar i dage.

• En nødsituation du ikke hurtigt kan afslutte. Under en sikkerhedshændelse skal du pege trafik væk fra en kompromitteret server nu. Fortalte dine SOA-timere verden om at cache dine records i en uge, kravler din rettelse ud på tværs af internettet, mens problemet fortsætter med at bide.

• Redundans der ikke er reel. Du har to nameservere, og du antager, at du er dækket — men begge peger på det samme rack på det samme netværk. Den første hardwarefejl tager hele molevitten, og det sikkerhedsnet du regnede med, var der aldrig.

Hvad det faktisk er

Nameserver-mangfoldighed. Dit domæne bør liste mindst to nameservere, og ideelt burde de sidde på genuint uafhængige netværksstier — ikke blot to navne der peger på den samme box. En seriøs DNS-udbyder spreder sine nameservere på tværs af mange separate netværksblokke og placeringer verden over, så selv to nameservere fra den samme udbyder giver dig reel, uafhængig redundans. Fejlcasen er den modsatte: en enkelt lille host, hvor begge “nameservere” er den samme maskine, så en fejl er total.

En note til den tekniske læser: vores tjek tæller dine NS-records og kigger derefter på, hvor meget genuint netværksmangfoldighed der sidder bag dem. Det primære signal er spredningen af distinkte IP-netværksblokke nameserverne peger på (groft sagt /16-ranges for IPv4 og /32 for IPv6), med antallet af distinkte udbyderprovider-navne som backup. Dette krediterer bevidst Anycast hyperscale-udbydere — Cloudflare, Google, AWS Route 53, Azure DNS — der annoncerer én netværksidentitet fra mange globalt separate routingstier og dermed leverer reel mangfoldighed selv fra ét brand. At have færre end to nameservere scorer nul på dette tjek og behandles som høj alvorlighed, fordi det er et uafbødet enkelt fejlpunkt for hele domænet.

SOA-recorden. Enhver DNS-zone har præcis én Start of Authority-record. Den navngiver den primære nameserver og den administrative kontaktperson, bærer et serienummer der øges ved enhver ændring, og — den del der betyder noget for din virksomhed — holder fire timere:

• Refresh — hvor ofte sekundære nameservere tjekker primæren for ændringer. God range: groft sagt 1 til 24 timer (3.600–86.400 sekunder).
• Retry — hvor snart der prøves igen, hvis en refresh mislykkes. God range: groft sagt 5 til 60 minutter (300–3.600 sekunder).
• Expire — hvor lang tid sekundære servere fortsætter med at udlevere dine records, hvis de slet ikke kan nå primæren. God range: groft sagt 1 til 4 uger (604.800–2.419.200 sekunder).
• Minimum TTL — gulvet for, hvor længe svar (inklusive “dette navn eksisterer ikke”-svar) caches. Bør være en fornuftig positiv værdi; 300 sekunder er et gængs valg.

Hvad “godt” ser ud som: en SOA der eksisterer, har en gyldig administrativ kontaktperson, og bærer timere inden for disse ranges. Værdier uden for rangene er ikke fatale — men de bremser enten dine ændringer (timere for lange) eller belaster dine nameservere unødvendigt (for korte). En manglende eller genuint ødelagt SOA er det mere alvorlige tilfælde.

Sådan fikser du det (gratis, ~15 minutter)

Dette afsnit er til den der administrerer dit domæne eller DNS — er det ikke dig, overrækk dem dette afsnit. Fikset er gratis; vi opkræver kun betaling for at overvåge, at det forbliver fikset.

Trin 1 — Sørg for, at du har mindst to nameservere på forskellig infrastruktur.

1. Tjek hvad du har i dag. Kør dig NS ditdomæne.com (eller brug et “DNS lookup” webværktøj) og læs nameserverne af. To eller flere er minimum.
2. Har du kun én, eller sidder begge på en enkelt lille host, flyt dit DNS til en udbyder der giver dig redundans som standard. Praktisk talt alle seriøse udbydere gør det:
   • Cloudflare — tildeler automatisk to nameservere spredt på tværs af dets globale Anycast-netværk, når du tilføjer et domæne.
   • AWS Route 53 — hver hosted zone får fire nameservere på tværs af separate Route 53-netværk.
   • Google Cloud DNS / Azure DNS — provisioner ligeledes flere nameservere på tværs af uafhængig infrastruktur.
3. Sæt for at skifte dit domænes nameservere hos din registrar (hvor du købte domænet) til dem din nye DNS-udbyder giver dig. Denne ændring kan tage 24–48 timer at propagere fuldt ud.
4. For bælteseler kan større eller højrisikovirksomheder køre sekundær DNS fra en anden uafhængig udbyder. For de fleste små virksomheder er dette valgfrit.

Trin 2 — Tjek (og om nødvendigt, ret) dine SOA-timere.

1. Kør dig SOA ditdomæne.com og læs refresh-, retry-, expire- og minimum-TTL-værdierne af.
2. Sammenlign dem med ranges ovenfor. I langt de fleste tilfælde har din DNS-udbyder allerede sat fornuftige standarder og der er intet at gøre.
3. Er en værdi uden for range, ret det der, hvor dit DNS er hostet:
   • På administrerede udbydere (Cloudflare, Route 53, Google, Azure) håndteres SOA’en i vid udstrækning for dig; du justerer den generelt via udbyderens DNS-indstillinger eller support frem for at redigere den manuelt.
   • På en selvkørt nameserver (BIND, PowerDNS) redigér SOA-linjen i zonefilen direkte og genindlæs zonen — husk at bumpe serienummeret, så sekundære server plukker ændringen op.
4. Kør opslagene igen efter enhver ændring for at bekræfte, at både nameserver-listen og SOA-timerne ser rigtige ud.

Almindelige fejl

• At behandle “to navne” som “to netværk.” To nameserver-navne der peger på den samme box eller det samme rack er et enkelt fejlpunkt iført forklædning. Det der tæller er uafhængige netværksstier, ikke antallet af navne.
• At antage, at mere altid er bedre, uden mangfoldighed. Fem nameservere alle på én skrøbelig host er ikke sikrere end én. Mangfoldighed slår mængde.
• At sætte timere for aggressivt. At skrue SOA-refresh eller minimum-TTL ned til “gøre ændringer øjeblikkelige” belaster blot dine nameservere og kan gøre driftsafbrydelser værre, med lille reel fordel. Fornuftige standarder balancerer allerede hastighed mod belastning.
• At sætte expire for lavt. Holder sekundære servere for hurtigt op med at udlevere din zone under en primær driftsforstyrrelse, bliver en genvindelig dip til en fuld driftsafbrydelse. Hold expire i ugers-intervallet.
• At redigere en zone manuelt og glemme serienummeret. På selvkørte nameservere plukker sekundære server kun ændringer op, når SOA-serienummeret stiger. Ændrer du records men lader serienummeret stå, propagerer dit “fix” aldrig.
• At lade DNS stå på registrarens bare standard. Nogle registrares built-in DNS er en enkelt, minimal opsætning. At flytte DNS til en rigtig udbyder giver dig normalt redundans og fornuftige SOA-timere i ét træk.

Bundlinjen

Dine nameservere og deres SOA-record er det fundament alt andet hviler på. To nameservere på genuint separate netværk betyder, at en enkelt fejl ikke kan tage hele din virksomhed offline på én gang; fornuftige SOA-timere betyder, at de ændringer du foretager faktisk når verden hurtigt. Begge er gratis at gøre rigtigt, begge er normalt allerede i god form i det øjeblik du er hos en ordentlig DNS-udbyder, og begge er værd et to-minutters tjek — fordi den dag de betyder noget, er den dag du har råd til det mindst.

FAQ