Un link breve brandizzato è, nella sua essenza, due componenti infrastrutturali uniti insieme: un record DNS che comunica a internet dove si trova il tuo sottodominio, e un certificato TLS che garantisce la legittimità della connessione HTTPS. Nessuno dei due è complicato preso singolarmente. La domanda interessante è cosa gira sull'edge dopo che il redirect è risolto - come una piattaforma che gestisce i domini personalizzati di migliaia di tenant emette certificati on-demand, evita i rate limit di Let's Encrypt, si mantiene sotto un budget di latenza p95 di 15ms e si riprende in modo elegante quando il team DNS di un cliente cancella il proprio CNAME a campagna in corso.
Di questo parla questo articolo.
TL;DR#
- La verifica DNS avviene tramite un challenge CNAME o TXT; l'emissione TLS avviene via ACME on-demand, attivata la prima volta che un nuovo hostname riceve una richiesta.
- Let's Encrypt impone un limite di 50 certificati per dominio registrato a settimana - il che significa che a larga scala è necessario un dominio registrato separato per ciascun tenant, non sottodomini di un singolo
elido.me. - I certificati ECDSA P-256 sono materialmente più veloci di RSA-2048 a livello di handshake TLS; Elido emette P-256 per ogni dominio personalizzato.
- Tre cause ricorrenti di guasto nei setup con dominio personalizzato in produzione: lag di propagazione DNS, record CAA scaduti e clienti che cancellano il proprio CNAME. Ognuna ha un percorso di ripristino concreto.
Le due componenti di uno shortener con dominio personalizzato#
I link brevi su dominio personalizzato richiedono due cose da te, proprietario del dominio, e due dalla piattaforma.
Da te: una modifica DNS (un record CNAME o ALIAS che punta il tuo sottodominio verso l'edge della piattaforma) e una prova di proprietà (di solito un record TXT DNS o un challenge CNAME che consente alla piattaforma di verificare che tu controlli il dominio prima di accettare di servirlo).
Dalla piattaforma: una regola di routing che riconosce il tuo hostname e sa da quale workspace servire i link, e un certificato TLS emesso per il tuo hostname affinché i browser mostrino il lucchetto verde anziché un avviso.
Elido gestisce le ultime due attraverso un servizio di validazione dei domini, responsabile della verifica DNS, dell'emissione dei certificati e dell'aggiornamento della tabella di routing. Guida il TLS automatico on-demand e risolve il mapping del workspace. Il nostro servizio edge - quello con il budget di latenza inferiore a 10 ms in regione - non sa nulla dell'emissione dei certificati; tutto avviene a monte del percorso della richiesta.
Il flusso di verifica è semplice. Aggiungi un CNAME dal tuo sottodominio a b.elido.me (tier Business), poi aggiungi un record TXT come _elido-verify.acme.example.com = "ws_abc123" per dimostrare di essere il proprietario del dominio. Il servizio di validazione dei domini interroga il record TXT, lo conferma, contrassegna il dominio come verificato e lo registra per il TLS. La prima richiesta HTTPS verso acme.example.com attiva l'emissione TLS on-demand - ne parliamo tra poco.
DNS: CNAME vs ALIAS vs A#
Il tipo di record DNS utilizzabile dipende dal sottodominio che stai delegando.
CNAME funziona per qualsiasi sottodominio non-apex. links.example.com CNAME b.elido.me. è la configurazione canonica. La RFC 1034 §3.6.2 vieta i record CNAME all'apex della zona (il nudo example.com) perché entrano in conflitto con i record SOA e NS che devono esistere lì. Quasi ogni registrar e provider DNS fa rispettare questo vincolo.
I record ALIAS / ANAME sono un'estensione non standard implementata da diversi provider DNS (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS) per risolvere esattamente il problema dell'apex. Si comportano sintatticamente come i CNAME ma si risolvono in record A/AAAA dietro le quinte, in modo che i nameserver del provider DNS appiattiscano la ricerca prima di pubblicarla. Se hai assolutamente bisogno che example.com (non www.example.com) faccia il redirect, ALIAS è la tua unica opzione compatibile con le specifiche DNS. Controlla la documentazione del tuo provider DNS - non sono interoperabili e il nome della funzionalità varia.
Un record A che punta direttamente a un IP Elido è l'ultima risorsa. Gli IP possono cambiare quando aggiungiamo un POP o riindirizziamo un cluster edge, e non consideriamo gli IP edge una superficie API stabile. Se oggi sei su un record A, passa a CNAME o ALIAS.
Un'altra cosa che gli operatori spesso trascurano: i redirect all'apex collidono spesso con il DNS email. I record MX, _dmarc, _domainkey e SPF TXT risiedono tutti all'apex o al di sotto di esso. Un ALIAS all'apex non entra in conflitto con loro - sono tipi di record diversi - ma alcune implementazioni ALIAS dei provider DNS hanno restrizioni non documentate sulla coesistenza dei record all'apex. Verificalo prima di metterlo davanti a una campagna.
TLS: ACME, rate limit e il pattern di emissione on-demand#
Ogni dominio personalizzato ottiene il proprio certificato. Non usiamo certificati wildcard per i domini dei tenant perché richiedono un challenge DNS-01 secondo la RFC 8555 §8.4, il che significa che dovremmo controllare la zona DNS del dominio di ogni tenant - e non lo facciamo. I challenge HTTP-01 sono più semplici (richiedono solo la raggiungibilità HTTP) e coprono i certificati per singolo hostname. Usiamo HTTP-01 per ogni dominio personalizzato.
La certification authority è Let's Encrypt. I loro rate limit sono il principale vincolo operativo da comprendere: 50 certificati per dominio registrato a settimana, dove "dominio registrato" è l'eTLD+1 (la parte immediatamente sopra il suffisso pubblico - example.com per links.example.com). I rinnovi di certificati duplicati non contano verso questo limite, ma ogni nuovo dominio sì.
Ciò ha un'implicazione importante per le piattaforme multi-tenant. Se lasci che tutti gli utenti creino domini personalizzati sotto *.yourbrand.com, il tuo budget di 50 certificati a settimana è condiviso tra tutti quei sottodomini di yourbrand.com. A qualsiasi scala significativa si raggiunge il cap. L'architettura corretta - e quella che Elido usa per i propri sottodomini di tier - prevede che il dominio personalizzato verificato di ciascun tenant sia un sottodominio del proprio dominio registrato (links.example.com), così il rate limit si applica per tenant, non per piattaforma.
L'emissione TLS on-demand è come l'edge gestisce il volume. Invece di pre-emettere certificati per ogni dominio verificato prima che arrivi traffico, il certificato viene emesso alla prima richiesta verso quell'hostname. Il TLS automatico on-demand interroga un endpoint upstream (nel nostro caso, il servizio di validazione dei domini) per verificare se l'hostname è autorizzato prima di tentare l'emissione. Se restituisce 200 (dominio verificato), l'edge procede con il challenge ACME HTTP-01, ottiene il certificato, lo mette in cache e serve la richiesta. Se l'hostname è sconosciuto, l'edge restituisce un TLS alert e la connessione fallisce prima che venga mai richiesto un certificato.
Il flusso ACME secondo la RFC 8555:
- L'edge richiede un nuovo ordine al server ACME (Let's Encrypt).
- Let's Encrypt risponde con un challenge HTTP-01: "colloca un token all'indirizzo
http://acme.example.com/.well-known/acme-challenge/<token>." - L'edge inserisce il token nel suo gestore HTTP in-memory e notifica Let's Encrypt.
- Let's Encrypt recupera il token via HTTP semplice (porta 80), lo valida e emette il certificato.
- L'edge archivia il certificato nel suo storage layer e serve la richiesta HTTPS originale.
I passaggi 1–5 aggiungono latenza alla prima richiesta da un dominio appena verificato, tipicamente 1–3 secondi. Ogni richiesta successiva usa un certificato in cache senza overhead osservabile.
Performance: la matematica dell'handshake TLS#
Una volta emesso il certificato, il costo per richiesta è l'handshake TLS più la logica di redirect.
Un handshake TLS 1.3 completo è 1 RTT. Da un client europeo al nostro POP UE in regione, sono circa 10–20ms a seconda della città. La session resumption TLS 1.3 (ticket o session ID) porta le connessioni successive a 0-RTT o 0,5-RTT per i dati - il client può inviare dati applicativi al primo flight. Per i link brevi, dove la richiesta HTTP è minuscola e la risposta è un 302 con un header Location, le sessioni ripristinate sembrano quasi istantanee dal punto di vista del client.
L'algoritmo del certificato è rilevante. I certificati ECDSA P-256 hanno una firma di circa 70 byte; i certificati RSA-2048 portano circa 256 byte di firma più una chiave pubblica molto più grande. Su una connessione mobile lenta la differenza in byte è trascurabile, ma il costo CPU della verifica della firma RSA non lo è: verificare una firma RSA-2048 richiede circa 30–50× i cicli CPU necessari per verificare una firma ECDSA P-256 a parità di livello di sicurezza. Per un edge che serve migliaia di connessioni concorrenti, questa differenza di CPU si accumula. Elido emette P-256 per tutti i certificati dei domini personalizzati. L'analisi di Cloudflare su ECDSA vs RSA in produzione giunge alla stessa conclusione ed è utile da leggere se gestisci la tua terminazione TLS.
Dopo l'handshake, il redirect stesso attertra nel percorso caldo: lookup LRU in-process (L1), fallthrough alla cache in memoria (L2) se non trovato, fallthrough all'origine su gRPC come ultima risorsa. Su un cache hit L1 - che rappresenta la stragrande maggioranza del traffico una volta che un link è caldo - il redirect si risolve in meno di 10 ms in regione (p50), end-to-end sull'edge, escluso l'handshake. Il budget p95 di 15ms accomoda gli hit L2 e la piccola frazione di traffico freddo. Vedi il deep-dive sugli smart link per l'architettura completa della cache e la meccanica di invalidazione.
Cosa si rompe in produzione#
I setup con dominio personalizzato falliscono in modi prevedibili. Ecco i tre che vediamo più spesso e come rimediare.
Lag di propagazione DNS. Aggiungi il CNAME, verifichi nella dashboard, ma il link non si risolve ancora per alcuni utenti. I valori TTL DNS per molte zone gestite dai registrar hanno come default 3600 secondi - un'ora di potenziale obsolescenza. Lo stato del dominio nella dashboard riflette se il servizio di validazione dei domini riesce a vedere la risposta DNS corretta dalla regione UE. Se mostra "verificato" ma gli utenti altrove ricevono ancora la vecchia destinazione, stanno usando un resolver che ha in cache la risposta precedente. Non esiste scorciatoia; bisogna aspettare che il TTL si scarichi. La soluzione per la volta successiva è abbassare il TTL a 300–600 secondi prima di effettuare la modifica, poi ripristinarlo dopo.
Record CAA scaduti o non corrispondenti. I record CAA (Certification Authority Authorization) indicano alle CA quali sono autorizzate a emettere certificati per un dominio. Se il tuo admin DNS ha precedentemente aggiunto example.com CAA 0 issue "digicert.com", Let's Encrypt rifiuterà di emettere un certificato per links.example.com perché links.example.com eredita la policy CAA dell'apex. L'errore è urn:ietf:params:acme:error:caa nella risposta ACME; la soluzione è aggiungere links.example.com CAA 0 issue "letsencrypt.org" (o rimuovere la restrizione CAA all'apex se è appropriato per la tua politica di sicurezza). L'endpoint di stato del servizio di validazione dei domini restituisce gli errori CAA nel corpo dell'errore così puoi diagnosticare senza dover scavare nei log dell'edge.
Il cliente cancella il CNAME a campagna in corso. Questo è quello doloroso. Un admin DNS dal lato del cliente rimuove o modifica il CNAME - forse durante una migrazione del dominio, forse accidentalmente - e ogni redirect da quel dominio personalizzato inizia a fallire perché l'edge non riesce più a servirlo, oppure, ancora peggio, il rinnovo del certificato TLS fallisce silenziosamente nell'arco del prossimo ciclo di rinnovo di 60 giorni e il certificato scade. Il servizio di validazione dei domini di Elido esegue un health check DNS periodico su tutti i domini verificati e contrassegna un dominio come degraded quando il CNAME non si risolve più verso il target atteso. Il proprietario del workspace riceve una notifica; c'è un periodo di tolleranza di 7 giorni prima che il dominio passi a suspended. Durante il periodo di tolleranza, le richieste continuano a essere servite dall'ultimo certificato valido. Il ripristino consiste nel: ripristinare il CNAME, attendere la propagazione, e lo stato del dominio torna automaticamente ad attivo al prossimo ciclo di health check (eseguito ogni 15 minuti).
Una breve panoramica pratica#
Ecco come appare il setup end-to-end, partendo da zero.
Passo 1: aggiungi i record DNS. Nel pannello di controllo del tuo provider DNS:
acme.example.com CNAME b.elido.me.
_elido-verify.acme.example.com TXT "ws_01HXK4..."
Il valore ws_01HXK4... è il token di verifica del tuo workspace, mostrato nella dashboard in Impostazioni → Domini personalizzati → Aggiungi dominio.
Passo 2: registra il dominio tramite l'API. Puoi farlo anche nella dashboard, ma se stai automatizzando un setup multi-tenant - per esempio, un'agenzia che sta onboardando un nuovo cliente - l'API è più pulita:
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": "acme.example.com",
"tier": "business"
}'
La risposta include un verification_token e un status pari a pending_verification. Esegui il polling di GET /v1/workspaces/{id}/domains/{domain_id} oppure controlla la dashboard fino a quando status passa a verified.
Passo 3: la prima richiesta emette il certificato. Una volta verificato, qualsiasi richiesta HTTPS verso acme.example.com attiverà il TLS on-demand se il certificato non è già in cache. La prima richiesta potrebbe richiedere 2–3 secondi mentre si completa lo scambio ACME. Ogni richiesta successiva sarà sub-15ms a p95.
Passo 4: crea link sotto il dominio personalizzato. Passa domain_id quando crei i link:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/links \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"domain_id": 17,
"slug": "spring-launch",
"destination_url": "https://example.com/landing/spring"
}'
Il link si risolve immediatamente su https://acme.example.com/spring-launch. Se stai gestendo questo setup come infrastructure-as-code, consulta il post sul Terraform provider - elido_custom_domain è una data source che puoi concatenare alle risorse elido_link.
Quando non usare un dominio personalizzato#
Non tutte le situazioni traggono vantaggio da un dominio personalizzato, e aggiungerne uno ha un costo di configurazione da entrambe le parti.
Tooling interno e link di staging. Se il link breve verrà cliccato solo da persone all'interno della tua azienda - documenti interni, puntatori all'ambiente di staging, risorse condivise su Slack - un dominio personalizzato aggiunge overhead di gestione DNS senza alcun beneficio per il brand. Usa un workspace su f.elido.me o s.elido.me e vai avanti.
Link di campagna usa-e-getta con vita di 48 ore. La sola finestra di propagazione DNS è potenzialmente di un'ora. Se la tua campagna viene lanciata domani e non hai ancora il record DNS in posizione, un dominio personalizzato è un rischio. Usa un sottodominio della piattaforma, lancia la campagna, e aggiungi il dominio personalizzato alla roadmap per la prossima.
Acquirenti enterprise SSO che non hanno ancora approvato la delega del sottodominio. In aziende con posture di sicurezza IT mature, la delega di un sottodominio a un SaaS di terze parti richiede una revisione di sicurezza - a volte una valutazione formale del rischio. La revisione può richiedere settimane. Se il tuo processo di acquisto è già in una lunga coda di approvazione, non bloccare il deal sul setup del dominio personalizzato. Inizia con il dominio della piattaforma; offri la migrazione a un dominio personalizzato come parte dell'onboarding post-vendita. Elido supporta la migrazione del dominio senza rompere i link esistenti, e la pagina delle soluzioni per le agenzie offre maggiori informazioni sulla configurazione white-label che rende questa transizione agevole.
I domini personalizzati sono disponibili nei piani Business ed Enterprise. I tier Free e Pro utilizzano sottodomini forniti dalla piattaforma. Se stai valutando la funzionalità, la dashboard ti consente di aggiungere un dominio verificato sul piano Pro come percorso di prova - consulta il confronto attuale dei piani sulla pagina dei prezzi per il limite esatto.
La guida di configurazione completa, incluse le raccomandazioni per i record CAA, il riferimento API per tutti gli endpoint dei domini e lo schema della risposta del health check del dominio, si trova su /docs/guides/custom-domains. La pagina della funzionalità dei domini personalizzati copre l'integrazione con Apple App Site Association e il flusso Universal Link / App Link per il deep-linking mobile su un dominio personalizzato.
Marius Voß è DevRel + edge infra di Elido. Si occupa del servizio di redirect edge e del servizio di validazione dei domini.
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