DNS OSINT: reconstruindo uma lista de domínios .br

Recentemente quis saber quais eram os domínios registrados pelo mesmo titular de um domínio .br. Pensei comigo: basta buscar no google whois br, jogar o domínio lá, clicar no link do nome do titular e pronto. Se fosse isso não estaria escrevendo esse post. O problema é que o registro.br não divulga isso. Descobri que o meu problema tem nome e se tem nome alguém já teve que resolver ele: reverse WHOIS. E de fato quando comecei a buscar por algum serviço na internet me deparei com um nicho OSINT bem específico. Alguns serviços dizem que tem, mas tu precisa pagar. Os gratuitos que testei não parecem indexar os registros .br.

Como estamos na era do código fácil escrito por IA eu pensei:

só fazer um script que pega os dados de um servidor internacional e já era.

“SÓ” é o erro mais comum de muitos desenvolvedores ao receber uma demanda de negócio que não conhece. Acontece que o problema de fazer scraping desses dados de qualquer serviço (ou até de vários ao mesmo tempo) é o menor dos problemas. Para isso você precisa saber a lista de domínios. E ai que eu entendi o buraco que eu estava me enfiando. O registro.br não fornece uma lista de todos os domínios registrados. Na verdade, qualquer busca em “lote” é difícil e proibida pelos próprios termos de uso. A única coisa que eles fornecem publicamente são dados estatísticos aparentemente atualizados em D-1. Ao acessar RegistroBR Stats é apresentado o gigantesco número de 5.899.670 registros .br cadastrados.

Bom, o problema já temos e é bem complexo. Da pra resolver?

Nesse artigo eu vou descrever todo o processo de refinamento para sair de um problema impossível e chegar em um plano viável. Mas antes de avançar vamos definir o básico. Eu quero um serviço que eu jogue um domínio br e tenha como retorno a lista dos domínios do mesmo titular. E quero isso gastando no máximo uns 30 pila (preferencialmente não gastando).

O problema do Reverse WHOIS

O reverse WHOIS é muito útil. Com ele dá para saber se o teu concorrente pretende lançar um novo produto, correlacionar riscos de segurança e possivelmente mais alguma dezena de coisas que eu nem faço ideia. Mas como antecipei na introdução, construir uma base dessas está longe de ser fácil. O registro.br além de não disponibilizar listas públicas aplica restrições explicitas nas consultas. Mesmo no simples whois qualquer busca retorna na sua cara isso:

Copyright © NIC.br A utilização dos dados abaixo é permitida somente conforme descrito na Política de Privacidade, sendo proibida a sua distribuição, comercialização ou reprodução, em > particular para fins publicitários ou propósitos similares. 2026-08-23 15:59:59 -03:00 - IP: meu ip bem aqui

Ou seja, não posso simplesmente varrer o registro.br e criar uma base. Se eu fizer isso com meu IP serei bloqueado. E se eu usar proxy ainda tem algum risco jurídico se eu disponibilizar isso como produto aqui no Brasil.

Mas esse nem é o problema principal. Veja, para varrer o registro.br eu preciso de uma lista. E essa lista não existe. Mais pra frente vamos explorar algumas alternativas mas nenhuma delas fornece uma lista completa de todos os registros criados. Para entender melhor é preciso entender como funciona o DNA e os registros. O DNS funciona basicamente com pull. Você digita o google.com.br e o seu computador vai perguntar para os serviços de DNS. Não existe o conceito de push, os DNS não ficam divulgando sua lista de endereços por que isso não faz sentido. Existem claro alguns processos de replica e troca entre servidores autoritativos (como os do registro.br) mas tu não pode simplesmente fazer um subscribe.

Em resumo, para criar uma base reverse WHOIS precisamos resolver o problema da lista e o problema de como consultar os dados da lista.

Como obter uma lista de domínios .br

Na introdução eu disse que o registro.br fornece dados estatísticos dos registros. Saber a quantidade de registros sem ter a lista de registros parece inútil, mas não é. Conhecendo o tamanho que essa lista deve ter delimitamos o problema. Qualquer numero acima desse valor provavelmente está errado. Qualquer numero abaixo está incompleto. Isso ainda não responde: como saber essa infeliz lista? Temos algumas ideias que descrevo abaixo:

1. Tentativa e erro

Ao tentar registrar um domínio .com.br ele precisa estar entre 2 e 26 caracteres. Além disso, tem uma restrição para caracteres que é:

Caracteres válidos são letras de “a” a “z”, números de “0” a “9”, o hífen, e os seguintes caracteres acentuados: à, á, â, ã, é, ê, í, ó, ô, õ, ú, ü, ç

Com a aplicação da formula de combinações teríamos um numero que podemos chamar de infinito. Algo tipo 1,52 × 10⁴⁴. Mesmo aplicando outras regras como não poder ter duplo hífen, ou palavras proibidas isso não reduz o suficiente. Então estamos falando de algo impossível de ser feito. Só armazenar isso custaria a casa dos zeta bytes então teria que usar alguma estratégia para controlar os índices e fazer isso de forma distribuída é um trabalho que certamente você não quer ter.

2. Listas públicas

Aqui é onde temos alguma partida real. Com algumas pesquisas encontrei o CommonCrawl . Este projeto é incrível e mantém uma lista de url indexadas que podemos usar. Claro, teremos que filtrar somente os .com.br. Ainda não abri os datasets e não sei que tipo de transformações e filtros serão necessários mas aqui já podemos conseguir boa parte dos domínios, mas não todos. O problema é que esses domínios dependem de indexação e para isso, precisam ser divulgados, não apenas registrados. E aqui temos o principal problema para completar a nossa base. Quando registramos um domínio, o registro.br vai obrigar a colocar os name servers ou atribuir os próprios. Mas isso não faz o domínio ser publicado. Não existe uma forma de receber nortificações de novos domínios. O DNS por padrão funciona por pull. Tu digita o endereço, o servidor DNS que tu usa vai em busca dos DNS que podem ter esse dado até chegar nos DNS do proprio registro.br (quando se trata de um novo domínio). Não existe o processo inverso, não para o público geral. Então, nesse universo de mihlões de domínios registrados uma boa parcela deles não vai aparecer simplesmente por que não foram usados por ninguém ainda.

3. Escutar DNS

Como já falei antes, o DNS e pull. Mas existe uma técnica que poderia nos ajudar aqui para detectar novos domínios quando eles forem divulgados: passive DNS. Seria basicamente ficar escutando pedidos de DNS e registrar eles. Aqui novamente temos serviços comerciais com valores proibitivos para um projeto pessoal. O mais promissor deles é Circl Passive DNS , mas ainda preciso entender as restrições de uso e cobertura. E a cobertura aqui é o ponto principal. Eu poderia rodar um serviço desse na minha máquina e provavelmente teria alguma coisa muito limitada por que aqui o ponto principal é a posição na rede. Quando um usuário em São Paulo digitar um endereço aleatório é possível que a request de DNS dele nunca chegue no meu nó.

Já vimos que reconstruir essa lista de domínios e principalmente manter ela atualizada é um trabalho bem complicado. Então, vamos nos contentar com o conjunto incompleto que é melhor que nada. Partindo de uma lista publica como a Common Crawl e já filtrando tudo que não é .br teremos uma lista bruta que pode ser muito útil. O proximo passo antes de um scraping maluco é pré-validar os registros minimamente. Para isso podemos usar um burro

dig algumdominio.com.br

Mais ou menos.

Agora temos o problema de escala. Executar dig 5 milhões de vezes é lento e ainda tem o risco de tu tomar um ban maroto do teu servidor DNS. Portanto aqui temos coisas básicas para fazer:

distribuir em dezenas de servidores de nomes públicos
usar uma ferramenta mais apropriada
não usar o teu IP

Por sorte eu não fui o primeiro a pensar nisso e a solução já existe: massdns . Essa ferramenta de cybersecurity é capaz de resolver até 350 mil domínios por segundo e distribuindo entre resolvers. Com isso e sendo bem conservador poderia validar toda a lista inicial. Registros que não retornam os name server são descartados e não seguem para a etapa de whois.

Criando a base

Agora vem a outra parte difícil e que provavelmente vai custar mais tempo: buscar os dados whois de cada um dos registros. Como falei lá em cima, o registro.br é bem restritivo quanto ao uso dos dados. Se eu criar uma base e transformar em um serviço usando o rdap.registro.br certamente terei problemas. Por sorte existem algumas duzias de serviços que também disponibilizam essas informações gratuitamente. Aqui volta o problema de escala. Tudo que falamos até agora se resume em dois problemas: conhecer os registros e resolver a escala.

Como fazer o scrap de milhões de registros whois sem tomar ban nos serviços? Bom, a primeira coisa que você precisa saber quando for fazer scrap de qualquer coisa em escala é não usar somente um IP. E não usar o SEU IP. Uma alternativa simples é usar serviços de proxy como o Webshare . Ele te da 10 ips grátis, mas somente 1 GB de brandwidht por mês. Em uma conta de padeiro eu cheguei em aproximadamente 10GB para whois em texto puro e cerca de 30GB se for RDAP json completo. Mas, o Webshare tem um plano baratinho de US$ 3 que te da 100 IPs proxy e 250GB de banda mês. Aqui já temos um custo benefício aceitável e diluiria o risco de perder um provider whois por abuso. Além disso o valor fica dentro dos 30 pila do projeto.

Limitações e considerações

Já discutimos os principais problemas e a solução para cada um e com isso fechamos o escopo do projeto. Nós vamos pegar e tratar uma lista pública de domínios que virá do Common Crawl. Com a lista em mãos pré validamos todos os registros e então chamamos nosso script que vai rodar o scraping gerando nossa base raw. Perceba que saímos de um ponto de partida que parecia ser impossível para uma entrega viável (limitada, mas viável). Identificamos as limitações e redefinimos o escopo. Sabemos que não temos como entregar uma lista atualizada com cada novo registro .br e também entendemos as implicações legais. Para cada problema buscamos uma alternativa.

Eu documentei aqui em poucas linhas um processo de refinamento que durou varias horas de pesquisa. Certamente deixei de fora detalhes mas o ponto principal que quero deixar registrado é:

Dado um problema que tu não entende, a primeira ideia que tu tiver para resolver provavelmente não vai funcionar.

Para resolver um problema é necessário quebrar ele em etapas e resolver o que da em cada etapa. Assim, tu já inviabiliza o projeto se em alguma etapa o resultado esperado não for o que é necessário. Por exemplo, se uma lista incompleta dos domínios não for aceita o projeto já é inviabilizado. Nesse projeto eu vou aceitar uma lista incompleta por que meu objetivo é aprender com o processo e não necessariamente criar um produto.

Próximos passos

O próximo passo será executar esse projeto iniciando é claro pela infeliz da lista e construção dos scripts de validação e de scraping.