RDAP da ICANN explicado: o substituto do WHOIS (guia 2026)

O WHOIS nunca foi projetado para consumo por máquinas e, depois de duas décadas de formatos de saída específicos de cada registrar e de uma década de ocultação de dados motivada por privacidade, deixou de funcionar como fonte de dados. O Registration Data Access Protocol (RDAP) da ICANN é o substituto padronizado: os mesmos dados de registro, entregues como JSON sobre HTTPS com um schema consistente. Este guia explica o que é o RDAP, o que suas respostas realmente contêm em 2026 (muito menos do que se espera), como ele difere do WHOIS no nível do protocolo e como trabalhar com dados de domínios em escala quando consultas domínio a domínio não são viáveis.

Principais conclusões

• O WHOIS está sendo aposentado: o protocolo devolve texto livre sem estrutura garantida, varia de registrar para registrar e não tem autenticação, tratamento de erros nem internacionalização padronizados.
• O RDAP é o substituto exigido pela ICANN: definido nas RFC 7480-7484, devolve JSON sobre HTTPS com um modelo de objetos documentado, códigos de status HTTP padrão e um registro de bootstrap para localizar o servidor correto.
• A estrutura é o ganho real: registrar, datas de criação e de expiração, name servers, códigos de status e registros de eventos chegam como campos nomeados, em vez de texto que precisa ser reconhecido por padrões.
• Os dados de contato praticamente desapareceram: as respostas RDAP para gTLDs vêm ocultadas por padrão. Nomes, e-mails e telefones de registrantes não são obtíveis em escala pelo RDAP, e nenhuma ferramenta legítima muda isso.
• Consulta domínio a domínio não escala: os servidores RDAP têm limites de taxa. Perguntas de nível populacional ("quantos domínios em .de rodam WordPress") exigem arquivos em massa, não consultas.
• Arquivos em massa respondem a outras perguntas: arquivos de zona e conjuntos enriquecidos por zona entregam domínio, name servers, MX, IP e CMS detectado em TLDs inteiros, que é a entrada certa para dimensionamento de mercado, pesquisa de infraestrutura e construção de conjuntos de dados.

Índice

1. RDAP da ICANN: a base moderna para dados de domínios e por que o WHOIS está obsoleto
2. O que o RDAP não entrega: ocultação de dados, limites de taxa e escala
3. Onde os dados em nível de domínio são realmente úteis
4. O que a WebTrackly oferece: pacotes de dados de domínios em massa
5. Schema dos dados: o que há dentro do CSV
6. Usando a API do catálogo
7. Processando os arquivos localmente
8. Erros comuns ao trabalhar com dados RDAP
9. Perguntas frequentes
10. Conclusão

RDAP da ICANN: a base moderna para dados de domínios e por que o WHOIS está obsoleto

A internet funciona sobre domínios, e entender quem os detém, quem os administra e quando foram registrados é fundamental para uma enorme variedade de atividades online, da geração de leads B2B a investigações de cibersegurança. Durante décadas, a ferramenta principal para isso foi o WHOIS. Só que o protocolo WHOIS tradicional, concebido nos primórdios da internet, virou uma relíquia, cada vez mais inadequada às exigências da web moderna. Sua saída em texto livre e inconsistente, somada a regulações de privacidade em evolução como o GDPR, o tornou notoriamente difícil de interpretar por software e muitas vezes incompleto para usos comerciais legítimos. É exatamente por isso que a visão geral do RDAP da ICANN como substituto do WHOIS não é apenas uma atualização, mas uma necessidade para quem leva a sério a inteligência de domínios.

O RDAP, ou Registration Data Access Protocol, surgiu na Internet Engineering Task Force (IETF) e na ICANN como a solução padronizada de próxima geração. Diferentemente do WHOIS, que muitas vezes exige um humano para interpretar formatos de saída variáveis de centenas de registrars distintos, o RDAP entrega dados estruturados e legíveis por máquina, tipicamente em JSON. Uma consulta devolve um objeto bem definido: o handle do domínio, um array events com os timestamps de registro, expiração e última alteração, um array nameservers, um array status com valores padronizados derivados do EPP e um array entities que descreve o registrar e quaisquer contatos que o registry opte por publicar. Cada campo tem nome, tipo e lugar definido no schema, que é exatamente o que o WHOIS nunca teve.

A escala é o que torna isso relevante. Centenas de milhões de nomes de domínio estão registrados no mundo, e checar manualmente registros WHOIS de sequer mil deles é inviável. Automatizar com WHOIS significa escrever e manter parsers para centenas de formatos de saída distintos, uma batalha permanente contra a inconsistência e contra mudanças silenciosas de formato. A regulação de privacidade agravou o problema: depois que o GDPR entrou em vigor, os registrars passaram a ocultar ou intermediar os campos de contato do registrante na saída WHOIS como rotina, e a mesma ocultação se estende ao RDAP. A consequência prática é que o WHOIS perdeu quase todo o valor que ainda tinha como fonte de contatos, enquanto seus problemas de parsing ficaram exatamente onde estavam.

O RDAP ataca esses desafios de frente. Ele oferece um mecanismo consistente de consulta e resposta, com uma estrutura padronizada para os dados de registro de domínios independentemente do registrar ou do domínio de topo (TLD). Isso inclui informações sobre o domínio, seu registrar, datas de criação e expiração, name servers e, com frequência, dados de contato mais estruturados (quando legalmente permitido) ou ao menos identificadores organizacionais. Por exemplo, em vez de tentar extrair um "e-mail do registrante" de um bloco de texto que pode estar rotulado como "Admin Contact", "Registrant Email" ou "Contact Email", o RDAP fornece campos JSON distintos para esses atributos, tornando a extração de dados precisa e confiável.

Considere um cenário real: uma empresa de SaaS B2B especializada em segurança de sites quer identificar clientes em potencial que rodam ambientes de hospedagem antigos e menos seguros. Com o WHOIS tradicional, ela teria de raspar milhares de registros, identificar manualmente os provedores de hospedagem a partir das entradas de name server (que muitas vezes são pouco claras) e então tentar encontrar algum dado de contato, lutando contra a ocultação o tempo todo. O processo é lento, propenso a erros e produz leads de baixa qualidade.

O RDAP resolve o problema de formato, e apenas o problema de formato. Ele entrega metadados técnicos confiáveis e comparáveis: qual registrar patrocina um domínio, quando ele foi criado e quando expira, para quais name servers ele delega e quais códigos de status administrativo se aplicam. Isso é genuinamente útil para análise de infraestrutura, para acompanhar a participação de mercado de registrars e provedores de DNS e para detectar domínios cujo padrão de registro ou delegação pareça atípico. O que ele não faz é restaurar o diretório de registrantes que existia antes de 2018. Qualquer fluxo de trabalho que suponha que o RDAP vai devolver uma pessoa de contato parte de uma premissa falsa e vai falhar na esmagadora maioria dos domínios de gTLD.

A migração para o RDAP é um padrão da indústria, documentado em RFCs como a RFC 7480, 7481, 7482, 7483 e 7484. Elas definem o protocolo, a estrutura de consulta e resposta e as considerações de segurança, garantindo uma base robusta e à prova de futuro para o acesso a dados de domínios. Ao adotar o RDAP, a ICANN e a comunidade da internet caminham para uma forma mais segura, eficiente e amigável a máquinas de consultar e receber dados de registro, essencial para manter a estabilidade e a utilidade da internet. Para as empresas, isso significa sair de uma abordagem manual e cheia de suposições rumo a uma estratégia orientada a dados e automatizada para identificar e engajar seu mercado-alvo. A WebTrackly coloca esse poder diretamente nas suas mãos, transformando dados RDAP brutos em insights acionáveis para seus times de vendas, marketing e dados.

O que o RDAP não entrega: ocultação de dados, limites de taxa e escala

Vale ser explícito sobre os limites do protocolo, porque boa parte do material publicado sobre RDAP os exagera discretamente.

• Os dados de contato do registrante vêm ocultados por padrão. Pela política de dados de registro da ICANN, as respostas RDAP de gTLDs omitem ou mascaram os dados de contato do registrante e dos contatos administrativo e técnico para o público em geral. Uma resposta típica traz uma entidade registrar com um contato de abuso e uma entidade registrante cujos campos vCard foram removidos ou substituídos por um endereço intermediário. Não existe um nível público que devolva os valores originais, e obtê-los exige um pedido de divulgação credenciado e limitado a uma finalidade, tratado caso a caso.
• A cobertura é desigual entre os TLDs. O RDAP é obrigatório para gTLDs. Muitos registries de ccTLD o operam voluntariamente, alguns o operam com menos campos e uns poucos ainda só oferecem WHOIS ou um formulário web. O registro de bootstrap da IANA informa qual servidor é autoritativo para um dado TLD, mas não diz o que esse servidor vai optar por publicar.
• Os limites de taxa tornam a consulta em massa impossível. Os endpoints RDAP de registries e registrars são protegidos contra coleta automatizada. Consultas sequenciais na casa dos milhões de domínios não são um uso previsto do protocolo, e tentar isso resulta em throttling ou bloqueio. É uma decisão de projeto, não um obstáculo a ser contornado por engenharia.
• As respostas descrevem o registro, não o site. O RDAP não sabe nada sobre qual CMS um site roda, qual CDN está na frente dele ou se ele sequer resolve. Essa informação vem da observação de DNS e HTTP, que é um problema de coleta de dados separado.

Esses limites determinam quais perguntas dá para responder com uma consulta e quais exigem um conjunto de dados em massa. Perguntar "qual é o registrar e a data de expiração deste domínio" é uma consulta. Perguntar "quantos domínios desta zona delegam para name servers da Cloudflare" é uma pergunta de conjunto de dados, e nenhuma quantidade de consultas vai transformá-la em uma consulta simples.

Onde os dados em nível de domínio são realmente úteis

Dados estruturados de registro e infraestrutura sustentam um conjunto de casos de uso mais estreito, porém mais defensável, do que o marketing em torno de inteligência de domínios costuma sugerir. Os três abaixo trabalham com o que está genuinamente disponível: metadados técnicos sobre domínios, não informações sobre as pessoas por trás deles.

Superfície de ataque e pesquisa de infraestrutura

Público-alvo: provedores de serviços de cibersegurança, empresas de teste de intrusão, times de resposta a incidentes, analistas de inteligência de ameaças.

Problema: identificar organizações que rodam infraestrutura potencialmente vulnerável ou desatualizada é um processo manual e demorado. Os dados WHOIS tradicionais são inconsistentes demais e frequentemente ocultados para mapear com eficácia os domínios até sua pilha tecnológica subjacente ou até padrões de registrar que possam indicar risco. As superfícies de ataque são vastas, e identificar proativamente alvos com configurações específicas e exploráveis é crítico, mas difícil.

O que os dados sustentam: arquivos em nível de zona permitem que um time de segurança enumere os domínios de um TLD, resolva sua delegação e infraestrutura de e-mail e cruze as plataformas de CMS detectadas com versões sabidamente vulneráveis. Trabalhar a partir de uma zona completa, em vez de uma lista amostrada, significa que o denominador é real: dá para dizer quantos domínios de uma zona usam determinado operador de name server ou provedor de e-mail, em vez de quantos apareceram na amostra que você conseguiu coletar. O RDAP então preenche os metadados de registro domínio a domínio para a lista curta que sai dessa análise, um volume que o protocolo atende sem problemas.

O que os dados não sustentam: eles não vão dizer com quem falar dentro dessas organizações. Montar uma lista de prospecção é um exercício à parte, que precisa se apoiar em informações que essas organizações publicam sobre si mesmas, e não é algo que um conjunto de dados de domínios forneça.

Dimensionamento de mercado para fundadores de SaaS e times de produto

Público-alvo: fundadores de SaaS, gerentes de produto, pesquisadores de mercado, investidores de venture capital.

Problema: validar a ideia de um novo produto SaaS exige entendimento profundo do mercado: quem são os clientes em potencial, que tecnologias eles usam hoje e qual o tamanho do mercado endereçável? Apoiar-se em evidências anedóticas ou em relatórios setoriais genéricos é insuficiente. Fundadores precisam de dados granulares sobre adoção de tecnologia e infraestrutura subjacente.

O que os dados sustentam: contagem. Se o seu produto tem como alvo sites WordPress, o tamanho da população endereçável é uma quantidade contável, e não uma estimativa: nas zonas cobertas aqui, 21.639.326 domínios são detectados como WordPress e 567.680 como Joomla. Se o seu produto é específico de uma região, os arquivos por zona permitem restringir a contagem aos TLDs que importam. Comparar contagens entre zonas ou entre snapshots feitos em momentos diferentes mostra onde uma plataforma está ganhando ou perdendo terreno, o que é uma base muito mais sólida para um business case do que o gráfico de participação de mercado publicado por um fornecedor.

Como executar: pegue o conjunto enriquecido das zonas de interesse, conte as linhas por CMS detectado e por operador de name server e repita com um snapshot posterior quando quiser uma tendência em vez de uma estimativa pontual.

Construção de conjuntos de dados para análise e machine learning

Público-alvo: cientistas de dados, engenheiros de dados, pesquisadores, analistas de business intelligence.

Problema: construir conjuntos de dados abrangentes para análise em larga escala, modelos de machine learning ou previsão de tendências esbarra em fontes de dados inconsistentes. Os dados WHOIS tradicionais são não estruturados, exigem limpeza e parsing extensos e muitas vezes não têm a consistência necessária para pipelines de dados robustos. Integrar pontos de dados dispersos de várias fontes web é complexo e demorado.

O que os dados sustentam: um ponto de partida estável e colunar. Cada arquivo enriquecido por zona é um CSV com uma linha por domínio e um conjunto fixo de colunas, que carrega direto em pandas, DuckDB, ClickHouse ou em um data warehouse, sem etapa de parsing. Domínio, name servers, MX, IP e CMS detectado são todos utilizáveis como features: concentração de provedores de hospedagem e de e-mail, padrões de delegação e escolha de plataforma são sinais informativos para tarefas de classificação, como separar domínios estacionados de sites ativos ou agrupar domínios por operador de infraestrutura. Quando o registry publica as datas de registro, elas estão incluídas e dão ao conjunto de dados uma dimensão temporal.

Ressalvas que vale incorporar: a detecção é observacional e vai ficar defasada para sites que mudaram recentemente; um domínio presente em um arquivo de zona está registrado, mas não necessariamente servindo conteúdo; e a ausência de um registro MX significa que não há e-mail configurado para aquele nome, não que a organização não tenha e-mail.

O que a WebTrackly oferece: pacotes de dados de domínios em massa

A WebTrackly é um catálogo de dados de domínios para download, não uma interface de busca nem um banco de contatos. São 1.538 pacotes no catálogo, organizados em quatro grupos.

A cobertura dessas zonas é de 285.582.781 domínios. A maior zona isolada é .com, com 163.422.083 domínios. Do lado da tecnologia, 21.639.326 domínios são detectados como WordPress e 567.680 como Joomla. O maior conjunto de dados curado, com todos os domínios registrados, contém 272.614.863 linhas.

A entrega é deliberadamente simples. O formato do download varia conforme o pacote e é informado na página do produto. As compras avulsas começam em $3.50. Há dois planos de assinatura para uso contínuo: o Pro, a $29/mês, cobre 50 pacotes mais 10 conjuntos de dados e 30.000 chamadas de API, e o Enterprise, a $99/mês, cobre 200 pacotes mais 50 conjuntos de dados e 300.000 chamadas de API.

O catálogo pode ser navegado em /packages/, com os arquivos de zona listados em /zones/, as listas por tecnologia em /domaindata/ e as compilações entre zonas em /datasets/. Os detalhes dos planos estão em /pricing/.

Schema dos dados: o que há dentro do CSV

Um pacote enriquecido por zona é descompactado em um CSV com uma linha por domínio e as colunas a seguir.

Os pacotes de arquivo de zona simples contêm apenas a coluna domain. As listas por tecnologia contêm os domínios nos quais uma dada plataforma foi detectada.

É igualmente importante deixar claro o que os arquivos não contêm:

• Nenhum contato pessoal de qualquer tipo. Nenhum nome, nenhum endereço de e-mail, nenhum telefone, nenhum perfil social.
• Nenhum dado de identidade do registrante. A data de registro é um metadado publicado pelo registry; quem está por trás de um domínio não faz parte destes arquivos.
• Nenhum sinal de intenção, firmográfico ou de porte da empresa.
• Nenhuma estimativa de tráfego, ranqueamento ou receita.

Se o que você precisa é de uma lista de pessoas para contatar, estes conjuntos de dados são a entrada errada, e nenhum filtro ou opção de exportação vai mudar isso.

Usando a API do catálogo

A API serve o catálogo: ela permite descobrir quais pacotes existem, inspecionar seus metadados e automatizar compra e download. Não é um endpoint de consulta domínio a domínio, e não há interface de consulta que devolva registros individuais de domínios. Toda requisição carrega um bearer token.

Listar os pacotes de arquivos de zona:

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

Buscar nos pacotes por tecnologia:

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

Obter o registro de detalhe de um único pacote, incluindo sua contagem de linhas e o preço atual:

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

Um padrão típico de automação é consultar periodicamente o catálogo em busca dos pacotes de que seu pipeline depende, comparar as contagens de linhas informadas com as da sua última ingestão e disparar um novo download quando uma zona tiver crescido ou encolhido de forma relevante. As cotas de chamadas de API são de 30.000 por mês no Pro e 300.000 por mês no Enterprise, o que é folgado para monitorar o catálogo e vai muito além do que um pipeline agendado precisa. A documentação completa dos endpoints está em /api/.

Processando os arquivos localmente

O formato do download varia conforme o pacote e é informado na página do produto. Como os arquivos são CSV puro, ferramentas de linha de comando padrão dão conta da primeira passada e um motor colunar cuida de todo o resto.

Descompacte e observe o formato dos dados:

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

Para um arquivo de zona única, grep e awk costumam bastar:

# domains delegating to Cloudflare name servers
grep -i 'ns.cloudflare.com' com-enriched.csv | wc -l

# domains with Google Workspace mail
grep -i 'aspmx.l.google.com' com-enriched.csv | wc -l

Para qualquer coisa analítica, carregue o CSV no DuckDB. Ele lê o arquivo no lugar, sem etapa de importação:

duckdb -c "
  SELECT cms, count(*) AS domains
  FROM read_csv_auto('com-enriched.csv')
  WHERE cms IS NOT NULL
  GROUP BY cms
  ORDER BY domains DESC
  LIMIT 20;
"

Para consultas repetidas em muitas zonas ao mesmo tempo, o ClickHouse é a escolha melhor. Crie uma tabela com as seis colunas, carregue os CSVs e as agregações sobre centenas de milhões de linhas rodam em segundos:

clickhouse-client --query "
  CREATE TABLE domains (
    domain String, reg_date Nullable(Date),
    ns String, mx String, ip String, cms String
  ) ENGINE = MergeTree ORDER BY domain"

clickhouse-client --query "INSERT INTO domains FORMAT CSVWithNames" < com-enriched.csv

Uma observação sobre escala: o conjunto de dados com todos os domínios registrados tem 272.614.863 linhas, então planeje dezenas de gigabytes descompactados e use um armazenamento colunar em vez de uma planilha. Os arquivos de zona individuais são bem menores e a maioria abre tranquilamente no DuckDB em um notebook.

Erros comuns ao trabalhar com dados RDAP

O RDAP é simples de consultar e fácil de interpretar mal. Estes são os erros que mais costumam produzir conclusões enganosas.

1. Erro: depender demais dos dados de contato diretos do RDAP bruto.

   • O que dá errado: muita gente espera que o RDAP forneça endereços de e-mail e telefones diretos e não ocultados dos registrantes. Por causa de regulações de privacidade (como o GDPR) e das políticas dos registrars, boa parte dessa informação costuma vir ocultada, intermediada (por exemplo, [email protected]) ou simplesmente indisponível pelo RDAP. Depender só do RDAP bruto para dados de contato vai gerar listas de leads de qualidade baixíssima ou vazias.
   • Por quê: a Temporary Specification da ICANN para dados de registro de gTLDs e diversas leis nacionais de privacidade determinam a proteção dos dados pessoais. Os registrars cumprem isso ocultando ou mascarando os dados de contato.
   • A correção: trate o RDAP como fonte de metadados técnicos e nada mais. Registrar, datas, name servers e códigos de status são confiáveis; os campos de contato não são. Se o seu projeto precisa alcançar organizações, isso tem de vir das informações que essas organizações publicam por conta própria, coletadas sob a base legal que se aplique à sua jurisdição e ao seu caso de uso. Nenhum produto de dados de domínios, incluindo este, fornece contatos de registrantes, e qualquer fornecedor que alegue extraí-los do RDAP está descrevendo algo que o protocolo não faz.

2. Erro: ignorar as nuances dos códigos de status do RDAP.

   • O que dá errado: o RDAP fornece códigos de status detalhados (por exemplo, clientDeleteProhibited, serverHold, pendingDelete). Interpretá-los mal leva a mirar domínios que não estão ativos, estão em disputa ou prestes a expirar. Abordar comercialmente um domínio em pendingDelete, por exemplo, é perda de tempo.
   • Por quê: esses códigos indicam o estado administrativo atual de um domínio. São essenciais para entender sua disponibilidade e estabilidade.
   • A correção: aprenda o vocabulário de status do EPP que o RDAP reaproveita. clientTransferProhibited é um bloqueio normal e não diz nada de negativo sobre um domínio; serverHold significa que o domínio não está sendo publicado no DNS; pendingDelete significa que ele está no ciclo de exclusão e vai cair em breve; redemptionPeriod significa que ele já expirou e ainda pode ser restaurado pelo registrante. Defina explicitamente quais status a sua análise inclui e registre essa decisão junto com os resultados, para que os números possam ser reproduzidos.

3. Erro: presumir que a atualização dos dados é universal e instantânea.

   • O que dá errado: acreditar que todos os dados RDAP são em tempo real e atualizados simultaneamente em todos os registrars. Embora o RDAP tenha sido projetado para acesso programático, os registrars têm ciclos de atualização diferentes e podem ocorrer atrasos de propagação.
   • Por quê: os dados de registro de domínios passam por várias partes (registrante, registrar, registry). As atualizações nem sempre são instantâneas em todo o ecossistema.
   • A correção: trate cada conjunto de dados e cada consulta como um snapshot com timestamp, e guarde esse timestamp junto com os dados. Os arquivos em massa refletem o estado de uma zona no momento em que a exportação foi gerada; o RDAP reflete o estado de um domínio no momento da consulta. Nenhum dos dois é um feed ao vivo. Para trabalho de tendências isso é uma vantagem, e não uma limitação, já que comparar snapshots datados é justamente o que torna uma tendência mensurável.

4. Erro: desprezar limites de taxa e políticas de uso justo.

   • O que dá errado: consultar agressivamente servidores RDAP, direta ou indiretamente pela API de uma plataforma, sem considerar os limites de taxa pode levar a banimentos de IP, bloqueios temporários ou degradação do serviço. Isso vale ainda mais quando se tenta raspar o RDAP bruto.
   • Por quê: servidores RDAP, como qualquer API pública, são protegidos contra abuso. Até a API da WebTrackly tem limites de taxa para garantir uso justo a todos os clientes.
   • A correção: não tente enumeração em massa pelo RDAP. Reserve as consultas para os casos em que você precisa de detalhe atual e autoritativo sobre um domínio específico, implemente backoff exponencial e respeite os cabeçalhos Retry-After quando fizer isso, e use arquivos em massa para qualquer coisa em escala populacional. Tentar reconstruir uma zona por meio de consultas domínio a domínio é mais lento e menos completo do que simplesmente baixar a zona.

5. Erro: confundir "registrar" com "provedor de hospedagem".

   • O que dá errado: misturar a entidade que registrou o domínio (o registrar, encontrado no RDAP) com a entidade que hospeda o conteúdo do site (o provedor de hospedagem, encontrado por consultas de DNS/IP). Um domínio registrado na GoDaddy pode estar hospedado na AWS, e vice-versa.
   • Por quê: são serviços distintos. O registrar administra o nome de domínio em si, enquanto o provedor de hospedagem serve os arquivos do site.
   • A correção: mantenha os dois atributos em colunas separadas e nunca deduza um a partir do outro. O registrar vem do RDAP. Os provedores de hospedagem e de e-mail são inferidos das colunas de name server, MX e IP de um arquivo em massa. Um arquivo de zona vai mostrar, por exemplo, que um domínio delega para name servers da Cloudflare enquanto seu A-record aponta para um provedor completamente diferente, que é exatamente o tipo de distinção que se perde quando os dois conceitos são fundidos.

6. Erro: ignorar a conformidade legal e ética (GDPR, CCPA, uso aceitável).

   • O que dá errado: usar dados extraídos, sobretudo dados de contato, sem considerar as regulações de privacidade ou as políticas de uso aceitável dos fornecedores de dados. Isso pode levar a sanções legais, dano reputacional e encerramento de conta.
   • Por quê: as leis de privacidade de dados são rígidas. Mesmo que os dados sejam públicos, sua coleta e uso precisam estar em conformidade com regulações como GDPR e CCPA.
   • A correção: saiba qual regime legal se aplica aos dados que você mantém. Domínio, name server, MX, IP e CMS detectado são atributos técnicos de infraestrutura, não dados pessoais sobre indivíduos identificáveis, e é por isso que os arquivos de domínios em massa são comparativamente simples de manusear. No instante em que você os combina com informações sobre pessoas, passa a tratar dados pessoais e todo o peso do GDPR, da CCPA e de regimes equivalentes se aplica. Mantenha essa fronteira visível no seu próprio pipeline, em vez de descobri-la durante uma auditoria.

Evitar esses erros mantém a análise baseada em RDAP defensável: correta sobre o que o protocolo reporta, explícita sobre o que ele omite e honesta quanto à diferença entre um snapshot e uma visão ao vivo.

Perguntas frequentes

P: O que exatamente é o RDAP e em que ele difere do WHOIS?
R: o RDAP (Registration Data Access Protocol) é o substituto moderno e padronizado do ultrapassado protocolo WHOIS. A diferença central é que o RDAP entrega dados estruturados e legíveis por máquina (tipicamente em JSON), enquanto o WHOIS devolve informação em texto livre e inconsistente, que varia muito de registrar para registrar. Esse formato estruturado torna os dados RDAP muito mais fáceis de interpretar, analisar e integrar a sistemas automatizados. O RDAP também oferece recursos de segurança aprimorados e suporte a internacionalização, sendo superior para acesso programático e inteligência de domínios em escala global.

P: Consigo obter nomes, e-mails ou telefones de registrantes pelo RDAP?
R: não, não em nenhuma escala útil. As respostas RDAP de gTLDs vêm ocultadas por padrão pela política da ICANN, e a maioria dos registries devolve um valor intermediário ou vazio nos campos de contato do registrante. A divulgação existe apenas como um processo de solicitação credenciado e limitado a uma finalidade, tratado caso a caso. Os conjuntos de dados da WebTrackly também não contêm contatos pessoais: domínio, data de registro quando publicada, name servers, MX, IP e CMS detectado são toda a extensão do que os arquivos carregam.

P: A WebTrackly oferece consulta domínio a domínio ou interface de busca?
R: não. O produto é um catálogo de pacotes para download. O formato do download varia conforme o pacote e é informado na página do produto. Não há interface para consultar um domínio individual nem busca filtrada sobre as linhas subjacentes; a filtragem acontece do seu lado, depois do download.

P: Quais formatos e formas de entrega estão disponíveis?
R: O formato do download varia conforme o pacote e é informado na página do produto. A exportação é gerada no momento da compra, então reflete o estado atual dos dados, e não um arquivo pré-construído de idade desconhecida. A API devolve os metadados do catálogo em JSON.

P: Qual é o tamanho dos conjuntos de dados?
R: a cobertura é de 285.582.781 domínios em 716 zonas. Só a zona .com responde por 163.422.083 domínios. O conjunto de dados com todos os domínios registrados contém 272.614.863 linhas. As listas por tecnologia são menores e mais focadas: 21.639.326 domínios para WordPress e 567.680 para Joomla.

P: O que a API do catálogo faz?
R: ela expõe o catálogo de pacotes. GET /api/v1/packages/?type=zone lista os pacotes de zona, GET /api/v1/packages/?type=technology&q=wordpress busca nos pacotes por tecnologia e GET /api/v1/packages/{slug}/ devolve o registro de detalhe de um pacote. As requisições são autenticadas com um cabeçalho Authorization: Bearer YOUR_API_KEY. As cotas são de 30.000 chamadas por mês no Pro e 300.000 no Enterprise.

P: Quanto custa?
R: as compras avulsas de pacotes começam em $3.50. Para uso contínuo há dois planos: o Pro, a $29/mês, que cobre 50 pacotes mais 10 conjuntos de dados e 30.000 chamadas de API, e o Enterprise, a $99/mês, que cobre 200 pacotes mais 50 conjuntos de dados e 300.000 chamadas de API. Os detalhes estão na página de preços.

P: Como devo carregar um arquivo tão grande?
R: descompacte e consulte com um motor colunar. O DuckDB lê CSV no lugar e dá conta de um único arquivo de zona tranquilamente em um notebook; o ClickHouse é a melhor escolha quando você quer agregações repetidas em muitas zonas ou na compilação completa entre zonas. Planilhas não são uma opção realista com essa quantidade de linhas.

Conclusão

A passagem do WHOIS para o RDAP é uma melhoria genuína, mas estreita. Ela resolve o problema de formato: os metadados de registro agora chegam em JSON, com schema documentado, semântica HTTP padrão e um registro de bootstrap que diz onde perguntar. Ela não resolve o problema de acesso, e nunca teve essa intenção. Os dados de contato do registrante foram removidos dos registros públicos por decisão de política, e o RDAP reproduz fielmente essa decisão.

O que isso significa na prática é que dados de domínios são dados técnicos. Registrar, datas, name servers, configuração de e-mail, endereços resolvidos e plataformas detectadas são todos reais, comparáveis e disponíveis em escala. Perguntas formuladas nesses termos são respondíveis com precisão. Perguntas que pressupõem um diretório de registrantes não são respondíveis de jeito nenhum, por ferramenta alguma.

Se o seu trabalho precisa de respostas em nível populacional sobre a infraestrutura de domínios, os arquivos em massa são o caminho prático: escolha a zona, a lista por tecnologia ou a compilação de que precisa no catálogo de pacotes, baixe o CSV e analise localmente com as ferramentas que você já controla.

Recursos relacionados

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