RDAP vs WHOIS: o guia completo da transição (códigos EPP, 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 os 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 registos gTLD mantenham um serviço WHOIS na porta 43. O RDAP (Registration Data Access Protocol) é agora o único protocolo obrigatório para aceder a dados de registo de domínios.
Este guia cobre a transição completa: porque 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 contacto e os bloqueios a ativar para proteger os seus domínios.
Teste os 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 ligaçã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 encriptação, sem autenticação.
Durante 40 anos, o WHOIS cumpriu o seu papel: identificar os responsáveis por um domínio. Mas as suas limitações técnicas tornaram-se problemas críticos à medida que a Internet crescia.
Linha do tempo ICANN do sunset WHOIS
A ICANN planeou 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 registos 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 registos gTLD desativam o 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 registos gTLD processavam cerca de 122 mil milhões de consultas WHOIS por mês contra 7 mil milhões em RDAP. Em agosto de 2025, o WHOIS havia caído para 49 mil milhões (queda de 60%) enquanto o RDAP alcançava 65 mil milhõ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 registos 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.
Porque o WHOIS precisava de ser substituído?
Cinco problemas estruturais tornavam o WHOIS inadequado:
- Sem formato padronizado: cada registo retorna os dados em um formato diferente. Fazer o parse das respostas WHOIS exige código específico por registo.
- Sem encriptação: 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 predefiniçã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 contactos não ASCII apresentam problemas.
RDAP: o sucessor moderno
Como funciona o RDAP? (bootstrap IANA, requisição HTTP, resposta JSON)
O RDAP baseia-se 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 registo, o RDAP utiliza um registo centralizado mantido pela IANA (RFC 9224). Este ficheiro JSON lista, para cada TLD, a URL do servidor RDAP correspondente. O cliente RDAP consulta este ficheiro, 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 |
| Encriptação | 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 registo formata essa resposta de forma diferente. Nenhum esquema partilhado, 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 mesmo com o RDAP Lookup.
Thin vs thick registries: porque duas consultas para .com?
Para alguns TLDs como .com, os dados de registo são divididos entre dois níveis:
- O registo (Verisign para .com) armazena os dados mínimos: nome de domínio, servidores de nomes, datas, status EPP. É um registo "thin".
- O registrar (o revendedor: OVHcloud, Gandi, GoDaddy, etc.) armazena os dados completos: contacto do titular, informações de faturação, detalhes administrativos.
Quando consulta o RDAP para um domínio .com, o registo 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 registos "thick": todos os dados são centralizados no nível do registo. Uma única consulta é suficiente.
Números-chave 2025
- 374 gTLDs desativaram o WHOIS na porta 43
- 65 mil milhões de consultas RDAP por mês processadas pelos registos gTLD (agosto de 2025)
- 100 mil milhões de consultas RDAP mensais em todos os registos (gTLDs, RIRs, bootstrap IANA)
- 60% dos ccTLDs implantaram um servidor RDAP (contra 48% em janeiro de 2025)
- 100% dos registos gTLD são obrigados a suportar RDAP
Cobertura RDAP por tipo de TLD
Todos os gTLDs suportam RDAP, mas a cobertura ccTLD é desigual. Os registos nacionais não são vinculados pelos contratos da ICANN e migram no seu próprio ritmo.
| ccTLD | País | RDAP | Domínios registados (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 a ser o WHOIS na porta 43. Se gere um portfólio multi-TLD, as 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, recolha 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 a 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 os 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 eliminação? Bloqueado pelo registo?
Dois prefixos distinguem a origem do status:
- client: definido pelo registrar (o seu revendedor), modificável pela sua interface de gestão
- server: definido pelo registo (Verisign, AFNIC, etc.), modificável apenas pelo registo
Códigos de proteção (bons)
Esses códigos indicam que proteções estão ativas no seu domínio. A sua presença é desejável.
| Código EPP | Significado | Porque é importante |
|---|---|---|
clientTransferProhibited | Transferência bloqueada pelo registrar | Impede o roubo de domínio via transferência não autorizada |
serverTransferProhibited | Transferência bloqueada pelo registo | Proteção adicional, frequentemente ligada a um registry lock |
clientDeleteProhibited | Eliminação bloqueada pelo registrar | Impede a eliminação acidental ou maliciosa |
serverDeleteProhibited | Eliminação bloqueada pelo registo | Proteção de nível registo contra eliminação |
clientUpdateProhibited | Modificação bloqueada pelo registrar | Impede a alteração não autorizada dos servidores de nomes |
serverUpdateProhibited | Modificação bloqueada pelo registo | Proteção do registo 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 eliminado, em período de graça (30 dias) | Entre em contacto com o seu registrar imediatamente para restaurá-lo |
pendingDelete | Eliminação definitiva iminente (5 dias) | Última chance de recuperação, entre em contacto com o registo |
serverHold | Resolução DNS suspensa pelo registo | O domínio não resolve mais. Verifique as obrigações junto ao registo |
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 | Registo 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 registo (eliminaçã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 a 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, eliminado nem modificado (servidores de nomes, contactos) sem desativar manualmente os locks.
Custo: geralmente gratuito, mas nem sempre ativado por predefinição.
Nível 3: registry lock
O próprio registo bloqueia o domínio com os status serverTransferProhibited, serverDeleteProhibited e serverUpdateProhibited. Qualquer modificação exige um procedimento manual junto ao registo, 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 os seus locks com o RDAP Lookup
Para verificar o estado dos seus bloqueios, consulte o 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 o 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 a ser 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 controlo 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 registos DNS para redirecionar o tráfego para sites de phishing.
A autenticação multifator não estava ativada por predefiniçã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 porque os bloqueios EPP são essenciais. Um domínio com clientUpdateProhibited ativo não teria os 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
- Contactos 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 registos 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 registos 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 utilizador identificado pode aceder a dados adicionais. Por exemplo, o titular de um domínio pode consultar as suas próprias informações completas.
Acesso privilegiado: reservado às forças policiais, aos organismos de proteção da propriedade intelectual e às equipas 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, registo 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 o 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 utilizador 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 a 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 a existir nas bases dos registos, mas o seu acesso é condicionado ao nível de habilitação do solicitante.
Para as equipas 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 registar, 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: as suas informações de contacto não ficam mais expostas aos agentes maliciosos. Em contrapartida, a monitorização dos registos de domínios abusivos (typosquatting, homóglifos) depende mais dos dados técnicos (datas, servidores de nomes, registrar) do que dos dados de contacto.
🎯 Plano de ação recomendado
1. Verificar os 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 registos 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é a sua zona.
4. Atualizar os seus scripts WHOIS
Se 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 as suas consultas direcionam os servidores corretos através do DNS Lookup para confirmar a resolução dos seus domínios.
5. Planear uma auditoria periódica
Os status EPP, as datas de expiração e as configurações DNS evoluem. Planeie 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
Qual é a diferença entre WHOIS e RDAP?
O WHOIS utiliza a porta TCP 43 e retorna texto simples não padronizado, sem encriptação nem autenticação. O RDAP utiliza HTTPS e retorna JSON estruturado (RFC 9083) com encriptação 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 registos 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 nos 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 eliminado 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 registo (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 secção está ausente ou indica que a zona não está assinada.
Descarregue 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 registo 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 encriptação e acesso diferenciado nativos.
- EPP: Extensible Provisioning Protocol (RFC 5730). Protocolo utilizado entre registrars e registos para gerir domínios. Os códigos de status EPP indicam o estado de um domínio.
- Bootstrap IANA: ficheiro JSON centralizado (RFC 9224) que associa cada TLD à URL do seu servidor RDAP. Permite a descoberta automática do servidor correto.
- Registo (registry): organismo que gere um TLD. Verisign para .com, AFNIC para .fr. Armazena os dados da zona e os registos de domínios.
- Registrar: revendedor credenciado que vende e gere 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 registo com verificação manual. Status
serverTransferProhibited,serverDeleteProhibited,serverUpdateProhibited. - Thin registry: registo que armazena apenas os dados mínimos (nome, NS, datas, status). Os dados completos ficam no registrar. Exemplo: .com.
- Thick registry: registo que centraliza todos os dados, incluindo os contactos do titular. Exemplo: .fr.
- Redemption period: período de graça de 30 dias após a eliminaçã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 contacto 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.
