"Propagering": hvorfor nogle allerede kan se det, og andre ikke kan

Modul 6: Tid, cache og flytning · Læsetid: 8 minutter

Læringsmål: Efter denne lektion kan du forklare hvorfor en DNS-ændring ikke er synlig alle steder på samme tid, vurdere hvor lang tid det tager, og løse problemet hvis det kun er dig, der stadig ser den gamle situation.

Nøglebegreber: "propagering", cache, negativ cache (NXDOMAIN), SOA-minimum, delegerings-TTL, navneserverskift, tømme cache

En misforståelse i ét ord

Du har ændret et record. Din kollega ser allerede den nye hjemmeside, du ser stadig den gamle. På internettet læser du så: "vent lidt, DNS'en skal lige propagere." Ordet propagering (udbredelse) giver indtryk af at din ændring ruller som en bølge over internettet, fra server til server.

Sådan fungerer det ikke. Din ændring ligger med det samme på domænets autoritative navneservere (eller inden for et par minutter, hvis din DNS-udbyder synkroniserer flere navneservere). Der bliver ikke sendt noget rundt. Det, du ser, er cacher der udløber: hver resolver giver det gamle svar indtil TTL'en i dens cache er brugt op (lektion 6.1). Fordi hver resolver begyndte at tælle på et andet tidspunkt, ser nogle ændringen før andre.

"Propagering" er altså egentlig: at vente til alle cacher er løbet tør. Den indsigt hjælper dig, for nu ved du præcis hvad du venter på, og hvor lang tid det maksimalt tager.

Hvor lang tid tager det?

Det afhænger af hvad du ændrer.

Eksisterende records

Her er det enkelt: den gamle TTL er maksimum. Havde recordet TTL 3600, ser alle det nye svar senest en time efter din ændring. Ser nogen stadig det gamle efter mere end en time, ligger problemet et andet sted (se længere nede).

Nye records og den negative cache

Et nyt record virker ofte med det samme, medmindre nogen allerede slog navnet op, da det endnu ikke fandtes. Resolveren fik dengang svaret NXDOMAIN ("dette navn findes ikke") eller "dette navn findes, men har ikke et record af denne type". Også det "nej" bliver husket. Det kaldes den negative cache.

Hvor længe et "nej" bliver gemt, står ikke i et record der ikke findes. Det kommer fra zonens SOA-record: ifølge RFC 2308 er det det mindste af to tal, TTL'en for selve SOA-recordet og det sidste felt i SOA-recordet (det "minimum"). Et eksempel:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; serienummer
                             14400      ; opdatering
                             3600       ; forsøg igen
                             1209600    ; udløb
                             300 )      ; minimum

Her bliver et "nej" husket i maksimalt 300 sekunder (det mindste af 3600 og 300). I nogle zoner er det en time eller mere.

Derfor er den gyldne regel: åbn ikke et nyt subdomæne i din browser, før du har oprettet det. Din computer og din resolver husker så, at det ikke findes, og du er den eneste der skal vente.

Skift af navneservere

Ved et navneserverskift venter du på noget andet: NS-recordene hos registreren for din endelse. De records fortæller resolvere, hvor domænets navneservere ligger (lektion 2.1), og også de bliver husket. Hver registry vælger sin egen TTL til det. Målt i november 2026:

Dertil kommer, at en registry nogle gange ikke publicerer din ændring med det samme, og at navneserverne hos din gamle udbyder i mellemtiden ofte stadig svarer med den gamle zone. Regn derfor med et par timer ved et navneserverskift, og med op til to dage ved .com. Sørg derfor for at begge udbydere har de samme, korrekte records under skiftet (lektion 6.3).

Er du den eneste, der stadig ser det gamle?

Ser en online-checker allerede det nye svar hos næsten alle resolvere, men ikke hos dig? Så ligger det gamle svar et sted tæt på dig. Gennemgå disse trin, fra hurtigt til grundigt:

1. Privat vindue eller en anden browser. Din browser gemmer DNS-svar og sider.
2. Mobil via 4G eller 5G, med wifi slået fra. Så bruger du din mobiludbyders resolver i stedet for dit hjemmenetværks.

3. Tøm din computers cache.

   • Windows (Kommandoprompt): ipconfig /flushdns
   • macOS (Terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux med systemd-resolved: resolvectl flush-caches
4. Genstart routeren. Mange routere fungerer som en lille resolver med sin egen cache.
5. Tjek hosts-filen. Har du tidligere testet en ny server ved at sætte adressen i din hosts-fil (C:\Windows\System32\drivers\etc\hosts eller /etc/hosts)? Den linje går forud for DNS'en. Fjern den. Det bliver ofte glemt.
6. Tjek direkte ved kilden. Slå recordet op hos den autoritative navneserver (dig A example.com @ns1.hosting.example). Står der stadig det gamle svar, er ændringen ikke gemt korrekt, eller du har lavet den det forkerte sted.

Stadig intet efter ventetiden?

Hvis TTL'en for længst er udløbet, og online-værktøjer også viser det gamle svar, nytter det ikke at vente mere. Så er der noget andet galt. De tre mest almindelige årsager:

• Ændret det forkerte sted. Dit domæne bruger navneservere fra en anden udbyder (for eksempel Cloudflare eller en sitebygger), og du ændrede recordene hos din hostingudbyder. Tjek hvilke navneservere dit domæne har (lektion 2.1), og lav ændringen der.
• Stavefejl eller manglende punktum. mail.example.com uden punktum bliver i mange kontrolpaneler til mail.example.com.example.com (lektion 2.2).
• Navneserverne er ikke enige med hinanden. Et domæne har mindst to navneservere. Hvis de ikke synkroniserer korrekt, giver den ene det nye svar og den anden det gamle. Sammenlign SOA-serienummeret hos hver navneserver: det skal være ens.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

I praksis: sådan ser det ud i et kontrolpanel

Vil du se hvad resolvere forskellige steder i verden svarer, kan du bruge en online DNS-checker der spørger en resolver per land (for eksempel dnschecker.org). I eksempelpanelet Mit WebOké tjekker kortet Domæne / E-mail sundhed dit domænes navneservere og records hos de autoritative navneservere, og DNS-diagnosen sammenligner navneservernes serienumre. Andre udbydere har ofte en tilsvarende kontrol i deres kontrolpanel; hvis ikke, giver dig og online-værktøjerne fra lektion 8.3 samme billede.

Opsummering

• Der bliver ikke "udbredt" noget: du venter til cacher udløber.
• Et ændret record er senest synligt overalt efter den gamle TTL; et nyt record som regel med det samme, medmindre nogen allerede har slået navnet op (negativ cache, bestemt af SOA-recordet).
• Et navneserverskift afhænger af TTL'en hos registreren: hos .nl en time, hos .com to dage.
• Er du den eneste, der stadig ser det gamle? Privat vindue, 4G, tøm cache, genstart routeren og tjek hosts-filen.
• Stadig gammelt hos den autoritative navneserver? Så nytter det ikke at vente: find fejlen.

Quiz

Opgave

Opgave Z6.2: Delegerings-TTL og negativ cache. To spørgsmål, begge kan besvares med dig eller et online dig-værktøj:

1. Hvor mange sekunder husker resolvere, ifølge .com-registreren, navneserverne for google.com? Slå det op hos en .com-server: dig NS google.com @a.gtld-servers.net og se på TTL'en i AUTHORITY-delen.
2. Hvor mange sekunder husker en resolver, at et navn under sidn.nl (webstedet for SIDN, registreren af .nl i Holland) ikke findes? Slå SOA-recordet for sidn.nl op hos ns1.sidn.nl og brug reglen fra denne lektion (det mindste af SOA-TTL'en og SOA-minimummet).

Læs mere

Trinnene i disse artikler handler om kontrolpanelerne hos WebOké; i andre kontrolpaneler fungerer det på lignende måde.

• En nameserver eller DNS-ændring kan tage op til 24 til 48 timer, før den er fuldt synlig overalt. Ser du ændringen ikke efter denne periode, så kontakt vores support, så hjælper vi dig videre.
• Websted eller e-mail virker ikke efter en flytning eller DNS-ændring: kontroller dit domæne
• DirectAdmin vejledning 5.11: Hvornår virker en ændring? Ventetid og TTL
• Sådan opretter du et subdomæne, og hvad du skal gøre, hvis det ikke virker
• Hvordan tester jeg mit domæne, før det er flyttet? (localhost)
• WebOké vejledning 5.17: Domæne og mailens sundhed: kontrollér og ret problemer