Aangepaste domeininstelling voor webapps: duidelijke stappen voor DNS-records, SSL-uitgifte, redirects en een laag-risico omschakelplan om downtime en cookieproblemen te vermijden.
Een aangepast domein is meer dan alleen een nettere URL. Zodra je overstapt van een platformadres (bijvoorbeeld een app die je hebt gebouwd op Koder.ai onder een platform-subdomein) naar je eigen domein, behandelen browsers en netwerken het als een andere site. Dat beïnvloedt routing, beveiliging en hoe gebruikerssessies zich gedragen.
Zodra je overschakelt naar een aangepast domein, veranderen een paar dingen direct:
www of het apex-domein landen, en je hebt consistente HTTP-naar-HTTPS-regels nodig.old-platform.example werkt niet automatisch op app.yourdomain.com.Korte uitval komt meestal door timing. DNS kan al verkeer naar de nieuwe host sturen voordat het SSL-certificaat klaar is, wat tot browserwaarschuwingen leidt. Of andersom: SSL is klaar, maar veel gebruikers komen nog bij de oude locatie omdat hun DNS-cache nog niet is verlopen.
Redirects kunnen ook logins subtiel breken. Een redirect die de hostnaam verandert (apex naar www, of andersom) kan cookies laten vallen als die voor de andere host waren gezet. Auth-providers kunnen mislukken als hun callback-URL nog op het oude domein staat.
Een laag-risico omschakeling betekent dat je overlap plant: houd de oude URL werkend, zet het nieuwe domein parallel op, schakel verkeer op een voorspelbaar moment om en maak rollback zo eenvoudig als DNS terugzetten.
Voordat je iets verandert, noteer precies welke namen je wilt dat gebruikers intypen en welke namen stilletjes moeten doorverwijzen. De meeste “waarom werkt dit half?”-momenten komen doordat teams het nooit eens worden over één ware hostnaam.
Begin met de grote keuze: apex (example.com) of www (www.example.com) als primair. Beide kunnen werken, maar kies er één en behandel de andere als redirect. Dit is later ook belangrijk voor cookies: sessies zijn meestal het eenvoudigst als de app op één consistente host leeft.
Bepaal daarna welke subdomeinen je nu nodig hebt en welke kunnen wachten. Een veelgebruikt patroon is app.example.com voor de webapp en api.example.com voor API's, met later toevoegingen zoals admin.example.com of assets.example.com. Als je een aangepast domein instelt op een platform zoals Koder.ai, mappen deze keuzes direct naar wat je voor SSL moet valideren en waar je in DNS naartoe wijst.
Veel mensen kopen een domein bij een registrar, maar DNS kan ergens anders gehost worden. Bevestig waar records vandaag worden bewerkt, wie toegang heeft en of er automatisering wijzigingen doorvoert (IT, een bureau of een managed DNS-provider). Als je niet kunt inloggen en de huidige records zien, stop dan en los dat eerst op.
Controleer ook wat het domein al gebruikt. E-mail is de klassieke val: je kunt mailbezorging breken door records te verwijderen of te overschrijven.
Leg vóór je verdergaat deze beslissingen vast:
www) en de redirectrichtingAls marketing al e-mail op example.com draait, laat mail-gerelateerde records ongemoeid en voeg alleen toe wat de app nodig heeft.
Het grootste risico bij een aangepast domein is meestal niet de app zelf. Het is één verkeerde DNS-wijziging die verkeer naar nergens stuurt, e-mail breekt of SSL-validatie laat falen.
Een A record verwijst een naam naar een IP-adres. Simpel gezegd: “stuur mensen naar deze server.” Het wordt vaak gebruikt voor het apex (example.com) wanneer je provider een vast IP geeft.
Een CNAME record verwijst één naam naar een andere naam. Simpel gezegd: “behandel deze naam als alias van die hostnaam.” Het is gebruikelijk voor www.example.com die naar een platform-hostnaam wijst.
Veel DNS-providers bieden ook ALIAS/ANAME voor het apex. Dat gedraagt zich als een CNAME maar werkt voor example.com. Als je provider het ondersteunt, kan dat beheer gemakkelijker maken omdat het doel kan veranderen zonder dat jij IPs moet bijwerken.
Een eenvoudig mentaal model:
Je voegt vaak TXT-records toe voor eigendomcontroles (platformverificatie) en voor SSL-certificaatvalidatie (sommige CAs valideren via een TXT-token). TXT wordt ook gebruikt voor e-mailbeleid zoals SPF. Per ongeluk een bestaande SPF-TXT verwijderen of overschrijven kan mailbezorging kapotmaken.
TTL bepaalt hoe lang andere systemen je DNS-antwoord cachen. Een dag vóór cutover: verlaag TTL op de records die je wilt wijzigen (meestal 300 tot 600 seconden). Als alles stabiel is, verhoog je die weer om queryload te verminderen.
Exporteer of maak een screenshot van de huidige zone voordat je bewerkt. Schrijf voor elk record dat je verandert de oude waarde, nieuwe waarde en TTL op. Als er iets misgaat, is rollback het herstellen van de vorige waarden.
Dit is vooral belangrijk als je domein al MX-, DKIM- of andere TXT-records voor e-mail heeft.
SSL (het slotje) versleutelt verkeer tussen de browser en je app. Moderne browsers en veel API's verwachten standaard HTTPS. Zonder HTTPS krijg je waarschuwingen, geblokkeerde verzoeken en kunnen functies zoals service workers, geolocatie en sommige betaalstromen stoppen met werken.
Om een certificaat uit te geven moet de certificaatautoriteit valideren dat je het domein beheert. De gangbare validatiemethoden zijn HTTP-validatie en DNS-TXT-validatie:
DNS-validatie is vaak makkelijker als je een CDN gebruikt of als je app nog niet bereikbaar is op het nieuwe domein.
Waar het certificaat wordt uitgegeven hangt af van je setup. Sommige teams geven certificaten rechtstreeks uit op hun hostingstack, sommige doen dat bij de CDN, en sommige platforms die aangepaste domeinen ondersteunen regelen het voor je (bijvoorbeeld Koder.ai kan het certificaat beheren tijdens domeininstelling). Belangrijk is te weten wie de levenscyclus van het certificaat beheert, inclusief vernieuwingen.
Certificaatuitgifte is niet altijd direct. DNS-propagatie, validatiechecks en rate limits kunnen vertraging opleveren. Plan retries en vermijd het plannen van je cutover op het allerlaatste moment.
Een praktisch tijdschema:
Een certificaat moet elke hostnaam dekken die gebruikers kunnen bezoeken. Controleer de SAN-lijst (Subject Alternative Names). Als je app bereikbaar is op zowel example.com als www.example.com, moet het certificaat beide bevatten.
Wildcards (zoals *.example.com) helpen voor veel subdomeinen, maar dekken het apex-domein (example.com) niet.
Concreet voorbeeld: als je alleen een cert uitgeeft voor www.example.com, zien gebruikers die example.com intypen nog steeds waarschuwingen tenzij je op een laag redirect inzet die al een geldig certificaat voor example.com heeft.
Redirects klinken simpel, maar de meeste domeinproblemen ontstaan hier: loops, mixed content en gebruikers die uitloggen omdat ze tussen hosts heen en weer stuiteren.
Kies één canonieke host en houd je daaraan: of www.example.com of example.com (apex). De andere ingang moet naar jouw gekozen canonieke host redirecten zodat cookies, sessies en SEO-signalen consistent blijven.
Veilige defaults:
http:// naar https:// voor elk verzoekVoor HTTP naar HTTPS: vermijd regels die gebruikers heen en weer laten springen. De makkelijkste manier om loops te voorkomen is de beslissing baseren op wat het verzoek daadwerkelijk was. Als je app achter een proxy of CDN zit, configureer het zo dat het forwarded headers respecteert (bijv. een header die zegt dat het originele schema HTTP was). Anders denkt je app mogelijk dat elk verzoek HTTP is en blijft het redirecten.
Houd tijdens een verhuizing oude paths levend. Als je routes verandert (bijv. /login naar /sign-in), voeg dan expliciete redirects voor die paden toe. Verlaat je niet op een algemene redirect naar de homepage; dat breekt bladwijzers en gedeelde links.
Wacht met HSTS tot later. Als je het te vroeg inschakelt en later HTTP nodig hebt voor validatie of troubleshooting, kunnen browsers weigeren. Wacht tot HTTPS stabiel is en je subdomein-dekking hebt bevestigd.
Om redirects te testen zonder iedereen te raken, gebruik een tijdelijke test-hostname, probeer een paar echte deep links (inclusief auth-pagina's) en voer een command-line verzoek uit dat elke redirectstap en uiteindelijke bestemming laat zien.
Een veilige cutover draait grotendeels om timing. Je wilt dat je nieuwe domein klaar en getest is voordat echte gebruikers erheen gestuurd worden, en je wilt DNS-wijzigingen snel zien rondgaan zodat je niet vastzit tijdens een incident.
Verlaag je DNS-TTL (voor de records die je gaat wijzigen) ruim van tevoren. Doe het bij voorkeur een dag van tevoren en wacht vervolgens tot de oude TTL-periode voorbij is zodat caches de lagere waarde oppikken.
Voeg daarna het aangepaste domein toe bij je hosting/provider en rond de vereiste verificatie af. Als je een platform zoals Koder.ai gebruikt, voeg het domein daar eerst toe zodat het platform eigendom kan bevestigen en routing kan voorbereiden.
Vraag SSL vroeg aan. Certificaten kunnen minuten of langer duren afhankelijk van validatie, en je wilt die vertraging niet tijdens de switch.
Voer vóór publiek maken een private test uit: bezoek het nieuwe eindpunt op een manier die niet van publieke DNS afhangt (bijv. tijdelijk host-entry op je eigen machine) en bevestig dat de site via HTTPS laadt met het juiste certificaat.
Gebruik een gefaseerde aanpak zodat je snel kunt stoppen als er iets mis lijkt te gaan:
www) voordat je gebruikers wijzigt.Als je geen echte canary op DNS-niveau kunt doen, kun je nog steeds stageren door eerst één hostname te wisselen (bijv. www) en het apex ongewijzigd te laten totdat je vertrouwen hebt.
Schrijf precies op wat je terugzet (welke records, welke waarden) en wie dat doet. Rollback is meestal het terugzetten van DNS.
Zorg dat de oude setup nog geldig is (inclusief SSL op het oude domein) zodat gebruikers watervrij terug kunnen vallen terwijl je het nieuwe pad repareert.
Een domeinwijziging is niet alleen een DNS-wijziging. Voor veel apps betekent “ingelogd zijn” cookies die browsers koppelen aan een specifieke hostnaam. Als je van host verandert, kan de browser stoppen met het sturen van oude cookies en ziet je app eruit alsof iedereen is uitgelogd.
Cookie-instellingen zijn meestal de oorzaak:
app.old.com wordt niet naar app.new.com gestuurd. Een cookie voor .example.com werkt over app.example.com en www.example.com./api) ziet je web-UI hem misschien niet.Lax is vaak oké, maar sommige SSO- of betaal-redirects hebben None plus Secure nodig.Om risico te verminderen, plan een korte transitie waarbij beide domeinen werken. Houd de oude hostnaam bereikbaar en redirect zorgvuldig, maar laat sessies op het nieuwe domein verversen. Als het kan, gebruik een gedeelde sessiestore zodat een gebruiker die op welke host dan ook binnenkomt herkend kan worden.
Als je SSO of OAuth gebruikt, werk dan instellingen bij vóór cutover: callback-URL's, toegestane origins en allowlists voor redirect-URIs. Anders kan inloggen bij de identity provider slagen maar mislukken bij terugkeer naar je app.
Test eerst de flows die meestal breken: aanmelding (en e-mailverificatie), login/logout, wachtwoordreset, checkout of betaalterugkeer en multi-tab-sessies.
Voorbeeld: als je www.example.com naar example.com redirectt, zorg dat cookies zijn gezet voor .example.com (of gebruik consequent één host). Anders stuiteren gebruikers tussen hostnames en verliezen hun sessie.
De meeste domeinproblemen zijn geen “mysterie internet issues.” Het zijn kleine mismatches tussen DNS, certificaten en redirectregels die pas zichtbaar worden als echte gebruikers komen.
Een makkelijke val is het apex-domein (example.com). Veel DNS-providers laten geen echte CNAME op het apex toe. Als je toch probeert het apex op een CNAME te laten wijzen, kan het stilletjes falen, inconsistent oplossen of alleen op sommige netwerken breken. Gebruik wat je DNS-host ondersteunt (vaak een A/AAAA-record of een ALIAS/ANAME-achtig record).
Een andere veelvoorkomende downtime-oorzaak is DNS omzetten voordat SSL op het nieuwe eindpunt klaar is. Gebruikers komen, de app laadt en de browser blokkeert omdat het certificaat ontbreekt of slechts een deel van je hostnamen dekt. In de praktijk wil je meestal dat het certificaat zowel example.com als www.example.com dekt, zelfs als je van plan bent één naar de ander te redirecten.
Veelgemaakte fouten die uitval of vreemd gedrag veroorzaken:
www naar apex, dan apex terug naar www), of in de ene laag HTTP forceren en in een andere laag HTTPShttp:// assets te hardcoden, wat browserwaarschuwingen en kapotte features veroorzaaktEen snelle sanity-check: open beide hostnamen (www en apex) via HTTPS, log in, vernieuw en bevestig dat de adresbalk nooit terugschakelt naar HTTP.
Als je dit op een platform zoals Koder.ai doet, bevestig dat aangepaste domeinen verbonden zijn en dat SSL is uitgegeven voordat je productie-DNS aanraakt, en houd een rollback-optie klaar zodat een slechte redirect of recordwijziging niet blijft hangen.
Een rustige cutover draait om voorbereiding. Het doel is simpel: gebruikers moeten ingelogd blijven, cookies moeten blijven werken en je moet snel kunnen terugrollen als iets mis lijkt te gaan.
Doe dit terwijl verkeer nog naar het oude domein gaat. Geef jezelf bij voorkeur een dag zodat DNS-wijzigingen tijd hebben om te settelen.
www, api, enz.) en kies je SSL-validatiemethode (DNS of HTTP).www naar apex (of andersom) en één canonieke host.Behandel het eerste uur na DNS-flip als een incident-oefening. Kijk naar echte gebruikersstromen, niet alleen statusdashboards.
Zelfs als Koder.ai (of een ander platform) aangepaste domeinen en SSL voor je regelt, blijft deze checklist relevant. De meeste issues komen van DNS en redirects, niet van app-code.
Je app draait op een tijdelijke platform-adres zoals myapp.koder.ai. Het werkt, maar je wilt klanten example.com laten gebruiken, met www.example.com die naar het apex redirectt, en alles geforceerd naar HTTPS.
Een eenvoudig DNS-plan houdt het risico laag. Noteer eerst de huidige werkende staat (maak een snapshot als je platform dat ondersteunt, zoals Koder.ai) en verlaag DNS-TTL naar iets korts een dag van tevoren.
Voeg de nieuwe records toe terwijl je de bestaande platform-URL ongemoeid laat:
example.com: A/ALIAS-record dat naar het hostingdoel wijst dat je platform opgeeftwww.example.com: CNAME die naar example.com wijst (of naar het platformdoel, afhankelijk van de provider)myapp.koder.ai zoals het is zodat je altijd een betrouwbare fallback hebtZodra DNS staat, vraag SSL aan voor beide hostnamen (example.com en www.example.com). Schakel verkeer niet om voordat het certificaat is uitgegeven en actief; anders krijgen gebruikers browserwaarschuwingen.
Cutover-tijdlijn met duidelijke checkpoints:
example.com in een incognito-venster (homepagina, statische assets, API-calls)www -> apex)Valideer na de verhuizing het cookie-gedrag. Log in, vernieuw en controleer of je ingelogd blijft op zowel www als apex. Als sessies breken, is dat vaak een cookie-domain- of SameSite-instelling die nog op de oude host was afgestemd.
Als de cutover werkt is het werk niet af. De meeste domeinmigraties falen later omdat niemand de langzame degradatie opmerkt: een certificaat dat bijna verloopt, een gehaaste DNS-wijziging of een redirect-aanpassing die een login-flow breekt.
Stel een klein monitoringroutinesetup in die je echt volhoudt. Je hebt geen enterprise-tool nodig om te beginnen, maar wel een paar betrouwbare signalen: beschikbaarheidschecks voor sleutelpagina's (home, login en een geauthenticeerde pagina), certificaatvervalalerts (bijv. 30 dagen en nogmaals 7 dagen), fout-ritmetracking (let op 4xx/5xx-spikes, niet alleen uptime) en af en toe redirect-validatie (HTTP gaat naar HTTPS en de preferente host wint).
Houd een korte rollback-venster klaar, zelfs als alles goed lijkt. Voor 24–72 uur, houd de vorige setup beschikbaar (oude DNS-targets, oude hostingconfig, oude TLS-instellingen) zodat je snel kunt terugdraaien als er een verborgen issue opduikt, zoals een betaalcallback of een OAuth-provider die nog naar het oude domein wijst.
Als je vertrouwen hebt, verhoog dan de DNS-TTL weer. Lage TTL is nuttig tijdens veranderingen, maar verhoogt de belasting op resolvers en vergroot de impact van kleine fouten later. Kies een normale TTL die past bij hoe vaak je verwacht te wijzigen (veel teams kiezen 1–4 uur).
Documenteer ten slotte de eindtoestand terwijl alles nog vers is: welke records er bestaan (type, naam, waarde, TTL), welke hostnamen worden ondersteund en de exacte redirectregels. Vermeld waar certificaten worden uitgegeven, wat ze dekken (apex, www, subdomeinen) en wie vernieuwingen beheert.
Als je op een platform bouwt en deployt, helpt het wanneer domeinen als eersteklas feature worden behandeld en rollback eenvoudig is. Op Koder.ai staan aangepaste domeinen naast snapshots en rollback, wat toekomstige domein- en redirect-wijzigingen minder stressvol maakt wanneer iets snel ongedaan moet worden gemaakt.
Standaard: kies één canonieke hostnaam en redirect alles ernaartoe.
example.com (apex) of www.example.com de “echte” host is.Dit houdt cookies, sessies en bladwijzers consistent en voorkomt half-werkende situaties.
Verlaag de TTL de dag vóór je van plan bent te switchen en wacht vervolgens tot de oude TTL is uitgeloopt.
Verlaag alleen de TTL van de records die je daadwerkelijk gaat wijzigen.
Veelvoorkomende vuistregels:
www.example.com of app.example.com als je naar een provider-hostnaam verwijst.example.com.Schakel geen gebruikersverkeer om totdat HTTPS geldig is op de nieuwe hostnamen.
Praktische volgorde:
Zo voorkom je browserwaarschuwingen en geblokkeerde verzoeken tijdens de omschakeling.
E-mail faalt meestal door het verwijderen of overschrijven van MX en TXT records.
Voordat je iets wijzigt:
Redirect-chains en loops ontstaan vaak door tegenstrijdige regels tussen je CDN/proxy en je app.
Veilige defaults:
http:// → https://Als je achter een proxy/CDN zit, zorg dat je app forwarded scheme-headers respecteert; anders kan je app denken dat elk verzoek HTTP is en blijven redirecten.
Ja, dat gebeurt vaak als cookies gescopeerd waren naar de oude hostnaam.
Waar je op moet letten:
old-host worden niet naar gestuurdWerk identity-instellingen voor de omschakeling bij.
Dingen die exact moeten overeenkomen met het nieuwe domein:
Als deze nog naar het oude domein wijzen, kan inloggen bij de provider slagen maar falen bij terugkeer naar je app.
Rollback is meestal gewoon het herstellen van de vorige DNS-waarden.
Houd het simpel:
Als je platform snapshots/rollback ondersteunt (Koder.ai doet dat), maak er dan één voordat je cutovert zodat je ook gerelateerde configuratiewijzigingen snel ongedaan kunt maken.
Test echte gebruikerspaden, niet alleen de homepage.
Test het volgende op zowel de canonieke host als de redirectende host:
Controleer ook dat de adresbalk op eindigt en altijd op , zonder mixed-content waarschuwingen.
Probeer geen CNAME op het apex te forceren als je DNS-host dat niet ondersteunt; gebruik het type dat je DNS-provider aanbeveelt.
Een snelle veiligheidsstap is het exporteren of screenshotten van de huidige zone zodat je deze snel kunt herstellen.
new-hostEen laag-risico aanpak is de oude host bereikbaar te houden tijdens de transitie zodat gebruikers sessies op het nieuwe domein kunnen verversen.