CNAME

CNAME er en type DNS-record, der gør ét domænenavn til et alias for et andet domænenavn. Forkortelsen står for Canonical Name. I stedet for at pege direkte på en IP-adresse peger recorden på et navn, som DNS derefter slår videre op.

Et typisk eksempel er, at www.eksempel.dk har en CNAME til eksempel.dk. Hvis roddomænets A-record senere ændres til en ny IP, følger www-navnet med, fordi det stadig peger på domænenavnet og ikke på den gamle IP.

CNAME bruges ofte til subdomæner, der kobles på eksterne platforme. En tjeneste kan bede virksomheden oprette support.eksempel.dk som alias til et teknisk værtsnavn hos leverandøren. Brugeren ser fortsat virksomhedens eget subdomæne, mens DNS finder den eksterne tjeneste.

En CNAME er ikke det samme som en almindelig viderestilling i browseren. Ved en redirect ændres den synlige URL, når webserveren sender brugeren videre. Ved CNAME sker forbindelsen i DNS-laget, før browseren kontakter serveren. Den eksterne server skal stadig være konfigureret til at modtage det oprindelige værtsnavn.

Det er en enkel recordtype, men den indgår ofte i komplekse opsætninger med hosting, CDN, e-mailverifikation og SaaS-platforme. Derfor skal man følge den konkrete tjenestes instruktioner præcist.

Læs først leverandørens opsætningsvejledning. Den angiver normalt et værtsnavn og en destination. Hvis der står, at shop skal pege på shops.platform.example, skal målet indtastes som et domænenavn, ikke som en URL med https eller en sti.

Kontrollér, om navnet allerede har andre records. Et CNAME-navn må som hovedregel ikke samtidig have eksempelvis A-, MX- eller TXT-records. Hvis shop.eksempel.dk allerede bruges til verifikation eller mail, skal konflikten løses før ændringen.

Vær opmærksom på roddomænet. Klassisk DNS tillader normalt ikke en almindelig CNAME på selve eksempel.dk, fordi roden også skal have blandt andet NS- og SOA-oplysninger. Nogle udbydere tilbyder ALIAS, ANAME eller CNAME flattening som en praktisk løsning, men det er ikke det samme som en standard-CNAME.

Planlæg ændringen med TTL. Hvis et subdomæne allerede peger et andet sted, kan en lavere TTL inden skiftet reducere den tid, caches beholder den gamle destination. Sænk den i god tid, ikke fem minutter efter problemet er opstået.

Test DNS-resultatet og den faktiske tjeneste. Et opslag kan vise den korrekte CNAME, mens websitet stadig fejler, fordi SSL-certifikatet ikke dækker subdomænet, eller platformen ikke har fået domænet tilføjet.

Dokumentér ejerskab. Notér hvilken ekstern tjeneste recorden tilhører. Når et abonnement opsiges to år senere, skal virksomheden kunne se, hvorfor subdomænet peger på et ukendt teknisk navn.

En virksomhed vil bruge kursus.eksempel.dk til en ekstern læringsplatform. Platformen oplyser destinationen customer.vendor-platform.com. Der oprettes en CNAME med værten kursus og den angivne destination.

Platformen verificerer efterfølgende domænet og udsteder et certifikat. Når en bruger besøger subdomænet, slår DNS først aliaset op og finder leverandørens infrastruktur. Adressen i browseren kan fortsat være virksomhedens eget subdomæne.

Senere flytter leverandøren sine servere. Virksomheden behøver ikke ændre sin CNAME, fordi aliaset stadig peger på leverandørens navn. Leverandøren opdaterer selv de underliggende A- eller AAAA-records.

I et andet tilfælde forsøger en medarbejder at få eksempel.dk til at vise andenvirksomhed.dk/side ved at oprette en CNAME. Det virker ikke som ønsket, fordi CNAME ikke kan pege på en URL-sti og ikke skaber en synlig redirect. Der skal bruges en webserver-redirect eller en anden løsning.

På en webshop kan betalings- eller sporingsleverandører også kræve CNAME-records. Her bør ændringen vurderes sammen med sikkerhed og tracking, fordi subdomænet kan indgå i dataflowet og ikke blot være en pæn adresse.

Den største fejl er at indtaste hele URL’en som mål, eksempelvis https://platform.example/path. En CNAME accepterer et domænenavn, ikke protokol, skråstreger eller en bestemt underside.

En anden faldgrube er at tro, at aliaset skjuler den tekniske leverandør i alle sammenhænge. DNS-opslag vil fortsat kunne vise CNAME-kæden. Funktionen handler om routing og administration, ikke anonymisering.

Pas også på lange CNAME-kæder. Hvis navn A peger på B, som peger på C, som peger på D, kræver opslaget flere trin og bliver sværere at fejlfinde. Følg leverandørens løsning, men undgå egne unødvendige mellemled.

Endelig kan en gammel CNAME blive en sikkerhedsrisiko, hvis den peger på en ekstern tjeneste, virksomheden ikke længere ejer. Fjern records, når løsningen udfases, så subdomænet ikke efterlades til en fremmed eller genoprettelig konto.

CNAME-resultatet bliver fulgt, indtil DNS når en record, der giver en adresse eller anden relevant information. Browseren arbejder altså ikke direkte med ordet “CNAME”; den får i sidste ende en destination, der kan kontaktes.

Nogle DNS-udbydere viser et automatisk punktum efter det fulde målnavn, mens andre skjuler det. Det afsluttende punktum markerer et fuldt kvalificeret domænenavn. Følg kontrolpanelets format og undgå at tilføje jeres eget domæne to gange.

En CNAME kan ikke reparere en forkert hosting-konfiguration. Serveren eller platformen skal kende domænet, og et gyldigt certifikat skal være på plads. DNS fortæller kun, hvor forbindelsen skal gå hen.

Hvis nameserverne ligger hos en anden udbyder end domæneregistratoren, skal recorden oprettes dér. Det er en almindelig årsag til, at en korrekt indtastet ændring tilsyneladende ikke har effekt.

Ved lancering af en hjemmeside bør både A-records, CNAME-records, mailposter og tredjepartstjenester dokumenteres samlet. Det minimerer risikoen for, at en simpel webændring rammer noget, der ikke var synligt i browseren.

CNAME bruges ofte til tjenester som nyhedsbreve, supportportaler, statussider og trackingdomæner. Hvert subdomæne bør have en ejer og et formål, fordi de ellers let bliver glemt efter et leverandørskifte.

En CNAME-kæde påvirkes af TTL på flere niveauer. Aliasets egen cache og destinationens records kan have forskellige levetider. Ved fejlfinding skal man derfor følge hele kæden til den endelige adresse.

Nogle leverandører beder både om en CNAME og en TXT-record til verifikation. De har forskellige funktioner: CNAME dirigerer navnet, mens TXT kan bevise ejerskab eller indeholde sikkerhedsdata. Opret kun de records, der står i vejledningen.

Hvis subdomænet bruges til e-mailafsendelse, kan CNAME indgå i DKIM eller tracking, mens MX-recorden stadig styrer modtagelse. Det er endnu en grund til ikke at slette ukendte records under en webflytning.

Fjernelse af en CNAME bør planlægges på samme måde som oprettelsen. Kontrollér trafik, integrationer og certifikater først. En tilsyneladende ubrugt record kan være indbygget i gamle e-mails, QR-koder eller automatiserede systemer.

Nogle platforme ændrer den anbefalede CNAME-destination ved migration eller kontoopgradering. Abonnér på driftsbeskeder eller gennemgå domæneindstillingerne ved større ændringer, så et gammelt alias ikke bliver stående efter udfasning.

Et subdomæne kan have sin egen cookie- og sikkerhedskontekst. Hvis CNAME bruges til tracking eller kundelogin, bør SameSite, certifikat og dataansvar vurderes sammen med DNS. Aliaset gør ikke automatisk tredjepartstjenesten til en intern løsning.

Ved fejlfinding kan kommandoer som dig eller nslookup vise den faktiske kæde. Sammenlign det autoritative svar med en offentlig resolver. Det gør det lettere at skelne mellem en forkert record og en gammel cache.

En CNAME kan være praktisk i et stagingmiljø, hvor testdomænet skal følge en platform, der ændrer IP. Men stagingmiljøet bør stadig beskyttes med login eller noindex og ikke være offentligt tilgængeligt som en parallel version af sitet.

Ved ejerskifte af domæne bør alle eksterne CNAME-destinationer gennemgås. De kan pege på konti, som den tidligere leverandør kontrollerer. DNS-zonen er derfor også en oversigt over afhængigheder og ikke kun tekniske linjer.

Notér også den forventede destination uden for DNS-panelet, så en senere ændring kan sammenlignes med den oprindelige leverandørinstruktion.

Guiden om HTTP, HTTPS og den tekniske vej til websitet forklarer næste led, når et CNAME har sendt trafikken videre til den rigtige tjeneste.