RDPA: O que é Registration Data Access Protocol?

Até o presente momento, proprietários de domínios podem ser encontrados com a ajuda de serviços Whois, baseados em um protocolo homônimo. No entanto, em 2015, IETF e ICANN criaram o primeiro documento RFC para que o protocolo RDAP (Registration Data Access Protocol) começasse a substituir o Whois.

Definição de Registration Data Access Protocol

O conceito do Registration Data Access Protocol (RDAP) foi pensado por um grupo de trabalho da Internet Engineering Task Force (IETF). Depois das primeiras fases do projeto terem durado quase quatro anos, a primeira versão do protocolo (1.0) foi publicada, em 26 de julho de 2016. Características e aplicações do RDAP são detalhadas por múltiplos Requests for Comments (RFC 7480-7484 e RFC 8056). Entre elas está o fato do protocolo possibilitar o acesso a mais informações sobre recursos básicos da internet, incluindo:

• Nomes de domínio
• Endereços IP
• Números de sistema autônomo (ASNs)

Além dos listados acima, o novo protocolo também dispõe de outros recursos interessantes. Por isso o RDAP é considerado a alternativa ideal ao Whois para executar consultas nos diversos núcleos de informação e coordenação. Elas incluem, por exemplo, o fornecimento de informações de contato dos proprietários de domínios ao seu banco de dados, assim como dados de contato de administradores (Admin C) e até mesmo o endereço do servidor de nomes usado e do respectivo administrador.

Por que o RDAP foi criado?

Em 1982, a IETF criou o protocolo Whois para atuar como um serviço de solicitações para a ARPANET (antecessora da internet). Entretanto ele ainda continua sendo usado, mais de 40 anos depois, em consultas on-line e é considerado, por muitos, uma pedra no sapato. As principais críticas feitas ao Whois apontam o fato que o protocolo não mais atende aos requisitos técnicos da internet.

Um de seus maiores problemas é que o Whois não funciona com códigos, portanto, ele não oferece suporte a textos não escritos no alfabeto latino. Outra grande desvantagem é que o acesso a dados sobre domínios não é feito por uma conexão segura e nem é regulamentado. Usuários anônimos conseguem acesso completo a dados, o que pode ser problemático.

Projetos como Whois++ e IRIS Denic Protocol conseguiram promover algumas melhorias, mas não se estabeleceram como alternativas sólidas ao Whois. Após inúmeras e extensas discussões dentro da comunidade ICANN sobre a necessidade de se encontrar uma solução, em setembro de 2021, o Security and Stability Advisory Committee (SSAC), por meio do Relatório SAC 501, deu vida ao grupo de trabalho que desenvolveria o RDAP.

Em janeiro de 2023, a ICANN realizou uma votação global para decidir sobre a substituição oficial do Whois pelo RDAP. O número necessário de votos foi atingido e, portanto, começou-se, oficialmente, a troca de protocolos. A partir de 2025, os núcleos de informação e coordenação, assim como os registradores de domínio, não serão mais obrigados a oferecer suporte ao Whois.

Como funciona o RDAP?

Para que a implementação do RDAP seja possível, é importante que se entenda como o protocolo funciona, tanto pelo lado do cliente quanto pelo lado do servidor. Para isso, interessados podem consultar os RFCs de 7480 a 7484, que descrevem o processo de implementação do Registration Data Access Protocol em detalhes. Além dos citados, existem outros RFCs que detalham extensões do RDAP. Abaixo, explicaremos superficialmente como o RDAP trabalha por HTTPS, conforme descrito no documento RFC 7840.

Tarefas do cliente

A implementação do RDAP pelo lado do cliente não é complexa. Por ter sido desenvolvido em HTTP, ele usa métodos HTTP já existentes para transferir dados. Clientes fazem solicitações ao servidor usando os métodos GET e HEAD. Tanto as solicitações GET quanto as HEAD devem incluir o cabeçalho Accept, que especifica os tipos de arquivos JSON aceitos pelo cliente.

Tarefas do servidor

A implementação é um pouco mais complexa pelo lado do servidor, já que ela abrange alguns casos especiais. Se a solicitação for bem-sucedida, o servidor deverá retornar os dados requeridos, no formato solicitado, com o código de status HTTP 200 (OK). Em solicitações GET, o servidor responde com os dados solicitados do proprietário. Em solicitações HEAD, ele indica se os dados do domínio em questão estão disponíveis.

Se souber onde os dados solicitados estão, mas não os obtiver, ele responderá com um dos seguintes códigos de status: 301, 302, 303 ou 307. O URL em que os dados podem ser encontrados é então enviado sob o cabeçalho HTTP Location.

Se o servidor não conseguir processar a solicitação, porque os dados solicitados não estão disponíveis, ele responderá com o código de status 404 (Not Found). Se os dados solicitados existirem, mas o servidor não quiser responder por algum motivo, ele apresentará o código de status 400 mais apropriado. Solicitações contendo erros, que não puderem ser entendidas como solicitações RDAP, são respondidas com o código de status 400 (Bad request). Neste caso, informações adicionais poderão ser enviadas no corpo da entidade HTTP.

Para informações mais detalhadas sobre processos, segurança e possibilidades de extensão do protocolo, consulte os RFCs correspondentes:

• RFC 7840: Uso de HTTP
• RFC 7841: Serviços de segurança
• RFC 7842: Formato de consulta
• RFC 7843: Respostas JSON
• RFC 7844: Encontrar dados de registro oficiais

Por que o RDPA é diferente?

Por diversos fatores, o Registration Data Access Protocol é considerado a versão aprimorada do Whois. Entre eles está o fato de o grupo de trabalho da IEFT ter se concentrado nas fraquezas do protocolo anterior, o que resultou em grande foco em segurança, estruturação e internacionalização do RDPA em comparação ao Whois. Como consequência, vários novos recursos foram criados, que incluem:

• Estruturação semântica de solicitação e resposta, incluindo mensagens de erros padronizadas.
• Acesso seguro aos dados de contato solicitados (por exemplo, por HTTPS).
• Possibilidade de expansão (por exemplo, adição de elementos de saída) .
• Mecanismo de bootstrapping (amparado pela busca a um servidor DNS oficial).
• Encaminhamento padronizado de consultas.
• Baseado na web (HTTP) e em conformidade com REST.
• Tradução descomplicada dos dados de saída.
• Possibilidade de conceder acesso diferenciado a dados de contato.

Em vários aspectos, o Registration Data Access Protocol se mostra muito mais flexível do que seu antecessor. Enquanto o Whois, protocolo baseado em texto, depende de TCP e de uma porta TCP específica (43), o RDAP usa o padrão web HTTP ou até mesmo HTTPS. Isso significa que todos os dados são entregues em formato JSON padronizado e legível por máquina. Portanto o RDAP atribui maior liberdade a consultas de dados, ao mesmo tempo em que facilita a programação de serviços de consulta capazes de se comunicar com diversas autoridades de registro de domínio. Ainda, ele consegue apresentar dados solicitados em diferentes idiomas.

Apresentamos, abaixo, tabela comparativa entre RDAP e Whois:

Críticas sobre a definição de direitos de acesso

Sem dúvida, uma das novas funcionalidades mais importantes do Registration Data Access Protocol é a possibilidade de configuração de direitos de acesso diferentes a grupos de usuários. O RDAP permite que registradores regulamentem quem pode ter acesso a que tipo de informação. Assim, usuários anônimos têm acesso limitado, enquanto usuários autorizados podem visualizar o conjunto completo de dados. No entanto, muitos pedem por melhores esclarecimentos sobre o tema.

Há uma preocupação para com aqueles que preferem permanecer anônimos e, ainda assim, desejam acesso total aos dados. Além disso, há uma demanda por diretrizes que definam, em casos como este, se o acessos a dados de domínios também devem ser concedidos a usuários de outro país. Em relação ao Whois, o RDAP tem como prioridade proteger dados de usuários e confiar no administrador do site cujo domínio foi registrado. De forma nenhuma essa confiança deve ser comprometida pela nova tecnologia de solicitações do RDAP.

Ao final de 2016, vários núcleos de informação e coordenação apelaram contra o período de implementação imposto pela ICANN, o que fez com que a organização optasse por estabelecer contratos junto a registradores e provedores relativos à transição ao RDAP.