Når du vil have fuld effekt af QUIC.cloud som CDN til WordPress eller WooCommerce, ender du næsten altid ved det samme punkt: DNS skal sættes korrekt op. Det er her, mange opsætninger enten bliver en succes med det samme eller trækker ud med fejl i mail, cache eller validering. Den gode nyhed er, at processen […]
Når du vil have fuld effekt af QUIC.cloud som CDN til WordPress eller WooCommerce, ender du næsten altid ved det samme punkt: DNS skal sættes korrekt op. Det er her, mange opsætninger enten bliver en succes med det samme eller trækker ud med fejl i mail, cache eller validering.
Den gode nyhed er, at processen i 2026 stadig er ganske ligetil, hvis du tager den i den rigtige rækkefølge. QUIC.cloud har gjort onboarding enkel, men der er et par steder, hvor små detaljer gør en stor forskel. Især DNSSEC, navneservere og bevaring af eksisterende DNS-poster kræver lidt ekstra opmærksomhed.
QUIC.cloud DNS betyder i praksis, at du flytter dit domænes autoritative DNS til QUIC.clouds navneservere. Det giver en tættere kobling mellem DNS og QUIC.clouds CDN-lag, og det er ofte den mest direkte vej til at få hele platformen til at arbejde korrekt sammen.
For WordPress og WooCommerce er det attraktivt, fordi du undgår flere af de begrænsninger, der kan opstå med tredjeparts-DNS. Et klassisk eksempel er roddomænet, hvor mange DNS-udbydere ikke håndterer CNAME på example.dk særlig elegant. Med QUIC.clouds egen DNS bliver den del enklere.
I 2026 er der især én ting, der skal stå meget klart: QUIC.cloud DNS understøtter ikke DNSSEC. Hvis DNSSEC er aktivt hos din registrator, skal det slås fra, før du skifter navneservere. Glemmer du det, kan domænet fejle ved opslag, selv om resten af opsætningen ser korrekt ud.
Før du går i gang, er det klogt at samle det praktiske først. Hvis dit site kører på WordPress med LiteSpeed og LiteSpeed Cache-plugin, er forløbet typisk meget enkelt, fordi QUIC.cloud integrerer direkte med pluginet og kan hente domænenøglen automatisk.
Du bør også have adgang til både WordPress-administrationen, QUIC.cloud-kontoen og domænets registrator. Det sidste bliver nødvendigt, når navneserverne skal ændres. Har du mail, eksterne tjenester eller særlige subdomæner, er det en fordel at kende de nuværende DNS-poster, før du klikker videre.
Selve opsætningen består af nogle få hovedtrin. Rækkefølgen betyder noget, fordi du først skal forbinde sitet med QUIC.cloud, derefter aktivere CDN og til sidst flytte DNS.
Det er punkt 5 og 6, der afgør, om skiftet bliver roligt. Når QUIC.cloud importerer posterne, skal du ikke bare klikke videre. Kig især efter mail-relaterede poster, gamle dubletter og konflikter mellem A-, AAAA- og CNAME-poster.
Når navneserverne er ændret, kan propagation tage op til 24 til 48 timer. Ofte går det hurtigere, men du bør regne med, at forskellige netværk kan se forskellige svar i en overgangsperiode. Det er helt normalt.
Det første tegn er, at QUIC.cloud-dashboardet begynder at vise korrekt status for domænet. Du kan også slå domænets navneservere op og bekræfte, at registratoren nu peger på QUIC.cloud.
På selve websitet kan du bruge et header-tjek og se efter x-qc-pop. Den header er et godt fingerpeg om, at trafik håndteres gennem QUIC.clouds netværk. DNS-værktøjer som dig, nslookup eller offentlige opslagstjenester er også nyttige, når du vil se, om ændringen er slået igennem globalt.
Det største praktiske problem ved et DNS-skift er sjældent selve websitet. Det er næsten altid mail, verifikationsposter eller tredjepartstjenester, der bliver glemt. Et importeret zone-udkast er en god start, men det er ikke en erstatning for et manuelt tjek.
Har du Microsoft 365, Google Workspace, ekstern mailfiltering, transaktionsmails eller domæneverifikation til andre platforme, skal de relevante poster blive i zonen. Det gælder især MX-poster og TXT-poster til SPF, DKIM og DMARC.
| Posttype | Skal normalt bevares? | Formål | Hvad du skal tjekke |
|---|---|---|---|
| A-record | Ja | Peger domæne til IPv4 | Fjern gamle eller dublerede poster |
| AAAA-record | Måske | Peger domæne til IPv6 | Undgå konflikt med CNAME på samme host |
| CNAME | Ja | Alias til andet hostnavn | Bruges ofte til www eller eksterne tjenester |
| MX | Ja | Mailrouting | Kritisk, hvis du bruger ekstern mail |
| TXT SPF | Ja | Tilladte mailservere | Bevar korrekt afsenderopsætning |
| TXT DKIM | Ja | Mailsignering | Må ikke slettes ved DNS-skift |
| TXT DMARC | Ja | Mailpolitik og rapportering | Giver kontrol over spoofing |
| TXT verifikation | Måske | Ejerskabsbekræftelse | Bruges af Google, Microsoft, Meta og andre |
En sund tommelfingerregel er enkel: Hvis en post ikke kun handler om webtrafik, så dobbelttjek den, før du aktiverer zonen.
De fleste fejl ved QUIC.cloud DNS skyldes ikke avanceret teknik. De skyldes, at én indstilling overses. Når det sker, ser problemet ofte større ud, end det egentlig er.
Særligt i 2026 er DNSSEC den fejl, der fortsat rammer mange. Lige bagefter kommer Cloudflare-proxy, konflikter mellem poster og misforståelser om, hvor navneservere faktisk ændres.
Hvis dit site ligger bag endnu et proxy-lag, kan QUIC.cloud få sværere ved at se den rigtige oprindelige serveropsætning. Det gælder især miljøer, hvor flere sikkerheds- eller cachelag er stablet oven på hinanden. Her hjælper det ofte at forenkle stien midlertidigt, indtil DNS og CDN er på plads.
Roddomænet er et klassisk emne, fordi example.dk ikke opfører sig helt som www.example.dk. Mange DNS-udbydere håndterer www med CNAME uden problemer, mens roddomænet kræver særlige record-typer eller workarounds. Når du bruger QUIC.cloud DNS, bliver den del mere direkte, fordi DNS-laget er lavet til at arbejde sammen med QUIC.clouds levering.
Det betyder ikke, at du skal droppe www. Tværtimod vælger mange stadig at definere ét primært domæne, lade det andet viderestille korrekt og holde struktur, cache og SSL ens hele vejen. Det giver en renere opsætning, især til webshops og sites med mange eksterne integrationer.
I den nyere dokumentation fylder domæne-aliaser også mere. Det er nyttigt, hvis ét site skal levere indhold på flere subdomæner, som static.example.dk eller et særskilt mediedomæne. Her er pointen ikke at oprette et nyt website, men at lade det eksisterende site levere ressourcer på flere navne. Det kan være smart ved asset-håndtering, kampagnesider eller særlige frontend-opsætninger, så længe DNS, SSL og cache er planlagt ordentligt.
Når du har gemt navneserverne hos registratoren, begynder ventetiden. Det er ikke et tegn på fejl, hvis ændringen ikke er synlig med det samme. Resolvere, browsere og internetudbydere cacher DNS forskelligt, og derfor kan resultatet være ujævnt i nogle timer.
Det bedste, du kan gøre i den fase, er at kontrollere fakta i stedet for at gætte. Tjek navneservere, slå poster op udefra, og bekræft at den aktive zone hos QUIC.cloud indeholder alt det nødvendige. Hvis websitet virker, men mail gør noget mærkeligt, er det næsten altid et tegn på en manglende eller forkert DNS-post og ikke på propagation alene.
Når DNS er aktivt, begynder den del, der ofte giver den mærkbare gevinst: finjustering. Du kan rense cache, kontrollere cache headers, teste svartider og sikre, at QUIC.cloud faktisk leverer indhold fra de rette noder.
Det er også nu, du bør tage et ekstra kig på sikkerhedslaget. Hvis en firewall, WAF eller et sikkerhedsplugin er for aggressivt, kan det genere både validering og trafik. Den type fejl viser sig tit som sporadiske problemer i admin, REST-kald eller billedlevering, selv om forsiden ser fin ud.
Hold også øje med TTL-værdierne på vigtige poster. For lange TTL’er gør fremtidige ændringer langsommere at rulle ud, mens ekstremt lave TTL’er kan være unødigt støjende. Et moderat niveau er ofte det mest praktiske, især hvis du administrerer et site, hvor både performance, stabilitet og maildrift skal fungere uden overraskelser.
Når den del er på plads, står du med en DNS-opsætning, der passer bedre til QUIC.clouds måde at arbejde på, og det giver et stærkt udgangspunkt for hurtigere, mere stabil levering af WordPress og WooCommerce.
Tjenester
Tilmeld dig vores nyhedsbrev
