Qualquer pessoa pode abrir um navegador e consultar um site público. Isso é a base da web — e vale também para os sinais que uma ferramenta de monitoramento externo observa: o certificado que o servidor apresenta, se o site responde, quais cabeçalhos ele envia, quando o domínio expira. Esses dados estão abertos para qualquer curl ou openssl. Mas há uma pergunta que nenhum GET público responde: quem controla este domínio?
É aí que entra a prova de posse. Ela não serve para esconder o que já é público; serve para afirmar, com uma ação verificável, que quem cadastrou o hostname tem autoridade sobre ele. E a forma mais comum de fazer essa prova é um registro TXT no DNS.
Por que um GET público não é suficiente
Um GET público prova que o site responde. Não prova que o domínio é seu.
Pense em um exemplo extremo: alguém poderia cadastrar google.com em uma ferramenta de monitoramento e começar a receber notificações sobre indisponibilidade, certificado SSL e headers de segurança do Google. A ferramenta faria as checagens externas normalmente — o site é público, afinal — e entregaria ao cadastrante informações sobre a infraestrutura de um terceiro.
Para os sinais públicos, isso não expõe nada novo — o mesmo dado sai de qualquer terminal. O problema aparece quando a ferramenta oferece algo que não é público, ou quando alguém precisa confiar que o cadastrante responde pelo domínio: um relatório entregue a um cliente, uma auditoria, um recurso que age sobre a infraestrutura.
Nesses casos, a solução é exigir uma ação que só quem controla o DNS do domínio pode realizar.
O que é o registro TXT e por que ele funciona
DNS (Domain Name System) é o sistema que traduz nomes de domínio em endereços IP e em outros dados operacionais. Um registro TXT é um campo de texto livre associado a um nome — pode ficar na raiz do domínio (exemplo.com) ou em um subdomínio (_cymesh.exemplo.com).
Criar ou alterar um registro TXT exige acesso ao painel de DNS do domínio ou à API do provedor de DNS. Não é algo que se faça por acaso, e não é algo que se faça sem controle do domínio. É exatamente essa barreira que transforma o TXT em prova de posse.
O fluxo típico é:
- O usuário cadastra o hostname na ferramenta de monitoramento.
- A ferramenta gera um valor aleatório (um token) e pede que o usuário crie um registro TXT com esse valor em uma posição específica — por exemplo,
_cymesh.exemplo.com. - A ferramenta consulta o DNS publicamente, lê o TXT e confirma que o valor bate.
- A posse está verificada. O monitoramento começa.
Quem não controla o DNS não consegue publicar o TXT. Sem o TXT, a ferramenta não começa a observar. Simples assim.
Por que TXT e não outro registro
Existem outros tipos de registro DNS — A, AAAA, CNAME, MX, entre outros. Cada um tem um propósito específico. O TXT é escolhido para verificação de posse por algumas razões práticas:
- Não altera o funcionamento do domínio. Um registro TXT não muda para onde o site aponta, não altera rotas de e-mail, não afeta resolução de nomes. Ele fica lá como um bilhete legível por máquinas, sem efeito colateral.
- Suporta texto livre. O valor pode ser um token longo e imprevisível, adequado para verificação criptográfica.
- É o padrão do setor. ACME (o protocolo usado pelo Let's Encrypt) usa challenge DNS-01, que é essencialmente a mesma ideia: publicar um TXT para provar controle. Quem já validou um domínio no Let's Encrypt já fez esse tipo de verificação.
Alternativas como modificar um registro A ou CNAME funcionariam como prova, mas teriam efeito colateral real no tráfego. O TXT é a opção que prova sem interferir.
O que isso significa na prática
Do ponto de vista de quem usa a ferramenta, a verificação de posse é uma etapa extra: acessar o painel de DNS, criar o registro, esperar a propagação (geralmente segundos a poucos minutos) e confirmar. Por isso faz sentido que ela não seja barreira para o que é público — e que seja exigida para o que não é.
É também o que separa "estou observando este domínio" de "este domínio é meu". A primeira afirmação qualquer um pode fazer; a segunda precisa de prova.
Do ponto de vista de quem opera a ferramenta, a prova de posse é uma decisão sobre o que cada recurso exige. Acompanhar um certificado público exige pouco; afirmar autoridade sobre a infraestrutura exige mais.
Próximo passo
Se você está avaliando ferramentas de monitoramento — ou construindo uma — vale perguntar: como essa ferramenta decide quem tem autoridade sobre um domínio? A resposta pode ser "registro TXT", "arquivo HTTP em caminho conhecido" (como o challenge HTTP-01 do ACME) ou "verificação por e-mail no WHOIS". Cada uma tem trade-offs, mas todas compartilham o mesmo princípio: provar controle antes de entregar o que não é público.
Na cymesh, o monitoramento dos sinais públicos — certificado, disponibilidade, cabeçalhos de segurança e expiração do domínio — começa assim que você cadastra o hostname. A prova por registro TXT é opcional: o fluxo é o descrito acima (publicar o token no DNS e confirmar) e dá ao hostname o selo de posse verificada, reconferido a cada 30 dias.