DNS for webmastere og udviklere: Hvad du bør forstå

Langt de fleste DNS-fejl opstår ikke fordi nogen er inkompetente - de opstår fordi DNS er et af de få steder i webverdenen, hvor en forkert rækkefølge eller en glemt post kan lægge en hel virksomhed ned i timer. E-mails bouncer, hjemmesiden er nede, og ingen ved præcis hvorfor. Forstår du DNS, kan du afkorte den tid markant.

Hvad DNS faktisk er - og hvorfor det er din opgave

DNS - Domain Name System - er internettets telefonbog. Når en browser vil finde dinhjemmeside.dk, slår den op i DNS for at finde den IP-adresse, som domænet peger på. Uden DNS skulle alle huske numeriske adresser som 185.230.63.107 i stedet for et domænenavn.

Systemadministratorer har traditionelt ejet DNS-konfigurationen, men i praksis er det i dag webmasteren, freelanceren eller WordPress-ejeren der sidder med adgangen til domæneregistraren og skal foretage ændringerne. Det kræver ikke en servereksamen - men det kræver at du forstår hvad du rører ved, og hvad konsekvenserne er.

DNS-poster administreres typisk via din domæneregistrar (fx Dandomain, Simply eller One.com) eller via dit hostingpanels DNS-zone. Ændringer slår ikke igennem øjeblikkeligt - og det er netop den forsinkelse, der skaber mest forvirring.

De vigtigste record-typer og hvornår du redigerer dem

En DNS-zone indeholder en samling poster kaldet records. Hver record har en type, et navn, en værdi og en TTL. Her er dem du støder på oftest:

• A-record: Peger et domæne eller subdomain på en IPv4-adresse. Det er den post du redigerer når du vil pege dinhjemmeside.dk på en ny server. Eksempel: @ → 185.230.63.107.

• AAAA-record: Samme som A-record, men til IPv6-adresser. Mange hostingplatforme understøtter begge - sæt begge op hvis din server har en IPv6-adresse.

• CNAME-record: Et alias der peger et subdomain på et andet domænenavn i stedet for en IP. Bruges typisk til www der peger på roddomænet, eller til at pege shop.dinside.dk på en ekstern platform. Du kan ikke sætte et CNAME på et roddomæne (@) - det er en hyppig fejl.

• MX-record: Fortæller internettet hvilken mailserver der håndterer e-mail for domænet. Redigeres når du skifter e-mailudbyder - fx til Google Workspace eller Microsoft 365. MX-records har en prioritetsværdi; lavere tal betyder højere prioritet.

• TXT-record: Fritekstpost der bruges til verifikation og e-mailsikkerhed. SPF, DKIM og DMARC (se nedenfor) er alle TXT-records. Google og andre tjenester bruger dem også til domæneejerskabsverifikation.

• NS-record: Angiver hvilke navneservere der er autoritative for domænet. Du redigerer NS-records når du flytter DNS-administration fra registraren til fx Cloudflare eller din hosting. Ændring af NS-records er den mest indgribende DNS-ændring du kan foretage.

Propagering: ventetiden og hvad du kan gøre ved den

Når du gemmer en DNS-ændring, opdateres den ikke øjeblikkeligt overalt. DNS-servere verden over cacher svar i en periode bestemt af TTL-værdien (se næste afsnit). Denne spredningsproces kaldes propagering.

I praksis tager det typisk 15 minutter til 48 timer, men langt de fleste ændringer slår igennem inden for 1-4 timer. Det afhænger af TTL-værdien på den gamle post og af hvor hurtigt de rekursive DNS-servere hos internetudbyderne opdaterer deres cache.

Under propagering kan to brugere opleve forskellige resultater - én ser den nye server, en anden ser stadig den gamle. Det er ikke en fejl, det er forventet adfærd. Du kan følge propageringen med et værktøj som dnsinfo.dk, der forespørger DNS-servere fra forskellige lokationer og viser om dine ændringer er slået igennem globalt.

TTL: juster det inden du flytter

TTL - Time To Live - er en tidsangivelse i sekunder der fortæller DNS-resolvere hvor længe de må cache et svar. En TTL på 86400 betyder at svaret kan caches i 24 timer. En TTL på 300 betyder 5 minutter.

Den vigtigste regel ved domæneflytninger er: sænk TTL-værdien i god tid inden flytningen. Sæt den til 300-600 sekunder (5-10 minutter) mindst 24-48 timer før du foretager selve ændringen. På den måde sikrer du at den gamle cache er udløbet hos størstedelen af verdens DNS-resolvere, og at din nye post spreder sig hurtigt når du skifter.

Glemmer du dette, kan du risikere at den høje TTL på den gamle post tvinger lang ventetid - selv om du har sat den nye A-record korrekt. Efter flytningen kan du sætte TTL tilbage til en højere værdi som 3600 eller 86400.

SPF, DKIM og DMARC: e-mailposterne der oftest fejles

Disse tre TXT-records er e-mailsikkerhedens treenighed. Mangler de, ender dine e-mails i spam - eller afvises de helt. Det er et af de hyppigste problemer ved hjemmesideflytninger, fordi e-mail-konfigurationen ikke altid følger med automatisk.

SPF (Sender Policy Framework) definerer hvilke mailservere der har lov til at sende e-mail på vegne af dit domæne. En SPF-post ser typisk sådan ud:

v=spf1 include:_spf.google.com ~all

Tilde-all (~all) betyder softfail - e-mails fra uautoriserede servere markeres som mistænkelige men afvises ikke. Minus-all (-all) er strengere og afviser dem. Du må kun have én SPF-record per domæne - har du flere, ignoreres de alle.

DKIM (DomainKeys Identified Mail) tilføjer en kryptografisk signatur til udgående e-mails. Modtagerens mailserver kan verificere signaturen mod den offentlige nøgle i din DNS. Nøglen leveres af din e-mailudbyder og indsættes som en TXT-record på et specifikt subdomain, fx google._domainkey.dinhjemmeside.dk.

DMARC (Domain-based Message Authentication, Reporting and Conformance) binder SPF og DKIM sammen og fortæller modtagerservere hvad de skal gøre hvis en e-mail fejler begge tjek. En simpel startpolitik:

v=DMARC1; p=none; rua=mailto:dmarc@dinhjemmeside.dk

p=none betyder at fejlende e-mails blot rapporteres men ikke afvises. Når du har analyseret rapporterne, kan du stramme til p=quarantine eller p=reject. DMARC kræver at enten SPF eller DKIM - helst begge - er konfigureret korrekt.

Du kan validere alle tre poster direkte på dnsinfo.dk, der analyserer din e-mailkonfiguration og viser konkrete fejl og anbefalinger.

Fejlfinding ved hjemmesideflytning

Flytning af en WordPress-side til nyt hosting er det scenarie der oftest afslører DNS-misforståelser. Her er de hyppigste problemer:

• A-record peger stadig på gammel server: Den klassiske fejl. Du har uploadet filer til ny hosting, men glemt at opdatere A-recorden. Tjek hvilken IP din A-record peger på med et DNS-opslag og sammenlign med den nye servers IP.

• www og roddomæne peger forskellige steder hen: dinside.dk peger på ny server, men www.dinside.dk peger stadig på gammel. Tjek begge. CNAME for www skal pege på roddomænet eller direkte på den nye IP.

• SSL-certifikat fejler: Certifikater som Let's Encrypt udstedes til en specifik IP. Hvis DNS ikke er propageret til den nye server, kan certifikatet ikke udstedes eller fornyes. Vent på fuld propagering inden du aktiverer SSL.

• E-mail holder op med at virke: MX-records er uændrede, men SPF-recorden refererer stadig til den gamle mailserver. Eller DKIM-nøglen mangler for den nye udbyder. Valider med dnsinfo.dk.

• NS-records opdateret men intet virker: Efter NS-skift kan der gå op til 48 timer. Tjek om de nye navneservere faktisk er autoritative med et NS-opslag.

Når du fejlsøger, er det vigtigt at skelne mellem om problemet er DNS (forkert record), propagering (korrekt record, men ikke spredt endnu) eller serverkonfiguration (DNS er korrekt, men serveren svarer forkert). dnsinfo.dk hjælper med den første kategori - den forespørger direkte mod autoritative navneservere og viser hvad der faktisk er konfigureret, uafhængigt af lokal DNS-cache.

Sådan bruger du dnsinfo.dk i dit workflow

dnsinfo.dk er et dansk DNS-opslagsværktøj der samler flere nyttige funktioner på ét sted. I forbindelse med domæneflytninger og fejlfinding er det særligt nyttigt til:

• DNS-opslag: Slå A, AAAA, CNAME, MX, TXT og NS-records op for et domæne. Du kan se hvad der er konfigureret hos de autoritative navneservere, og sammenligne med hvad din lokale resolver returnerer.

• WHOIS-opslag: Find ud af hvem der ejer et domæne, hvornår det udløber, og hvilke navneservere der er registreret. Nyttigt når du overtager et projekt og skal kortlægge DNS-strukturen.

• Blacklist-tjek: Verificer om din mailservers IP-adresse er endt på en spam-blacklist - en hyppig årsag til at e-mails afvises eller ender i spam.

• E-mailkonfigurationsvalidering: Analysér SPF, DKIM og DMARC for et domæne og få konkrete fejlmeldinger. Særligt nyttigt ved nyopsætning af e-mail eller efter skift af e-mailudbyder.

Brug det som din første stop inden du begynder at ændre noget - dokumentér hvad der er konfigureret nu, så du har et udgangspunkt at vende tilbage til hvis noget går galt.

Teknisk rådgivning i forbindelse med domæneflytninger og servermigrationer er en del af det arbejde vi løser hos Kodesmeden - særligt i projekter hvor DNS-konfigurationen er viklet ind i en større WordPress- eller Laravel-opsætning.

Tjekliste til næste domæneflytning

Gem denne liste og brug den aktivt næste gang du flytter et domæne eller skifter hosting:

• Mindst 48 timer før flytning: Sænk TTL på alle relevante records til 300-600 sekunder. Dokumentér nuværende DNS-konfiguration med et opslag på dnsinfo.dk.

• Inden flytning: Verificer at ny server er klar og konfigureret korrekt - herunder SSL, WordPress-konfiguration og eventuelle subdomæner.

• Selve flytningen: Opdater A-record (og AAAA hvis relevant) til ny servers IP. Opdater www-CNAME hvis nødvendigt. Opdater MX-records hvis e-mailudbyder skifter.

• Efter ændring: Tjek propagering via dnsinfo.dk fra multiple lokationer. Vent på fuld propagering inden SSL-certifikat aktiveres.

• E-mailvalidering: Verificer SPF, DKIM og DMARC via dnsinfo.dk. Test at e-mails sendes og modtages korrekt.

• Blacklist-tjek: Tjek om ny servers IP er på kendte spam-blacklister.

• Når alt virker: Sæt TTL tilbage til 3600 eller 86400. Behold adgang til gammel server i minimum 48 timer som fallback.

DNS er ikke kompliceret - men det er uforgivenligt over for sjusk. En velplanlagt flytning med lav TTL, dokumenteret udgangspunkt og systematisk validering reducerer nedetid fra timer til minutter. Det er forskellen på en lancering der glider og en der kræver akut fejlsøgning kl. 23.