Links curtos com domínio personalizado: DNS, TLS, e o que corre na borda

Um link curto com marca é, no seu núcleo, duas peças de infraestrutura unidas: um registro 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 equipe 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 registrado por semana - o que significa que precisa de um domínio registrado 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, registros 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. Um domínio personalizado também transforma um link curto comum em uma verdadeira URL vanity - um endereço legível e com marca, como go.acme.com/spring.

Da sua parte: uma alteração de DNS (um registro CNAME ou ALIAS a apontar o seu subdomínio para a borda da plataforma) e uma prova de propriedade (normalmente um registro 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 registro 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 registro TXT, confirma-o, marca o domínio como verificado, e registra-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 registro DNS que pode usar depende de qual subdomínio está delegando.

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 registros CNAME no ápice da zona (o example.com simples) porque conflituam com os registros SOA e NS que devem existir lá. Quase todos os registradores e fornecedores de DNS impõem isto.

Os registros 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 registros 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 registro 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 registro 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 registros 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 registro diferentes - mas algumas implementações de ALIAS de fornecedores de DNS têm restrições não documentadas sobre coexistência de registros 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 registrado por semana, onde "domínio registrado" é 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 usuários criar domínios personalizados sob *.suamarca.com, o seu orçamento de 50 certificados por semana é compartilhado 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 registrado (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:

1. A borda solicita uma nova ordem ao servidor ACME (Let's Encrypt).
2. O Let's Encrypt responde com um desafio HTTP-01: "coloque um token em http://acme.example.com/.well-known/acme-challenge/<token>."
3. A borda coloca o token no seu handler HTTP em memória e notifica o Let's Encrypt.
4. O Let's Encrypt obtém o token via HTTP simples (porta 80), valida-o, e emite o certificado.
5. 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 gerenciar 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 usuários. 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 usuários noutras regiões ainda obtêm o destino antigo, estão acedendo 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.

Registros CAA expirados ou com incompatibilidade. Os registros 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 registros 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 automatizando 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 gerenciando 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 compartilhados 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 registro 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 avaliando 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 registros 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

• Atingindo p95 < 15ms para redirecionamentos a partir de FRA, ASH e SGP
• Configure links curtos com marca: escolha um domínio, implemente numa tarde
• Deep links para aplicações móveis sem SDK
• Residência de dados na UE para ferramentas de marketing: o que o seu DPO realmente pergunta
• URLs de vaidade explicadas: links com marca que as pessoas lembram
• Como encurtar uma URL: links gratuitos, com marca e em massa