"No Registry RDAP Server": Como Obter Dados de Domínio Mesmo Assim

Mais cedo ou mais tarde, todo projeto de dados de domínio esbarra na mesma mensagem: "no registry rdap server was identified for this domain." Não é um bug no seu script. Significa que a ferramenta não conseguiu encontrar um endpoint RDAP para aquele TLD, e nenhuma quantidade de novas tentativas vai resolver isso. Este guia explica por que o erro acontece, quais partes do espaço de nomes de domínios ele afeta e como montar um conjunto de dados utilizável a partir de arquivos de zona e enriquecimento em massa, em vez de consultas ao vivo domínio a domínio.

RESUMO / PONTOS PRINCIPAIS

• O erro é uma lacuna de protocolo, não uma falha de rede: a adoção do RDAP é obrigatória para gTLDs, mas opcional para a maioria dos ccTLDs, de modo que boa parte do espaço de nomes simplesmente não tem um servidor RDAP para consultar.
• Consultas ao vivo não escalam: os registries aplicam limites de taxa agressivos, ocultam campos do titular por causa do GDPR e respondem um domínio por vez. Esse modelo quebra muito antes de você chegar a um milhão de domínios.
• Arquivos em massa são a alternativa prática: os arquivos de zona listam diretamente os domínios registrados em um TLD, sem consulta por domínio e sem dependência de RDAP.
• A WebTrackly distribui arquivos em massa, não um serviço de consulta: 1.538 pacotes — 716 arquivos de zona por TLD, 716 conjuntos de zona enriquecidos (NS, MX, IP, CMS detectado), 79 listas de sites por tecnologia e 27 conjuntos de dados selecionados.
• Escala da cobertura: 285.582.781 domínios nos pacotes de zona, incluindo 163.422.083 em .com; o conjunto de dados com todos os domínios registrados tem 272.614.863 linhas.
• O que os arquivos contêm: nomes de domínio, servidores de nomes, registros MX, IPs resolvidos e o CMS detectado, quando disponível. Não contêm dados pessoais de contato — sem e-mails, sem telefones, sem nomes de titulares.
• A entrega é um download: O formato do download varia conforme o pacote e é informado na página do produto. O processamento acontece na sua máquina, com as ferramentas que você já usa.

ÍNDICE

1. Por que "No Registry RDAP Server" acontece
2. Cinco usos em que dados de domínio em massa realmente funcionam
3. Como são os arquivos e como se comparam às consultas ao vivo
4. Trabalhando com os dados: comprar, baixar, processar localmente
5. Erros comuns na aquisição de dados de domínio
6. Perguntas frequentes
7. Conclusão
8. Recursos relacionados

Por que "No Registry RDAP Server" acontece

O RDAP (Registration Data Access Protocol) é o sucessor estruturado do WHOIS, baseado em JSON. Em vez de interpretar texto livre, o cliente identifica o servidor autoritativo de um TLD e recebe uma resposta tipada. É justamente na etapa de identificação que tudo trava: o cliente RDAP consulta o registro de bootstrap da IANA e, se o TLD não tiver entrada ali, não há para onde enviar a consulta. É exatamente isso que a mensagem "no registry rdap server was identified for this domain" está informando.

A lacuna é estrutural. A ratificação do RDAP pela ICANN exige o serviço RDAP dos registries de gTLD e dos registrars credenciados, mas os ccTLDs operam sob política nacional e estão fora desse contrato. Muitos mantêm apenas WHOIS, alguns oferecem um formulário web com CAPTCHA e outros não publicam nada legível por máquina. Assim, o mesmo script que devolve um objeto JSON limpo para example.com devolve o erro de RDAP para uma longa cauda de domínios de código de país — e essa cauda não é pequena.

Mais duas restrições pesam mesmo quando existe um servidor RDAP. Primeiro, os limites de taxa: os registries protegem um serviço pensado para consultas ocasionais, e um volume sustentado de consultas em massa leva ao throttling ou ao bloqueio do seu IP. Segundo, a supressão de dados: depois do GDPR, nome, e-mail e endereço postal do titular ficam de fora das respostas públicas na maioria dos domínios, ou seja, os campos que as pessoas geralmente esperam extrair simplesmente não estão lá. O RDAP é excelente para informar o status, as datas e os servidores de nomes de um domínio que você já tem em vista. Ele nunca foi projetado como mecanismo de descoberta.

Descoberta é outro problema, com outra fonte de dados: os arquivos de zona. Um arquivo de zona é a própria lista do registry com os domínios delegados em um TLD e seus registros de servidor de nomes. Não exige consulta por domínio, não é afetado pelas lacunas do bootstrap do RDAP e é o único método que entrega um denominador real, e não uma amostra. Se a sua pergunta é "quais domínios existem neste TLD e qual é a infraestrutura deles", um arquivo de zona responde direto; o RDAP nunca vai responder, por mais tentativas que você programe.

A WebTrackly foi construída em torno dessa distinção. O catálogo tem 1.538 pacotes para download: 716 arquivos de zona por TLD, 716 conjuntos enriquecidos cobrindo as mesmas zonas com servidores de nomes, registros MX, IPs resolvidos e CMS detectado, 79 listas de sites agrupadas por tecnologia e 27 conjuntos de dados selecionados. Somados, os pacotes de zona cobrem 285.582.781 domínios, sendo 163.422.083 deles em .com. O formato do download varia conforme o pacote e é informado na página do produto.

Precisa da lista de domínios, e não de uma consulta isolada?
Explore o catálogo de dados de domínio — arquivos de zona e conjuntos de zona enriquecidos com NS, MX, IP e CMS.
Ver bancos de dados → | Ver preços →

Cinco usos em que dados de domínio em massa realmente funcionam

Dados de zona e de enriquecimento em massa respondem perguntas em nível de população. Eles mostram quantos domínios existem, o que roda neles e onde resolvem. Não dizem para quem enviar e-mail — isso é outra categoria de dado, e não está nesses arquivos. Os casos de uso abaixo são os que os dados realmente sustentam.

1. Dimensionamento de mercado por tecnologia

• Para quem é: fundadores de SaaS, gerentes de produto e analistas que precisam dimensionar um mercado endereçável.
• O problema: os números de adoção publicados por fornecedores costumam vir de uma amostra dos N sites mais populares, o que superestima sistematicamente as ferramentas corporativas e subestima a cauda longa.
• Como os dados em massa ajudam: o campo de detecção de CMS nos conjuntos de zona enriquecidos e as listas de sites por tecnologia entregam contagens absolutas contra um denominador conhecido. O WordPress aparece em 21.639.326 domínios do catálogo; o Joomla, em 567.680. São contagens sobre a população de zonas rastreada, não uma extrapolação a partir de uma amostra de sites famosos.
• Como interpretar: sempre informe o denominador junto da contagem. "21,6 milhões de domínios com WordPress em 279,9 milhões cobertos" é uma afirmação defensável; "o WordPress move X% da web" não é, a menos que você saiba dizer exatamente qual web foi medida.

2. Análise de infraestrutura e hospedagem

• Para quem é: provedores de hospedagem, fornecedores de CDN e analistas de infraestrutura.
• O problema: a participação de mercado em hospedagem é quase sempre chute, porque ninguém publica número de clientes.
• Como os dados em massa ajudam: os conjuntos enriquecidos trazem o servidor de nomes e o IP resolvido de cada domínio. Agrupar pelo sufixo do NS aproxima o provedor de DNS; mapear IPs para os ASNs que os anunciam aproxima a rede de hospedagem. Os dois são diretamente contáveis em uma zona inteira.
• Ressalva importante: uma CDN na frente da origem mascara o IP de origem. Trate as participações de hospedagem derivadas de IP como uma medida da borda, não do lugar onde o servidor fisicamente está.

3. Pesquisa de infraestrutura de e-mail

• Para quem é: times de entregabilidade, pesquisadores de segurança de e-mail e analistas antiabuso.
• O problema: perguntas como "que fatia deste TLD usa Google Workspace, Microsoft 365 ou e-mail próprio" não têm resposta pública.
• Como os dados em massa ajudam: os registros MX estão incluídos nos conjuntos de zona enriquecidos. Classificar os hostnames de MX por padrão de provedor transforma a zona inteira em uma distribuição que você pode plotar, e repetir o exercício em um snapshot posterior revela a migração entre provedores.
• O que isso não entrega: um registro MX é um destino de roteamento de correio, não uma caixa postal. Não há endereços nesses arquivos.

4. Pesquisa de segurança e medição de superfície de ataque

• Para quem é: pesquisadores de segurança, times de CERT e analistas de inteligência de ameaças.
• O problema: um reconhecimento que depende de RDAP ou WHOIS ao vivo trava de imediato — limites de taxa e o erro de servidor RDAP ausente tornam impossível cobrir a zona inteira.
• Como os dados em massa ajudam: comece pela lista da zona, e não por consultas. Filtre localmente a população que interessa (um CMS, um servidor de nomes, uma faixa de IP) e depois direcione suas próprias ferramentas de varredura ou verificação para esse subconjunto. A lista de domínios é a entrada da sua análise, não a análise em si.
• Nota de responsabilidade: qualquer teste ativo precisa ficar dentro do escopo que você está autorizado a testar. Uma lista de domínios para download não é autorização.

5. Criar e manter o seu próprio conjunto de dados

• Para quem é: engenheiros e cientistas de dados que precisam de uma tabela-base em nível de domínio.
• O problema: construir seu próprio crawler para cobertura em escala de zona significa resolvers, novas tentativas, armazenamento, deduplicação e manutenção constante — um projeto e tanto antes de responder à primeira pergunta.
• Como os dados em massa ajudam: um pacote de zona já é um CSV plano com uma linha por domínio. Carregue no DuckDB, ClickHouse ou Postgres, junte com suas tabelas internas e baixe um snapshot novo quando precisar comparar. Cada pacote é gerado no momento da compra, então uma nova compra entrega um snapshot atual para confrontar com o anterior.
• Dica prática: guarde e date todos os snapshots que baixar. A mudança ao longo do tempo é o que esses dados produzem de mais valioso, e só dá para calculá-la se você tiver mantido o arquivo antigo.

Como são os arquivos e como se comparam às consultas ao vivo

Vale ser concreto em dois pontos: o formato dos dados que você recebe e como isso difere do que uma consulta RDAP ou WHOIS ao vivo devolve.

Tabela 1: exemplos de linhas de um pacote de zona enriquecido

O formato do download varia conforme o pacote e é informado na página do produto. Um pacote de arquivo de zona contém a lista de domínios; um pacote enriquecido acrescenta as colunas de resolução e detecção mostradas abaixo. Os campos são preenchidos quando foi possível determiná-los e ficam vazios caso contrário.

É exatamente isso, e nada além. Não há coluna de contato, de empresa ou de titular, porque os dados pessoais de registro são suprimidos na fonte para a maioria dos domínios e não é algo que esses pacotes tentem reconstruir. Se o seu fluxo de trabalho parte do princípio de que um endereço de e-mail virá junto com o domínio, este é o momento de redesenhar o fluxo.

Tabela 2: arquivos em massa x RDAP/WHOIS ao vivo x scanners ao vivo

São abordagens complementares, não substitutas. O RDAP continua sendo a ferramenta certa quando você precisa do status autoritativo de um domínio específico. Um scanner ao vivo é a ferramenta certa quando você precisa de uma impressão digital tecnológica profunda de um site agora. Os arquivos em massa são a ferramenta certa quando a pergunta é sobre uma população — e são, dos três, os únicos imunes ao problema do servidor RDAP ausente, porque nunca executam uma consulta.

Trabalhando com os dados: comprar, baixar, processar localmente

Não há interface de busca para filtrar nem consulta do lado do servidor para executar. O fluxo é: escolher um pacote, comprá-lo, baixar o ZIP e fazer a filtragem na sua própria máquina.

Passo 1: encontre o pacote

Explore /zones/ para arquivos de zona por TLD e conjuntos de zona enriquecidos, /datasets/ para as coleções selecionadas e /packages/ para o catálogo completo, incluindo as listas de sites por tecnologia. Cada item informa a contagem de linhas antes da compra, então você sabe o tamanho do que está comprando.

Passo 2: compre e baixe

Os pacotes começam em $3.50 e o download é imediato. O arquivo é exportado na hora da compra, então o snapshot reflete o estado do catálogo naquele momento, e não uma build antiga. Os planos por assinatura cobrem uso recorrente: o Pro, a $29/month, inclui 50 pacotes e 10 conjuntos de dados com 30.000 chamadas de API; o Enterprise, a $99/month, inclui 200 pacotes e 50 conjuntos de dados com 300.000 chamadas de API. Os detalhes estão em /pricing/.

Passo 3: descompacte e inspecione

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

Passo 4: filtre com ferramentas de linha de comando para cortes rápidos

# domains whose detected CMS is WordPress
awk -F',' '$5 == "WordPress"' com-enriched.csv > wordpress.csv

# domains on Google Workspace mail
grep -i 'google.com' com-enriched.csv | cut -d',' -f1 > gsuite-domains.txt

# name server distribution, top 20
cut -d',' -f2 com-enriched.csv | sort | uniq -c | sort -rn | head -20

Passo 5: use um motor colunar para qualquer análise

Quando você passar a cruzar arquivos ou agregar centenas de milhões de linhas, migre para DuckDB ou ClickHouse. O DuckDB lê o CSV diretamente, sem etapa de importação:

-- CMS distribution across the zone
SELECT cms, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE cms IS NOT NULL
GROUP BY cms
ORDER BY domains DESC;

-- domains present in this month's snapshot but not last month's
SELECT n.domain
FROM read_csv_auto('com-2026-07.csv') n
LEFT JOIN read_csv_auto('com-2026-06.csv') o USING (domain)
WHERE o.domain IS NULL;

Essa segunda consulta é a que vale virar hábito. Um snapshot isolado descreve um estado; dois snapshots descrevem uma mudança — e é na mudança que está o sinal.

Passo 6: automatize o acesso ao catálogo pela API

A API expõe o catálogo de pacotes — o que existe, quanto custa, quantas linhas tem — para que você possa automatizar a descoberta e os downloads. Ela não é um endpoint de consulta de domínios.

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

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

# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

A referência completa dos endpoints está em /api/. Um padrão comum é uma rotina agendada que lista os pacotes que você acompanha, verifica se há uma build mais recente, baixa o arquivo e o carrega no seu data warehouse ao lado do snapshot anterior.

Erros comuns na aquisição de dados de domínio

1. Tratar consultas ao vivo como fonte de dados em massa.

   • O que dá errado: limites de taxa, timeouts e o erro de servidor RDAP ausente transformam um trabalho de 500.000 domínios em um script que nunca termina e produz resultados parciais nos quais você não pode confiar.
   • Por quê: RDAP e WHOIS são protocolos por domínio, com expectativas de serviço por domínio. O uso em massa está fora de escopo por design.
   • A correção: obtenha a população a partir de um arquivo de zona e use consultas apenas para o pequeno subconjunto em que você realmente precisa do status autoritativo por domínio.

2. Esperar dados de contato em dados de domínio.

   • O que dá errado: o pipeline é desenhado em torno de uma coluna de e-mail que nunca chega, e o projeto empaca na última etapa.
   • Por quê: os campos de contato do titular são suprimidos das respostas públicas de WHOIS e RDAP desde o GDPR na maioria dos domínios. Conjuntos de dados de domínio em massa, incluindo estes, trazem atributos de infraestrutura, não dados pessoais.
   • A correção: defina desde o início se você precisa de um conjunto de dados em nível de domínio ou de um conjunto de dados de contatos. São produtos diferentes, com bases legais diferentes; não presuma que um vai gerar o outro.

3. Trabalhar com um único snapshot.

   • O que dá errado: você consegue descrever o estado atual, mas não mostrar tendência alguma — que costuma ser justamente a pergunta que aparece.
   • Por quê: mudança exige duas observações. Um arquivo sozinho não produz delta.
   • A correção: arquive e date todo download. Comparar dois snapshots revela novos registros, domínios que caíram e migrações entre provedores de hospedagem ou de e-mail.

4. Ler a detecção de CMS como certeza.

   • O que dá errado: a análise informa um número preciso que um concorrente, com um método de detecção ligeiramente diferente, contradiz.
   • Por quê: a detecção é baseada em impressão digital. Front-ends headless, cache agressivo e transformações de CDN escondem a plataforma subjacente, e um campo de CMS vazio significa "não detectado", não "sem CMS".
   • A correção: informe a taxa de detecção junto de cada percentual e deixe explícito que os números descrevem instalações detectadas.

5. Presumir que o IP resolvido identifica o host.

   • O que dá errado: os números de participação de mercado em hospedagem saem dominados por um punhado de redes de CDN.
   • Por quê: quando um site está atrás de uma CDN ou de um proxy reverso, o A-record publicado pertence à rede de borda, não ao servidor de origem.
   • A correção: separe "provedor de borda/CDN" de "host de origem" no seu modelo e use os dados de servidor de nomes como um segundo sinal, independente.

6. Subaproveitar os registros NS e MX.

   • O que dá errado: a análise para no campo de CMS e as colunas mais ricas ficam sem exame.
   • Por quê: NS e MX são baratos de interpretar e incomumente estáveis — as organizações trocam de CMS com muito mais frequência do que de provedor de DNS ou de e-mail.
   • A correção: construa uma vez as regras de classificação de provedores sobre os hostnames de NS e MX e reutilize-as em todas as zonas que você baixar.

Perguntas frequentes

P: Por que recebo "no registry rdap server was identified for this domain" em alguns TLDs e em outros não?
R: o serviço RDAP é contratualmente obrigatório para gTLDs, mas opcional para ccTLDs, que seguem política nacional. Se um TLD não tem entrada no registro de bootstrap da IANA, o cliente RDAP não consegue determinar para onde enviar a consulta e informa exatamente esse erro. É uma lacuna na adoção do protocolo, não uma falha do seu cliente.

P: A WebTrackly faz consultas RDAP ou WHOIS para mim?
R: não. A WebTrackly distribui arquivos em massa já preparados. O formato do download varia conforme o pacote e é informado na página do produto. Não existe serviço de consulta por domínio.

P: O que vem, de fato, em um pacote?
R: os pacotes de arquivo de zona contêm a lista de domínios de um TLD. Os pacotes de zona enriquecidos acrescentam servidores de nomes, registros MX, IPs resolvidos e o CMS detectado, quando foi possível determiná-los. Os pacotes de tecnologia são listas de sites nos quais um determinado CMS ou tecnologia foi detectado. Os conjuntos de dados selecionados são compilações entre zonas, sendo o maior deles o de todos os domínios registrados, com 272.614.863 linhas.

P: Endereços de e-mail ou telefones estão incluídos?
R: não. Os pacotes contêm apenas atributos de domínio e de infraestrutura. Não há dados de contato pessoais ou corporativos em nenhum arquivo.

P: Qual é o tamanho da cobertura?
R: 1.538 pacotes no total — 716 arquivos de zona, 716 conjuntos de zona enriquecidos, 79 listas de sites por tecnologia e 27 conjuntos de dados selecionados. Juntos, os pacotes de zona cobrem 285.582.781 domínios, dos quais 163.422.083 são .com. O WordPress é detectado em 21.639.326 domínios e o Joomla em 567.680.

P: Quão atualizados são os dados?
R: cada pacote é exportado no momento da compra, então você recebe a build atual, e não um arquivo preparado meses antes. Para acompanhar mudanças, compre o mesmo pacote novamente mais adiante e compare os dois snapshots.

P: O que a API faz?
R: ela expõe o catálogo. GET /api/v1/packages/?type=zone lista os pacotes de zona, ?type=technology&q=wordpress filtra pacotes de tecnologia por palavra-chave e /api/v1/packages/{slug}/ devolve os detalhes de um pacote. A autenticação é por bearer token. A API não aceita um nome de domínio para devolver informações sobre ele.

P: Quanto custa?
R: pacotes individuais começam em $3.50, em compra única. O Pro custa $29/month por 50 pacotes e 10 conjuntos de dados com 30.000 chamadas de API; o Enterprise custa $99/month por 200 pacotes e 50 conjuntos de dados com 300.000 chamadas de API. Veja /pricing/.

P: Como isso se compara ao BuiltWith ou ao Wappalyzer?
R: essas ferramentas fazem a impressão digital de sites individuais em profundidade e são a melhor escolha para analisar uma propriedade em detalhe. Os pacotes em massa cobrem zonas inteiras com menos profundidade por domínio, que é o que perguntas em nível de população exigem. São respostas para perguntas diferentes.

Conclusão

"No registry rdap server was identified for this domain" é uma característica permanente do espaço de nomes, não uma indisponibilidade temporária. A cobertura do RDAP é desigual por design, os campos do titular são suprimidos e protocolos por domínio não respondem perguntas em nível de população, por mais scripts que se escrevam.

A resposta prática é trocar a fonte de dados, e não a lógica de novas tentativas. Arquivos de zona e conjuntos de zona enriquecidos entregam a lista de domínios, seus servidores de nomes, seu roteamento de e-mail, seus endereços resolvidos e, quando detectável, seu CMS — em CSV plano, que você processa localmente com grep, DuckDB ou ClickHouse. Eles não contêm dados de contato, e saber disso de antemão é o que impede um projeto de falhar na etapa final.

Explorar o catálogo de dados de domínio →

Recursos relacionados

• Catálogo de pacotes — 1.538 bancos de dados de domínio para download
• Arquivos de zona por TLD — .com, .net, .de e mais de 700 outros
• Conjuntos de dados selecionados — todos os domínios registrados, servidores MX, e-commerce
• Documentação da API — acesso ao catálogo com bearer token
• Preços — compras únicas a partir de $3.50