Configurazione del dominio personalizzato per app web: DNS, SSL e cutover

Cosa cambia con un dominio personalizzato (e cosa può andare storto)

Un dominio personalizzato è più di un URL più carino. Nel momento in cui passi da un indirizzo di piattaforma (per esempio, un'app che hai costruito su Koder.ai sotto un sottodominio di piattaforma) al tuo dominio, i browser e le reti lo trattano come un sito diverso. Questo influenza il routing, la sicurezza e il comportamento delle sessioni utente.

Appena passi a un dominio personalizzato, alcune cose cambiano subito:

• Routing DNS: gli utenti smettono di andare al vecchio hostname e cominciano a raggiungere la destinazione indicata dal tuo DNS.
• TLS/SSL: il certificato deve corrispondere ai nuovi hostname ed essere attivo prima che arrivino utenti reali.
• Redirect: decidi se gli utenti atterrano su www o sull'apex, e servono regole coerenti da HTTP a HTTPS.
• Cookie e sessioni: i cookie sono limitati a un dominio. Un cookie di login per old-platform.example non funzionerà automaticamente su app.yourdomain.com.
• Caching e propagazione: i resolver DNS e i browser memorizzano le risposte, quindi non tutti si aggiornano nello stesso istante.

Brevi interruzioni solitamente nascono dalla temporizzazione. Il DNS può cominciare a inviare traffico al nuovo host prima che il certificato SSL sia pronto, causando avvisi nel browser. Oppure può succedere il contrario: il certificato è pronto, ma molti utenti colpiscono ancora il vecchio host perché la loro cache DNS non è scaduta.

I redirect possono anche rompere i login in modi sottili. Un redirect che cambia hostname (da apex a www, o viceversa) può far perdere cookie se erano impostati per l'altro host. I provider di autenticazione possono fallire se la callback URL è ancora il vecchio dominio.

Un cutover a basso rischio significa pianificare una sovrapposizione: mantenere il vecchio URL funzionante, preparare il nuovo dominio in parallelo, cambiare il traffico in un momento prevedibile e rendere il rollback semplice come riportare indietro il DNS.

Decidi dominio e hostname prima di toccare il DNS

Prima di cambiare qualsiasi cosa, annota esattamente quali nomi vuoi che gli utenti digitino e quali devono semplicemente reindirizzare. La maggior parte dei momenti del tipo “perché funziona a metà?” nasce da un team che non ha concordato un unico hostname vero.

Inizia con la scelta principale: apex (example.com) o www (www.example.com) come primario. Entrambi possono funzionare, ma scegline uno e tratta l'altro come redirect. Questo conta anche per i cookie: le sessioni sono generalmente più semplici quando l'app vive su un host coerente.

Poi decidi quali sottodomini ti servono ora e quali possono aspettare. Un pattern comune è app.example.com per la web app e api.example.com per le API, con admin.example.com o assets.example.com aggiunti più tardi. Se stai configurando un dominio personalizzato su una piattaforma come Koder.ai, queste scelte mappano direttamente a ciò che dovrai convalidare per SSL e a cosa puntare nel DNS.

Sapere chi controlla davvero il DNS

Molte persone comprano un dominio dal registrar, ma il DNS può essere ospitato altrove. Conferma dove si modificano oggi i record, chi ha accesso e se ci sono automazioni che gestiscono le modifiche (IT aziendale, un'agenzia o un provider DNS gestito). Se non puoi effettuare il login e vedere i record attuali, fermati e risolvi prima quello.

Fai anche una verifica di cosa usa già il dominio. La posta elettronica è la trappola classica: puoi interrompere la consegna della posta cancellando o sovrascrivendo record.

Prima di procedere, cattura queste decisioni per iscritto:

• Hostname primario (apex o www) e direzione del redirect
• Sottodomini necessari ora (app, api, admin) vs idee future
• Dove è ospitato il DNS e chi può pubblicare modifiche
• Record critici esistenti (MX, SPF, DKIM, DMARC, TXT di verifica)
• Aspettative su cookie e auth (host singolo vs condiviso tra sottodomini)

Se il marketing già gestisce la posta su example.com, non toccare i record legati alla posta mentre aggiungi solo ciò che serve all'app.

Record DNS che userai e perché sono importanti

La maggior parte del rischio nello spostamento di un dominio personalizzato non è nell'app in sé. È una modifica DNS sbagliata che manda il traffico nel vuoto, rompe la posta o fa fallire la validazione SSL.

I record principali (A, CNAME e affini)

Un record A punta un nome a un indirizzo IP. In termini semplici: “manda le persone a questo server.” È comune per l'apex (example.com) quando il provider ti dà un IP fisso.

Un record CNAME punta un nome a un altro nome. In termini semplici: “tratta questo nome come alias di quell'hostname.” È comune per www.example.com che punta a un hostname della piattaforma.

Molti provider DNS offrono anche ALIAS/ANAME per l'apex. Si comporta come un CNAME ma funziona per example.com. Se il tuo provider lo supporta, può essere più facile da gestire perché la destinazione può cambiare senza che tu tocchi gli IP.

Un modello mentale semplice:

• A: name -> IP (diretto)
• CNAME: name -> name (alias)
• TXT: name -> testo (prove e policy)
• MX: name -> server di posta (non toccare a meno che non sia intenzionale)

TXT: verifica, SSL e sicurezza email

Spesso aggiungerai TXT per verifiche di proprietà del dominio (verifica piattaforma) e per la validazione del certificato SSL (alcune CA validano via token TXT). TXT è anche usato per policy email come SPF. Cancellare o sostituire uno SPF esistente può rompere la consegna della posta.

TTL: la tua manopola della velocità di cambiamento

Il TTL controlla per quanto tempo altri sistemi memorizzano nella cache la risposta DNS. Un giorno prima del cutover, abbassa il TTL sui record che prevedi di cambiare (comunemente 300–600 secondi). Quando tutto è stabile, rialzalo per ridurre il carico di query.

Evita di sovrascrivere record esistenti e documenta il rollback

Prima di modificare, esporta o fai screenshot della zona attuale. Annota ogni record che cambierai, il suo vecchio valore, il nuovo valore e il TTL. Se qualcosa va storto, il rollback è ripristinare i valori precedenti.

Questo è particolarmente importante quando il dominio già ha MX, DKIM o altri TXT per la posta.

Emissione SSL: validazione, tempistiche e copertura

SSL (l'icona del lucchetto) cifra il traffico tra browser e app. I browser moderni e molte API si aspettano HTTPS di default. Senza di esso puoi ottenere avvisi, richieste bloccate e funzionalità come service worker, geolocalizzazione e alcuni flussi di pagamento possono smettere di funzionare.

Per emettere un certificato, l'autorità di certificazione deve verificare che controlli il dominio. I metodi comuni di validazione sono la validazione HTTP e la validazione via TXT DNS:

• Validazione HTTP: si mette un file temporaneo o una risposta a una URL specifica sull'app.
• Validazione TXT DNS: si aggiunge un record TXT nella zona DNS.

La validazione DNS è spesso più semplice quando usi una CDN o quando la tua app non è ancora raggiungibile sul nuovo dominio.

Dove viene emesso il certificato dipende dalla tua configurazione. Alcuni team emettono certs direttamente nello stack di hosting, altri lo fanno alla CDN, e alcune piattaforme che supportano custom domain gestiscono il tutto per te (per esempio, Koder.ai può gestire il certificato durante la configurazione del dominio). Ciò che conta è sapere chi è responsabile del ciclo di vita del certificato, incluse le rinnovazioni.

Tempistiche e retry

L'emissione non è sempre istantanea. La propagazione DNS, i controlli di validazione e i limiti di rate possono rallentare. Pianifica retry e evita di fissare il cutover all'ultimo minuto.

Un piano pratico di tempistica:

• Abbassa il TTL un giorno prima così i cambi si applicano più velocemente.
• Aggiungi i record di validazione presto (TXT o token HTTP).
• Aspetta che il certificato risulti emesso per tutti gli hostname.
• Solo allora punta il traffico al nuovo target.

Copertura: assicurati che gli hostname giusti siano inclusi

Un certificato deve coprire ogni hostname che gli utenti possono raggiungere. Controlla la lista SAN (Subject Alternative Names). Se la tua app sarà disponibile sia su example.com che su www.example.com, il certificato deve includere entrambi.

I wildcard (come *.example.com) possono aiutare per molti sottodomini, ma non coprono l'apex (example.com).

Esempio concreto: se emetti un cert solo per www.example.com, gli utenti che digitano example.com vedranno comunque avvisi a meno che tu non reindirizzi a un livello che ha già un certificato valido per example.com.

Regole di redirect: www, apex, HTTP → HTTPS e default sicuri

I redirect sembrano semplici, ma la maggior parte dei problemi di dominio emerge qui: loop, contenuto misto e utenti che vengono disconnessi perché rimbalzano tra host.

Scegli un host canonico e mantienilo: www.example.com o example.com (apex). L'altro punto di accesso dovrebbe reindirizzare al host canonico scelto così cookie, sessioni e segnali SEO restano coerenti.

Default sicuri:

• Un host canonico, con un singolo redirect 301 dall'altro host
• Redirect 301 da http:// a https:// per ogni richiesta
• Conserva path e query string durante i redirect (i deep link devono funzionare)
• Reindirizza una sola volta (evita catene tipo http -> https -> www)

Per HTTP→HTTPS, evita regole che rimbalzino gli utenti avanti e indietro. Il modo più semplice per prevenire loop è basare la decisione su cosa fosse realmente la richiesta originale. Se la tua app sta dietro a un proxy o CDN, configuralo per rispettare le intestazioni forwarded (per esempio, un header che indica che lo schema originale era HTTP). Altrimenti, la tua app può pensare che ogni richiesta sia HTTP e continuare a reindirizzare all'infinito.

Durante una migrazione, mantieni i vecchi percorsi vivi. Se stai cambiando route (come /login in /sign-in), aggiungi redirect espliciti per quelle path. Non fare affidamento su un redirect blanket verso la homepage: rompe bookmark e link condivisi.

Rinvieni HSTS all'inizio. Se lo abiliti troppo presto e poi hai bisogno di servire HTTP per validazioni o troubleshooting, i browser potrebbero rifiutare. Aspetta che HTTPS sia stabile e che tu abbia confermato la copertura dei sottodomini.

Per testare i redirect senza impattare tutti, usa un hostname di test temporaneo, prova alcuni deep link reali (incluse pagine di auth) ed esegui richieste da riga di comando che mostrino ogni step di redirect e la destinazione finale.

Piano passo-passo per un cutover a basso rischio (senza downtime)

Un cutover sicuro è soprattutto questione di tempistica. Vuoi che il nuovo dominio sia pronto e testato prima che qualsiasi utente reale vi venga indirizzato, e vuoi che le modifiche DNS si propaghino in fretta così non resti bloccato durante un incidente.

1) Preparare e testare prima di toccare il DNS di produzione

Abbassa il TTL dei record che cambierai con largo anticipo. Fallo il giorno prima se puoi, poi attendi che la finestra del vecchio TTL sia trascorsa così le cache avranno il tempo di recepire il nuovo valore.

Poi aggiungi il dominio personalizzato nel tuo hosting/provider e completa le verifiche richieste. Se usi una piattaforma come Koder.ai, aggiungi il dominio lì prima così la piattaforma può confermare la proprietà e preparare il routing.

Emetti il certificato SSL in anticipo. I certificati possono richiedere minuti o più in base alla validazione, e non vuoi quel ritardo durante il cambio.

Prima di rendere pubblico il dominio, fai un test privato: colpisci il nuovo endpoint in un modo che non dipenda dal DNS pubblico (per esempio modificando temporaneamente il file hosts sulla tua macchina) e conferma che il sito carica in HTTPS con il certificato corretto.

2) Cutover in passi piccoli e reversibili

Usa un approccio a tappe così puoi fermarti rapidamente se qualcosa non va:

• Riduci il TTL in anticipo, poi attendi che il periodo del vecchio TTL sia completamente passato.
• Completa la verifica del dominio nel tuo host e conferma che internamente il dominio punti alla app corretta.
• Conferma che SSL sia attivo per ogni hostname che servirai (apex e/o www) prima di cambiare gli utenti.
• Cambia il DNS in modo controllato: comincia con un sottodominio, una piccola regione o un percorso a audience limitata se possibile.
• Mantieni il vecchio dominio online e reindirizzante mentre osservi traffico e tassi di errore stabilizzarsi.

Se non puoi fare un vero canary a livello DNS, puoi comunque stratificare cambiando prima un solo hostname (per esempio www) e lasciando l'apex intatto finché non hai fiducia.

3) Pianifica il rollback mentre sei ancora calmo

Scrivi esattamente cosa reverterai (quali record, quali valori) e chi lo farà. Il rollback di solito è ripristinare il DNS com'era.

Assicurati che la vecchia configurazione sia ancora valida (incluso SSL sul vecchio dominio) così gli utenti possono tornare puliti mentre risolvi il nuovo percorso.

Evitare cookie, sessioni e auth rotti dopo lo spostamento

Un cambio di dominio non è solo una modifica DNS. Per molte app, “essere loggati” dipende da cookie che i browser legano a un hostname specifico. Se cambi hostname, il browser potrebbe smettere di inviare i vecchi cookie e la tua app sembrerà aver disconnesso tutti.

Le impostazioni dei cookie sono spesso la causa:

• Domain decide quali hostname possono ricevere il cookie. Un cookie impostato per app.old.com non verrà inviato a app.new.com. Un cookie impostato per .example.com può funzionare su app.example.com e www.example.com.
• Path limita dove il cookie viene inviato. Se è troppo stretto (es. /api), la UI web potrebbe non vederlo.
• Secure indica che il cookie viene inviato solo su HTTPS. Dopo il passaggio a HTTPS-only, le richieste HTTP non lo includeranno.
• SameSite influenza i redirect cross-site e i flussi embedded. Lax spesso è sufficiente, ma alcuni SSO o redirect di pagamento possono richiedere None più Secure.

Per ridurre il rischio, pianifica una breve transizione in cui entrambi i domini funzionano. Mantieni il vecchio hostname che risponde e reindirizza con cura, ma consenti il refresh delle sessioni sul nuovo dominio. Se puoi, usa uno store di sessione condiviso così un utente che colpisce uno qualsiasi dei due hostname può essere riconosciuto.

Se usi SSO o OAuth, aggiorna le impostazioni prima del cutover: callback URL, allowed origins e qualsiasi allowlist per redirect URI. Altrimenti i login possono riuscire presso l'identity provider ma fallire al ritorno nell'app.

Testa per prime le flow che di solito si rompono: registrazione (e verifica email), login/logout, reset password, checkout o ritorni da pagamento, e sessioni multi-tab.

Esempio: se reindirizzi www.example.com a example.com, assicurati che i cookie siano impostati per .example.com (o usa coerentemente un solo hostname). Altrimenti gli utenti rimbalzano tra host e perdono la sessione.

Errori comuni che causano outage o comportamenti strani

La maggior parte dei problemi di dominio non sono “misteriosi problemi internet”. Sono piccole discrepanze tra DNS, certificati e regole di redirect che si manifestano solo quando gli utenti reali colpiscono il sito.

Una trappola semplice è l'apex (example.com). Molti provider DNS non consentono un vero CNAME all'apex. Se provi a puntare l'apex a un CNAME, può fallire silenziosamente, risolversi in modo incoerente o rompersi solo su alcune reti. Usa ciò che il tuo host DNS supporta (spesso un record A/AAAA, o un record ALIAS/ANAME).

Un'altra causa frequente di downtime è cambiare il DNS prima che SSL sia pronto sul nuovo endpoint. Gli utenti arrivano, l'app si carica e poi il browser lo blocca perché manca il certificato o copre solo parte degli hostname. In pratica, di solito vuoi che il certificato copra sia example.com che www.example.com, anche se prevedi di reindirizzare uno all'altro.

Errori comuni che creano outage o comportamenti strani:

• Cambiare DNS senza abbassare il TTL in anticipo, poi aspettare ore perché le vecchie risposte scadano
• Mantenere regole di redirect che creano loop (www → apex poi apex → www), o forzare HTTP in un posto e HTTPS in un altro
• Distribuire contenuti misti hardcodando http:// per asset, che provoca avvisi del browser e funzionalità rotte
• Dimenticare record DNS non-web, specialmente MX e TXT, che possono rompere email e verifiche di dominio
• Testare solo un browser e non considerare cache HSTS o peculiarità di cookie che altri utenti incontreranno

Un controllo rapido: apri entrambi gli hostname (www e apex) su HTTPS, esegui il login, ricarica e conferma che la barra dell'indirizzo non torni mai a HTTP.

Se lo fai su una piattaforma come Koder.ai, conferma che i custom domain siano collegati e che SSL sia emesso prima di toccare il DNS di produzione, e tieni pronto un piano di rollback così un redirect o un record sbagliato non rimanga appeso.

Checklist rapida prima, durante e dopo il cutover

Un cutover calmo è soprattutto lavoro di preparazione. L'obiettivo è semplice: gli utenti devono continuare a loggarsi, i cookie devono continuare a funzionare e devi poter tornare indietro rapidamente se qualcosa non va.

Prima del cutover

Fai queste operazioni mentre il traffico va ancora al vecchio dominio. Concediti un giorno se puoi, così le modifiche DNS hanno il tempo di stabilizzarsi.

• Abbassa il TTL DNS (solo per i record che cambierai) e annota i valori correnti per poterne ripristinare rapidamente.
• Documenta ogni hostname che servirai (apex, www, api, ecc.) e scegli il metodo di validazione SSL (DNS o HTTP).
• Prepara le regole di redirect e testale in staging: HTTP → HTTPS, www → apex (o viceversa) e un host canonico.
• Aggiorna le impostazioni di auth che dipendono da URL esatti: callback OAuth, allowed origins, impostazioni cookie e SSO.
• Decidi chi osserva cosa durante il cutover (log, controlli di uptime, casella support) e fissa una finestra di cambi breve.

Durante e dopo il cutover

Quando cambi il DNS, tratta la prima ora come un drill d'incidente. Guarda i flussi reali degli utenti, non solo i dashboard di stato.

• Durante: monitora picchi di 4xx/5xx, loop di redirect e fallimenti di login (specialmente “invalid redirect URI” o cadute improvvise di sessione).
• Dopo: conferma la catena del certificato in più browser e che le pagine critiche carichino in HTTPS senza contenuti misti.
• Dopo: verifica il comportamento canonico (solo un host nella barra dell'indirizzo) e che i cookie critici vengano impostati e inviati.
• Dopo: mantieni il vecchio dominio che reindirizza per un po'. Molti utenti torneranno da bookmark, email o link in cache.

Anche se Koder.ai (o un altro provider) gestisce custom domain e SSL per te, questa checklist rimane rilevante. La maggioranza dei problemi deriva da DNS e redirect, non dal codice dell'app.

Scenario di esempio: passare da un URL di piattaforma a un dominio personalizzato

La tua app gira su un indirizzo temporaneo di piattaforma come myapp.koder.ai. Funziona, ma vuoi che i clienti usino example.com, con www.example.com che reindirizza all'apex e tutto forzato su HTTPS.

Un piano DNS semplice riduce il rischio. Prima di cambiare qualsiasi cosa, annota lo stato attualmente funzionante (fai uno snapshot se la tua piattaforma lo supporta, come fa Koder.ai) e riduci il TTL DNS a qualcosa di breve con 24 ore di anticipo.

Aggiungi i nuovi record lasciando intatto l'URL della piattaforma:

• example.com: record A/ALIAS che punta al target di hosting fornito dalla piattaforma
• www.example.com: CNAME che punta a example.com (o al target della piattaforma, a seconda del provider)
• Mantieni myapp.koder.ai così avrai sempre un fallback noto funzionante

Una volta che il DNS è a posto, richiedi SSL per entrambi gli hostname (example.com e www.example.com). Non cambiare il traffico finché il certificato non è emesso e attivo, altrimenti gli utenti vedranno avvisi del browser.

Timeline di cutover con checkpoint chiari:

• T-24h: abbassa il TTL, conferma che puoi fare rollback rapidamente
• T-0: abilita il dominio nell'host dell'app, verifica che SSL sia pronto
• T+15m: testa example.com in una finestra in incognito (home, asset statici, chiamate API)
• T+30m: abilita i redirect (HTTP→HTTPS e www→apex)
• Momento rollback: se login o chiamate API falliscono, riporta il DNS al target precedente e mantieni l'URL della piattaforma attivo

Dopo lo spostamento, valida il comportamento dei cookie. Effettua il login, ricarica e controlla di restare autenticato sia su www che su apex. Se le sessioni si rompono, spesso è una configurazione di cookie o SameSite che assume ancora il vecchio host.

Passi successivi: monitora, documenta e rendi più sicuri i cambi futuri

Dopo che il cutover ha funzionato, il lavoro non è finito. La maggior parte dei fallimenti nei domain move arriva dopo, perché nessuno nota un lento degrado: un certificato vicino alla scadenza, una modifica DNS frettolosa o una variazione del redirect che rompe un flusso di login.

Stabilisci una piccola routine di monitoraggio che manterrai davvero. Non serve uno strumento enterprise per cominciare, ma ti servono alcuni segnali affidabili: controlli di disponibilità per pagine chiave (home, login e una pagina autenticata), avvisi di scadenza certificato (per esempio a 30 giorni e poi a 7 giorni), monitoraggio del tasso di errori (osserva i picchi di 4xx/5xx, non solo l'uptime) e convalide periodiche dei redirect (HTTP va a HTTPS e l'hostname preferito vince).

Tieni una breve finestra di rollback, anche se tutto sembra a posto. Per 24–72 ore, mantieni la configurazione precedente pronta (vecchi target DNS, vecchia configurazione hosting, vecchie impostazioni TLS) così puoi tornare indietro rapidamente se appare un problema nascosto, come un callback di pagamento o un provider OAuth che punta ancora al vecchio dominio.

Quando sei sicuro, rialza i valori TTL DNS. Il TTL basso è utile durante i cambi, ma aggiunge carico ai resolver e aumenta l'impatto di piccoli errori. Scegli un TTL normale che rispecchi quanto spesso prevedi cambi (molti team scelgono 1–4 ore).

Infine, documenta lo stato finale mentre è ancora fresco: quali record esistono (tipo, nome, valore, TTL), quali hostname sono supportati e le regole di redirect esatte. Includi dove sono emessi i certificati, cosa coprono (apex, www, sottodomini) e chi è responsabile dei rinnovi.

Se costruisci e distribuisci su una piattaforma, aiuta quando i domini sono trattati come feature di prima classe e il rollback è semplice. Su Koder.ai, i custom domain stanno accanto a snapshot e rollback, il che può rendere meno stressanti i cambi futuri quando qualcosa deve essere annullato rapidamente.