Consulta WHOIS de domínios: como buscar dados de titularidade

"Consulta WHOIS de domínios" é como a maioria das pessoas descreve o ato de verificar quem registrou um nome de domínio. Por trás disso estão o WHOIS e seu sucessor estruturado, o RDAP. Este artigo explica o que esses protocolos de fato retornam em 2026, por que os campos de contato do titular estão quase sempre ocultados e que tipos de dados de domínio ainda podem ser obtidos em massa — incluindo o que a WebTrackly publica e, igualmente importante, o que ela não publica.

TL;DR / PRINCIPAIS PONTOS

• O WHOIS responde a uma única pergunta, bem estreita: o que o registry e o registrador guardam sobre o registro de um domínio — datas de criação e expiração, registrador, códigos de status e servidores de nomes.
• Os campos de contato do titular estão ocultados. Desde a entrada em vigor do GDPR, em 2018, a especificação temporária da ICANN e a política que a sucedeu exigem que a maioria das respostas WHOIS/RDAP de gTLDs oculte nome, endereço, telefone e caixa postal do titular. Não existe forma legítima de obter esses campos em escala.
• O RDAP substituiu o WHOIS como protocolo padrão. Ele devolve JSON sobre HTTPS em vez de texto não estruturado, com um mecanismo de bootstrap documentado para localizar o servidor correto.
• O que escala bem são os dados de infraestrutura: quais domínios existem em um TLD, seus servidores de nomes, servidores de e-mail, endereços IP resolvidos e o CMS ou plataforma web detectada no site ativo.
• A WebTrackly publica exatamente esses dados de infraestrutura em arquivos para download — O formato do download varia conforme o pacote e é informado na página do produto.
• Os arquivos não contêm nenhum contato pessoal. Sem nomes de titulares, sem endereços de caixa postal, sem números de telefone, sem dados de intenção. Se você precisa disso, este não é o dataset certo.

ÍNDICE

• O que "Consulta WHOIS de domínios" realmente significa
• O que um registro WHOIS contém, campo a campo
• Por que os contatos do titular são ocultados após o GDPR
• RDAP: o sucessor estruturado do WHOIS
• Os limites das consultas domínio a domínio
• O que a WebTrackly realmente publica
  • Estrutura do catálogo
  • Números de cobertura
  • O esquema do arquivo
  • O que os arquivos não contêm
• O fluxo real: comprar, baixar, processar localmente
• A API: um catálogo, não uma busca de domínios
• Preços e entrega
• Erros comuns ao trabalhar com dados de domínio
• Perguntas frequentes
• RECURSOS RELACIONADOS

O que "Consulta WHOIS de domínios" realmente significa

Todo nome de domínio é registrado por meio de um registrador, que por sua vez informa o registro ao registry responsável por operar aquele domínio de topo. As duas partes mantêm um registro dessa operação e ambas expõem uma interface de consulta ao público. O WHOIS, definido na RFC 3912, é a mais antiga dessas interfaces: um serviço TCP simples na porta 43 que recebe um nome de domínio e devolve texto livre.

É a esse texto que as pessoas se referem quando falam em "consulta WHOIS de um domínio". Trata-se de um registro de titularidade, não de um perfil empresarial. Ele descreve a relação administrativa entre titular, registrador e registry. Não diz nada sobre o que o site faz, quem trabalha lá ou como o negócio ganha dinheiro — e nunca foi projetado para isso.

A confusão surge porque o registro costumava incluir nome, endereço postal, telefone e caixa postal do titular. Por cerca de duas décadas, isso transformou o WHOIS em um diretório público de fato. Essa era terminou em 2018, e boa parte da frustração de quem faz uma consulta hoje vem justamente dessa mudança.

O que um registro WHOIS contém, campo a campo

Uma resposta típica de gTLD, seja via WHOIS ou RDAP, traz as seguintes categorias de informação:

• Nome de domínio e sua forma internacionalizada, além do ID interno do domínio no registry.
• Registrador — nome, IANA ID, contato de abuso e o servidor WHOIS do próprio registrador.
• Datas — criação, última atualização e expiração. São os campos mais confiavelmente preenchidos de todo o registro e a razão pela qual os dados de data de registro são minimamente utilizáveis.
• Códigos de status — status EPP como clientTransferProhibited, serverHold, pendingDelete ou redemptionPeriod. Eles descrevem o estado do ciclo de vida do registro e são genuinamente informativos: um domínio em redemptionPeriod expirou e está dentro da janela de recuperação.
• Servidores de nomes — os servidores DNS autoritativos delegados para o domínio. Esse campo é público por política e é um dos poucos que continua completo.
• DNSSEC — se a delegação está assinada.
• Objetos de contato — titular, administrativo, técnico e de cobrança. Na esmagadora maioria dos registros de gTLD, hoje são apenas marcadores ocultados.

A cobertura varia conforme o TLD. Os registries de ccTLD definem sua própria política: alguns publicam um registro mais completo que os gTLDs, muitos publicam bem menos e vários limitam a taxa de requisições ou protegem o serviço WHOIS com CAPTCHA. Não existe um padrão global único sobre o que uma "consulta WHOIS" deve conter além do contrato da ICANN, que vincula apenas os gTLDs.

Por que os contatos do titular são ocultados após o GDPR

Quando o Regulamento Geral de Proteção de Dados passou a ser exigível, em maio de 2018, publicar os dados pessoais de todo titular de domínio residente na UE em um diretório consultável de forma anônima tornou-se insustentável. A ICANN adotou uma Especificação Temporária que obrigou as partes contratadas a suprimir a maior parte dos campos de contato do titular da saída pública, posteriormente formalizada na Registration Data Policy. Na prática, os registradores aplicaram a supressão globalmente, em vez de tentar determinar quais titulares estavam de fato cobertos pela legislação europeia.

As consequências práticas para quem constrói algo em cima desses dados:

• Nome, organização, rua, cidade, CEP, telefone e caixa postal do titular são substituídos por strings como REDACTED FOR PRIVACY ou Data Protected.
• País e, às vezes, estado ou província sobrevivem em muitos registros — por isso ainda é parcialmente possível derivar distribuições por país a partir dos dados de registro.
• Os registradores costumam expor um canal anonimizado — um formulário web ou um endereço de encaminhamento específico por domínio — que permite alcançar o titular sem revelar sua identidade. Esses canais não são dados de contato extraíveis e têm limite de taxa por design.
• O acesso a dados não ocultados existe apenas por canais restritos, mediante solicitação, para partes com base legal demonstrada e avaliação caso a caso. Não é um feed em massa, e nenhum conjunto de dados comercial pode substituí-lo legalmente.

Os serviços de privacidade e proxy são anteriores ao GDPR e acrescentam uma segunda camada: mesmo onde um registry publicaria dados de contato, o titular pode ter pago por um proxy que figura como detentor nominal. Entre a supressão e o proxy, tratar o WHOIS como fonte de informações de contato deixou de ser uma estratégia viável em qualquer escala.

RDAP: o sucessor estruturado do WHOIS

O RDAP — Registration Data Access Protocol, especificado nas RFCs 7480 a 7484 e nas RFC 9082/9083 — foi projetado para corrigir os problemas estruturais do WHOIS. Ele roda sobre HTTPS, devolve JSON, dá suporte adequado à internacionalização e define um arquivo de bootstrap publicado pela IANA, para que o cliente descubra qual servidor é autoritativo para um dado TLD ou faixa de IP. Todos os registries e registradores de gTLD são obrigados a operar serviços RDAP desde 2019, e a exigência do WHOIS na porta 43 foi descontinuada em seguida.

Uma consulta mínima se parece com isto:

# Find the authoritative RDAP base URL for the TLD
curl -s https://data.iana.org/rdap/dns.json | jq '.services[] | select(.[0][] == "com")'

# Query a domain
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{
  ldhName,
  status,
  events: [.events[] | {eventAction, eventDate}],
  nameservers: [.nameservers[].ldhName]
}'

O que importa observar nessa saída é o formato do que volta. Eventos, status e servidores de nomes vêm estruturados e preenchidos. O array entities — onde ficam os contatos de titular, administrativo e técnico — trará uma entidade de registrador com contato de abuso e uma entidade de titular cujos campos vCard estão ocultados. O RDAP mudou a codificação, não a política de divulgação.

O RDAP também tem limite de taxa, por consulta e por domínio. É a ferramenta certa para investigar um domínio, verificar uma data de expiração ou checar um código de status antes de uma transferência. É a ferramenta errada para montar um dataset de um milhão de domínios.

Os limites das consultas domínio a domínio

Suponha que você queira responder a algo como "quantos domínios deste TLD rodam WordPress" ou "quais servidores de nomes são mais comuns no .de". Um protocolo domínio a domínio não responde a isso. Você precisaria primeiro conhecer a população de domínios, depois consultar cada um deles e ainda buscar cada site separadamente, porque WHOIS e RDAP nada dizem sobre o software que roda no site.

São necessárias três fontes de dados distintas:

1. A população — quais domínios existem em uma zona. Isso vem de arquivos de zona ou de listagens equivalentes derivadas dos registries, não do WHOIS.
2. Resolução DNS — os servidores de nomes, os servidores de e-mail e os registros A de cada domínio, obtidos ao resolvê-los.
3. Detecção de plataforma — o que o site ativo retorna, obtido ao buscá-lo e comparar assinaturas no HTML, nos cabeçalhos e nos caminhos dos assets.

Fazer isso por conta própria é um projeto de engenharia de verdade: acordos de acesso a arquivos de zona ou fontes equivalentes, uma fazenda de resolvers que não te leve a um bloqueio por excesso de requisições, um crawler educado e armazenamento para centenas de milhões de linhas. Comprar o resultado desse pipeline como arquivo costuma sair mais barato do que reconstruí-lo.

O que a WebTrackly realmente publica

Estrutura do catálogo

O catálogo da WebTrackly reúne 1.538 pacotes, divididos em quatro tipos:

Os pacotes de zona podem ser explorados em /zones/, as compilações curadas em /datasets/ e o catálogo completo em /packages/.

Números de cobertura

• 285.582.781 domínios em todas as zonas.
• 163.422.083 domínios apenas em .com.
• 21.639.326 domínios com WordPress detectado.
• 567.680 domínios com Joomla detectado.
• 272.614.863 linhas no dataset de todos os domínios registrados.

Vale ler esses números com atenção. O valor de WordPress é a contagem de domínios em que o WordPress foi detectado no site ativo — não uma contagem de todas as instalações de WordPress existentes, nem a afirmação de que todo domínio do catálogo foi acessado. A detecção exige um site que responda; domínios estacionados, redirecionados e que não resolvem estão presentes nas listas de zona, mas não trazem valor de plataforma.

O esquema do arquivo

Um pacote enriquecido por zona é um CSV mais ou menos com este formato:

domain,created,ns,mx,ip,cms
example.com,2011-04-17,ns1.example-dns.net;ns2.example-dns.net,mx1.mailhost.net,203.0.113.14,WordPress
sample.com,,ns1.hoster.io;ns2.hoster.io,,198.51.100.7,

Observações sobre os campos, porque as ressalvas importam mais do que o cabeçalho:

• domain — sempre presente. É a chave primária.
• created — a data de registro, preenchida somente onde o registry a publica. Muitos ccTLDs não publicam, então espere uma coluna esparsa fora dos principais gTLDs.
• ns — servidores de nomes delegados. Útil para análise de hospedagem e de provedores de DNS, e uma das colunas mais completas do arquivo.
• mx — os registros de troca de e-mail do domínio: os hostnames dos servidores que aceitam mensagens para ele, como um endpoint do Google Workspace ou do Microsoft 365. São nomes de servidor, não endereços de caixa postal.
• ip — o endereço resolvido no momento da coleta. Sites atrás de um CDN resolvem para a borda do CDN, o que é um fato sobre o CDN, não sobre onde está a origem.
• cms — a plataforma detectada no site ativo, em branco quando nada foi detectado ou o site não respondeu.

O que os arquivos não contêm

Dito de forma direta, para não restar ambiguidade antes da compra:

• Nenhum dado de contato pessoal. Sem nomes de titulares, sem endereços de caixa postal, sem números de telefone, sem pessoas nomeadas em qualquer empresa. É uma decisão deliberada de projeto e uma consequência da supressão descrita acima — esses dados não estão legalmente disponíveis nessa escala, e qualquer fornecedor que os ofereça em volume merece ser questionado de perto.
• Nenhum dado de intenção ou sinal de compra. Nada sobre uma organização estar ou não avaliando uma aquisição.
• Nenhuma estimativa de tráfego, receita ou número de funcionários.
• Nenhum serviço de consulta domínio a domínio. O produto são arquivos em massa, não uma API de consulta sobre domínios individuais. Para um único domínio, use o RDAP diretamente, como mostrado acima.
• Nenhuma busca por tecnologia na interface. O agrupamento por tecnologia existe como um conjunto de pacotes prontos; não é um construtor de consultas interativo.

O fluxo real: comprar, baixar, processar localmente

O fluxo é deliberadamente simples, e tudo o que vem depois do download acontece na sua própria máquina:

1. Escolha um pacote em /packages/, /zones/ ou /datasets/, conforme a zona ou a plataforma que interessa a você.
2. Compre. A exportação é gerada na hora da compra, em vez de servida a partir de um arquivo pré-montado e desatualizado.
3. Baixe o ZIP na sequência — a entrega é por download direto, com o CSV dentro do arquivo compactado.
4. Descompacte e consulte localmente. Sem idas e vindas de API, sem cobrança por linha.

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

# Quick filtering with standard tools
grep -c ',WordPress$' com-enriched.csv
awk -F, '$6 == "Joomla" { print $1 }' com-enriched.csv > joomla-domains.txt

Para qualquer coisa maior que alguns milhões de linhas, um motor colunar é bem mais confortável que ferramentas de shell. O DuckDB lê CSV diretamente, sem etapa de importação:

-- DuckDB: top name server providers in a zone
SELECT
    regexp_extract(split_part(ns, ';', 1), '([^.]+\.[^.]+)$', 1) AS ns_domain,
    count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE ns IS NOT NULL AND ns <> ''
GROUP BY 1
ORDER BY domains DESC
LIMIT 25;

-- Registration cohorts, where the registry publishes creation dates
SELECT date_trunc('year', created) AS cohort, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE created IS NOT NULL
GROUP BY 1
ORDER BY 1;

O ClickHouse é a melhor escolha se a ideia for manter várias zonas carregadas e consultá-las repetidamente:

CREATE TABLE domains
(
    domain  String,
    created Nullable(Date),
    ns      String,
    mx      String,
    ip      String,
    cms     LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY domain;

INSERT INTO domains
SELECT * FROM file('com-enriched.csv', 'CSVWithNames');

Análises típicas que isso viabiliza: participação de mercado de hospedagem e DNS por zona, distribuição de CMS entre TLDs, concentração de provedores de e-mail, curvas de coorte de registro para zonas que publicam datas de criação e clusterização de faixas de IP para identificar infraestrutura operada por um único provedor.

A API: um catálogo, não uma busca de domínios

A API expõe o catálogo de pacotes. Ela permite descobrir e inspecionar o que está disponível e automatizar decisões de compra; ela não busca domínios individuais, porque os dados de domínio são entregues em arquivos.

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

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

# Inspect a single package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

Um cliente Python mínimo sobre os mesmos endpoints:

import requests

BASE = "https://webtrackly.com/api/v1"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

zones = requests.get(f"{BASE}/packages/", headers=HEADERS,
                     params={"type": "zone"}).json()

for pkg in zones.get("results", []):
    print(pkg["slug"], pkg.get("domains_count"))

detail = requests.get(f"{BASE}/packages/com/", headers=HEADERS).json()
print(detail)

A documentação completa dos endpoints está em /api/.

Preços e entrega

Os pacotes individuais são compras avulsas a partir de $3.50: O formato do download varia conforme o pacote e é informado na página do produto. Dois planos de assinatura atendem ao uso recorrente:

Os detalhes atualizados estão em /pricing/.

Erros comuns ao trabalhar com dados de domínio

1. Esperar que o WHOIS identifique uma empresa. Ele identifica um registro. Mesmo antes da supressão, o titular era frequentemente uma empresa de hospedagem, uma agência ou um serviço de proxy, e não a organização por trás do site. Use dados de registro para questões de ciclo de vida e delegação, e dados de infraestrutura para questões sobre o site em si.

2. Tratar um IP resolvido como o servidor de origem. Qualquer domínio atrás de um CDN ou proxy reverso resolve para a borda. Agregar IPs sem levar isso em conta produz um gráfico sobre adoção de CDN travestido de gráfico sobre hospedagem.

3. Supor que uma coluna CMS vazia significa "sem CMS". Em branco significa que nada foi detectado, o que também cobre sites que não responderam, redirecionaram, bloquearam a requisição ou rodam algo sem assinatura confiável. Reporte as taxas de detecção junto com as contagens, ou o denominador vai mentir em silêncio.

4. Ler datas de criação ausentes como registros novos. Muitos registries de ccTLD simplesmente não publicam datas de criação. Uma coluna esparsa é um artefato de política, não um sinal sobre a idade do domínio.

5. Ignorar a velocidade com que esses dados envelhecem. Domínios expiram, servidores de nomes mudam, sites são refeitos. Qualquer snapshot é uma observação pontual no tempo. Se uma decisão depende do estado atual, baixe o pacote de novo em vez de reaproveitar um arquivo do trimestre passado.

6. Carregar centenas de milhões de linhas em uma planilha. Planilhas estouram o limite muito antes desses arquivos. Um motor colunar em um notebook lida com a zona .com inteira com folga; uma planilha nem sequer abre o arquivo.

Perguntas frequentes

P: Consigo obter nomes e dados de contato do titular em uma consulta WHOIS?
R: Para a maioria dos domínios gTLD, não. Os campos de contato do titular estão ocultados desde que a política pós-GDPR da ICANN entrou em vigor, em 2018. Os registradores costumam oferecer um canal anonimizado para alcançar o titular sem revelar a identidade, e existe acesso restrito, mediante solicitação, para partes com base legal demonstrada. Nenhum dos dois é fonte em massa, e os arquivos da WebTrackly não contêm nenhum tipo de dado de contato pessoal.

P: Qual é a diferença entre WHOIS e RDAP?
R: O RDAP é o substituto padronizado. Ele entrega JSON sobre HTTPS, dá suporte adequado a texto internacionalizado e publica um arquivo de bootstrap da IANA para que os clientes localizem o servidor autoritativo de qualquer TLD. O WHOIS devolve texto não estruturado pela porta 43, em formato que varia entre registries. O RDAP mudou a codificação e o transporte; não mudou o que é divulgado.

P: Em que formato chegam os pacotes da WebTrackly?
R: O formato do download varia conforme o pacote e é informado na página do produto. A exportação é gerada no momento da compra, em vez de servida a partir de um arquivo pré-montado.

P: Quantos domínios estão cobertos?
R: 285.582.781 em todas as zonas, incluindo 163.422.083 em .com. O dataset de todos os domínios registrados contém 272.614.863 linhas. Os pacotes por tecnologia cobrem 21.639.326 domínios com WordPress detectado e 567.680 com Joomla.

P: Posso consultar um único domínio pela WebTrackly?
R: Não. O produto são arquivos em massa organizados por zona, tecnologia ou dataset curado. Para um único domínio, consulte o RDAP diretamente — é gratuito, autoritativo para dados de registro e exige uma única requisição HTTP.

P: A API permite filtrar domínios por tecnologia ou país?
R: A API serve o catálogo de pacotes, não um mecanismo de consulta em nível de domínio. Você pode listar e filtrar pacotes por tipo e termo de busca, depois comprar e baixar os que precisar. A filtragem de linhas individuais acontece localmente, no DuckDB, no ClickHouse ou na ferramenta que você preferir.

P: Quão atuais são os dados?
R: As exportações são geradas na hora da compra a partir do estado atual do catálogo. Como a web muda continuamente, trate qualquer download como um snapshot e baixe de novo antes de decisões que dependam do estado presente.

P: Quais são os limites dos planos?
R: O Pro custa $29/mês e inclui 50 pacotes, 10 datasets e 30.000 chamadas de API. O Enterprise custa $99/mês e inclui 200 pacotes, 50 datasets e 300.000 chamadas de API. Pacotes individuais também podem ser comprados avulsos a partir de $3.50. Veja /pricing/.

A WebTrackly publica dados de zonas de domínio, DNS e detecção de CMS em arquivos para download.
Ver dados de domínio → | Ver preços →

Recursos relacionados

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