CNAME flattening – pek rotdomenet til et vertsnavn

Mange webplattformer gir et mål som kunde.plattform.example, ikke en fast IP-adresse. På www.bedrift.no kan dette normalt løses med CNAME. På rotdomenet bedrift.no kolliderer en vanlig CNAME med DNS-postene som allerede må finnes der.

CNAME flattening, ALIAS og ANAME er navn leverandører bruker på løsninger som følger målvertsnavnet og returnerer adresseposter til klienten. De løser samme praktiske problem, men er ikke én felles, standardisert posttype med identisk oppførsel.

Hvorfor vanlig CNAME ikke passer på soneapex

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

Soneapex må allerede ha minst:

bedrift.no. IN SOA ns1.dnsleverandor.example. hostmaster.bedrift.no. (...)
bedrift.no. IN NS  ns1.dnsleverandor.example.
bedrift.no. IN NS  ns2.dnsleverandor.example.

Det kan også finnes MX, TXT, CAA, A og AAAA på apex. En ordinær CNAME kan ikke sameksistere med disse.

Dette er ikke en begrensning i nettleseren eller .no-registeret. Det følger av DNS-modellen. Et kontrollpanel som tillater «CNAME på @» bruker derfor vanligvis en syntese- eller aliasfunksjon bak grensesnittet.

Hva flattening faktisk gjør

Anta at kontrollpanelet viser:

bedrift.no. CNAME kunde.plattform.example.

Ved flattening gjør DNS-leverandøren i prinsippet dette:

1. Mottar et A- eller AAAA-spørsmål for bedrift.no.
2. Slår opp kunde.plattform.example og følger eventuell CNAME-kjede.
3. Henter målets IPv4- eller IPv6-adresser.
4. Returnerer adressene med bedrift.no som eiernavn.

Klienten kan se:

bedrift.no. 300 IN A 192.0.2.40
bedrift.no. 300 IN AAAA 2001:db8::40

Klienten ser altså ofte ikke en CNAME på apex. Den får et syntetisert A- eller AAAA-svar fra den autoritative DNS-leverandøren.

Dette gir to viktige konsekvenser:

• dig bedrift.no CNAME kan være tomt selv om panelet viser CNAME-lignende konfigurasjon
• svaret avhenger både av egen DNS-leverandør og målets DNS

Eksempeladressene er reservert for dokumentasjon og skal ikke brukes i produksjon.

Flattening, ALIAS og ANAME er produktbegreper

Ikke kopier ordet ALIAS fra én leverandør til en annen sonefil og forvent samme resultat. Les hvilke mål, posttyper, TTL-er og DNSSEC-modeller den konkrete leverandøren støtter.

Cloudflare som konkret eksempel

Cloudflare bruker CNAME flattening automatisk for CNAME på soneapex. For et DNS-only-mål beskriver Cloudflares flattening-eksempel at det offentlige svaret består av målets adresser, med den laveste TTL-en av CNAME-konfigurasjonen og målposten.

Hvis posten er proxied, returneres i stedet Cloudflares anycast-adresser og en plattformstyrt TTL. Da er to forskjellige mekanismer aktive:

• flattening løser målvertsnavnet
• proxyen blir det offentlige nettverksendepunktet

Et avvik mellom IP-en i panelets mål og offentlig dig er derfor ikke automatisk en feil. Kontroller proxy-status først.

Cloudflare kan også flattene CNAME på andre navn. Leverandøren advarer om at dette kan bryte tredjepartsverifisering som forventer å se selve CNAME-posten. Ikke slå på global flattening uten å kartlegge slike poster.

Velg løsning etter hva webplattformen gir

Plattformen gir faste A- og AAAA-adresser

Bruk de dokumenterte adressepostene direkte. Ikke bygg et aliaslag bare fordi kontrollpanelet tilbyr det.

Plattformen gir bare et vertsnavn

For www er en ordinær CNAME normalt mest portabel:

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

For apex velger dere én av disse:

• leverandørens støttede flattening-, ALIAS- eller ANAME-løsning
• plattformens dokumenterte apex-adresser
• www som hovednavn, med HTTP-redirect fra apex via en webtjeneste

Plattformen krever en CNAME for verifisering

Publiser den nøyaktige posten slik dokumentasjonen krever. Hvis tjenesten kontrollerer at posttypen er CNAME, kan flattening gjøre at den bare ser A/AAAA og avviser verifiseringen.

Ikke anta at en funksjon som er praktisk på apex bør slås på for alle CNAME-poster.

TTL består av flere lag

Med et vanlig CNAME kan resolveren cache både aliaset og sluttpostene etter deres respektive TTL-er. Ved flattening gjør den autoritative leverandøren mål-oppslaget og velger hva klientens syntetiserte svar skal få som TTL.

Spør leverandøren eller test:

• hvor ofte målet hentes på nytt
• hvordan målpostens TTL påvirker resultatet
• hvilken TTL klienten får
• hva som skjer ved timeout, NXDOMAIN eller SERVFAIL hos målet
• om stale adresser kan brukes ved midlertidig feil
• om proxied og DNS-only oppfører seg ulikt

En lav synlig TTL garanterer ikke at leverandørens interne målcache er like kort. En høy mål-TTL kan forsinke IP-endringer hos plattformen, avhengig av implementasjonen.

Flattening er ikke helsesjekk eller failover

Hvis målet returnerer tre A-poster, kan flattening returnere de samme adressene. Det betyr ikke at DNS-leverandøren tester applikasjonen og fjerner en syk server.

Kontroller om tjenesten:

• bare følger DNS-svaret
• har dokumenterte helsesjekker
• vurderer IPv4 og IPv6 separat
• har fallback når mål-oppslaget feiler
• beskytter mot løkker og for lange CNAME-kjeder

Bruk guiden til DNS-failover hvis tilgjengelighetsstyring er kravet.

DNSSEC må valideres på det offentlige svaret

Ved vanlig CNAME kan resolveren validere aliaset under én sone og målpostene under en annen. Ved apex-flattening returnerer leverandøren syntetiserte A/AAAA som data under kundens sone.

Leverandøren må støtte kombinasjonen av flattening og DNSSEC riktig. Test:

dig bedrift.no A +dnssec
dig bedrift.no AAAA +dnssec
dig bedrift.no DNSKEY +dnssec

Kontroller med en validerende resolver og se etter SERVFAIL, ikke bare at en ikke-validerende direkteforespørsel får en adresse. Ikke kopier DNSSEC-signaturer eller syntetiserte svar manuelt mellom leverandører.

HTTPS og redirect løses ikke i DNS

Flattening sender klienten til en adresse. Plattformen må fortsatt:

• kjenne bedrift.no som et tilkoblet domene
• presentere gyldig TLS-sertifikat
• velge riktig nettsted etter vertsnavn
• redirecte mellom apex og www hvis én variant er hovedadresse
• bruke konsekvent canonical URL og interne lenker

DNS kan ikke lage en HTTP 301-redirect. To navn som viser samme innhold uten redirect er heller ikke automatisk én SEO-adresse.

Les www eller ikke-www for webdelen.

Test det brukeren faktisk spør etter

Et komplett grunnsett er:

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

Forvent ikke at CNAME-spørsmålet viser panelkonfigurasjonen når apex er flattened. A og AAAA viser adressene klienten kan bruke. MX og TXT bekrefter at e-post- og verifiseringsdata fortsatt finnes på apex.

Test deretter tjenesten:

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

Kontroller status, redirect, sertifikat og innhold. Test både IPv4 og IPv6 hvis begge annonseres.

Flytting til ny DNS-leverandør

Flattening kan forsvinne i en soneeksport eller bli representert med en leverandørspesifikk markering. En ny leverandør kan:

• ikke støtte samme funksjon
• støtte bare enkelte mål
• bruke en annen TTL-modell
• gi aliaset en annen proxy-status
• signere syntetiske svar annerledes
• forvente en annen posttype i importen

Før navnetjenerbytte:

1. Identifiser alle flattened, ALIAS- og ANAME-poster.
2. Dokumenter mål, proxy-status og forventede offentlige A/AAAA-svar.
3. Gjenskap funksjonen hos ny leverandør, ikke bare tekstlinjen fra eksporten.
4. Spør alle nye navnetjenere direkte.
5. Test DNSSEC, HTTPS, redirect og e-postposter.
6. Behold gammel DNS aktiv gjennom cacheperioden.

Se DNS-sone og sonefil for resten av migreringsinventaret.

Vanlige feil

Den enkleste robuste beslutningen

Bruk denne rekkefølgen:

1. Følg webplattformens dokumenterte domeneoppsett.
2. Bruk vanlig CNAME på www når det passer.
3. Bruk dokumenterte A/AAAA på apex når plattformen tilbyr det.
4. Bruk flattening eller alias bare når DNS-leverandøren støtter målet og testkravene.
5. Velg én offentlig hovedadresse og redirect den andre over HTTPS.

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

Flattening er nyttig fordi det bevarer standard A/AAAA-svar på apex mens leverandøren følger et vertsnavn. Det er også en skjult avhengighet. Dokumenter implementasjonen og test offentlig DNS på nytt ved hver plattform- eller DNS-flytting.