Configurare un dominio personalizzato con HTTPS richiede due record DNS e circa tre minuti di attesa per la propagazione. Il resto del tempo viene solitamente speso per capire cosa significano i record, perché sono necessari entrambi e cosa succede dopo averli aggiunti. Questo post è la versione pratica: cinque passi concreti, l'esatta chiamata API e una spiegazione del macchinario dei certificati così sai cosa fare quando qualcosa va storto.
Perché TLS è importante specificamente per i link brevi#
Un link breve senza HTTPS è una responsabilità in modi in cui un URL regolare senza HTTPS non lo è.
La risposta di redirect - un 301 o 302 con un header Location - è l'intero payload. Se la richiesta HTTP iniziale viaggia su HTTP semplice, chiunque sul percorso di rete può leggere l'URL di destinazione prima che il client lo segua. Ciò significa che la tua destinazione di campagna, il tuo URL di affiliato o il link al tuo strumento interno è visibile a qualsiasi osservatore di rete sul primo hop. I browser moderni hanno iniziato a far emergere avvisi di sicurezza sui link brevi HTTP precisamente a causa di questo pattern di esposizione.
I codici QR aggravano il problema. Una persona che scansiona un codice in uno spazio fisico non ha alcuna relazione precedente con l'URL - il codice è l'intero segnale di fiducia. Un avviso del browser al primo caricamento è il peggior punto di attrito possibile: hai già pagato per la stampa, il posizionamento dell'evento o i media OOH, e un avviso di sicurezza alla scansione è la cosa più probabile a far allontanare una persona curiosa. Un certificato TLS valido sotto il tuo dominio è il segnale di fiducia più economico che puoi comprare per una campagna basata su QR.
Su s.elido.me o b.elido.me, il certificato TLS appartiene a Elido. Il lucchetto è reale, ma il dominio non è tuo, il che significa che la fiducia del brand si accumula sulla piattaforma, non su di te. Un dominio personalizzato sotto go.acme.com mette il tuo nome sul certificato.
Maggiori dettagli sui fondamentali DNS e TLS nel post cornerstone: Link brevi con dominio personalizzato: DNS, TLS e cosa gira all'edge.
Passo 1: Scegli l'hostname#
La scelta più comune è un breve sottodominio del tuo dominio primario: go.example.com, links.example.com o s.example.com. Più corto è meglio - il prefisso del sottodominio appare in ogni link che invii.
Due vincoli da conoscere prima di decidere:
Solo sottodominio, a meno che il tuo provider DNS non supporti record ALIAS. RFC 1034 §3.6.2 proibisce i record CNAME all'apice della zona (example.com). Se vuoi che l'apice nudo reindirizzi, il tuo provider DNS deve supportare record ALIAS o ANAME (Route 53 ALIAS, CNAME flattening di Cloudflare, ALIAS di DNSimple). Queste sono estensioni non standard che appiattiscono la lookup prima di pubblicarla. Controlla la documentazione del tuo provider; il nome della funzionalità varia e non tutti i provider la offrono.
Scegli un sottodominio che non usi per nient'altro. links.example.com che reindirizza tramite Elido non deve avere anche un record A che punta al tuo server web o un CNAME esistente. I record DNS per lo stesso nome devono essere coerenti.
Per la maggior parte dei team: go.example.com o links.example.com va bene. Sceglilo, annotalo e passa al passo 2.
Passo 2: Registra il dominio in Elido#
Apri Impostazioni → Domini personalizzati → Aggiungi dominio nella dashboard, inserisci il tuo hostname e clicca Aggiungi. La risposta è due valori di record DNS: un token di verifica e il target CNAME. Userai entrambi nel passo 3.
Se stai scriptando questo - onboardando un nuovo workspace cliente, eseguendolo come parte di una pipeline di deploy o gestendolo con il provider Terraform - la chiamata API è:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"hostname": "go.example.com",
"is_wildcard": false
}'
Il corpo della risposta include un verification_token (una stringa hex random) e instructions contenenti gli esatti valori dei record DNS:
{
"domain": {
"id": 42,
"hostname": "go.example.com",
"status": "pending_verification"
},
"instructions": {
"txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
"cname_record": "go.example.com CNAME edge.elido.me"
}
}
I domini personalizzati sono disponibili sui piani a pagamento. Il piano Business è il punto di ingresso per i domini personalizzati; le agency che gestiscono più domini cliente sotto un'organizzazione dovrebbero guardare al modello di workspace nella pagina di soluzioni per agency.
Passo 3: Aggiungi i due record DNS#
Vai al pannello di controllo del tuo provider DNS e aggiungi entrambi i record dall'oggetto instructions. Hai bisogno di entrambi - il CNAME instrada il traffico all'edge di Elido; il record TXT dimostra che possiedi il dominio prima che Elido accetti di servirlo.
Per un sottodominio regolare:
go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
Per un dominio wildcard (piano Business, copre *.go.example.com):
*.go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
Il prefisso _elido-verify è una convenzione standard di challenge DNS - mette la prova di proprietà a un sottodominio dell'hostname che si sta verificando, così il record TXT non può collidere con il CNAME.
Alcune note specifiche del provider:
- Cloudflare: Aggiungi entrambi i record. Lascia il toggle proxy CNAME off (nuvola grigia, solo DNS). Il proxy HTTP di Cloudflare strippa l'hostname originale prima che raggiunga l'edge di Elido, il che rompe il controllo di autorizzazione
CaddyAsk. La modalità solo DNS passa la richiesta non modificata. - AWS Route 53: Usa un record ALIAS se hai bisogno dell'apice; per i sottodomini un CNAME semplice è corretto. Route 53 non supporta CNAME all'apice della zona ma supporta ALIAS verso target esterni.
- GoDaddy / Namecheap / la maggior parte dei DNS registrar: CNAME e TXT standard - nessuna configurazione speciale.
Imposta il TTL di entrambi i record a 300 secondi (5 minuti) se il tuo provider lo permette. Il TTL predefinito per molte zone gestite è 3600 secondi; un TTL più breve significa conferma di propagazione più rapida e recupero più rapido se devi cambiare i record in seguito.
Passo 4: Attendi la verifica#
Una volta che i record sono al loro posto, domain-manager esegue il polling per loro automaticamente usando il resolver pubblico di Google (8.8.8.8) a breve intervallo. Non devi cliccare "Verifica ora."
Il servizio controlla due condizioni prima di marcare il dominio come attivo:
_elido-verify.go.example.comrestituisce un record TXT il cui valore èverify=<token>- questo conferma che controlli la zona DNS.go.example.comsi risolve tramite CNAME aedge.elido.me- questo conferma che il traffico raggiungerà l'edge di Elido.
Quando entrambi i controlli passano, status passa da pending_verification a verified. Puoi fare polling tu stesso:
curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
-H "Authorization: Bearer $ELIDO_API_TOKEN"
Osserva il campo status. Il tempo tipico di propagazione per record impostati con un TTL di 300s è sotto i 5 minuti. I record al TTL predefinito di 3600s possono richiedere fino a un'ora se sei in una parte del mondo dove i resolver sono aggressivi nel caching.
Se la verifica si blocca, controlla che i tuoi record siano pubblicati correttamente:
dig TXT _elido-verify.go.example.com +short
dig CNAME go.example.com +short
La lookup TXT dovrebbe restituire "verify=<your-token>". La lookup CNAME dovrebbe restituire edge.elido.me. (il punto finale è normale).
Passo 5: La prima richiesta emette il certificato automaticamente#
Una volta che domain-manager marca il dominio come verificato e lo registra con Caddy, hai finito dalla tua parte. TLS avviene senza ulteriori azioni.
Il meccanismo è il TLS on-demand di Caddy (ADR-0012): piuttosto che pre-emettere certificati per ogni dominio verificato, Caddy emette il certificato al primo handshake TLS per un nuovo hostname. Prima di tentare l'emissione ACME, Caddy chiama l'endpoint CaddyAsk di domain-manager - un semplice HTTP GET ?domain=go.example.com. Se domain-manager restituisce 200 (il dominio è nello stato verificato o attivo), Caddy procede. Se restituisce 404, l'handshake TLS fallisce e nessun certificato viene mai richiesto. Questo gate è l'ultima linea di difesa contro l'emissione errata di certificati per hostname non riconosciuti.
Quando Caddy procede effettivamente, il flusso ACME (RFC 8555) esegue una challenge HTTP-01:
- Caddy richiede un nuovo ordine da Let's Encrypt.
- Let's Encrypt risponde con un token di challenge: posizionalo a
http://go.example.com/.well-known/acme-challenge/<token>. - Caddy posiziona il token nel suo handler HTTP in-memory.
- Let's Encrypt recupera il token su HTTP semplice e lo valida.
- Il certificato viene emesso, memorizzato nella cache certificati di Caddy e la richiesta HTTPS originale viene servita.
I passi 1-5 aggiungono circa 2-3 secondi di latenza alla primissima richiesta a un dominio appena verificato. Ogni richiesta successiva usa il certificato cached senza overhead. Caddy gestisce il rinnovo automaticamente prima della scadenza.
Elido emette certificati ECDSA P-256 per tutti i domini personalizzati. Le firme P-256 sono più piccole e più veloci da verificare rispetto a RSA-2048, il che conta all'edge dove gli handshake TLS sono nel percorso caldo.
Tranelli comuni#
Record CAA che bloccano Let's Encrypt. I record Certification Authority Authorization (CAA) specificano quali autorità di certificazione sono autorizzate a emettere certificati per un dominio. Se la tua zona DNS ha example.com CAA 0 issue "digicert.com", Let's Encrypt rifiuterà di emettere un certificato per go.example.com perché eredita la policy CAA dell'apice. La soluzione: aggiungi go.example.com CAA 0 issue "letsencrypt.org", o rimuovi la restrizione apice se la tua policy di sicurezza lo consente. L'endpoint status di domain-manager restituisce errori CAA nel suo corpo di errore.
Proxy Cloudflare abilitato. Vedi il passo 3 - il CNAME deve essere solo DNS (nuvola grigia). La modalità orange-cloud (proxied) riscrive l'hostname nella richiesta, il che causa il fallimento dell'autorizzazione CaddyAsk.
CNAME flattening all'apice. Il CNAME flattening di Cloudflare funziona per la maggior parte dei casi d'uso ma ha un effetto sottile: la risposta DNS dai nameserver di Cloudflare è un record A (l'IP risolto), non un CNAME. Il controllo di verifica di Elido usa LookupCNAME, che riesce quando i nameserver del provider servono una risposta CNAME sintetizzata. Se l'appiattimento del tuo provider DNS serve solo il record A finale e nessun CNAME, il controllo CNAME non passerà. In pratica, l'appiattimento di Cloudflare include il CNAME nella catena di risposta per record non-apice; all'apice dipende dall'implementazione del provider. Testa con dig CNAME go.example.com da un resolver standard prima di concludere che c'è un bug.
Il TLS wildcard è HTTP-01, non DNS-01. Elido non emette certificati wildcard (*.go.example.com) tramite il flusso automatizzato standard - per RFC 8555 §8.4, i certificati wildcard richiedono una challenge DNS-01, che richiede accesso in scrittura alla zona DNS. Elido non controlla la tua zona DNS. La funzionalità di dominio wildcard sul piano Business significa che un CNAME copre il routing per tutti i sottodomini, ma ogni hostname (client1.go.example.com, client2.go.example.com) ottiene il proprio certificato emesso tramite HTTP-01 alla prima richiesta - non un singolo cert wildcard. Il risultato operativo è lo stesso: i sottodomini funzionano automaticamente. Il certificate store cresce proporzionalmente.
Cancellare il CNAME dopo la verifica. Se il tuo team DNS rimuove il CNAME durante una migrazione o pulizia, il controllo di salute periodico di domain-manager rileverà il record mancante e sposterà il dominio allo status degraded. Ricevi una notifica; c'è un periodo di grazia prima che il dominio sia sospeso. Ripristina il CNAME e il controllo di salute riporterà il dominio allo status attivo automaticamente.
Come questo differisce da Bitly e Rebrandly#
Il setup del dominio personalizzato di Bitly richiede di caricare un certificato TLS o usare il loro flusso di cert gestito, che coinvolge un passo manuale di richiesta certificato nei tier di piano più vecchi. Il livello di automazione dipende dal tuo piano Bitly; gli account enterprise ottengono un percorso più gestito.
Il processo di setup di Rebrandly è raffinato - la loro procedura guidata di onboarding fornisce istruzioni CNAME specifiche del provider e valida la propagazione nel browser. Il meccanismo TLS sottostante è frontato da CloudFront: Rebrandly usa la funzionalità di dominio personalizzato di AWS CloudFront, il che significa che l'autorità di certificazione e il ciclo di vita del cert sono gestiti dall'ACM di Amazon. Funziona bene, ma significa che il traffico del tuo dominio personalizzato instrada attraverso l'infrastruttura AWS US-East per impostazione predefinita, che è rilevante se stai valutando la residenza dei dati UE (vedi Elido vs Rebrandly per il confronto completo della residenza).
L'approccio di Elido - Caddy on-demand TLS con un gate di autorizzazione domain-manager - mantiene l'intero ciclo di vita del certificato in-house, funziona identicamente per deployment self-hosted e non crea una dipendenza da alcun CDN di terze parti per la gestione dei certificati. Il costo di latenza della prima richiesta (2-3s per la challenge ACME) è il trade-off; le richieste successive non portano overhead.
Una volta completata la verifica, crea un link sotto il tuo dominio personalizzato passando domain_id nella chiamata di creazione del link - o selezionalo dal picker di dominio nella dashboard o nell'app mobile. Il link è immediatamente live su https://go.example.com/<slug> con un certificato valido.
Ulteriori letture: Link brevi con dominio personalizzato: DNS, TLS e cosa gira all'edge copre l'architettura completa inclusa la meccanica della cache edge, i rate limit e le modalità di fallimento in produzione. La guida di configurazione del dominio completa inclusi i consigli CAA e il riferimento API è su /docs/guides/custom-domains.
Marius Voß è DevRel + edge infra a Elido. Possiede i servizi edge-redirect e domain-manager.
Correlati sul blog#
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Gratis, nessuna registrazione richiesta · 2 al giorno