DNS for nytt nettsted – en trygg plan før lansering

DNS kobler domenet til det nye nettstedet, men samme sone kan også styre e-post, sertifikater og andre tjenester. En trygg lansering endrer bare postene som faktisk skal flytte webtrafikken.

Målet er ikke «alle nye DNS-poster». Målet er et dokumentert postsett som sender bedrift.no og www.bedrift.no til riktig plattform uten å skade det som allerede virker.

Først: finn hvem som eier hvert lag

Leverandørene kan være forskjellige. Et domene hos én registrar kan bruke DNS hos en annen, web hos en tredje og e-post hos en fjerde.

Finn aktive navnetjenere før du redigerer. En korrekt post i et gammelt eller inaktivt panel påvirker ingen brukere.

dig bedrift.no NS +short

Ikke bytt navnetjenere hvis én webpost er nok

Å endre A, AAAA eller CNAME flytter den aktuelle webadressen. Å bytte navnetjenere flytter ansvaret for hele DNS-sonen og kan påvirke:

• nettsted og underdomener
• MX og e-postmottak
• SPF, DKIM og DMARC
• sertifikatutstedelse og CAA
• verifisering av tredjepartstjenester
• SRV-poster og andre integrasjoner
• DNSSEC og DS hos foreldresonen

Behold fungerende DNS-leverandør hvis webplattformen bare trenger noen nye poster. Bytt NS først når dere bevisst flytter hele sonen og har kopiert og testet alle avhengigheter.

Hent verdiene fra den konkrete webplattformen

Be om en skriftlig oppskrift for:

• apex eller rotdomenet bedrift.no
• www.bedrift.no
• eventuelle verifiseringsposter
• IPv4 og IPv6
• forventet proxy-status
• domeneverifisering og sertifikatutstedelse
• om gammel post skal erstattes eller beholdes midlertidig

Ikke bruk en IP du finner ved å slå opp plattformens egen nettside. Ikke kopier eksempelverdier fra en generell guide. Plattformen kan bruke lastbalansering, CDN eller kundespesifikk binding.

Velg én hovedadresse

Bestem om nettstedets offentlige hovedadresse er:

https://bedrift.no/

eller:

https://www.bedrift.no/

Begge DNS-navn bør normalt fungere, men den andre varianten bør få en permanent HTTP-redirect til hovedadressen. DNS alene lager ikke redirect.

Bruk samme hovedadresse i canonical, sitemap, interne lenker, annonser og bedriftsprofiler. Det gjør måling og indeksering tydeligere.

Tre vanlige DNS-oppsett

Eksemplene bruker adresser og navn reservert for dokumentasjon.

Fast IPv4 fra webhotellet

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

IPv4 og testet IPv6

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

Publiser AAAA bare når hele IPv6-veien, brannmur, webserver og HTTPS er testet. En gammel eller halvferdig AAAA kan sende enkelte brukere til feil side.

Plattformen gir et vertsnavn

www  300 IN CNAME kunde.plattform.example.

Vanlig CNAME passer ikke på soneapex fordi apex allerede har SOA og NS. Følg plattformens dokumenterte A/AAAA eller bruk en støttet CNAME flattening-, ALIAS- eller ANAME-løsning .

Les A mot CNAME når leverandøren oppgir flere alternativer.

Webflytting skal normalt ikke endre e-post

Ta vare på dagens e-postposter før lansering:

dig bedrift.no MX
dig bedrift.no TXT
dig _dmarc.bedrift.no TXT

Kartlegg også alle DKIM-selectorer fra e-postleverandøren. De kan være TXT eller CNAME på navn som selector1._domainkey.bedrift.no.

Ikke:

• slett MX fordi webhotellet ikke bruker posten
• legg til en ny SPF-post ved siden av den eksisterende
• kopier en eksempel-DMARC-policy uten rapportmottak og plan
• fjern verifiseringsposter bare fordi de ser ukjente ut
• aktiver webplattformens e-postmal hvis bedriften bruker en annen leverandør

Hvis e-post også skal flyttes, gjennomfør det som en egen, dokumentert endring. Se peke domene uten e-postproblemer .

Test nettstedet før offentlig DNS endres

Webplattformen må kjenne domenet og ha riktig innhold før brukerne sendes dit.

Når plattformen tillater direkte IP-test, kan curl --resolve koble vertsnavnet til ny adresse lokalt:

curl --resolve 'bedrift.no:443:192.0.2.40' https://bedrift.no/
curl --resolve 'www.bedrift.no:443:192.0.2.40' https://www.bedrift.no/

Bytt dokumentasjonsadressen med adressen dere har fått. Testen bruker riktig vertsnavn og TLS mot valgt adresse uten å endre offentlig DNS.

Kontroller:

• TLS-sertifikat og kjede
• riktig nettsted for begge vertsnavn
• redirect til valgt hovedadresse
• statuskode, innhold og bilder
• kontaktlenker og telefonnummer
• skjema fra innsending til faktisk mottak
• personverninformasjon og cookiebruk
• 404-side og viktige gamle URL-er
• mobilvisning og tastaturnavigasjon

En grønn forside er ikke nok hvis kontaktskjemaet aldri kommer frem.

Sertifikat og CAA må være klare

Noen plattformer kan verifisere og utstede sertifikat før DNS-endringen. Andre krever at domenet peker til plattformen først.

Avklar:

• hvilke navn sertifikatet skal dekke
• hvilken sertifikatutsteder plattformen bruker
• om CAA tillater denne utstederen
• om ACME krever TXT eller HTTP-verifisering
• hvor raskt plattformen oppretter sertifikatet
• hvordan fornyelse skjer senere

Ikke tving all HTTP til HTTPS før plattformen har et gyldig sertifikat og riktig redirectmodell.

Planlegg TTL før lanseringsdagen

Hvis dagens webpost har høy TTL, kan dere senke den minst én gammel TTL-periode før endringen. Da har resolvere mulighet til å hente lavere verdi før lansering.

Eksempel:

Tidslinjen må tilpasses gammel TTL og plattformens prosedyre. «24–48 timer propagering» er ikke en universell forklaring; se på hvilke data som var cachet og hvor lenge.

Publiser med et konkret endringsark

Loggfør tidspunkt, utfører og kontrollresultat. Endre ikke flere uavhengige tjenester samtidig hvis det kan unngås.

Kontroller DNS på riktig nivå

Spør først autoritativ DNS for å se hva sonen publiserer:

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

Sammenlign deretter resolverne brukerne benytter:

dig @1.1.1.1 bedrift.no A
dig @8.8.8.8 bedrift.no A

Et riktig autoritativt svar og et gammelt rekursivt svar peker mot cache. Et feil autoritativt svar krever endring i sonen, ikke mer venting.

Kontroller A og AAAA separat. En samlet nettlesertest kan skjule hvilken adressefamilie som ble brukt.

Etter at DNS peker riktig

Test hele produksjonsopplevelsen fra eksternt nettverk:

• apex og www over HTTP og HTTPS
• forventet redirect uten loop
• sertifikat for alle offentlige navn
• reell skjemainnsending og mottak
• innkommende og utgående e-post
• overvåking fra mer enn én nettverksvei
• logger og varsling
• kritiske URL-er fra den gamle siden

Oppdater eller send inn sitemap med valgt hovedadresse. Kontroller at produksjon ikke har noindex, at robots-regler ikke er arvet fra staging, og at canonical peker til offentlig URL.

Bruk den komplette lanseringssjekklisten for resten av nettstedet.

Rollback må være mulig før endringen

Rollback for web-DNS er normalt å gjenopprette de dokumenterte gamle webpostene. Det forutsetter at gammel hosting fortsatt er aktiv og har riktig innhold og sertifikat.

Stopp eller reverser dersom:

• nytt nettsted gir TLS-feil
• feil innhold vises på apex eller www
• kritisk skjema feiler
• IPv4 og IPv6 gir ulike produksjonssider
• sertifikatet ikke kan utstedes innen avtalt vindu
• e-postposter utilsiktet er endret

Ikke slett hele sonen eller bytt navnetjenere som panikkløsning. Rett det avgrensede navnet og posttypen.

Hvis Vymo skal lage nettstedet

Vymo leverer én enkel bedriftsnettside og hosting til 0 kroner det første året. Fra år to koster hosting fra 49 kroner per måned, fakturert årlig. E-post er ikke inkludert i gratistilbudet og bestilles separat.

Vi setter opp nettstedet og domenekoblingen. Bedriften må være registrert, og leveranseomfang, innhold og eventuell flytting av eksisterende DNS avklares før publisering. Bestill gratis nettside med bedrift, e-post og valgfri eksisterende nettadresse.

En trygg DNS-lansering er liten og målbar: endre bare webveien, bevar e-post, test begge adressene og ha den gamle verdien klar hvis produksjonen ikke består kontrollen.