Um link curto com marca é, no seu núcleo, duas peças de infraestrutura unidas: um registo DNS que diz à internet que o seu subdomínio vive aqui, e um certificado TLS que prova que a ligação HTTPS é legítima. Nenhuma delas é complicada isoladamente. A questão interessante é o que corre na borda depois de o redirecionamento ser resolvido - como uma plataforma que gere os domínios personalizados de milhares de inquilinos emite certificados on-demand, evita os limites de taxa do Let's Encrypt, mantém um orçamento de latência p95 de 15ms, e recupera graciosamente quando a equipa de DNS de um cliente elimina o seu CNAME a meio de uma campanha.
É disso que trata esta publicação.
Resumo#
- A verificação DNS é um desafio CNAME ou TXT; a emissão TLS acontece via ACME on-demand, acionada da primeira vez que um novo hostname recebe um pedido.
- O Let's Encrypt tem um limite de 50 certificados por domínio registado por semana - o que significa que precisa de um domínio registado separado por inquilino à escala, não subdomínios de um único
elido.me. - Os certificados ECDSA P-256 são materialmente mais rápidos do que RSA-2048 na camada de TLS handshake; o Elido emite P-256 para cada domínio personalizado.
- Três coisas quebram rotineiramente as configurações de domínio personalizado em produção: atraso de propagação DNS, registos CAA expirados, e clientes que eliminam o seu próprio CNAME. Cada um tem um caminho de recuperação concreto.
As duas partes de um encurtador com domínio personalizado#
Os links curtos com domínio personalizado requerem duas coisas de si, o proprietário do domínio, e duas coisas da plataforma.
Da sua parte: uma alteração de DNS (um registo CNAME ou ALIAS a apontar o seu subdomínio para a borda da plataforma) e uma prova de propriedade (normalmente um registo TXT DNS ou um desafio CNAME que permite à plataforma verificar que controla o domínio antes de concordar em servi-lo).
Da plataforma: uma regra de encaminhamento que reconhece o seu hostname e sabe de que espaço de trabalho servir links, e um certificado TLS emitido para o seu hostname para que os browsers mostrem um cadeado verde em vez de um aviso.
O Elido trata dos segundos dois através de um serviço de validação de domínios, que é responsável pela verificação DNS, emissão de certificados, e manter a tabela de encaminhamento atualizada. Aciona TLS automático sob demanda e resolve o mapeamento de espaço de trabalho. O nosso serviço de edge - aquele com o orçamento de latência inferior a 10 ms na região - não sabe nada sobre emissão de certificados; tudo isso acontece antes do caminho do pedido.
O fluxo de verificação é simples. Adiciona um CNAME do seu subdomínio para b.elido.me (nível Business), depois adiciona um registo TXT como _elido-verify.acme.example.com = "ws_abc123" para provar que é proprietário do domínio. O serviço de validação de domínios pesquisa o registo TXT, confirma-o, marca o domínio como verificado, e regista-o para TLS. O primeiro pedido HTTPS para acme.example.com aciona a emissão TLS on-demand - mais sobre isso em breve.
DNS: CNAME vs ALIAS vs A#
O tipo de registo DNS que pode usar depende de qual subdomínio está a delegar.
O CNAME funciona para qualquer subdomínio não ápice. links.example.com CNAME b.elido.me. é a configuração canónica. O RFC 1034 §3.6.2 proíbe registos CNAME no ápice da zona (o example.com simples) porque conflituam com os registos SOA e NS que devem existir lá. Quase todos os registradores e fornecedores de DNS impõem isto.
Os registos ALIAS / ANAME são uma extensão não padronizada que vários fornecedores de DNS implementam (ALIAS do Route 53, achatamento CNAME do Cloudflare, ALIAS do DNSimple) para resolver precisamente o problema do ápice. Comportam-se como CNAMEs sintaticamente mas resolvem para registos A/AAAA nos bastidores, pelo que os servidores de nomes do fornecedor de DNS achatam a pesquisa antes de a publicar. Se absolutamente precisar de example.com (não www.example.com) para redirecionar, o ALIAS é a sua única opção compatível com as especificações DNS. Verifique a documentação do seu fornecedor de DNS - não são interoperáveis, e o nome da funcionalidade varia.
O registo A a apontar diretamente para um IP do Elido é o último recurso. Os IPs podem mudar quando adicionamos um POP ou reendereçamos um cluster de borda, e não consideramos os IPs de borda uma superfície de API estável. Se está num registo A hoje, migre para um CNAME ou ALIAS.
Mais uma coisa que os operadores falham: os redirecionamentos de ápice colidem frequentemente com o DNS de e-mail. Os registos MX, _dmarc, _domainkey, e SPF TXT vivem todos no ápice ou abaixo dele. Um ALIAS no ápice não conflitua com eles - são tipos de registo diferentes - mas algumas implementações de ALIAS de fornecedores de DNS têm restrições não documentadas sobre coexistência de registos no ápice. Teste isto antes de colocar em frente a uma campanha.
TLS: ACME, limites de taxa, e o padrão de emissão on-demand#
Cada domínio personalizado obtém o seu próprio certificado. Não usamos certificados wildcard para domínios de inquilinos porque requerem um desafio DNS-01 por RFC 8555 §8.4, o que significa que precisaríamos de controlar a zona DNS do domínio de cada inquilino - e não o fazemos. Os desafios HTTP-01 são mais simples (apenas requerem acessibilidade HTTP) e cobrem certificados por hostname. Usamos HTTP-01 para cada domínio personalizado.
A autoridade de certificação é o Let's Encrypt. Os seus limites de taxa são a principal restrição operacional que precisa de entender: 50 certificados por domínio registado por semana, onde "domínio registado" é o eTLD+1 (a parte logo acima do sufixo público - example.com para links.example.com). As renovações de certificados duplicados não contam para este limite, mas cada novo domínio conta.
Isto tem uma implicação importante para plataformas multi-inquilino. Se deixar todos os seus utilizadores criar domínios personalizados sob *.suamarca.com, o seu orçamento de 50 certificados por semana é partilhado entre todos esses subdomínios de suamarca.com. Em qualquer escala significativa atinge o limite. A arquitetura correta - e a que o Elido usa para os seus próprios subdomínios de nível - é que o domínio personalizado verificado de cada inquilino seja um subdomínio do seu próprio domínio registado (links.example.com), de forma que o limite de taxa se aplique por inquilino, não por plataforma.
A emissão TLS on-demand é a forma como a borda gere o volume. Em vez de pré-emitir certificados para cada domínio verificado antes de qualquer tráfego chegar, o certificado é emitido no primeiro pedido para esse hostname. O TLS automático sob demanda pergunta a um endpoint upstream (no nosso caso, o serviço de validação de domínios) se o hostname é permitido antes de tentar a emissão. Se devolver 200 (o domínio está verificado), a borda prossegue com o desafio ACME HTTP-01, obtém o certificado, coloca-o em cache, e serve o pedido. Se o hostname for desconhecido, a borda devolve um alerta TLS e a ligação falha antes de qualquer certificado ser alguma vez solicitado.
O fluxo ACME por RFC 8555:
- A borda solicita uma nova ordem ao servidor ACME (Let's Encrypt).
- O Let's Encrypt responde com um desafio HTTP-01: "coloque um token em
http://acme.example.com/.well-known/acme-challenge/<token>." - A borda coloca o token no seu handler HTTP em memória e notifica o Let's Encrypt.
- O Let's Encrypt obtém o token via HTTP simples (porta 80), valida-o, e emite o certificado.
- A borda armazena o certificado na sua camada de armazenamento e serve o pedido HTTPS original.
Os passos 1–5 acrescentam latência ao primeiro pedido de um domínio recém-verificado, tipicamente 1–3 segundos. Cada pedido subsequente atinge um certificado em cache sem sobrecarga observável.
Desempenho: matemática do TLS handshake#
Uma vez emitido o certificado, o custo por pedido é o TLS handshake mais a lógica de redirecionamento.
Um TLS 1.3 handshake completo é 1 RTT. De um cliente europeu para o nosso POP na região da UE, isso é aproximadamente 10–20ms dependendo da cidade. A retomada de sessão TLS 1.3 (tickets ou IDs de sessão) reduz as ligações subsequentes para 0-RTT ou 0,5-RTT para dados - o cliente pode enviar dados de aplicação no primeiro voo. Para links curtos, onde o pedido HTTP é pequeno e a resposta é um 302 com um cabeçalho Location, as sessões retomadas parecem quase instantâneas da perspetiva do cliente.
O algoritmo do certificado é importante. Os certificados ECDSA P-256 têm uma assinatura de cerca de 70 bytes; os certificados RSA-2048 transportam aproximadamente 256 bytes de assinatura mais uma chave pública muito maior. Numa ligação móvel lenta, a diferença em bytes é negligenciável, mas o custo de CPU da verificação de assinatura RSA não é: verificar uma assinatura RSA-2048 demora cerca de 30–50× os ciclos de CPU de verificar uma assinatura ECDSA P-256 ao nível de segurança equivalente. Para uma borda a servir milhares de ligações simultâneas, essa diferença de CPU acumula. O Elido emite P-256 para todos os certificados de domínio personalizado. A análise da Cloudflare sobre ECDSA vs RSA em produção chega à mesma conclusão e vale a pena ler se gerir a sua própria terminação TLS.
Após o handshake, o próprio redirecionamento cai no caminho crítico: pesquisa LRU em processo (L1), passagem para o cache em memória (L2) se não encontrado, passagem para a origem via gRPC como último recurso. Num acerto de cache L1 - que representa a esmagadora maioria do tráfego uma vez que um link está quente - o redirecionamento resolve em menos de 10 ms na região (p50), de ponta a ponta na borda, excluindo o handshake. O orçamento de 15ms p95 acomoda os acertos L2 e a pequena fração de tráfego frio. Consulte o aprofundamento de smart links para a arquitetura de cache completa e a mecânica de invalidação.
O que quebra em produção#
As configurações de domínio personalizado falham de formas previsíveis. Aqui estão as três que vemos com mais frequência e o que fazer em cada caso.
Atraso de propagação DNS. Adiciona o CNAME, verifica no painel, e o link ainda não resolve para alguns utilizadores. Os valores de TTL de DNS para muitas zonas geridas por registradores têm por padrão 3600 segundos - uma hora de obsolescência potencial. O estado de domínio do painel reflete se o serviço de validação de domínios consegue ver a resposta DNS correta a partir da região da UE. Se mostrar "verificado" mas os utilizadores noutras regiões ainda obtêm o destino antigo, estão a aceder a um resolvedor que tem a resposta anterior em cache. Não há atalho; espera que o TTL drene. A correção para a próxima vez é baixar o TTL para 300–600 segundos antes de fazer a alteração, depois restaurá-lo.
Registos CAA expirados ou com incompatibilidade. Os registos Certification Authority Authorization (CAA) dizem às CAs qual delas tem permissão para emitir certificados para um domínio. Se o seu administrador DNS adicionou anteriormente example.com CAA 0 issue "digicert.com", o Let's Encrypt recusará emitir um certificado para links.example.com porque links.example.com herda a política CAA do ápice. O erro é urn:ietf:params:acme:error:caa na resposta ACME; a correção é adicionar links.example.com CAA 0 issue "letsencrypt.org" (ou remover a restrição CAA do ápice se isso for apropriado para a sua política de segurança). O endpoint de estado do serviço de validação de domínios devolve erros CAA no corpo do erro para que possa diagnosticar isto sem vasculhar os logs da borda.
O cliente elimina o CNAME a meio da campanha. Este é o doloroso. Um administrador de DNS do lado do cliente remove ou altera o CNAME - talvez como parte de uma migração de domínio, talvez acidentalmente - e cada redirecionamento desse domínio personalizado começa a falhar porque a borda já não o pode servir, ou pior, a renovação do certificado TLS falha silenciosamente durante a próxima janela de renovação de 60 dias e o certificado expira. O serviço de validação de domínios do Elido executa uma verificação periódica de saúde de DNS em todos os domínios verificados e marca um domínio como degraded quando o CNAME já não resolve para o destino esperado. O proprietário do espaço de trabalho recebe uma notificação; existe um período de carência de 7 dias antes de o domínio ser movido para suspended. Durante o período de carência, os pedidos continuam a ser servidos a partir do último certificado válido. A recuperação é: restaurar o CNAME, aguardar a propagação, e o estado do domínio volta automaticamente para ativo no próximo ciclo de verificação de saúde (corre a cada 15 minutos).
Uma breve demonstração#
Aqui está o aspeto da configuração de ponta a ponta, começando do zero.
Passo 1: Adicione os registos DNS. No painel de controlo do seu fornecedor de DNS:
acme.example.com CNAME b.elido.me.
_elido-verify.acme.example.com TXT "ws_01HXK4..."
O valor ws_01HXK4... é o seu token de verificação de espaço de trabalho, mostrado no painel em Definições → Domínios Personalizados → Adicionar Domínio.
Passo 2: Registe o domínio com a API. Também pode fazer isto no painel, mas se estiver a automatizar uma configuração multi-inquilino - por exemplo, uma agência a integrar um novo cliente - a API é mais limpa:
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"
}'
A resposta inclui um verification_token e um status de pending_verification. Pesquise GET /v1/workspaces/{id}/domains/{domain_id} ou observe o painel até que status transite para verified.
Passo 3: O primeiro pedido emite o certificado. Uma vez verificado, qualquer pedido HTTPS para acme.example.com irá acionar o TLS on-demand se o certificado não estiver já em cache. Esse primeiro pedido pode demorar 2–3 segundos enquanto a troca ACME se completa. Cada pedido subsequente é inferior a 15ms no p95.
Passo 4: Crie links sob o domínio personalizado. Passe domain_id ao criar links:
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"
}'
O link resolve imediatamente em https://acme.example.com/spring-launch. Se estiver a gerir esta configuração como infraestrutura como código, consulte a publicação do fornecedor Terraform - elido_custom_domain é uma fonte de dados que pode encadear em recursos elido_link.
Quando não usar um domínio personalizado#
Nem toda a situação beneficia de um domínio personalizado, e adicionar um tem custos de configuração em ambos os lados.
Ferramentas internas e links de staging. Se o link curto só for clicado por pessoas dentro da sua empresa - documentação interna, ponteiros de ambiente de staging, recursos partilhados no Slack - um domínio personalizado adiciona sobrecarga de gestão de DNS por zero benefício de marca. Use um espaço de trabalho em f.elido.me ou s.elido.me e siga em frente.
Links de campanha descartáveis com uma validade de 48 horas. A janela de propagação DNS por si só pode ser uma hora. Se a sua campanha se lança amanhã e ainda não tem o registo DNS no lugar, um domínio personalizado é uma responsabilidade. Use um subdomínio da plataforma, lance a campanha, e adicione o domínio personalizado ao roadmap para a próxima.
Compradores de SSO empresarial que ainda não aprovaram a delegação de subdomínio. Em empresas com posturas de segurança de TI maduras, a delegação de subdomínio para um SaaS de terceiros requer revisão de segurança - às vezes uma avaliação de risco formal. A revisão pode demorar semanas. Se o seu processo de compra já está numa longa fila de aprovação, não bloqueie o negócio na configuração do domínio personalizado. Comece com o domínio da plataforma; ofereça migrar para um domínio personalizado como parte do onboarding pós-venda. O Elido suporta migração de domínio sem quebrar links existentes, e a página de soluções para agências tem mais informações sobre a configuração de white-label que torna esta transição limpa.
Os domínios personalizados estão disponíveis nos planos Business e Enterprise. Os níveis Free e Pro usam subdomínios fornecidos pela plataforma. Se estiver a avaliar a funcionalidade, o painel permite adicionar um domínio verificado no Pro como caminho de teste - verifique a comparação de planos atual na página de preços para o limite exato.
O guia de configuração completo, incluindo recomendações de registos CAA, referência de API para todos os endpoints de domínio, e o esquema de resposta de verificação de saúde de domínio, está em /docs/guides/custom-domains. A página de funcionalidades de domínios personalizados cobre a integração Apple App Site Association e o fluxo Universal Link / App Link para deep-linking móvel num domínio personalizado.
Marius Voß é DevRel + infraestrutura de borda no Elido. É responsável pelos serviços de redirecionamento de borda e de validação de domínios.
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