Defaults.Exposed › Fikser › Navneserver-oppsett (mangfold og SOA)

Slik fikser du Navneserver-oppsett (mangfold og SOA)

Navneserverne er katalogen som forteller hele internett hvor nettstedet og e-posten din finnes. Hvis de alle sitter på ett nettverk og det går ned, forsvinner virksomheten fra internett i samme øyeblikk — ingen side, ingen e-post, ingenting — og en sløv klokkeinnstilling på disse serverne kan la endringer du gjør bli hengende i dagevis.

Bunnlinjen for virksomheten din: Hvis alle navneserverne for domenet ditt lever på ett enkelt nettverk, tar en enkelt driftsstans eller et angrep på det nettverket nettstedet OG e-posten offline samtidig — du fortsetter å betale ansatte og annonser mens ingen kunder kan nå deg. Separat kan feilkonfigurerte SOA-timere la DNS-endringene dine (en ny server, en byttet e-postleverandør, en nødomdirigerring) propagere i dager i stedet for timer.

Hva dette kan koste deg

• Det ene nettverket alle navneserverne sitter på har en dårlig ettermiddag — en driftsstans eller et DDoS-angrep — og nettstedet og e-posten din forsvinner begge på samme tid. Kunder får feilsider, salgsinboxen din returnerer, og det er ingenting webutvikleren din kan gjøre annet enn å vente på at noens andres nettverk kommer seg.
• Et større kundes sikkerhetsteam kjører en leverandørsjekk, ser alle navneserverne dine hos én leverandør uten redundans, og noterer domenet ditt som et enkelt feilpunkt — friksjon på en kontrakt du ellers ville ha vunnet.
• Du flytter til et nytt webhotell eller bytter e-postleverandør, men en feil 'oppdatering'-timer i SOA-posten gjør at andre DNS-servere fortsetter å dele ut den gamle adressen i dager — så noen kunder lander på et dødt nettsted og e-posten din deles i to.
• En sikkerhetshendelse tvinger deg til å omdirigere trafikk raskt, men SOA-timerne forteller verden om å cache de gamle postene i en uke, så endringen du gjorde for en time siden fortsatt ikke har nådd halvparten av internett mens problemet fortsetter.
• De to navneserverne dine er teknisk sett to navn, men de peker til samme rack på samme nettverk — så redundansen du trodde du hadde er en illusjon, og en enkelt feil tar ned alt.

Hvorfor det er viktig. Hvert besøk på nettstedet og alle e-poster sendt til deg starter med et oppslag mot navneserverne dine. De er fundamentet resten av online-tilstedeværelsen din hviler på. Hvis det fundamentet ikke har redundans, slår en enkelt feil ut alt på én gang; hvis timeringsvediene er feil, er alle endringene du gjør trege med å tre i kraft — nøyaktig når du minst har råd til det.

Hva dette er, i enkle ord

Før noen kan nå nettstedet ditt eller sende deg en e-post, må datamaskinen stille et enkelt spørsmål: «hvor bor dette domenet egentlig?» Serverne som svarer på det spørsmålet er navneserverne dine. De er katalogoppføringen for hele online-tilstedeværelsen din — det aller første enhver besøkende og enhver e-post berører, før nettstedet eller innboksen er involvert.

Denne siden dekker to deler av å gjøre den katalogen riktig:

1. Mangfold — har du minst to navneservere, og sitter de på genuint separate deler av nettverket, slik at en enkelt driftsstans ikke kan stilne alle på én gang?
2. SOA-posten — en liten «start av autoritet»-post som holder timeringsvediene som kontrollerer hvor lenge resten av internett stoler på og cacher DNS-svarene dine. Sett timerne feil og alle endringer du gjør tar lengre tid å nå verden.

Ingen av delene er glamorøse. Begge er fundamenter. Når de er riktige tenker du aldri på dem; når de er feil, oppdager du det i verste mulig øyeblikk.

Hva dette kan koste deg

• Alt offline på én gang. Hvis alle navneserverne dine bor på ett nettverk og det nettverket har en driftsstans eller rammes av et DDoS-angrep, går nettstedet og e-posten mørk sammen. Dette er ikke teoretisk — en enkelt DNS-leverandør som angripes har slått store, velfunderte selskaper av internett i store deler av en dag. Med redundans på tvers av nettverk er én feil overlevbar; uten det er det totalt.

• En avtale tapt på en leverandørsjekk. Et større kundes sikkerhets- eller innkjøpsteam kjører en sjekk før de signerer, ser alle navneserverne dine konsentrert hos én leverandør uten reserveordning, og flagget domenet ditt som et enkelt feilpunkt. Det er den typen lite, unngåelig merke som skaper friksjon på en kontrakt du ellers ville ha vunnet.

• Endringer som ikke tar. Du bytter webhotell, flytter e-postleverandør, eller trenger å omdirigere trafikk raskt. En feil «refresh» eller «expire»-timer i SOA-posten gjør at andre DNS-servere fortsetter å betjene det gamle svaret i dager. Halvparten av kundene lander på den nye siden, halvparten på den døde; noe e-post flyter til den gamle leverandøren, noe til den nye. Endringen du gjorde for en time siden er fortsatt ikke ferdig.

• En nødsituasjon du ikke raskt kan avslutte. Under en sikkerhetshendelse trenger du å peke trafikk bort fra en kompromittert server nå. Hvis SOA-timerne fortalte verden om å cache postene dine i en uke, kryper fiksen ut over internett mens problemet fortsetter å bite.

• Redundans som ikke er reell. Du har to navneservere, så du antar at du er dekket — men begge peker til samme rack på samme nettverk. Den første maskinvarefeilen tar ned alt, og sikkerhetsnettet du stolte på var aldri der.

Hva det faktisk er

Navneserver-mangfold. Domenet ditt bør liste minst to navneservere, og ideelt sett bør de sitte på genuint uavhengige nettverksveier — ikke bare to navn som peker til samme boks. Bak kulissene peker hvert navneservernavn til én eller flere IP-adresser, og det som virkelig betyr noe er om de adressene opptar forskjellige deler av internettets ruting. En seriøs DNS-leverandør sprer navneserverne sine på tvers av mange separate nettverksblokker og lokasjoner over hele verden, så selv to navneservere fra samme leverandør gir deg reell, uavhengig redundans. Feilsaken er det motsatte: ett enkelt lite webhotell der begge «navneserverne» er samme maskin, slik at én feil er total.

En merknad for den tekniske leseren: sjekken vår teller NS-postene dine og ser deretter på hvor mye genuint nettverksmangfold som sitter bak dem. Det primære signalet er spredningen av distinkte IP-nettverksblokker navneserverne peker inn i, med antallet distinkte leverandørnavn som en siste utvei. Dette krediterer bevisst Anycast-leverandører — Cloudflare, Google, AWS Route 53, Azure DNS — som annonserer én nettverksidentitet fra mange globalt separate rutingstier og dermed leverer reelt mangfold selv fra ett merke. Å ha færre enn to navneservere scorer null på denne sjekken og behandles som høy alvorlighetsgrad, fordi det er et umitigert enkelt feilpunkt for hele domenet.

SOA-posten. Hvert DNS-sone har nøyaktig én Start of Authority-post. Den navngir den primære navneserveren og den administrative kontakten, bærer et serienummer som øker ved hver endring, og — den delen som betyr noe for virksomheten — holder fire timere:

• Refresh — hvor ofte sekundære navneservere re-sjekker primæren for endringer. Godt område: omtrent 1 til 24 timer (3 600–86 400 sekunder).
• Retry — hvor snart de skal prøve igjen hvis en oppdatering mislykkes. Godt område: omtrent 5 til 60 minutter (300–3 600 sekunder).
• Expire — hvor lenge sekundære servere fortsetter å betjene postene dine hvis de ikke kan nå primæren i det hele tatt. Godt område: omtrent 1 til 4 uker (604 800–2 419 200 sekunder).
• Minimum TTL — gulvet for hvor lenge svar (inkludert «dette navnet eksisterer ikke»-svar) caches. Bør være en fornuftig positiv verdi; 300 sekunder er et vanlig valg.

Hva «bra» ser ut som: en SOA som eksisterer, har en gyldig administrativ kontakt, og bærer timere innenfor disse områdene. Verdier utenfor disse er ikke dødelig — men de bremser enten endringene dine (for lange timere) eller belaster navneserverne unødvendig (for korte). En manglende eller genuint ødelagt SOA er det mer alvorlige tilfellet.

Slik fikser du det (gratis, ~15 minutter)

Dette er for den som administrerer domenet eller DNS-en din — hvis det ikke er deg, gi dem denne seksjonen. Fiksen er gratis; vi tar bare betalt for å overvåke at den forblir fikset.

Steg 1 — Sørg for at du har minst to navneservere på mangfoldig infrastruktur.

1. Sjekk hva du har i dag. Kjør dig NS dittdomene.com (eller bruk et «DNS-oppslag»-nettverktøy) og les av navneserverne. To eller flere er minimum.
2. Hvis du bare har én, eller begge er hos et enkelt lite webhotell, flytt DNS til en leverandør som gir deg redundans som standard. Praktisk talt alle seriøse leverandører gjør dette:
   • Cloudflare — tilordner to navneservere spredt på tvers av det globale Anycast-nettverket automatisk når du legger til et domene.
   • AWS Route 53 — hvert hostet sone får fire navneservere på tvers av separate Route 53-nettverk.
   • Google Cloud DNS / Microsoft 365 / Azure DNS — tilsvarende klargjøring av flere navneservere på tvers av uavhengig infrastruktur.
3. For å bytte, sett domenets navneservere hos registraren (der du kjøpte domenet) til de den nye DNS-leverandøren gir deg. Denne endringen kan ta 24–48 timer å propagere fullt ut.
4. For belt-og-bukseseler-motstandskraft kan større eller høyrisiko-virksomheter kjøre sekundær DNS fra en annen uavhengig leverandør. For de fleste små virksomheter er dette valgfritt — en enkelt anerkjent leverandør gir allerede reell tverrnettverksredundans.

Steg 2 — Sjekk (og om nødvendig, fiks) SOA-timerne.

1. Kjør dig SOA dittdomene.com og les av refresh-, retry-, expire- og minimum-TTL-verdiene.
2. Sammenlign dem med områdene ovenfor. I det store flertallet av tilfeller har DNS-leverandøren allerede satt fornuftige standarder og det er ingenting å gjøre.
3. Hvis en verdi er utenfor området, fiks det der DNS-en din er hostet:
   • På administrerte leverandører (Cloudflare, Route 53, Google, Azure) håndteres SOA-en i stor grad for deg; du justerer den generelt gjennom leverandørens DNS-innstillinger eller support snarere enn å redigere den for hånd.
   • På en selvdrevet navneserver (BIND, PowerDNS), rediger SOA-linjen i sonefilen direkte og last inn sonen på nytt — husk å bumpe serienummeret slik at sekundære servere plukker opp endringen.
4. Etter enhver endring, kjør oppslagene på nytt for å bekrefte at både navneserver-listen og SOA-timerne ser riktige ut.

Vanlige feil

• Behandle «to navn» som «to nettverk». To navnestener som peker til samme boks eller rack er et enkelt feilpunkt forkledd. Det som betyr noe er uavhengige nettverksveier, ikke antall navn.
• Anta at mer alltid er bedre, uten mangfold. Fem navneservere alle på ett skjørt webhotell er ikke tryggere enn én. Mangfold slår mengde.
• Sette timere for aggressivt. Å skru SOA refresh eller minimum-TTL helt ned til «gjøre endringer øyeblikkelige» hamrer bare navneserverne og kan gjøre driftsintanser verre, med liten reell fordel. Fornuftige standarder balanserer allerede hastighet mot belastning.
• Sette expire for lavt. Hvis sekundære servere slutter å betjene sonen for tidlig under en primær driftsstans, blir et recoverable problem en full driftsstans. Hold expire i ukeregionen.
• Redigere en sone for hånd og glemme serienummeret. På selvdrevne navneservere plukker sekundærservere bare opp endringer når SOA-serienummeret øker. Endre poster men la serienummeret være og «fiksen» propagerer aldri.
• La DNS stå hos registrarens bare standard. Noen registrars innebygde DNS er et enkelt, minimalt oppsett. Å flytte DNS til en ekte leverandør gir vanligvis redundans og fornuftige SOA-timere i én bevegelse.

Bunnlinjen

Navneserverne og SOA-posten er fundamentet alt annet hviler på. To navneservere på genuint separate nettverk betyr at én enkelt feil ikke kan ta hele virksomheten offline på én gang; fornuftige SOA-timere betyr at endringene du gjør faktisk når verden raskt. Begge er gratis å gjøre riktig, begge er vanligvis allerede i god form i det øyeblikket du er på en ordentlig DNS-leverandør, og begge er verdt en to-minutters sjekk — fordi dagen de betyr noe er dagen du minst kan unne deg at de er feil.

FAQ