RDAP vs WHOIS: o guia completo da transição (códigos EPP, LGPD/RGPD, bloqueio de domínio)
Por CaptainDNS
Publicado em 17 de março de 2026
- O WHOIS (porta 43) não é mais obrigatório desde 28 de janeiro de 2025 para os gTLDs. 374 TLDs já o desativaram.
- O RDAP (RFC 9082/9083) é o substituto: respostas JSON estruturadas, HTTPS nativo, acesso diferenciado compatível com o RGPD.
- Os códigos EPP (como
clientTransferProhibited) indicam o estado de proteção do seu domínio. Um domínio sem bloqueio de transferência está vulnerável a roubo. - Verifique seus domínios críticos com uma ferramenta RDAP: status EPP, datas de expiração, bloqueios ativos.
Em 2025, consultar um servidor WHOIS é como enviar um fax: o protocolo ainda funciona, mas pertence a outra época. Desde 28 de janeiro de 2025, a ICANN não exige mais que os registros gTLD mantenham um serviço WHOIS na porta 43. O RDAP (Registration Data Access Protocol) é agora o único protocolo obrigatório para acessar dados de registro de domínios.
Este guia cobre a transição completa: por que o WHOIS foi substituído, como funciona o RDAP, o que significam os códigos EPP exibidos nos resultados, como o RGPD transformou o acesso aos dados de contato e os bloqueios a ativar para proteger seus domínios.
Teste seus domínios agora
WHOIS: 40 anos de serviço, depois a aposentadoria
Da RFC 812 (1982) ao fim oficial (2025)
O WHOIS foi formalizado em 1982 pela RFC 812, numa época em que a Internet contava apenas algumas centenas de hosts. O protocolo é minimalista: o cliente abre uma conexão TCP na porta 43, envia um nome de domínio em texto simples e recebe uma resposta em texto livre. Sem formato padronizado, sem criptografia, sem autenticação.
Durante 40 anos, o WHOIS cumpriu seu papel: identificar os responsáveis por um domínio. Mas suas limitações técnicas se tornaram problemas críticos à medida que a Internet crescia.
Linha do tempo ICANN do sunset WHOIS
A ICANN planejou a transição ao longo de vários anos:
- 2015: publicação das RFC 7480 a 7484 (primeira versão do RDAP)
- 2019: obrigatoriedade para todos os registros gTLD de suportar RDAP em paralelo com o WHOIS
- 2023: publicação das RFC 9082, 9083 e 9224 (versão consolidada do RDAP)
- 28 de janeiro de 2025: fim da obrigatoriedade de manter o WHOIS na porta 43 para os gTLDs
- Fevereiro de 2025: 74 registros gTLD desativam seu serviço WHOIS no mês seguinte ao sunset
- Junho de 2025: o volume de consultas RDAP ultrapassa o de WHOIS pela primeira vez
- Setembro de 2025: 374 gTLDs desativaram o WHOIS
- Janeiro de 2026: a ICANN revoga a acreditação do registrar Brennercom por não implementação do RDAP, um precedente que confirma que a conformidade RDAP não é opcional
O ritmo da transição é claro: em janeiro de 2025, os registros gTLD processavam cerca de 122 bilhões de consultas WHOIS por mês contra 7 bilhões em RDAP. Em agosto de 2025, o WHOIS havia caído para 49 bilhões (queda de 60%) enquanto o RDAP alcançava 65 bilhões. A inversão das curvas ocorreu em junho de 2025.
O status varia conforme o tipo de TLD. Para os gTLDs, o RDAP é obrigatório e o WHOIS é opcional. Para os ccTLDs (.br, .de, .uk), a migração permanece voluntária, pois esses registros não estão sujeitos aos contratos da ICANN. Cerca de 60% dos ccTLDs implantaram o RDAP (aumento de 12% desde janeiro de 2025), mas alguns pesos pesados como .de, .cn e .jp ainda não possuem serviço RDAP.
Por que o WHOIS precisava ser substituído?
Cinco problemas estruturais tornavam o WHOIS inadequado:
- Sem formato padronizado: cada registro retorna os dados em um formato diferente. Fazer o parse das respostas WHOIS exige código específico por registro.
- Sem criptografia: as consultas e respostas trafegam em texto simples na porta 43. Qualquer intermediário de rede pode lê-las.
- Sem autenticação: impossível distinguir um pesquisador de segurança de um spammer. Todos recebem os mesmos dados.
- Incompatível com o RGPD: o WHOIS expõe por padrão os dados pessoais do titular (nome, endereço, e-mail, telefone). O RGPD proíbe essa divulgação sem base legal.
- Sem internacionalização: o WHOIS não suporta Unicode. Os nomes de domínio internacionalizados (IDN) e os contatos não ASCII apresentam problemas.
RDAP: o sucessor moderno
Como funciona o RDAP? (bootstrap IANA, requisição HTTP, resposta JSON)
O RDAP se baseia em três componentes:
1. O bootstrap IANA: como encontrar o servidor correto?
Ao contrário do WHOIS, onde é preciso conhecer o servidor de cada registro, o RDAP utiliza um registro centralizado mantido pela IANA (RFC 9224). Este arquivo JSON lista, para cada TLD, a URL do servidor RDAP correspondente. O cliente RDAP consulta este arquivo, identifica o servidor para o TLD pesquisado e envia a requisição.
2. A requisição HTTP: uma simples URL
GET https://rdap.verisign.com/com/v1/domain/captaindns.com
Sem protocolo binário, sem porta exótica. É uma requisição HTTPS padrão, compatível com qualquer navegador, cliente HTTP ou ferramenta de automação.
3. A resposta JSON: dados estruturados
O servidor retorna um objeto JSON normalizado pela RFC 9083. Cada campo tem um nome definido, um tipo preciso e uma semântica documentada. Não é mais necessário fazer parse de texto livre.
Comparativo WHOIS vs RDAP
| Critério | WHOIS | RDAP |
|---|---|---|
| Protocolo | TCP porta 43, texto simples | HTTPS, JSON estruturado |
| Criptografia | Nenhuma | TLS nativo |
| Formato de resposta | Texto livre, não padronizado | JSON normalizado (RFC 9083) |
| Autenticação | Nenhuma | OAuth 2.0, acesso diferenciado |
| Internacionalização | Limitada (ASCII) | Unicode completo (IDN suportado) |
| Descoberta do servidor | Manual (hardcoded por TLD) | Automática (bootstrap IANA, RFC 9224) |
| Conformidade RGPD | Impossível sem proxy | Nativa (redação seletiva) |
| Status ICANN (gTLD) | Opcional desde 01/2025 | Obrigatório |
Na prática: a mesma consulta em WHOIS e em RDAP
Para tornar a diferença tangível, veja o que os dois protocolos retornam para captaindns.com.
Resposta WHOIS (texto simples, porta 43):
Domain Name: CAPTAINDNS.COM
Registry Domain ID: 2925482234_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.infomaniak.com
Registrar URL: http://www.infomaniak.com
Updated Date: 2025-09-11T08:32:12Z
Creation Date: 2025-09-08T06:06:37Z
Registry Expiry Date: 2026-09-08T06:06:37Z
Registrar: Infomaniak Network SA
Domain Status: clientTransferProhibited
Name Server: CHELSEA.NS.CLOUDFLARE.COM
Name Server: HAL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Cada registro formata essa resposta de forma diferente. Nenhum esquema compartilhado, nenhuma garantia sobre a ordem ou o nome dos campos.
Resposta RDAP (JSON estruturado, HTTPS):
{
"objectClassName": "domain",
"ldhName": "CAPTAINDNS.COM",
"status": ["client transfer prohibited"],
"events": [
{ "eventAction": "registration", "eventDate": "2025-09-08T06:06:37Z" },
{ "eventAction": "expiration", "eventDate": "2026-09-08T06:06:37Z" },
{ "eventAction": "last changed", "eventDate": "2025-09-11T08:32:12Z" }
],
"nameservers": [
{ "ldhName": "CHELSEA.NS.CLOUDFLARE.COM" },
{ "ldhName": "HAL.NS.CLOUDFLARE.COM" }
],
"secureDNS": { "delegationSigned": false },
"rdapConformance": [
"rdap_level_0",
"icann_rdap_technical_implementation_guide_1",
"icann_rdap_response_profile_1"
]
}
Os mesmos dados, mas em um formato previsível, tipado e analisável por qualquer biblioteca JSON. O campo rdapConformance indica os perfis ICANN que o servidor respeita, uma informação que não existia no WHOIS. Teste você mesmo com o RDAP Lookup.
Thin vs thick registries: por que duas consultas para .com?
Para alguns TLDs como .com, os dados de registro são divididos entre dois níveis:
- O registro (Verisign para .com) armazena os dados mínimos: nome de domínio, servidores de nomes, datas, status EPP. É um registro "thin".
- O registrar (o revendedor: OVHcloud, Gandi, GoDaddy, etc.) armazena os dados completos: contato do titular, informações de faturamento, detalhes administrativos.
Quando você consulta o RDAP para um domínio .com, o registro Verisign retorna os dados básicos e inclui um link para o servidor RDAP do registrar com os dados completos. Um cliente RDAP completo segue esse link automaticamente.
Outros TLDs como .fr (AFNIC) são registros "thick": todos os dados são centralizados no nível do registro. Uma única consulta é suficiente.
Números-chave 2025
- 374 gTLDs desativaram o WHOIS na porta 43
- 65 bilhões de consultas RDAP por mês processadas pelos registros gTLD (agosto de 2025)
- 100 bilhões de consultas RDAP mensais em todos os registros (gTLDs, RIRs, bootstrap IANA)
- 60% dos ccTLDs implantaram um servidor RDAP (contra 48% em janeiro de 2025)
- 100% dos registros gTLD são obrigados a suportar RDAP
Cobertura RDAP por tipo de TLD
Todos os gTLDs suportam RDAP, mas a cobertura ccTLD é desigual. Os registros nacionais não são vinculados pelos contratos da ICANN e migram no seu próprio ritmo.
| ccTLD | País | RDAP | Domínios registrados (est.) |
|---|---|---|---|
| .uk | Reino Unido | Sim (desde 2022) | 10,5 M |
| .fr | França | Sim (desde 2022) | 4 M |
| .nl | Países Baixos | Sim (desde 2024) | 6,2 M |
| .br | Brasil | Sim (desde 2017, pioneiro) | 5 M |
| .au | Austrália | Sim (desde 2026) | 4,3 M |
| .de | Alemanha | Não (apenas WHOIS) | 17,4 M |
| .cn | China | Não (apenas WHOIS) | 20 M |
| .eu | União Europeia | Não (apenas WHOIS) | 3,6 M |
| .jp | Japão | Não (apenas WHOIS) | 1,7 M |
| .ru | Rússia | Não (apenas WHOIS) | 5 M |
| .us | Estados Unidos | Não (apenas WHOIS) | 1,8 M |
Para os ccTLDs sem RDAP, o fallback continua sendo o WHOIS na porta 43. Se você gerencia um portfólio multi-TLD, suas ferramentas devem suportar os dois protocolos em paralelo.
Rate limiting e consultas automatizadas
Como os servidores RDAP são simples APIs HTTPS, eles implementam rate limiting para evitar abusos (scraping massivo, coleta de dados em massa). Um cliente que ultrapassa o limite autorizado recebe uma resposta HTTP 429 (Too Many Requests).
Boas práticas para consultas automatizadas:
- Respeite o cabeçalho
Retry-After: quando o servidor retorna um 429, ele pode incluir um cabeçalho indicando o tempo de espera antes de tentar novamente - Implemente um backoff exponencial: aumente o intervalo entre cada tentativa (1s, 2s, 4s, 8s) com um componente aleatório para evitar rajadas sincronizadas
- Limite sua taxa: a maioria dos servidores tolera uma a duas consultas por segundo. Alguns, como o Cloudflare, limitam a 10 consultas por período de 10 segundos
- Faça cache dos resultados: os dados RDAP mudam raramente. Um cache de algumas horas reduz a carga nos servidores e acelera seus processos
Códigos EPP: entendendo os status do seu domínio
Os resultados RDAP incluem os códigos de status EPP (Extensible Provisioning Protocol). Esses códigos indicam o estado atual do seu domínio: ele está protegido contra transferência? Em espera de exclusão? Bloqueado pelo registro?
Dois prefixos distinguem a origem do status:
- client: definido pelo registrar (seu revendedor), modificável pela sua interface de gestão
- server: definido pelo registro (Verisign, AFNIC, etc.), modificável apenas pelo registro
Códigos de proteção (bons)
Esses códigos indicam que proteções estão ativas no seu domínio. Sua presença é desejável.
| Código EPP | Significado | Por que é importante |
|---|---|---|
clientTransferProhibited | Transferência bloqueada pelo registrar | Impede o roubo de domínio via transferência não autorizada |
serverTransferProhibited | Transferência bloqueada pelo registro | Proteção adicional, frequentemente ligada a um registry lock |
clientDeleteProhibited | Exclusão bloqueada pelo registrar | Impede a exclusão acidental ou maliciosa |
serverDeleteProhibited | Exclusão bloqueada pelo registro | Proteção de nível registro contra exclusão |
clientUpdateProhibited | Modificação bloqueada pelo registrar | Impede a alteração não autorizada dos servidores de nomes |
serverUpdateProhibited | Modificação bloqueada pelo registro | Proteção do registro contra modificações DNS |
Códigos de alerta (críticos)
Esses códigos sinalizam um problema ou uma ação urgente necessária.
| Código EPP | Significado | Ação necessária |
|---|---|---|
redemptionPeriod | Domínio excluído, em período de graça (30 dias) | Entre em contato com seu registrar imediatamente para restaurá-lo |
pendingDelete | Exclusão definitiva iminente (5 dias) | Última chance de recuperação, entre em contato com o registro |
serverHold | Resolução DNS suspensa pelo registro | O domínio não resolve mais. Verifique as obrigações junto ao registro |
clientHold | Resolução DNS suspensa pelo registrar | Frequentemente ligado a uma fatura em aberto ou verificação de identidade pendente |
Códigos transitórios (informativos)
Esses códigos indicam uma operação em andamento. São temporários.
| Código EPP | Significado | Duração típica |
|---|---|---|
pendingTransfer | Transferência para outro registrar em andamento | 5 dias (período de aprovação) |
pendingCreate | Registro em processamento | Alguns minutos a algumas horas |
pendingRenew | Renovação em processamento | Alguns minutos |
pendingUpdate | Modificação DNS em andamento | Alguns minutos |
addPeriod | Período de graça após registro (exclusão com reembolso possível) | 5 dias |
renewPeriod | Período de graça após renovação | 5 dias |
transferPeriod | Período de graça após transferência | 5 dias |
autoRenewPeriod | Domínio renovado automaticamente, cancelamento possível | 30 a 45 dias |
Tabela completa dos códigos EPP
O status ok (ou active) é o status padrão: indica que nenhuma restrição nem operação está em andamento. Esse status desaparece assim que outro código de proteção ou restrição é ativado.
Um domínio corretamente protegido exibe no mínimo clientTransferProhibited. Um domínio crítico (marca, site principal) também deveria ter clientDeleteProhibited e clientUpdateProhibited.
Bloqueio de domínio: a proteção indispensável
Os 3 níveis de locks
Nível 1: registrar lock (transfer lock)
É o bloqueio básico, ativável pela interface do seu registrar. Ele define o status clientTransferProhibited e impede a transferência do domínio para outro registrar sem sua autorização explícita.
Custo: gratuito na maioria dos registrars. Não há motivo para não ativá-lo.
Nível 2: registrar full lock
Além do transfer lock, este nível adiciona clientDeleteProhibited e clientUpdateProhibited. O domínio não pode ser transferido, excluído nem modificado (servidores de nomes, contatos) sem desativar manualmente os locks.
Custo: geralmente gratuito, mas nem sempre ativado por padrão.
Nível 3: registry lock
O próprio registro bloqueia o domínio com os status serverTransferProhibited, serverDeleteProhibited e serverUpdateProhibited. Qualquer modificação exige um procedimento manual junto ao registro, frequentemente com verificação de identidade.
Custo: pago (de 50 a 300 EUR/ano dependendo do TLD e do registrar). Reservado para domínios críticos: marcas, sites e-commerce, infraestrutura.
Verificar seus locks com o RDAP Lookup
Para verificar o estado dos seus bloqueios, consulte seu domínio por meio de uma ferramenta RDAP. Os status EPP retornados indicam imediatamente quais locks estão ativos:
clientTransferProhibitedvisível: transfer lock ativoclientDeleteProhibitedvisível: delete lock ativoclientUpdateProhibitedvisível: update lock ativo- Nenhum desses status, apenas
ok: nenhuma proteção ativa
O que fazer se nenhum lock estiver ativo?
Se seu domínio exibe apenas o status ok sem nenhum código de proteção:
- Faça login na interface do seu registrar
- Procure a opção "bloqueio de transferência", "transfer lock" ou "domain lock"
- Ative-a imediatamente
- Para domínios críticos, ative também o delete lock e o update lock se disponíveis
- Verifique novamente via RDAP que os status
clientTransferProhibitedaparecem
Um domínio sem transfer lock pode ser transferido por um terceiro que obtenha o código de autorização (authcode). O roubo de domínio continua sendo uma ameaça real e incidentes recentes o confirmam.
Caso real: o sequestro massivo durante a migração Google Domains para Squarespace (2024)
Em julho de 2024, a aquisição dos domínios do Google Domains pela Squarespace provocou um dos incidentes de domain hijacking mais documentados do ano. Entre 9 e 12 de julho, atacantes assumiram o controle de domínios pertencentes a grandes empresas cripto: Celer Network, Compound Finance, Pendle Finance e Unstoppable Domains, entre outras.
A falha: a Squarespace havia migrado aproximadamente 10 milhões de nomes de domínio do Google Domains, mas sem exigir verificação por e-mail na criação da conta. Os atacantes conseguiram criar contas usando os endereços de e-mail associados aos domínios migrados, antes que os titulares legítimos o fizessem. Uma vez conectados, modificaram os registros DNS para redirecionar o tráfego para sites de phishing.
A autenticação multifator não estava ativada por padrão nas contas migradas, e a plataforma não fornecia nem log de auditoria nem notificação por e-mail para ações nas contas.
Este incidente ilustra por que os bloqueios EPP são essenciais. Um domínio com clientUpdateProhibited ativo não teria seus servidores de nomes modificados, mesmo após uma comprometimento de conta. As proteções EPP atuam como uma rede de segurança independente da segurança da conta no registrar.
WHOIS, RDAP e RGPD: quais dados permanecem visíveis?
Antes do RGPD (2018)
Antes de maio de 2018, uma consulta WHOIS retornava todos os dados do titular sem restrição:
- Nome completo e organização
- Endereço postal completo
- E-mail, telefone, fax
- Contatos administrativo e técnico
Esses dados eram explorados massivamente: spam direcionado, phishing, roubo de identidade, assédio a titulares. Os serviços de "WHOIS privacy" vendidos pelos registrars eram a única proteção.
Após o RGPD: redação seletiva vs mascaramento total
O RGPD (Regulamento Geral sobre a Proteção de Dados), aplicado desde maio de 2018, impôs uma mudança radical. Os dados pessoais não podem mais ser divulgados sem base legal. Os registros e registrars adotaram duas abordagens:
Redação seletiva: os dados pessoais (nome, endereço, e-mail, telefone) são mascarados ou substituídos por menções genéricas ("REDACTED FOR PRIVACY"). Os dados técnicos (servidores de nomes, datas, status EPP) permanecem visíveis.
Mascaramento total: alguns registros retornam um mínimo absoluto de informações. Apenas o nome de domínio, as datas e os status são expostos.
Na prática, uma consulta RDAP em 2026 retorna tipicamente:
| Dado | Visível? |
|---|---|
| Nome de domínio | Sim |
| Registrar | Sim |
| Datas (criação, expiração, atualização) | Sim |
| Status EPP | Sim |
| Servidores de nomes | Sim |
| Nome do titular | Não (mascarado) |
| Endereço do titular | Não (mascarado) |
| E-mail do titular | Não (mascarado ou e-mail relay) |
| Telefone do titular | Não (mascarado) |
Acesso diferenciado RDAP (anônimo, autenticado, privilegiado)
O RDAP integra nativamente um sistema de acesso diferenciado, algo que o WHOIS não podia oferecer:
Acesso anônimo: apenas dados públicos (nome de domínio, datas, status, servidores de nomes). É o que uma consulta RDAP padrão retorna.
Acesso autenticado: via token OAuth 2.0, um usuário identificado pode acessar dados adicionais. Por exemplo, o titular de um domínio pode consultar suas próprias informações completas.
Acesso privilegiado: reservado às forças policiais, aos organismos de proteção da propriedade intelectual e às equipes de cibersegurança credenciadas.
SSAD e RDRS: rumo a um acesso padronizado aos dados não públicos
A ICANN concebeu o SSAD (System for Standardized Access/Disclosure) para formalizar o acesso aos dados não públicos dos domínios. O projeto, originado do processo EPDP Fase 2, abrange 18 recomendações interdependentes: credenciamento dos solicitantes, critérios de consulta, exigências de resposta, registro de logs e níveis de serviço.
Na prática, o SSAD nunca foi implantado como tal. A avaliação operacional de janeiro de 2022 revelou um custo e uma complexidade desproporcionais. A ICANN então lançou o RDRS (Registration Data Request Service) como sistema de transição. Desde seu lançamento, mais de 13.000 contas de solicitantes únicos foram criadas no RDRS, submetendo aproximadamente 3.600 solicitações de divulgação de dados não públicos junto aos registrars gTLD.
Em outubro de 2025, o conselho de administração da ICANN prorrogou o RDRS até dezembro de 2027. Durante esse período, a ICANN melhora a interface do usuário e desenvolve um protocolo de autenticação dedicado às forças policiais. O RDRS permanece um sistema de transição: a comunidade ICANN ainda debate sua evolução para um modelo permanente, seja o SSAD original ou um sucessor simplificado.
Esse modelo resolve o conflito fundamental entre transparência e privacidade: os dados continuam existindo nas bases dos registros, mas seu acesso é condicionado ao nível de habilitação do solicitante.
Para as equipes de cibersegurança, essa restrição complica as investigações sobre domínios maliciosos. Identificar o titular de um domínio de phishing agora exige uma solicitação formal ao registrar, com justificativa legal. O prazo de tratamento varia de algumas horas a várias semanas dependendo do registrar e da jurisdição.
Para os proprietários de marcas, a proteção é reforçada: suas informações de contato não ficam mais expostas aos agentes maliciosos. Em contrapartida, o monitoramento dos registros de domínios abusivos (typosquatting, homóglifos) depende mais dos dados técnicos (datas, servidores de nomes, registrar) do que dos dados de contato.
🎯 Plano de ação recomendado
1. Verificar seus domínios
Consulte cada domínio crítico por meio de uma ferramenta RDAP. Verifique os status EPP, as datas de expiração e os servidores de nomes. Identifique os domínios sem proteção (status ok sozinho). Priorize os domínios que recebem tráfego, e-mail ou representam uma marca.
2. Ativar os bloqueios de transferência
Para cada domínio sem clientTransferProhibited, ative o bloqueio de transferência na interface do seu registrar. Para domínios críticos (marca, site principal, e-mail), adicione clientDeleteProhibited e clientUpdateProhibited. O procedimento leva menos de 2 minutos e o bloqueio entra em vigor imediatamente.
3. Configurar o DNSSEC
O RDAP exibe o status DNSSEC do seu domínio. Se a menção "unsigned" ou a ausência de dados DNSSEC aparecer, ative a assinatura de zona. O DNSSEC protege a integridade dos seus registros DNS e constitui um pré-requisito para o DANE (autenticação de certificados TLS por DNS). Verifique com o verificador DNSSEC que a cadeia de confiança está completa, da raiz DNS até sua zona.
4. Atualizar seus scripts WHOIS
Se você utiliza scripts ou ferramentas que consultam o WHOIS na porta 43, migre-os para RDAP. As bibliotecas RDAP existem em todas as linguagens comuns (Python: rdap, Go: openrdap, JavaScript: rdap-client). O formato JSON é mais simples de parsear do que o texto livre WHOIS. Use o bootstrap IANA para resolver automaticamente o servidor RDAP de cada TLD em vez de manter uma lista estática de servidores. Verifique que suas consultas direcionam os servidores corretos através do DNS Lookup para confirmar a resolução dos seus domínios.
5. Planejar uma auditoria periódica
Os status EPP, as datas de expiração e as configurações DNS evoluem. Planeje uma verificação trimestral dos seus domínios críticos. Verifique que os bloqueios de transferência continuam ativos (alguns registrars os desativam temporariamente durante operações de manutenção), que o DNSSEC está funcional e que as datas de expiração oferecem uma margem suficiente.
❓ FAQ - Perguntas frequentes
FAQ
Qual é a diferença entre WHOIS e RDAP?
O WHOIS utiliza a porta TCP 43 e retorna texto simples não padronizado, sem criptografia nem autenticação. O RDAP utiliza HTTPS e retorna JSON estruturado (RFC 9083) com criptografia TLS nativa e suporte a acesso diferenciado via OAuth 2.0. O RDAP é o sucessor oficial do WHOIS para os gTLDs desde janeiro de 2025.
O WHOIS ainda funciona em 2026?
Para alguns TLDs, sim. A ICANN não obriga mais os registros gTLD a manter o WHOIS desde 28 de janeiro de 2025, mas também não proíbe mantê-lo. 374 gTLDs já o desativaram. Os ccTLDs (.br, .de, .uk) não estão sujeitos às regras da ICANN e podem manter o WHOIS indefinidamente. Na prática, preveja que o WHOIS desaparecerá progressivamente.
O que significa o código EPP clientTransferProhibited?
Esse código indica que o registrar ativou um bloqueio de transferência no domínio. Nenhuma transferência para outro registrar pode ser iniciada enquanto esse status estiver ativo. É a proteção básica contra o roubo de domínio. Todo titular deveria ativá-lo em seus domínios.
Meu domínio exibe apenas o status ok, é normal?
O status ok significa que nenhuma restrição está ativa. O domínio pode ser transferido, modificado ou excluído sem obstáculo. Se é um domínio importante, ative imediatamente o transfer lock (clientTransferProhibited) através do seu registrar para protegê-lo.
Ainda é possível ver os dados do proprietário de um domínio?
Em acesso anônimo, não. Desde o RGPD (2018), os dados pessoais do titular (nome, endereço, e-mail, telefone) são mascarados nas respostas WHOIS e RDAP. Apenas os dados técnicos permanecem visíveis: nome de domínio, registrar, datas, status EPP, servidores de nomes. Um acesso autenticado ou privilegiado pode revelar mais dados conforme o nível de habilitação.
O que é o registry lock e quanto custa?
O registry lock é um bloqueio aplicado no nível do registro (Verisign, AFNIC, etc.), com os status serverTransferProhibited, serverDeleteProhibited e serverUpdateProhibited. Qualquer modificação exige um procedimento manual com verificação de identidade. O custo varia de 50 a 300 EUR/ano dependendo do TLD e do registrar. É recomendado para domínios de marca e sites de alto valor.
Como migrar meus scripts WHOIS para RDAP?
Substitua as consultas TCP porta 43 por requisições HTTPS para os servidores RDAP. Use o bootstrap IANA (RFC 9224) para descobrir automaticamente o servidor RDAP de cada TLD. As respostas JSON são mais simples de parsear do que o texto livre WHOIS. Bibliotecas RDAP existem para Python, Go, JavaScript, Ruby e a maioria das linguagens comuns.
O RDAP exibe as informações DNSSEC de um domínio?
Sim. A resposta RDAP inclui os dados de delegação segura (secure DNS) quando o DNSSEC está ativo no domínio: algoritmo, tipo de digest e fingerprint DS. Se o domínio não tem DNSSEC, essa seção está ausente ou indica que a zona não está assinada.
Baixe as tabelas comparativas
Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.
📖 Glossário
- WHOIS: protocolo de consulta de dados de registro de domínios (RFC 3912), utilizando a porta TCP 43. Em processo de substituição pelo RDAP.
- RDAP: Registration Data Access Protocol (RFC 9082/9083). Sucessor do WHOIS, baseado em HTTPS e JSON, com criptografia e acesso diferenciado nativos.
- EPP: Extensible Provisioning Protocol (RFC 5730). Protocolo utilizado entre registrars e registros para gerenciar domínios. Os códigos de status EPP indicam o estado de um domínio.
- Bootstrap IANA: arquivo JSON centralizado (RFC 9224) que associa cada TLD à URL do seu servidor RDAP. Permite a descoberta automática do servidor correto.
- Registro (registry): organismo que gerencia um TLD. Verisign para .com, AFNIC para .fr. Armazena os dados da zona e os registros de domínios.
- Registrar: revendedor credenciado que vende e gerencia nomes de domínio em nome dos titulares. OVHcloud, Gandi, GoDaddy são registrars.
- Transfer lock: bloqueio que impede a transferência de um domínio para outro registrar. Corresponde ao status EPP
clientTransferProhibited. - Registry lock: bloqueio aplicado no nível do registro com verificação manual. Status
serverTransferProhibited,serverDeleteProhibited,serverUpdateProhibited. - Thin registry: registro que armazena apenas os dados mínimos (nome, NS, datas, status). Os dados completos ficam no registrar. Exemplo: .com.
- Thick registry: registro que centraliza todos os dados, incluindo os contatos do titular. Exemplo: .fr.
- Redemption period: período de graça de 30 dias após a exclusão de um domínio, durante o qual o titular pode restaurá-lo mediante pagamento de taxa.
- RGPD: Regulamento Geral sobre a Proteção de Dados. Regulamento europeu que impõe a proteção de dados pessoais e provocou o mascaramento dos dados de contato no WHOIS e RDAP.
📚 Guias de RDAP e gestão de domínio relacionados
- RDAP vs WHOIS: guia completo da transição 2025 (este artigo)
- Ciclo de vida de um nome de domínio: expiração, proteção e boas práticas: as 7 etapas, riscos e proteções concretas.
