CNAME mot A-post – velg riktig DNS-peker

En A-post kobler et DNS-navn til en IPv4-adresse. En CNAME-post gjør et DNS-navn til alias for et annet DNS-navn.

Velg etter verdien leverandøren faktisk gir:

• får dere en stabil IPv4-adresse, brukes A
• får dere et vertsnavn for et subdomene, brukes ofte CNAME
• på soneapex må vanlig CNAME erstattes av dokumentert A/AAAA eller en støttet aliasfunksjon

Forskjellen i ett eksempel

bedrift.no.      300 IN A     192.0.2.40
www.bedrift.no.  300 IN CNAME bedrift.no.

Et A-spørsmål for bedrift.no får IPv4-adressen som svar. Et oppslag for www.bedrift.no følger CNAME til bedrift.no og henter deretter A og eventuelt AAAA.

192.0.2.0/24 er reservert for dokumentasjon. Bruk bare adressen webplattformen har tildelt den konkrete tjenesten.

Sammenligning

AAAA gjør samme type direkte adressekobling som A, men til IPv6. CNAME kan ende i både A og AAAA.

Hva CNAME egentlig betyr

CNAME står for Canonical Name. Aliasnavnet er eiernavnet til CNAME-posten, mens verdien er målnavnet:

butikk.bedrift.no. 300 IN CNAME kunde.plattform.example.

Det betyr ikke at de to URL-ene er identiske for SEO eller at plattformen automatisk kjenner kundedomenet. Det betyr bare at DNS-oppløsningen fortsetter ved målnavnet.

Målet må være et DNS-navn. Dette er feil verdier:

192.0.2.40
https://kunde.plattform.example/
kunde.plattform.example/path
kunde.plattform.example:443

CNAME kan ikke peke til IP-adresse, URL, sti eller port. Bruk A/AAAA for adresse, HTTP for redirect og SRV eller HTTPS/SVCB når den aktuelle tjenestestandarden og klientene støtter portinformasjon.

CNAME-navnet kan ikke ha andre ordinære poster

RFC 2181 presiserer at et aliasnavn med CNAME ikke kan ha andre ordinære DNS-data på samme navn.

Dette er ugyldig:

app.bedrift.no. IN CNAME kunde.plattform.example.
app.bedrift.no. IN TXT "verification=abc123"

Hvis tjenesten krever både CNAME og TXT på app.bedrift.no, må leverandøren gi en annen verifiseringsplassering eller en annen koblingsmodell.

DNSSEC-relaterte poster har egne regler rundt aliasnavn, men det gjør ikke blandingen med MX, TXT, A eller AAAA gyldig.

Hvorfor CNAME ikke kan stå vanlig på apex

Soneapex er bedrift.no. Det må allerede ha SOA og NS, og har ofte MX, TXT og CAA. En ordinær CNAME ville kreve at disse postene ikke fantes på samme navn.

Derfor er dette ikke en standard sonekonfigurasjon:

bedrift.no. IN CNAME kunde.plattform.example.

Noen DNS-paneler tillater likevel «CNAME på @». De bruker da CNAME flattening eller en ALIAS-/ANAME-funksjon og returnerer syntetiserte A/AAAA-svar offentlig.

Slike funksjoner har ulike regler for TTL, mål, DNSSEC, eksport og proxy. Les CNAME flattening på apex før leverandørbytte.

Når A-post er riktig

Bruk A når:

• webplattformen gir en dokumentert IPv4-adresse
• soneapex skal peke til fast server eller load balancer
• adressen eies eller holdes stabil av leverandøren
• dere kan oppdatere posten kontrollert når adressen endres

bedrift.no. 300 IN A 192.0.2.40

Ikke slå opp leverandørens vertsnavn én gang og hardkod adressen som A uten tillatelse. Plattformen kan endre IP, bruke geografiske svar eller kreve vertsnavnet for trafikkstyring.

Flere A-poster er heller ikke automatisk lastbalansering eller failover. Klienter cacher og velger adresser ulikt, og DNS-svaret kjenner ikke nødvendigvis tjenestehelsen.

Bruk A-post-guiden for trygg endring, flere adresser og proxy.

Når CNAME er riktig

Bruk CNAME når:

• www skal følge apex eller et plattformmål
• et subdomene kobles til SaaS, CDN eller statusplattform
• leverandøren styrer målvertsnavnets adresser
• en tjeneste uttrykkelig krever CNAME-verifisering
• samme aliasnavn ikke trenger andre posttyper

www.bedrift.no.     300 IN CNAME bedrift.no.
status.bedrift.no.  300 IN CNAME status.vendor.example.

Leverandøren må fortsatt knytte vertsnavnet til riktig kundekonto og utstede gyldig sertifikat. CNAME alene beviser ikke at dere kontrollerer målplattformen.

CNAME for domeneverifisering

En tjeneste kan gi:

token123.bedrift.no. IN CNAME verify.vendor.example.

Verdien er et DNS-navn, ikke en «verifiserings-URL». Kopier eiernavn og mål nøyaktig.

Før posten slettes, kontroller om den bare brukes ved førstegangsverifisering eller også ved:

• løpende kontroll over domene og DNS
• sertifikatfornyelse
• DKIM-nøkkelrotasjon
• tjenestens gjenoppretting

En gammel verifiserings-CNAME bør ikke bli stående uten eier. Hvis leverandørkontoen eller målet slettes mens DNS-aliaset består, kan det oppstå dangling DNS og risiko for subdomain takeover .

CNAME brukes ofte for DKIM

E-postleverandører kan be om:

selector1._domainkey.bedrift.no. IN CNAME selector1.customer.vendor.example.

Da publiserer leverandøren den faktiske DKIM-nøkkelen hos målet og kan rotere den uten at kunden endrer TXT manuelt.

Ikke legg en TXT-nøkkel på samme selector-navn ved siden av CNAME. Sjekk hvilken type leverandørens instruks krever.

MX- og NS-mål skal ikke være CNAME

Dette er to forskjellige lag:

bedrift.no. IN MX 10 mx.vendor.example.

MX-posten peker til et vertsnavn. Dette målet skal løse til adresseposter, ikke være et CNAME-alias. Den samme hovedregelen gjelder mål i NS-poster.

Ikke bruk CNAME som et skjult mellomledd for å gjøre e-post- eller navnetjenermål enklere å bytte. Følg tjenestens dokumenterte kanoniske vertsnavn.

Korte CNAME-kjeder er bedre

Dette virker teknisk, men gir ekstra avhengigheter:

www.bedrift.no. CNAME kunde.platform-a.example.
kunde.platform-a.example. CNAME edge.platform-b.example.
edge.platform-b.example. A 192.0.2.40

Resolveren må følge kjeden. Hvert ledd kan ha egen TTL, DNSSEC-status, tilgjengelighet og leverandør.

Unngå:

• CNAME som peker til seg selv
• løkker mellom to eller flere navn
• unødvendig lange kjeder
• mål som ikke finnes
• mål under domener som kan utløpe

Plattformstyrte kjeder kan være tilsiktet. Dokumenter dem og test sluttresultatet i stedet for å «rydde» leverandørens oppsett uten forståelse.

TTL gjelder både alias og mål

Resolveren kan cache CNAME-posten og adressepostene for målet med ulike TTL-er. Ved endring kan noen ha gammel aliasverdi, andre nytt alias med gamle måladresser.

Senk relevant CNAME-TTL i forkant hvis aliasmålet skal byttes. Dere kontrollerer ikke nødvendigvis TTL for leverandørens mål.

Et CNAME følger fremtidige adresseendringer etter cache, men gjør ikke alle endringer øyeblikkelige.

DNSSEC følger flere soner

Når alias og mål ligger i ulike signerte soner, validerer resolveren relevante data gjennom begge DNSSEC-kjedene. En feil hos målsonen kan gi SERVFAIL selv om kundens CNAME er korrekt signert.

Test CNAME og sluttadresser med en validerende resolver. dig +dnssec ber om DNSSEC-data, men er ikke alene en full validering.

CNAME er ikke HTTP-redirect eller canonical

Hvis både bedrift.no og www.bedrift.no peker til samme plattform, må webserveren fortsatt velge én hovedadresse og sende den andre med HTTP 301 eller 308.

DNS kan ikke:

• bevare eller endre URL-sti
• velge HTTPS-skjema
• sende HTTP-status
• angi HTML-canonical
• flytte brukeren til en synlig annen adresse

Konfigurer redirect og sertifikat i webplattformen.

Slik tester dere

dig www.bedrift.no CNAME
dig www.bedrift.no A
dig www.bedrift.no AAAA
dig @<autoritativ-navnetjener> www.bedrift.no CNAME +norecurse

Første oppslag viser aliasposten. A og AAAA viser sluttadressene klienten kan bruke. Direkte autoritativt oppslag viser hva egen sone publiserer uten rekursiv cache.

Ved flattening eller proxy kan offentlig CNAME være tomt selv om panelet viser en CNAME-lignende konfigurasjon. Se da på A/AAAA og proxy-status.

Test tjenesten etter DNS:

curl -I https://www.bedrift.no/

Kontroller sertifikat, status, redirect og innhold. Et korrekt DNS-alias kan fortsatt gå til en plattform som ikke har bundet kundedomenet.

Vanlige feil

Valget i praksis

1. Bruk nøyaktig type og verdi fra aktiv leverandør.
2. Velg A når verdien er en godkjent IPv4-adresse.
3. Velg CNAME når et subdomene skal følge et vertsnavn.
4. Bruk dokumentert apex-løsning når leverandøren bare gir vertsnavn.
5. Kontroller konflikt med TXT, MX og eksisterende poster.
6. Test autoritativt svar, sluttadresser, TLS og webinnhold.
7. Dokumenter eier og fjern aliaset når tjenesten avvikles.

Vymo setter opp domenekoblingen for den enkle bedriftsnettsiden vi leverer. Kunden får foreløpig ikke et selvbetjent DNS- eller flatteningpanel. Hvis DNS ligger hos en annen leverandør, send domenenavn, DNS-leverandør og de offentlige verdiene plattformen har oppgitt via kontaktsiden . Ikke send passord, API-nøkler eller flyttekoder.

A er en direkte IPv4-adresse. CNAME er et alias med en ny DNS-avhengighet. Det riktige valget er det tjenesten dokumenterer og dere kan teste hele veien til fungerende HTTPS.