Por que um domínio personalizado não começa a rotear até você provar que é dono dele

Subdomain takeover é uma daquelas classes de vulnerabilidade que parece obscura até você ver acontecer uma vez: uma equipe aponta status.example.com para um serviço de terceiros, para de usar esse serviço, esquece de remover o registro de DNS, e meses depois outra pessoa reivindica aquele mesmo slot de serviço e agora controla o que status.example.com serve — com certificado válido e tudo, para qualquer um que visitar. É uma classe de bug bem documentada justamente porque o modo de falha é tão fácil de criar por acidente e tão fácil de deixar passar até ser explorado.

Onde a proteção padrão realmente está

Todo app começa com uma URL funcionando e com certificado sem nada para configurar: https://<name>.<server-ip>.sslip.io — um truque de DNS gratuito (o sslip.io resolve com base no IP embutido no próprio hostname) que não precisa de nenhum registro de DNS seu, então não há nada para configurar errado no primeiro dia.

Adicionar um domínio personalizado real é onde o risco de takeover geralmente vive, e é onde a verificação real acontece: junto com o registro de DNS que você adiciona (um registro A para o IP do servidor, ou CNAME para um subdomínio), um segundo registro TXT é solicitado — _railyard-verify.<domain> → railyard-verify=<token>. Checado automaticamente a cada 30 segundos, ou sob demanda com Check now. O certificado e o roteamento não começam até esse registro TXT de fato ser encontrado. Alguém apontando um domínio que não controla para um app — a mecânica exata por trás de um takeover — simplesmente nunca passa de “não verificado”, porque não consegue produzir um token que nunca recebeu.

Os estados que tornam isso legível, não só aplicado

Um domínio mostra um de cinco estados, e cada um responde uma pergunta diferente com honestidade em vez de colapsar tudo num “pendente” genérico: não verificado (o registro TXT ainda não foi encontrado), pendente (propriedade confirmada, certificado ainda não emitido), no ar (de fato servindo tráfego), sem roteamento (verificado, mas o app não fez redeploy desde que foi adicionado — um redeploy é o que de fato roteia), ou mal configurado (a emissão de certificado falhou, com Check now mostrando por quê). Saber em qual desses um domínio está é a diferença entre “deve estar tudo bem” e de fato saber o que falta fazer.

Wildcards recebem a mesma verificação, em escala

Adicionar *.example.com roteia todo subdomínio para o app de uma vez em vez de adicionar cada um à mão — genuinamente útil para um produto multi-tenant que dá a cada cliente seu próprio subdomínio. A verificação de propriedade escala junto: ela sonda railyard-check.example.com em vez de cada subdomínio possível, então o wildcard não pode ser reivindicado sem controlar a zona real. Por padrão, cada subdomínio recebe seu próprio certificado na primeira vez que é visitado; adicionar uma credencial de DNS gera um único certificado cobrindo o wildcard inteiro, uma troca de complexidade de configuração contra número de certificados que vale escolher deliberadamente em vez de cair por padrão.

O par www/domínio puro, tratado junto

Marque Also add the www/bare-domain version e os dois são adicionados e verificados juntos, redirecionando para qualquer um que você marcar depois como principal — um detalhe que importa porque a metade desse par que alguém esquece geralmente é a que acaba sem monitoramento e, eventualmente, a que um takeover de fato ataca.

Referência completa: Domains and HTTPS.