“Nenhum servidor RDAP de registro foi identificado”: causas e soluções

Se uma consulta de domínio retorna “nenhum servidor RDAP de registro foi identificado para este domínio”, a consulta nunca chegou a um registro. O cliente RDAP falhou na etapa de bootstrap: não conseguiu mapear o TLD do domínio para uma URL base de RDAP. Este artigo explica por que isso acontece, como funciona o registro bootstrap da IANA, como verificar a causa por conta própria e o que fazer quando um TLD realmente não tem serviço RDAP — inclusive quando um dataset de arquivo de zona é o substituto prático para consultas domínio a domínio.

TL;DR / Principais conclusões

• A mensagem significa que o cliente RDAP não encontrou, no registro bootstrap da IANA, uma URL base para o TLD do domínio. É uma falha de resolução, não uma resposta de “domínio não encontrado”.
• As três causas habituais são: o TLD não tem serviço RDAP algum (a maioria dos ccTLDs), o cliente está usando uma cópia em cache desatualizada do arquivo de bootstrap, ou a entrada não é um TLD real (um erro de digitação, um nome interno ou um hostname isolado).
• Você confirma a causa em uma única requisição: baixe https://data.iana.org/rdap/dns.json e procure o TLD nele.
• A ICANN exige RDAP para os gTLDs sob contrato. Os ccTLDs estão fora desse contrato, então a disponibilidade de RDAP ali é voluntária e irregular; alguns publicam RDAP, outros publicam apenas WHOIS e outros não publicam nenhum dos dois em formato legível por máquina.
• Onde existe RDAP mas não WHOIS, ou vice-versa, uma cadeia de fallback — bootstrap RDAP, depois o endpoint documentado pelo próprio registro e, por fim, WHOIS na porta 43 — resolve a maioria dos casos.
• Quando você precisa saber o que existe em uma zona, e não o registro de um domínio específico, consultas domínio a domínio são a ferramenta errada, independentemente do status do RDAP. Um dataset de arquivo de zona lista os domínios registrados diretamente.
• Arquivos de zona e datasets enriquecidos entregam domínios e infraestrutura (servidores de nomes, MX, IP, CMS detectado). Eles não contêm contatos de titulares, e nenhum dataset deste site contém.

Sumário

1. O que “nenhum servidor RDAP de registro foi identificado” realmente significa
2. Como o bootstrap do RDAP resolve um servidor
3. Diagnosticando a causa em três verificações
4. Fallbacks que funcionam quando o bootstrap falha
5. Quando o objetivo real é enumeração, não consulta
6. O que há de fato nos arquivos
7. O fluxo de trabalho real: comprar, baixar, processar localmente
8. Encontrando pacotes pela API
9. Erros comuns & como evitá-los
10. Perguntas frequentes
11. Conclusão
12. Recursos relacionados

O que “nenhum servidor RDAP de registro foi identificado” realmente significa

A mensagem de erro “nenhum servidor rdap de registro foi identificado para este domínio” é um obstáculo comum e profundamente disruptivo para quem tenta reunir informações sobre domínios. Para entender de verdade suas implicações e a solução da WebTrackly, é preciso primeiro compreender o próprio RDAP. O Registration Data Access Protocol (RDAP) é o sucessor do veterano protocolo WHOIS, projetado para oferecer uma forma mais estruturada, segura e padronizada de acessar dados de registro de domínios. Ele é construído sobre HTTP(S) e usa JSON na transferência de dados, o que o torna mais legível por máquina e mais amigável a desenvolvedores do que seu antecessor.

A ICANN (Internet Corporation for Assigned Names and Numbers) tornou obrigatória a adoção do RDAP para gTLDs (generic Top-Level Domains) como .com, .org, .net e muitos outros. O objetivo é melhorar o acesso aos dados, a privacidade e a internacionalização. A internet, porém, é vasta e descentralizada. Embora os gTLDs em geral cumpram a exigência, muitos ccTLDs (country code Top-Level Domains) como .de (Alemanha) ou .jp (Japão) operam sob registros diferentes e apresentam níveis variados de implementação de RDAP — às vezes nenhuma.

Quando você se depara com “nenhum servidor rdap de registro foi identificado para este domínio”, isso normalmente significa uma entre várias coisas:

1. TLD sem suporte: aquele Top-Level Domain específico (por exemplo, um ccTLD menos conhecido ou um gTLD muito novo) simplesmente não tem servidor RDAP configurado ou reconhecido pelo sistema que faz a consulta. Esse é um problema comum em muitos registros de código de país que não migraram totalmente do WHOIS ou mantêm sistemas proprietários próprios.
2. Falha técnica ou configuração incorreta: o servidor RDAP daquele TLD pode existir, mas estar temporariamente fora do ar, mal configurado ou com problemas de rede, o que leva à falha na consulta.
3. Serviços de privacidade ou proxy de domínio: embora o RDAP tenha sido projetado para respeitar mais a privacidade, alguns domínios usam serviços de proteção que ocultam deliberadamente os dados do titular. Isso não é exatamente um erro de “nenhum servidor RDAP de registro”, mas é um desafio relacionado ao acesso a dados úteis.
4. Convenções de nomenclatura fora do padrão: alguns domínios de nicho ou internos podem não seguir as estruturas padronizadas reguladas pela ICANN, o que os torna invisíveis para resolvedores RDAP convencionais.

A consequência prática é que você não recebe resposta alguma, em vez de um “este domínio não está registrado” com valor de autoridade. Os dois são fáceis de confundir e levam a conclusões muito diferentes: uma falha de bootstrap não diz absolutamente nada sobre a existência do domínio.

As abordagens manuais para contornar isso são tediosas e ineficientes. Você pode testar diferentes clientes WHOIS, vasculhar arquivos de dados históricos ou até recorrer à investigação manual do site. Isso consome horas, muitas vezes rende informações incompletas ou desatualizadas e é completamente inescalável para listas de centenas ou milhares de domínios. Geração de leads e análise de mercado modernas exigem automação e dados abrangentes.

Como o bootstrap do RDAP resolve um servidor

O RDAP não tem servidor central. Cada registro opera o seu, e o cliente precisa descobrir qual deles é autoritativo para um determinado nome. Esse processo de descoberta é definido na RFC 7484 e se chama bootstrapping.

A IANA publica um arquivo de bootstrap para nomes de domínio em https://data.iana.org/rdap/dns.json. É um documento JSON que contém um array services. Cada entrada é um array de dois elementos: uma lista de TLDs e uma lista de URLs base de RDAP que os atendem. Um cliente que resolve example.com pega o rótulo mais à direita, com, procura a entrada de serviço que o contém e emite GET {base_url}domain/example.com contra a URL encontrada.

# Inspect the bootstrap file directly
curl -s https://data.iana.org/rdap/dns.json | head -c 400

# Check whether a specific TLD has an RDAP base URL at all
curl -s https://data.iana.org/rdap/dns.json \
  | python3 -c "import json,sys; d=json.load(sys.stdin); t=sys.argv[1]; \
print([s[1] for s in d['services'] if t in s[0]] or 'NO RDAP SERVICE FOR .'+t)" de

Se esse comando imprimir NO RDAP SERVICE, o erro não é um bug no seu cliente, e nenhuma quantidade de novas tentativas vai mudar isso. O TLD simplesmente não está no registro, que é exatamente a condição descrita pela mensagem.

Dois detalhes adicionais importam. Primeiro, o arquivo traz um timestamp de publication; clientes que fazem cache de forma agressiva podem não enxergar um TLD recém-adicionado por dias. Segundo, a RFC 7484 especifica correspondência pelo rótulo mais longo, então um cliente que ingenuamente compara apenas o último rótulo pode tratar mal nomes sob sufixos de múltiplos rótulos. Ambos produzem a mesma mensagem visível ao usuário, por razões diferentes.

Diagnosticando a causa em três verificações

1. O sufixo é um TLD real? Compare-o com a lista de TLDs da IANA em https://data.iana.org/TLD/tlds-alpha-by-domain.txt. Nomes internos (.local, .internal, .corp), erros de digitação e hostnames enviados com prefixo de subdomínio são os alarmes falsos mais comuns.
2. O TLD está no arquivo de bootstrap? Use o comando acima. A ausência é a resposta definitiva: não há servidor RDAP a identificar.
3. A cópia do seu cliente está atualizada? Force um novo download do dns.json e tente de novo. Muitas bibliotecas e wrappers de CLI guardam o arquivo de bootstrap em disco e nunca o expiram. Se um download novo resolve o TLD mas a sua ferramenta não, a culpa é do cache.

Executar essas três verificações nessa ordem distingue um problema de entrada de um problema de cliente e de uma lacuna real do registro — e cada um tem uma correção diferente.

Fallbacks que funcionam quando o bootstrap falha

O Registry Agreement da ICANN e a exigência do Registration Data Access Protocol se aplicam aos gTLDs. Os operadores de ccTLD não são parte desse acordo, então suas políticas de dados de registro são definidas nacionalmente. É por isso que .com, .org, .app e os gTLDs mais recentes resolvem sem atrito, enquanto uma longa cauda de zonas de código de país não.

Uma cadeia de fallback que dá conta da maioria dos casos reais:

1. Bootstrap da IANA. O caminho padrão; use-o primeiro.
2. O endpoint RDAP documentado pelo próprio registro. Alguns registros operam RDAP, mas não constam do arquivo de bootstrap. As páginas de TLD da IANA em https://www.iana.org/domains/root/db/<tld>.html indicam a organização patrocinadora e seu serviço de dados de registro.
3. WHOIS na porta 43. Consulte whois.iana.org pelo próprio TLD para descobrir o host WHOIS autoritativo e, em seguida, consulte esse host pelo domínio. A saída é texto não estruturado, então preveja parsing específico para cada registro.
4. DNS como verificação de existência. Uma consulta NS não substitui os dados de registro, mas um conjunto de registros NS delegados é forte indício de que o domínio está registrado — muitas vezes o único fato de que você realmente precisava.

# Find the authoritative WHOIS host for a ccTLD, then query the domain
whois -h whois.iana.org de
whois -h whois.denic.de example.de

# Existence check via delegation
dig +short NS example.de

Nada disso recupera os dados de contato do titular. A maioria dos registros os oculta por política, e o RDAP foi projetado para tornar essa ocultação explícita, não para expor mais informações.

Quando o objetivo real é enumeração, não consulta

Boa parte do tráfego que chega a esse erro não está tentando consultar um único domínio. Está tentando responder a uma pergunta populacional: quais domínios existem neste TLD, quais deles rodam determinado CMS, quais apontam para um provedor de e-mail específico. RDAP domínio a domínio é um instrumento ruim para isso mesmo onde funciona — seria preciso uma requisição por nome, e os registros aplicam limites de taxa à altura.

Para essa classe de pergunta, a fonte da verdade é o arquivo de zona, não o registro de cadastro. Um arquivo de zona lista os nomes delegados em um TLD. Ele não contém nenhuma informação sobre o titular, que é precisamente o motivo pelo qual pode ser publicado em massa.

A WebTrackly distribui esses dados como um catálogo de 1,538 pacotes:

• 716 arquivos de zona de TLD — a lista de domínios delegados de cada zona coberta.
• 716 conjuntos enriquecidos por zona — os mesmos domínios com servidores de nomes, registros MX, IP resolvido e CMS detectado.
• 79 listas de sites por CMS ou tecnologia — por exemplo, WordPress com 21,639,326 domínios e Joomla com 567,680.
• 27 datasets selecionados — incluindo o dataset de todos os domínios registrados, com 272,614,863 linhas.

A cobertura entre as zonas soma 285,582,781 domínios, dos quais .com sozinho responde por 163,422,083. Navegue pelo catálogo em /packages/, pelas zonas em /zones/ e pelos conjuntos selecionados em /datasets/.

O que há de fato nos arquivos

O formato do download varia conforme o pacote e é informado na página do produto. As colunas dependem do tipo de pacote:

• Arquivos de zona: o nome do domínio e a data de registro, quando o registro a publica. Muitos não publicam, e o campo fica vazio em vez de estimado.
• Conjuntos enriquecidos por zona: domínio, servidores de nomes (ns), servidores de e-mail (mx), endereço IP resolvido e CMS detectado, quando identificável.
• Listas de tecnologia e CMS: os domínios nos quais aquela tecnologia foi detectada.

O que os arquivos não contêm, em nenhum pacote, é igualmente importante deixar claro:

• Nenhum nome de titular, endereço postal, e-mail ou telefone.
• Nenhum cadastro de empresa, cargo ou identificador pessoal.
• Nenhum sinal de intenção, tráfego ou receita.
• Nenhuma consulta interativa por domínio — o produto são arquivos em massa, não uma interface de consulta sobre nomes individuais.

Se o seu fluxo de trabalho depende de contatos dos titulares, estes dados não os fornecem — e o RDAP também não, para a grande maioria dos domínios, já que a ocultação hoje é o padrão nos gTLDs.

O fluxo de trabalho real: comprar, baixar, processar localmente

1. Escolha um pacote. Selecione a zona, a lista de tecnologia ou o dataset selecionado que corresponde à sua pergunta. Os preços começam em $3.50 na compra avulsa; veja /pricing/.
2. Compre. A exportação é gerada na hora da compra, então o arquivo reflete o estado do catálogo naquele momento, e não um snapshot pré-montado de idade desconhecida.
3. Baixe. O formato do download varia conforme o pacote e é informado na página do produto.
4. Processe localmente. Os arquivos são grandes o bastante para que uma planilha seja a ferramenta errada. Utilitários Unix dão conta da filtragem; um motor analítico embarcado dá conta de junções e agregações.

unzip -o zone_example.zip -d ./data

# Count rows and inspect the header
wc -l ./data/*.csv
head -3 ./data/*.csv

# Filter by a nameserver operator without loading the file into memory
grep -F ',ns1.example-dns.net,' ./data/enriched.csv > ./data/subset.csv

-- DuckDB reads the CSV directly; no import step, no server
SELECT mx, count(*) AS domains
FROM read_csv_auto('./data/enriched.csv')
WHERE cms = 'WordPress'
GROUP BY mx
ORDER BY domains DESC
LIMIT 25;

Para análises repetidas em várias zonas, carregar os CSVs no ClickHouse e consultá-los como uma única tabela compensa o tempo de configuração. Para uma única pergunta sobre uma única zona, o DuckDB direto sobre o CSV chega mais rápido à resposta.

Encontrando pacotes pela API

A API serve o catálogo: ela informa quais pacotes existem e o que cada um cobre. Não é um endpoint de busca de domínios, e não existe consulta por domínio. Autentique-se com um bearer token.

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

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

# Fetch details for one package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

Os planos de assinatura incluem cotas de chamadas de API: o Pro, a $29/mês, cobre 50 pacotes e 10 datasets com 30,000 chamadas de API; o Enterprise, a $99/mês, cobre 200 pacotes e 50 datasets com 300,000 chamadas de API. A documentação completa está em /api/.

Erros comuns & como evitá-los

1. Ler a falha de bootstrap como “o domínio não existe”.

   • O que dá errado: um pipeline marca nomes como não registrados porque a chamada RDAP falhou, e a lógica seguinte age com base nisso.
   • A correção: trate a falha de bootstrap como um resultado desconhecido, com código de status próprio, distinto de uma resposta negativa autoritativa. Confirme a existência à parte, com uma verificação de delegação no DNS.

2. Manter o arquivo de bootstrap em cache indefinidamente.

   • O que dá errado: um TLD que ganhou suporte a RDAP meses atrás continua falhando localmente porque o dns.json em cache é anterior a isso.
   • A correção: atualize o arquivo em uma rotina programada e respeite o campo publication. Uma atualização diária é suficiente.

3. Construir uma estratégia de ccTLD apoiada só em RDAP.

   • O que dá errado: premissas de cobertura tiradas do comportamento dos gTLDs falham nas zonas de código de país, produzindo lacunas silenciosas no dataset.
   • A correção: mantenha um mapa explícito, por TLD, de qual protocolo está disponível — RDAP, WHOIS ou nenhum — e roteie as consultas de acordo, em vez de insistir em um protocolo que nunca foi oferecido.

4. Usar consultas domínio a domínio para responder a perguntas populacionais.

   • O que dá errado: milhões de requisições sequenciais, limites de taxa, endereços de origem bloqueados e semanas de execução para algo que um único arquivo responde.
   • A correção: use dados no nível da zona quando a pergunta for sobre uma zona, e reserve as consultas domínio a domínio para o pequeno conjunto de nomes que realmente precisa de um registro de cadastro atual.

5. Esperar contatos de titulares de qualquer uma dessas fontes.

   • O que dá errado: um projeto é dimensionado em torno de dados de contato que as políticas de ocultação e os formatos de dados em massa não fornecem, e trava assim que isso fica claro.
   • A correção: dimensione em torno do que é de fato publicado — o domínio, sua delegação, sua infraestrutura de e-mail e hospedagem e sua stack de software detectada.

6. Fazer parsing do texto WHOIS como se fosse um formato único.

   • O que dá errado: um parser escrito para a saída de um registro atribui campos errados silenciosamente na saída de outro, já que o WHOIS na porta 43 não tem esquema.
   • A correção: prefira o JSON do RDAP onde ele existir e trate o formato de cada servidor WHOIS como um alvo de parsing separado, com testes próprios.

Perguntas frequentes

P: Esse erro significa que o domínio não está registrado?
R: Não. Significa que o cliente não conseguiu determinar a qual servidor RDAP perguntar. Depois desse erro, o status de registro do domínio é desconhecido, não negativo. Uma consulta DNS pelos registros NS do domínio é uma verificação independente e rápida de se ele está delegado.

P: Por que tantos ccTLDs falham?
R: A exigência de RDAP da ICANN decorre do Registry Agreement dos gTLDs, do qual os operadores de ccTLD não são parte. Seus serviços de dados de registro seguem políticas nacionais, então alguns publicam RDAP, outros publicam apenas WHOIS na porta 43 e outros não publicam nenhum dos dois em formato legível por máquina.

P: Dá para resolver trocando de cliente RDAP?
R: Só se a causa for um cache desatualizado ou uma implementação ruim da correspondência pelo rótulo mais longo. Se o TLD estiver ausente do dns.json, todo cliente em conformidade vai falhar da mesma forma.

P: O que os pacotes da WebTrackly contêm?
R: O formato do download varia conforme o pacote e é informado na página do produto. Os pacotes de zona listam os domínios de um TLD, mais a data de registro quando o registro a publica. Os pacotes enriquecidos acrescentam servidores de nomes, registros MX, IP resolvido e CMS detectado. Os pacotes de tecnologia listam os domínios nos quais determinada tecnologia foi detectada.

P: Os arquivos incluem e-mails ou telefones dos titulares?
R: Não. Nenhum pacote contém dados de contato pessoais de qualquer tipo, e não há interface de consulta por domínio. Os dados descrevem domínios e sua infraestrutura.

P: Quão atual é um arquivo baixado?
R: A exportação é gerada no momento da compra, a partir dos dados atuais do catálogo, ou seja, você não baixa um arquivo pré-montado de idade desconhecida.

P: Como funciona a precificação?
R: As compras avulsas de pacotes começam em $3.50. As assinaturas são Pro a $29/mês (50 pacotes e 10 datasets, 30,000 chamadas de API) e Enterprise a $99/mês (200 pacotes e 50 datasets, 300,000 chamadas de API). Detalhes em /pricing/.

P: O que a API faz?
R: Ela expõe o catálogo de pacotes — lista e filtra pacotes por tipo, faz buscas entre eles e recupera os detalhes de um pacote específico pelo slug. Ela não realiza consultas de domínio.

Conclusão

“Nenhum servidor RDAP de registro foi identificado para este domínio” é uma falha de resolução no bootstrap com três causas corriqueiras: uma entrada que não é um TLD real, um arquivo de bootstrap em cache desatualizado ou um TLD sem serviço RDAP. Uma requisição a https://data.iana.org/rdap/dns.json revela qual das três você tem em mãos, e cada uma tem uma correção distinta — corrigir a entrada, atualizar o cache ou recorrer ao host WHOIS documentado pelo registro.

Se o objetivo de fundo nunca foi um único registro de cadastro, mas um inventário do que existe em uma zona, o protocolo era o instrumento errado desde o início. Um dataset de arquivo de zona responde a essa pergunta diretamente, em um único arquivo, com os domínios e sua infraestrutura — e sem os contatos de titulares que nem o RDAP nem os dados em massa vão lhe dar.

Trabalhando com dados no nível da zona?
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 — mais de 1,500 bancos de dados de domínios para download
• Arquivos de zona por TLD — .com, .net, .de e mais de 700
• Datasets selecionados — todos os domínios registrados, servidores MX, e-commerce
• Preços — compras avulsas a partir de $3.50