Configurar um domínio personalizado com HTTPS requer dois registos DNS e cerca de três minutos à espera de propagação. O resto do tempo é geralmente gasto a perceber o que os registos significam, por que razão ambos são necessários, e o que acontece depois de os adicionar. Esta publicação é a versão prática: cinco passos concretos, a chamada de API exata, e uma explicação da maquinaria de certificados para que saiba o que fazer quando algo correr mal.
Por que razão o TLS é importante especificamente para links curtos#
Um link curto sem HTTPS é uma responsabilidade de formas que um URL normal sem HTTPS não é.
A resposta de redirecionamento - um 301 ou 302 com um cabeçalho Location - é o payload inteiro. Se o pedido HTTP inicial viaja sobre HTTP simples, qualquer pessoa no caminho de rede pode ler o URL de destino antes de o cliente o seguir. Isso significa que o destino da sua campanha, o seu URL de afiliado, ou o link da sua ferramenta interna é visível para qualquer observador de rede no primeiro salto. Os browsers modernos começaram a mostrar avisos de segurança em links curtos HTTP precisamente por causa deste padrão de exposição.
Os códigos QR agravam o problema. Uma pessoa que digitaliza um código num espaço físico não tem relação prévia com o URL - o código é o único sinal de confiança. Um aviso do browser no primeiro carregamento é o pior ponto de atrito possível: já pagou pela impressão, pelo posicionamento no evento, ou pelo espaço em publicidade exterior, e um aviso de segurança na digitalização é o que mais provavelmente afastará uma pessoa curiosa. Um certificado TLS válido sob o seu próprio domínio é o sinal de confiança mais barato que pode obter para uma campanha baseada em QR.
Em s.elido.me ou b.elido.me, o certificado TLS pertence ao Elido. O cadeado é real, mas o domínio não é seu, o que significa que a confiança de marca acresce à plataforma, não a si. Um domínio personalizado sob go.acme.com coloca o seu nome no certificado.
Mais sobre os fundamentos de DNS e TLS na publicação cornerstone: Links curtos com domínio personalizado: DNS, TLS, e o que corre na borda.
Passo 1: Escolha o hostname#
A escolha mais comum é um subdomínio curto do seu domínio principal: go.example.com, links.example.com, ou s.example.com. Mais curto é melhor - o prefixo de subdomínio aparece em cada link que envia.
Duas restrições a conhecer antes de decidir:
Apenas subdomínio, a menos que o seu fornecedor de DNS suporte registos ALIAS. O RFC 1034 §3.6.2 proíbe registos CNAME no ápice da zona (example.com). Se quiser que o ápice base redirecione, o seu fornecedor de DNS deve suportar registos ALIAS ou ANAME (ALIAS do Route 53, achatamento CNAME do Cloudflare, ALIAS do DNSimple). Estas são extensões não padronizadas que achatam a pesquisa antes de a publicar. Verifique a documentação do seu fornecedor; o nome da funcionalidade varia e nem todos os fornecedores a oferecem.
Escolha um subdomínio que não use para mais nada. links.example.com a redirecionar pelo Elido não deve também ter um registo A a apontar para o seu servidor web ou um CNAME existente. Os registos DNS para o mesmo nome devem ser consistentes.
Para a maioria das equipas: go.example.com ou links.example.com é adequado. Escolha, anote, e passe ao passo 2.
Passo 2: Registe o domínio no Elido#
Abra Definições → Domínios Personalizados → Adicionar Domínio no painel, introduza o seu hostname e clique em Adicionar. A resposta são dois valores de registo DNS: um token de verificação e o destino CNAME. Usará ambos no passo 3.
Se estiver a criar scripts - integrar um novo espaço de trabalho de cliente, executar como parte de um pipeline de implementação, ou gerir com o fornecedor Terraform - a chamada de 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
}'
O corpo da resposta inclui um verification_token (uma string hexadecimal aleatória) e instructions com os valores exatos dos registos 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"
}
}
Os domínios personalizados estão disponíveis nos planos pagos. O plano Business é o ponto de entrada para domínios personalizados; as agências que gerem vários domínios de clientes sob uma organização devem consultar o modelo de espaço de trabalho na página de soluções para agências.
Passo 3: Adicione os dois registos DNS#
Aceda ao painel de controlo do seu fornecedor de DNS e adicione ambos os registos do objeto instructions. Precisa de ambos - o CNAME encaminha o tráfego para a borda do Elido; o registo TXT prova que é o proprietário do domínio antes do Elido concordar em servi-lo.
Para um subdomínio normal:
go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
Para um domínio wildcard (plano Business, cobre *.go.example.com):
*.go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
O prefixo _elido-verify é uma convenção de desafio DNS padrão - coloca a prova de propriedade num subdomínio do hostname a ser verificado, de forma que o registo TXT não possa colidir com o CNAME.
Algumas notas específicas de fornecedores:
- Cloudflare: Adicione ambos os registos. Deixe o toggle de proxy CNAME desligado (nuvem cinzenta, apenas DNS). O proxy HTTP do Cloudflare reescreve o hostname original antes de chegar à borda do Elido, o que quebra a verificação de autorização
CaddyAsk. O modo apenas DNS passa o pedido sem modificações. - AWS Route 53: Use um registo ALIAS se precisar do ápice; para subdomínios, um CNAME simples é correto. O Route 53 não suporta CNAME no ápice da zona, mas suporta ALIAS para destinos externos.
- GoDaddy / Namecheap / maioria dos DNS de registradores: CNAME e TXT padrão - sem configuração especial.
Defina o TTL de ambos os registos para 300 segundos (5 minutos) se o seu fornecedor permitir. O TTL padrão para muitas zonas geridas é de 3600 segundos; um TTL mais curto significa confirmação de propagação mais rápida e recuperação mais rápida se precisar de alterar os registos mais tarde.
Passo 4: Aguarde a verificação#
Uma vez que os registos estejam no lugar, o domain-manager pesquisa-os automaticamente usando o resolvedor público do Google (8.8.8.8) num intervalo curto. Não precisa de clicar em "Verificar agora".
O serviço verifica duas condições antes de marcar o domínio como ativo:
_elido-verify.go.example.comdevolve um registo TXT cujo valor éverify=<token>- isto confirma que controla a zona DNS.go.example.comresolve via CNAME paraedge.elido.me- isto confirma que o tráfego chegará à borda do Elido.
Quando ambas as verificações passam, o status muda de pending_verification para verified. Pode fazer a pesquisa você mesmo:
curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
-H "Authorization: Bearer $ELIDO_API_TOKEN"
Observe o campo status. O tempo de propagação típico para registos definidos com TTL de 300s é inferior a 5 minutos. Os registos com TTL padrão de 3600s podem demorar até uma hora se estiver numa parte do mundo onde os resolvedores são agressivos no caching.
Se a verificação parar, verifique se os seus registos estão publicados corretamente:
dig TXT _elido-verify.go.example.com +short
dig CNAME go.example.com +short
A pesquisa TXT deve devolver "verify=<your-token>". A pesquisa CNAME deve devolver edge.elido.me. (o ponto final é normal).
Passo 5: O primeiro pedido emite o certificado automaticamente#
Uma vez que o domain-manager marque o domínio como verificado e o registe no Caddy, terminou a sua parte. O TLS acontece sem qualquer ação adicional.
O mecanismo é o TLS on-demand do Caddy (ADR-0012): em vez de pré-emitir certificados para cada domínio verificado, o Caddy emite o certificado no primeiro TLS handshake para um novo hostname. Antes de tentar a emissão ACME, o Caddy chama o endpoint CaddyAsk do domain-manager - um simples HTTP GET ?domain=go.example.com. Se o domain-manager devolver 200 (o domínio está no estado verificado ou ativo), o Caddy prossegue. Se devolver 404, o TLS handshake falha e nenhum certificado é alguma vez solicitado. Este portão é a última linha de defesa contra a emissão incorreta de certificados para hostnames não reconhecidos.
Quando o Caddy prossegue, o fluxo ACME (RFC 8555) executa um desafio HTTP-01:
- O Caddy solicita uma nova ordem ao Let's Encrypt.
- O Let's Encrypt responde com um token de desafio: coloque-o em
http://go.example.com/.well-known/acme-challenge/<token>. - O Caddy coloca o token no seu handler HTTP em memória.
- O Let's Encrypt obtém o token via HTTP simples e valida-o.
- O certificado é emitido, armazenado na cache de certificados do Caddy, e o pedido HTTPS original é servido.
Os passos 1–5 acrescentam aproximadamente 2–3 segundos de latência ao primeiro pedido para um domínio recém-verificado. Cada pedido subsequente usa o certificado em cache sem sobrecarga. O Caddy trata da renovação automaticamente antes da expiração.
O Elido emite certificados ECDSA P-256 para todos os domínios personalizados. As assinaturas P-256 são menores e mais rápidas de verificar do que RSA-2048, o que importa na borda onde os TLS handshakes estão no caminho crítico.
Armadilhas comuns#
Registos CAA a bloquear o Let's Encrypt. Os registos Certification Authority Authorization (CAA) especificam quais as autoridades de certificação que têm permissão para emitir certificados para um domínio. Se a sua zona DNS tiver example.com CAA 0 issue "digicert.com", o Let's Encrypt recusará emitir um certificado para go.example.com porque herda a política CAA do ápice. A correção: adicione go.example.com CAA 0 issue "letsencrypt.org", ou remova a restrição do ápice se a sua política de segurança o permitir. O endpoint de estado do domain-manager devolve erros CAA no corpo do erro.
Proxy do Cloudflare ativado. Ver passo 3 - o CNAME deve ser apenas DNS (nuvem cinzenta). O modo de nuvem laranja (com proxy) reescreve o hostname no pedido, o que faz com que a autorização CaddyAsk falhe.
Achatamento CNAME no ápice. O achatamento CNAME do Cloudflare funciona para a maioria dos casos de uso, mas tem um efeito subtil: a resposta DNS dos servidores de nomes do Cloudflare é um registo A (o IP resolvido), não um CNAME. A verificação do Elido usa LookupCNAME, que tem sucesso quando os servidores de nomes do fornecedor servem uma resposta CNAME sintetizada. Se o achatamento do seu fornecedor de DNS servir apenas o registo A final e nenhum CNAME, a verificação CNAME não passará. Na prática, o achatamento do Cloudflare inclui o CNAME na cadeia de resposta para registos não ápice; no ápice depende da implementação do fornecedor. Teste com dig CNAME go.example.com a partir de um resolvedor padrão antes de concluir que existe um bug.
TLS wildcard é HTTP-01, não DNS-01. O Elido não emite certificados wildcard (*.go.example.com) via o fluxo automatizado padrão - por RFC 8555 §8.4, os certificados wildcard requerem um desafio DNS-01, que requer acesso de escrita à zona DNS. O Elido não controla a sua zona DNS. A funcionalidade de domínio wildcard no plano Business significa que um CNAME cobre o encaminhamento para todos os subdomínios, mas cada hostname (client1.go.example.com, client2.go.example.com) obtém o seu próprio certificado emitido via HTTP-01 no primeiro pedido - não um único certificado wildcard. O resultado operacional é o mesmo: os subdomínios funcionam automaticamente. A loja de certificados cresce proporcionalmente.
Eliminar o CNAME após a verificação. Se a sua equipa de DNS remover o CNAME durante uma migração ou limpeza, a verificação periódica de saúde do domain-manager detetará o registo em falta e moverá o domínio para o estado degraded. Recebe uma notificação; existe um período de carência antes de o domínio ser suspenso. Restaure o CNAME e a verificação de saúde moverá o domínio de volta para ativo automaticamente.
Como isto difere do Bitly e do Rebrandly#
A configuração de domínio personalizado do Bitly requer que carregue um certificado TLS ou use o fluxo de certificado gerido deles, que envolve um passo manual de pedido de certificado nos níveis de plano mais antigos. O nível de automação depende do seu plano Bitly; as contas enterprise têm um caminho mais gerido.
O processo de configuração do Rebrandly é polido - o assistente de integração fornece instruções CNAME específicas do fornecedor e valida a propagação no browser. O mecanismo TLS subjacente é baseado no CloudFront: o Rebrandly usa a funcionalidade de domínio personalizado do AWS CloudFront, o que significa que a autoridade de certificação e o ciclo de vida do certificado são geridos pelo ACM da Amazon. Isso funciona bem, mas significa que o tráfego do seu domínio personalizado é encaminhado por omissão através da infraestrutura AWS US-East, o que é relevante se estiver a avaliar a residência de dados na UE (consulte Elido vs Rebrandly para a comparação completa de residência).
A abordagem do Elido - TLS on-demand do Caddy com um portão de autorização do domain-manager - mantém o ciclo de vida completo do certificado internamente, funciona de forma idêntica para implementações auto-hospedadas, e não cria uma dependência em nenhuma CDN de terceiros para gestão de certificados. O custo de latência no primeiro pedido (2–3s para o desafio ACME) é o compromisso; os pedidos subsequentes não têm sobrecarga.
Uma vez que a verificação esteja completa, crie um link sob o seu domínio personalizado passando domain_id na chamada de criação de link - ou selecione-o no seletor de domínio no painel ou na aplicação móvel. O link fica imediatamente ativo em https://go.example.com/<slug> com um certificado válido.
Leitura adicional: Links curtos com domínio personalizado: DNS, TLS, e o que corre na borda cobre a arquitetura completa incluindo mecânica de cache de borda, limites de taxa e modos de falha em produção. O guia completo de configuração de domínio incluindo recomendações CAA e a referência de API está em /docs/guides/custom-domains.
Marius Voß é DevRel + infraestrutura de borda no Elido. É responsável pelos serviços edge-redirect e domain-manager.
Relacionado no blog#
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Grátis, sem necessidade de registo · 2 por dia