WHOIS vs RDAP: como funcionam os dados de domínio da ICANN (Guia 2026)

Todo domínio deixa um rastro de registro e, por quarenta anos, a forma de ler esse rastro foi o WHOIS. O protocolo sucessor da ICANN, o RDAP, responde às mesmas perguntas por uma interface REST moderna, com JSON estruturado. Ambos foram feitos para consultar um domínio por vez — exatamente o formato errado para pesquisa, dimensionamento de mercado ou análise de infraestrutura em milhões de nomes. Este guia explica em que os dois protocolos realmente diferem, onde cada um deixa de ser útil e o que os arquivos de domínios em massa entregam que um protocolo de consulta jamais entregará.

TL;DR / Pontos-chave

• WHOIS é um protocolo de texto puro na porta 43: sem schema, sem nomes de campo padronizados, sem formatos de data padronizados. Cada registry e cada registrar formata a saída de um jeito ligeiramente diferente, então fazer parsing em escala significa manter um parser por fonte.
• RDAP é o sucessor determinado pela ICANN: RESTful, apenas HTTPS, respostas em JSON, códigos de erro padronizados, suporte a internacionalização e encaminhamento de consultas entre servidores. Ele resolve o problema de parsing, não o de acesso.
• Nenhum dos dois é fonte de dados em massa: ambos têm limite de requisições por design. Consultar milhões de domínios via WHOIS ou RDAP resulta em throttling e bloqueio, e nenhum registry oferece isso como caso de uso suportado.
• A censura do GDPR vale para os dois: desde 2018, nome, e-mail e endereço postal do titular aparecem censurados ou substituídos por serviços de proxy nas respostas públicas da maioria dos domínios. WHOIS/RDAP público não é uma base de contatos.
• Nenhum dos protocolos diz nada sobre o que o site roda: CMS, servidor web, CDN, provedor de e-mail e IP estão todos fora do registro de domínio. Essa informação vem da resolução DNS e do fingerprinting HTTP, não do registry.
• A WebTrackly vende justamente a camada em massa: O formato do download varia conforme o pacote e é informado na página do produto.
• A análise é sua: os arquivos são insumos para as suas próprias ferramentas. Não há construtor de consultas no navegador, não há consulta por domínio e não há dados de contato.

Índice

1. Entendendo o WHOIS: o protocolo legado
2. Conhecendo o RDAP: o padrão moderno
3. WHOIS vs RDAP: lado a lado
4. Onde os dois protocolos param
5. O que os arquivos de domínios em massa contêm
6. Comprando e processando um pacote
7. Automatizando com a API do catálogo
8. Erros comuns na aquisição de dados de domínios & como evitá-los
9. Perguntas frequentes (FAQ)
10. Recursos relacionados

Entendendo o WHOIS: o protocolo legado

WHOIS é um protocolo de consulta e resposta usado para interrogar bases que armazenam os responsáveis registrados por um recurso da internet — um nome de domínio, um bloco de endereços IP ou um número de sistema autônomo. Surgiu nos primeiros anos da internet e foi padronizado pela IETF no início dos anos 1980. Seu propósito era servir de diretório: permitir que qualquer pessoa descobrisse quem responde por um recurso, principalmente para resolver problemas de rede e tratar abusos.

A estrutura é deliberadamente simples. Um registro WHOIS é um bloco de texto puro devolvido pela porta TCP 43. O cliente conecta ao servidor WHOIS operado pelo registrar ou pelo registry do domínio, envia o nome de domínio e recebe um bloco de texto de volta.

Um registro WHOIS típico inclui:

• Dados do titular: nome, organização, endereço, e-mail e telefone de quem detém o domínio — hoje censurados na maioria dos domínios.
• Contato administrativo: a parte responsável por questões administrativas.
• Contato técnico: a parte responsável por questões técnicas.
• Dados do registrar: a empresa por meio da qual o domínio foi registrado.
• Datas de registro: data de criação, data da última atualização, data de expiração.
• Servidores de nomes: os servidores DNS autoritativos do domínio.
• Status do domínio: códigos de status EPP como clientTransferProhibited ou pendingDelete.

O valor do WHOIS, na sua intenção original, era transparência e responsabilização. Se um site estivesse envolvido em atividade maliciosa, ou se houvesse uma falha técnica, o WHOIS abria caminho até o responsável. Para pesquisa competitiva, ele oferecia fatos básicos: data de registro, registrar e servidores de nomes.

As desvantagens pesam mais hoje. A maior delas é a ausência de schema. Cada registrar e cada registry formata a saída de um jeito, com rótulos de campo, formatos de data e ordenação de seções variando. O parsing automatizado exige, portanto, expressões regulares e lógica sob medida para cada fonte; um parser escrito para a saída de um registrar frequentemente falha na de outro.

O limite de requisições é a segunda restrição. Servidores WHOIS são dimensionados para consultas individuais, não para extração em massa. Consultar milhares ou milhões de domínios leva a throttling, bloqueio de IP ou telas de CAPTCHA. Além disso, os próprios dados envelhecem: titulares mudam de endereço, alteram informações e deixam os detalhes desatualizarem, e os registrars não cobram atualizações com rigor.

A mudança decisiva para quem esperava usar o WHOIS como fonte de contatos veio com o GDPR, em 2018. Para se adequar, a ICANN passou a exigir que os registrars censurassem dados pessoais na saída pública do WHOIS dos titulares afetados. Na maioria dos domínios, hoje, nome, e-mail e telefone do titular aparecem como "REDACTED FOR PRIVACY" ou como um endereço de encaminhamento de um serviço de privacidade. O WHOIS público deve ser tratado como fonte de fatos técnicos e de registro, não de dados pessoais.

Conhecendo o RDAP: o padrão moderno

Reconhecendo a inconsistência da saída do WHOIS e a necessidade crescente de controles de acesso, a ICANN conduziu o desenvolvimento do RDAP, o Registration Data Access Protocol. O RDAP foi projetado como substituto padronizado, seguro e extensível. A ICANN o adotou em 2017 e, desde então, registries e registrars vêm implementando-o gradualmente.

A diferença arquitetural é o ponto central. Em vez de texto puro na porta 43, o RDAP é um serviço web RESTful que devolve dados estruturados, normalmente em JSON. Isso elimina o problema de parsing: com um schema definido, um sistema automatizado extrai um campo pelo nome, em vez de reconhecer padrões dentro de um bloco de texto.

Principais vantagens do RDAP sobre o WHOIS:

• Formato de dados padronizado: a saída em JSON é legível por máquina e se integra diretamente aos seus pipelines.
• Recursos de segurança: o RDAP roda sobre HTTPS e suporta autenticação e autorização, de modo que solicitantes credenciados podem, em princípio, receber respostas mais completas do que os anônimos.
• Internacionalização: suporte adequado a nomes de domínio internacionalizados e a dados de contato multilíngues.
• Tratamento de erros: códigos de status HTTP e objetos de erro padronizados, para que o cliente distinga "não encontrado" de "limite de requisições atingido" e de "erro de servidor".
• Encaminhamentos: uma resposta RDAP pode apontar o cliente para o servidor autoritativo do objeto, o que torna viáveis as consultas entre registries.

O empenho da ICANN com o RDAP mira uma forma uniforme e auditável de acessar dados de registro. Para quem consulta registros de domínio de forma programática, o RDAP é um ganho claro de confiabilidade em relação ao antecessor.

O RDAP não muda o que está no registro. Ele opera sob os mesmos mandatos de privacidade do WHOIS: dados pessoais seguem censurados nas respostas públicas. Você consulta de forma mais limpa, mas os campos de contato continuam sendo proxies ou marcadores. A cobertura também é desigual — nem todo registry ou registrar concluiu a implantação do RDAP, então alguns domínios ainda só são alcançáveis por WHOIS. E a carga útil continua sendo dado de registro: nada sobre a tecnologia em operação, a hospedagem ou o conteúdo do site.

WHOIS vs RDAP: lado a lado

Onde os dois protocolos param

Quaisquer que sejam as diferenças, WHOIS e RDAP respondem a uma única pergunta: o que o registry registra sobre este nome? Várias categorias de pergunta ficam totalmente fora desse escopo.

1. Nenhuma detecção de tecnologia. O registro de domínio diz quem registrou o domínio, não que software o site roda. CMS, plataforma de e-commerce, servidor web e bibliotecas JavaScript são descobertos acessando o site, não consultando o registry.
2. Nenhum dado de contato utilizável. O GDPR e regimes equivalentes retiraram os dados do titular das respostas públicas. Existe acesso credenciado para autoridades e detentores de direitos; não é um canal de uso geral.
3. Nenhuma visão de infraestrutura. Além dos servidores de nomes, os protocolos nada dizem sobre o IP resolvido, a rede de hospedagem, a CDN à frente da origem ou o provedor de e-mail por trás dos registros MX.
4. Nenhuma agregação. Mesmo com o JSON limpo do RDAP, cobrir milhões de nomes significa orquestrar consultas em centenas de servidores, cada um com seus próprios limites e sua própria disponibilidade. Isso é um projeto de infraestrutura, não uma consulta.
5. Nenhuma garantia de atualidade em escala. Os protocolos não têm mecanismo para dizer o que mudou desde a sua última passagem. Detectar mudança significa reconsultar tudo.
6. Nenhuma visão populacional. Você não pode perguntar ao WHOIS ou ao RDAP "quantos domínios .de existem" ou "quais domínios resolvem para esta rede". Eles respondem apenas perguntas por nome.

São exatamente essas as perguntas que os arquivos de domínios em massa respondem, porque um arquivo é uma população, não uma consulta.

Trabalhando com dados de domínios em escala?
O formato do download varia conforme o pacote e é informado na página do produto.
Ver o catálogo → | Ver preços →

O que os arquivos de domínios em massa contêm

O catálogo da WebTrackly está organizado em três grupos:

• Arquivos de zona por TLD — 716 pacotes cobrindo .com, .net, .de, .org e centenas de outros. Só o pacote .com contém 163.422.083 domínios. Veja Arquivos de zona por TLD.
• Listas de tecnologia e CMS — 79 pacotes de domínios agrupados pela plataforma detectada neles. O pacote WordPress contém 21.639.326 domínios. Veja Dados de domínios.
• Datasets curados — 27 pacotes, incluindo o dataset de todos os domínios registrados, com 272.614.863 linhas. Veja Datasets.

O formato do download varia conforme o pacote e é informado na página do produto. O arquivo é gerado no momento da compra, então reflete o estado da fonte naquela data, e não um snapshot em cache de um rastreamento anterior. Os preços começam em $3.50 por pacote; veja Preços para os planos de assinatura.

Campos que você pode esperar

As colunas variam conforme o tipo de pacote — um arquivo de zona é enxuto, enquanto uma lista de tecnologia traz os campos de detecção e de resolução. A tabela abaixo mostra o formato dos dados, e não a promessa de que toda coluna apareça em todo pacote.

O que não está nos arquivos: nomes de pessoas, endereços de e-mail, números de telefone, dados firmográficos de empresas ou sinais comportamentais de intenção. A WebTrackly vende dados de domínios. Tudo que diz respeito às pessoas por trás de um domínio está fora do escopo, tanto por decisão de produto quanto por conformidade.

Comprando e processando um pacote

O fluxo é deliberadamente curto — não há construtor de consultas para aprender, porque a análise acontece na sua máquina, com as suas ferramentas.

1. Encontre o pacote. Navegue pelo catálogo ou vá direto a /zones/ para arquivos de zona de TLD, /domaindata/ para listas de tecnologia ou /datasets/ para datasets curados. Cada item exibe a contagem de linhas, então você conhece o tamanho antes de comprar.
2. Compre. Compras avulsas começam em $3.50. As assinaturas (Pro por $29/mês, Enterprise por $99/mês) incluem uma cota mensal de pacotes e datasets mais cota de API; detalhes na página de preços.
3. Baixe. O ZIP é produzido sob demanda e fica disponível imediatamente após o pagamento.
4. Processe localmente. Descompacte e trabalhe o CSV no que você já usa.

Para um arquivo de algumas centenas de milhões de linhas, ferramentas de linha de comando e um motor colunar superam uma planilha com folga:

unzip com-zone.zip
wc -l com-zone.csv

# filter rows by name server with plain grep
grep -i 'cloudflare' com-zone.csv > cloudflare-hosted.csv

# or query the CSV directly with DuckDB, no import step
duckdb -c "SELECT ns, count(*) AS n FROM 'com-zone.csv' GROUP BY ns ORDER BY n DESC LIMIT 20"

Para análises recorrentes, carregue uma vez no PostgreSQL ou no ClickHouse com uma cópia em massa e indexe as colunas pelas quais você filtra. Cruzar dois pacotes — por exemplo, uma lista de tecnologia com um arquivo de zona — é um join direto pela coluna de domínio.

Automatizando com a API do catálogo

Os planos por assinatura incluem acesso à API para navegar pelo catálogo e obter metadados dos pacotes de forma programática. O Pro inclui 30.000 chamadas por mês; o Enterprise, 300.000. A API é uma interface de catálogo: ela lista e descreve pacotes e datasets. Não é um serviço de consulta por domínio.

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

A referência completa de endpoints, incluindo os de datasets e de conta, está na página de documentação da API.

Erros comuns na aquisição de dados de domínios & como evitá-los

Trabalhar com dados de whois vs rdap icann em escala real revela sempre o mesmo punhado de erros. Estes são os que vale a pena evitar.

1. Tratar WHOIS ou RDAP como fonte em massa

   • O que dá errado: escrever um script que percorre uma lista de um milhão de domínios e consulta cada um por WHOIS ou RDAP.
   • Por que dá errado: ambos os protocolos têm limite de requisições por fonte e nenhum registry suporta esse padrão. Você será limitado em minutos, e a execução vai demorar mais do que o tempo em que os dados permanecem válidos.
   • A solução: parta de um arquivo em massa que já contenha a população e reserve as consultas por nome para o pequeno subconjunto em que você precisa do registro atual do registry.

2. Esperar dados de contato nos registros de domínio

   • O que dá errado: planejar um fluxo de prospecção em cima dos e-mails dos titulares.
   • Por que dá errado: esses campos estão censurados ou substituídos por proxy na maioria dos domínios desde 2018. O plano falha nos dados, não na execução.
   • A solução: use dados de domínios pelo que eles são — um mapa de nomes, infraestrutura e tecnologia — e obtenha dados de contato por canais em que o consentimento e a origem estejam documentados.

3. Montar um parser por registrar e chamar isso de pipeline

   • O que dá errado: parsing de WHOIS baseado em regex que funciona nos registrars testados e destrói silenciosamente o resto.
   • Por que dá errado: o WHOIS não tem schema. Rótulos de campo, formatos de data e ordenação de seções variam, e mudam sem aviso.
   • A solução: prefira o RDAP onde o registry o suporta, já que o schema JSON é estável. Quando você precisa de um TLD inteiro, use o arquivo de zona em vez de reconstruí-lo nome por nome.

4. Ignorar a rapidez com que os dados envelhecem

   • O que dá errado: reaproveitar um arquivo do ano passado na análise deste ano.
   • Por que dá errado: domínios expiram, migram de host, trocam de CMS e entram atrás de CDNs o tempo todo. Conclusões tiradas de uma população desatualizada descrevem uma web que não existe mais.
   • A solução: baixe de novo quando a análise for relevante. A WebTrackly gera o arquivo no momento da compra, então um novo download é um extrato novo, não uma cópia em cache.

5. Subestimar o custo de construir a camada de coleta

   • O que dá errado: decidir rastrear e fazer fingerprinting da web internamente porque cada etapa isolada parece simples.
   • Por que dá errado: resolução em escala, lógica de retentativa, manutenção de fingerprints, armazenamento e agendamento de novos rastreamentos são um compromisso contínuo de engenharia, não uma sprint.
   • A solução: compre o arquivo populacional nos casos em que você precisa de cobertura e construa internamente só onde suas exigências realmente divergem do que já existe pronto.

6. Carregar centenas de milhões de linhas na ferramenta errada

   • O que dá errado: abrir um CSV de vários gigabytes em uma planilha, ou percorrê-lo linha a linha em uma linguagem de script.
   • Por que dá errado: as contagens de linhas aqui chegam a centenas de milhões. Ferramentas que carregam tudo na memória não vão terminar.
   • A solução: processe em streaming. Filtros de linha de comando, DuckDB direto sobre o CSV ou uma carga em massa em um banco colunar dão conta desse tamanho sem dificuldade.

7. Pular a revisão jurídica do que você coletou

   • O que dá errado: supor que, por o dado estar publicamente acessível, qualquer uso dele é permitido.
   • Por que dá errado: GDPR, CCPA e os termos de uso dos registries restringem como os dados de registro podem ser processados e republicados, independentemente de como foram obtidos.
   • A solução: mantenha dados pessoais totalmente fora do pipeline. Nomes de domínio, registros DNS, IPs e fingerprints de tecnologia não identificam indivíduos; os dados do titular, sim.

Perguntas frequentes (FAQ)

P: Qual é a diferença prática entre WHOIS e RDAP?
R: O WHOIS devolve texto não estruturado pela porta 43 e exige um parser sob medida por registrar. O RDAP devolve JSON sobre HTTPS seguindo um schema definido, suporta autenticação, usa códigos de erro HTTP padrão e pode encaminhar o cliente ao servidor autoritativo. Para uso programático, o RDAP é claramente mais fácil de trabalhar. Ambos estão sujeitos à mesma censura de privacidade e aos mesmos limites de requisições.

P: Consigo obter e-mails ou telefones dos titulares por algum dos protocolos?
R: Não na maioria dos domínios. Desde que o GDPR entrou em vigor, em 2018, a ICANN exige que os registrars censurem dados pessoais nas respostas públicas de WHOIS e RDAP. Existem vias de acesso credenciado para partes específicas, como autoridades policiais. A WebTrackly não vende dados de contato de nenhum tipo.

P: A WebTrackly oferece consulta de um domínio individual?
R: Não. O produto são arquivos em massa. O formato do download varia conforme o pacote e é informado na página do produto. Não existe interface de busca por domínio.

P: Em que formato vêm os downloads e quão atuais eles são?
R: O formato do download varia conforme o pacote e é informado na página do produto. O arquivo é gerado no momento da compra, e não servido a partir de um snapshot pré-montado.

P: Qual é o tamanho do catálogo?
R: 1.538 pacotes: 716 arquivos de zona de TLD, 79 listas de tecnologia e CMS e 27 datasets curados. Para dar escala: o pacote da zona .com contém 163.422.083 domínios, o pacote WordPress tem 21.639.326 e o dataset de todos os domínios registrados, 272.614.863 linhas.

P: Quanto custa?
R: Compras avulsas de pacotes começam em $3.50. O Pro custa $29/mês e inclui 50 pacotes, 10 datasets e 30.000 chamadas de API. O Enterprise custa $99/mês, com 200 pacotes, 50 datasets e 300.000 chamadas de API. Os detalhes atuais estão na página de preços.

P: Existe API?
R: Sim, para o catálogo. A API lista pacotes e datasets e devolve seus metadados, com autenticação por bearer token. Veja a documentação da API. Ela não faz consultas de domínio.

P: Como devo processar um arquivo com centenas de milhões de linhas?
R: Em streaming, em vez de carregar tudo. Ferramentas padrão de linha de comando dão conta de filtrar e contar; o DuckDB consulta um CSV no lugar, sem etapa de importação; para análises recorrentes, faça uma carga em massa no PostgreSQL ou no ClickHouse e indexe as colunas pelas quais você filtra.

Conclusão

WHOIS e RDAP fazem aquilo para que foram criados: dizem o que um registry registra sobre um nome. O RDAP faz isso com um schema, sobre HTTPS, com tratamento de erros de verdade — um ganho real, e vale migrar qualquer código que consulte dados de registro. O que nenhum dos dois protocolos jamais fará é entregar uma população. São consultas, limitadas por design, esvaziadas de dados pessoais por regulação e silenciosas sobre tudo o que acontece depois da resolução.

Quando a pergunta é sobre um TLD inteiro, uma plataforma inteira ou um segmento inteiro da web, o insumo certo é um arquivo. É isso que a WebTrackly publica: arquivos de zona, listas de tecnologia e datasets curados, em CSV, gerados na compra, para você analisar com as suas próprias ferramentas.

Comece pelo catálogo.
O formato do download varia conforme o pacote e é informado na página do produto.
Ver pacotes → | Ver preços →

Recursos relacionados

• Catálogo de pacotes — 1.538 bases de domínios para download
• Arquivos de zona por TLD — .com, .net, .de e mais de 700 outros
• Dados de domínios — listas de domínios por CMS e tecnologia
• Datasets curados — todos os domínios registrados, servidores MX, e-commerce
• Preços — compras avulsas a partir de $3.50