Sådan forbinder du dit eget domæne med et bookingsystem
Siden er bygget. Logoet sidder rigtigt, avancerne er sat, en testbooking er gået igennem på platformens subdomæne, og en på kontoret har allerede sendt linket til tre kunder. Så kommer det oplagte spørgsmål: hvorfor står der stadig en andens navn i adressen? Denne guide viser, hvordan du forbinder dit eget domæne med et bookingsystem uden at hyre nogen — hvad du egentlig ændrer, hvilke to eller tre poster det drejer sig om, hvorfor hængelåsen dukker op senere, end du regner med, og den ene indstilling, der i stilhed ødelægger firmaets e-mail, hvis du rører ved den.
Du behøver ikke forstå DNS i dybden. Du skal have ét billede i hovedet: dit domænenavn er et vejskilt, og du drejer det mod en ny bygning. Alt nedenfor er detaljer om det billede.
Hvor dit domæne egentlig bor
Op til tre forskellige firmaer kan være involveret, og de fleste ejere kender kun det ene. Registratoren er der, hvor du købte navnet og betaler den årlige fornyelse. DNS-udbyderen er der, hvor navnets poster redigeres — ofte samme firma som registratoren, men ikke altid, især ikke hvis en webdesigner for år tilbage flyttede navnet til en separat DNS-tjeneste. Webhostingen er der, hvor din nuværende side kører.
De poster, du skal tilføje, ligger hos DNS-udbyderen. Find derfor først ud af, hvem det er. Log ind hos registratoren og se, hvilke navneservere domænet har. Hører de til registratoren, redigerer du posterne dér. Peger de et andet sted hen, er det dér, du arbejder. Et par minutter på det her sparer en eftermiddag med ændringer i et kontrolpanel, som intet læser.
Roddomæne eller subdomæne: beslut dig, før du rører noget
Roddomænet — også kaldet apex eller det ”nøgne” domæne — er ditbureau.dk uden noget foran. Et subdomæne er alt med en etiket foran: www.ditbureau.dk, book.ditbureau.dk, rejser.ditbureau.dk. Platformen accepterer begge, men valget bestemmer, hvilken post du tilføjer.
Grunden er gammel og kan ikke forhandles. Roddomænet bærer allerede de poster, der definerer selve domænet, og DNS tillader ikke, at en CNAME deler navn med noget andet. Derfor peges et roddomæne med en A-post direkte mod en IP-adresse, mens et subdomæne peges med en CNAME mod et andet værtsnavn.
| Roddomæne (ditbureau.dk) | Subdomæne (book.ditbureau.dk) | |
|---|---|---|
| Post du tilføjer | A-post, der peger på en IP-adresse | CNAME, der peger på et værtsnavn hos platformen |
| Hvad kunden skriver | Den kortest mulige adresse | Et ord mere, hvilket betyder mindre, når kunden kommer via et link |
| Din eksisterende side | Skal flytte væk fra roddomænet, ellers erstattes den af bookingsiden | Bliver præcis, hvor den er |
| Firmaets e-mail | Upåvirket, så længe MX-posterne får lov at være | Upåvirket |
| Passer til | Et bureau, hvis hjemmeside ER bookingsiden | Et bureau med præsentationsside, blog eller CMS, det vil beholde |
De fleste bureauer, der allerede har en hjemmeside, bør starte med et subdomæne. Den række, folk er uenige om, er den anden: nogle ejere synes, at et subdomæne virker mindre etableret. Det er et fair synspunkt, men det vejer mindre, når de fleste kunder kommer til dig via et link på WhatsApp eller Instagram og ikke ved at taste adressen.
Posterne du tilføjer, og hvad hver enkelt gør
Det guidede DNS-trin viser de præcise værdier for dit domæne. Kopiér dem derfra, ikke fra en artikel — heller ikke denne. Herunder står, hvad hver post er til, så skærmen giver mening, når du ser den.
- CNAME, til et subdomæne. Name: den etiket, du har valgt, fx
book. Value: platformens værtsnavn fra DNS-trinnet. Den siger ”dette navn er et alias for det der”, så hvis platformens servere flytter, virker din post stadig, uden at du rører den. - A-post, til et roddomæne. Name:
@, som de fleste DNS-paneler bruger om det nøgne domæne. Value: IP-adressen fra DNS-trinnet. Den siger ”dette navn bor på denne adresse”. - TXT, nogle gange. Nogle hostingopsætninger beder også om en verifikationspost: en lang tilfældig streng under et navn, som DNS-trinnet angiver. Den gør intet for de besøgende. Den beviser, at den, der styrer domænet, har sagt ja til forbindelsen. Viser trinnet en, så tilføj den; gør det ikke, mangler der intet.
To fejl står for de fleste mislykkede forsøg. Den første er at skrive hele domænet i feltet Name. Mange paneler tilføjer automatisk dit domæne, så book.ditbureau.dk bliver til book.ditbureau.dk.ditbureau.dk, som ikke fører nogen steder hen. Skriv kun etiketten. Den anden er at lade en gammel post blive stående. Har book allerede en A-post fra et tidligere projekt, kan en CNAME ikke stå ved siden af, og nogle paneler beholder stiltiende den gamle. Slet først den gamle post for præcis det navn.
Har din DNS-udbyder en proxy-kontakt på posten — Cloudflare viser den som en orange sky — så sæt den til DNS-only, mens du forbinder. En proxy svarer de besøgende på platformens vegne og skjuler den dermed for det tjek, der beskrives nedenfor.
Hvorfor hængelåsen kommer sidst
Det er her, ejere tror, at noget er gået i stykker. Posterne er gemt, domænet ser rigtigt ud, og browseren siger, at forbindelsen ikke er sikker — eller siden åbner slet ikke. Intet er i stykker. Rækkefølgen ligger bare fast.
Et TLS-certifikat, hængelåsen, udstedes af en certifikatudsteder, der først skal bekræfte, at domænet virkelig peger derhen, hvor anmodningen siger. Den tjekker ved at slå navnet op i offentlig DNS og i de fleste opsætninger ved at sende en forespørgsel til domænet og forvente, at platformen svarer. Indtil din post har nået de resolvere, udstederen bruger, fejler tjekket, og ingen mængde klik ændrer det. Så snart posten slår igennem, anmoder platformen automatisk om certifikatet. Du køber ikke noget, uploader ikke noget og fornyer ikke noget.
Hvor længe det tager at slå igennem, afhænger mest af TTL på den post, der lå der før: den tid, andre servere har fået lov at huske det gamle svar. Et helt nyt navn dukker som regel hurtigt op. Et navn, der pegede et andet sted hen i går, kan blive ved med at svare med den gamle adresse et stykke tid. Ved du, at du erstatter en eksisterende post, så sænk dens TTL dagen før, og ventetiden bliver kortere.
Ellers: vent, og tjek så. Bliv ikke ved med at redigere posten — hver ændring giver hver server, der har gemt et forkert svar, endnu en grund til at blive ved med at levere det. Offentlige DNS-opslagstjenester viser, hvad resten af verden ser for dit navn; når de viser værdien fra DNS-trinnet, er certifikatet det næste, der sker.
Hvad en fejl koster
De dyre fejl ligger ikke i bookingsiden. De ligger i alt det andet, der hænger på dit domæne.
Den værste er at skifte navneservere, når du kun skulle tilføje en post. At flytte navneserverne overdrager hele domænet til en ny DNS-udbyder, og alle poster, der ikke genskabes dér, forsvinder — også de MX-poster, der leverer firmaets e-mail. Et bureau kan miste en dags mails fra kunder, bekræftelser fra leverandører og flyselskabernes besked om køreplansændringer, før nogen opdager, at indbakken er blevet stille. Intet ved at forbinde en bookingside kræver, at navneserverne flyttes. Tilføj poster; lad resten være.
Den anden er at pege roddomænet mod bookingsiden, mens den gamle side stadig har sider, folk bruger: en visumside, der ligger godt på Google, en kontaktside, der står trykt på visitkortene. De links lander nu på en bookingside, der ikke har dem. Flyt enten den gamle side til et subdomæne først, eller forbind bookingsiden til et subdomæne i stedet.
Den tredje koster kun nerver: at melde den nye adresse ud, før hængelåsen er der. En browser, der advarer kunderne mod din side på selve dagen, hvor du promoverede den, er en dårlig introduktion. Meld ud, når certifikatet er aktivt, ikke når posten er gemt.
Behold platformens domæne — det er din reserve
Det subdomæne hos platformen, som din side startede på, forsvinder ikke, når dit eget domæne er forbundet. Det kan ikke fjernes, og det er med vilje.
Det er adressen, du tester fra, mens det egne domæne falder på plads, og den, der stadig virker, hvis fornyelsen hos registratoren glipper, eller nogen kommer til at ændre i DNS. Bookingsystemet bag begge adresser er det samme, så bookinger, kunder og rapporter er ligeglade med, hvilken dør der blev brugt. Skriv den ned et sted, der ikke afhænger af, at dit eget domæne er oppe.
Det giver også den rigtige rækkefølge for en ny side, den samme som når du lancerer et OTA på én dag: gå live på det subdomæne, som tilmeldingsguiden opretter uden at bede om kort, og forbind dit domæne, når siden er værd at vise frem. Hvad selve siden dækker, når adressen er din, står i hvad en white-label-rejseside faktisk giver dig.
Tjekliste: forbind dit eget domæne med et bookingsystem
- Find ud af, hvem der hoster din DNS. Navneserverne på domænet fortæller det.
- Vælg roddomæne eller subdomæne. Har du en side, du vil beholde, så vælg subdomæne.
- Notér alle eksisterende poster, især MX, før du ændrer noget. Et skærmbillede er nok.
- Slet eventuelle gamle poster på præcis det navn, du vil bruge.
- Tilføj posten fra DNS-trinnet: CNAME til subdomæne, A til roddomæne, plus TXT hvis trinnet viser en. Skriv kun etiketten i feltet Name.
- Sæt en eventuel proxy på posten til DNS-only.
- Vent, til posten slår igennem offentligt. Bliv ikke ved med at redigere den.
- Bekræft hængelåsen, lav en testbooking på den nye adresse, og fortæl det så til kunderne.
Det meste af listen er ventetid. Det eneste trin, der for alvor kan skade dig, er det, den ikke indeholder: at flytte navneserverne.