RDPA: O que é Re­gis­tra­tion Data Access Protocol?

Até o presente momento, pro­pri­e­tá­rios de domínios podem ser en­con­tra­dos 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 (Re­gis­tra­tion Data Access Protocol) começasse a subs­ti­tuir o Whois.

Definição de Re­gis­tra­tion Data Access Protocol

O conceito do Re­gis­tra­tion Data Access Protocol (RDAP) foi pensado por um grupo de trabalho da Internet En­gi­ne­e­ring 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. Ca­rac­te­rís­ti­cas e apli­ca­ções do RDAP são de­ta­lha­das por múltiplos Requests for Comments (RFC 7480-7484 e RFC 8056). Entre elas está o fato do protocolo pos­si­bi­li­tar o acesso a mais in­for­ma­çõ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 in­te­res­san­tes. Por isso o RDAP é con­si­de­rado a al­ter­na­tiva ideal ao Whois para executar consultas nos diversos núcleos de in­for­ma­ção e co­or­de­na­ção. Elas incluem, por exemplo, o for­ne­ci­mento de in­for­ma­ções de contato dos pro­pri­e­tá­rios de domínios ao seu banco de dados, assim como dados de contato de ad­mi­nis­tra­do­res (Admin C) e até mesmo o endereço do servidor de nomes usado e do res­pec­tivo ad­mi­nis­tra­dor.

Por que o RDAP foi criado?

Em 1982, a IETF criou o protocolo Whois para atuar como um serviço de so­li­ci­ta­ções para a ARPANET (an­te­ces­sora da internet). En­tre­tanto ele ainda continua sendo usado, mais de 40 anos depois, em consultas on-line e é con­si­de­rado, por muitos, uma pedra no sapato. As prin­ci­pais críticas feitas ao Whois apontam o fato que o protocolo não mais atende aos re­qui­si­tos 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 des­van­ta­gem é que o acesso a dados sobre domínios não é feito por uma conexão segura e nem é re­gu­la­men­tado. Usuários anônimos conseguem acesso completo a dados, o que pode ser pro­ble­má­tico.

Projetos como Whois++ e IRIS Denic Protocol con­se­gui­ram promover algumas melhorias, mas não se es­ta­be­le­ce­ram como al­ter­na­ti­vas sólidas ao Whois. Após inúmeras e extensas dis­cus­sões dentro da co­mu­ni­dade ICANN sobre a ne­ces­si­dade 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 de­sen­vol­ve­ria o RDAP.

Em janeiro de 2023, a ICANN realizou uma votação global para decidir sobre a subs­ti­tui­ção oficial do Whois pelo RDAP. O número ne­ces­sá­rio de votos foi atingido e, portanto, começou-se, ofi­ci­al­mente, a troca de pro­to­co­los. A partir de 2025, os núcleos de in­for­ma­ção e co­or­de­na­ção, assim como os re­gis­tra­do­res de domínio, não serão mais obrigados a oferecer suporte ao Whois.

Como funciona o RDAP?

Para que a im­ple­men­ta­ção do RDAP seja possível, é im­por­tante que se entenda como o protocolo funciona, tanto pelo lado do cliente quanto pelo lado do servidor. Para isso, in­te­res­sa­dos podem consultar os RFCs de 7480 a 7484, que descrevem o processo de im­ple­men­ta­ção do Re­gis­tra­tion Data Access Protocol em detalhes. Além dos citados, existem outros RFCs que detalham extensões do RDAP. Abaixo, ex­pli­ca­re­mos su­per­fi­ci­al­mente como o RDAP trabalha por HTTPS, conforme descrito no documento RFC 7840.

Tarefas do cliente

A im­ple­men­ta­ção do RDAP pelo lado do cliente não é complexa. Por ter sido de­sen­vol­vido em HTTP, ele usa métodos HTTP já exis­ten­tes para trans­fe­rir dados. Clientes fazem so­li­ci­ta­ções ao servidor usando os métodos GET e HEAD. Tanto as so­li­ci­ta­ções GET quanto as HEAD devem incluir o cabeçalho Accept, que es­pe­ci­fica os tipos de arquivos JSON aceitos pelo cliente.

Tarefas do servidor

A im­ple­men­ta­ção é um pouco mais complexa pelo lado do servidor, já que ela abrange alguns casos especiais. Se a so­li­ci­ta­ção for bem-sucedida, o servidor deverá retornar os dados re­que­ri­dos, no formato so­li­ci­tado, com o código de status HTTP 200 (OK). Em so­li­ci­ta­ções GET, o servidor responde com os dados so­li­ci­ta­dos do pro­pri­e­tá­rio. Em so­li­ci­ta­ções HEAD, ele indica se os dados do domínio em questão estão dis­po­ní­veis.

Se souber onde os dados so­li­ci­ta­dos estão, mas não os obtiver, ele res­pon­derá com um dos seguintes códigos de status: 301, 302, 303 ou 307. O URL em que os dados podem ser en­con­tra­dos é então enviado sob o cabeçalho HTTP Location.

Se o servidor não conseguir processar a so­li­ci­ta­ção, porque os dados so­li­ci­ta­dos não estão dis­po­ní­veis, ele res­pon­derá com o código de status 404 (Not Found). Se os dados so­li­ci­ta­dos existirem, mas o servidor não quiser responder por algum motivo, ele apre­sen­tará o código de status 400 mais apro­pri­ado. So­li­ci­ta­ções contendo erros, que não puderem ser en­ten­di­das como so­li­ci­ta­ções RDAP, são res­pon­di­das com o código de status 400 (Bad request). Neste caso, in­for­ma­ções adi­ci­o­nais poderão ser enviadas no corpo da entidade HTTP.

Para in­for­ma­ções mais de­ta­lha­das sobre processos, segurança e pos­si­bi­li­da­des de extensão do protocolo, consulte os RFCs cor­res­pon­den­tes:

• 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 Re­gis­tra­tion Data Access Protocol é con­si­de­rado a versão apri­mo­rada do Whois. Entre eles está o fato de o grupo de trabalho da IEFT ter se con­cen­trado nas fraquezas do protocolo anterior, o que resultou em grande foco em segurança, es­tru­tu­ra­ção e in­ter­na­ci­o­na­li­za­ção do RDPA em com­pa­ra­ção ao Whois. Como con­sequên­cia, vários novos recursos foram criados, que incluem:

• Es­tru­tu­ra­ção semântica de so­li­ci­ta­ção e resposta, incluindo mensagens de erros pa­dro­ni­za­das.
• Acesso seguro aos dados de contato so­li­ci­ta­dos (por exemplo, por HTTPS).
• Pos­si­bi­li­dade de expansão (por exemplo, adição de elementos de saída) .
• Mecanismo de bo­ots­trap­ping (amparado pela busca a um servidor DNS oficial).
• En­ca­mi­nha­mento pa­dro­ni­zado de consultas.
• Baseado na web (HTTP) e em con­for­mi­dade com REST.
• Tradução des­com­pli­cada dos dados de saída.
• Pos­si­bi­li­dade de conceder acesso di­fe­ren­ci­ado a dados de contato.

Em vários aspectos, o Re­gis­tra­tion Data Access Protocol se mostra muito mais flexível do que seu an­te­ces­sor. Enquanto o Whois, protocolo baseado em texto, depende de TCP e de uma porta TCP es­pe­cí­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 pa­dro­ni­zado e legível por máquina. Portanto o RDAP atribui maior liberdade a consultas de dados, ao mesmo tempo em que facilita a pro­gra­ma­ção de serviços de consulta capazes de se comunicar com diversas au­to­ri­da­des de registro de domínio. Ainda, ele consegue apre­sen­tar dados so­li­ci­ta­dos em di­fe­ren­tes idiomas.

Apre­sen­ta­mos, abaixo, tabela com­pa­ra­tiva entre RDAP e Whois:

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

Sem dúvida, uma das novas fun­ci­o­na­li­da­des mais im­por­tan­tes do Re­gis­tra­tion Data Access Protocol é a pos­si­bi­li­dade de con­fi­gu­ra­ção de direitos de acesso di­fe­ren­tes a grupos de usuários. O RDAP permite que re­gis­tra­do­res re­gu­la­men­tem quem pode ter acesso a que tipo de in­for­ma­ção. Assim, usuários anônimos têm acesso limitado, enquanto usuários au­to­ri­za­dos podem vi­su­a­li­zar o conjunto completo de dados. No entanto, muitos pedem por melhores es­cla­re­ci­men­tos sobre o tema.

Há uma pre­o­cu­pa­ção para com aqueles que preferem per­ma­ne­cer anônimos e, ainda assim, desejam acesso total aos dados. Além disso, há uma demanda por di­re­tri­zes que definam, em casos como este, se o acessos a dados de domínios também devem ser con­ce­di­dos a usuários de outro país. Em relação ao Whois, o RDAP tem como pri­o­ri­dade proteger dados de usuários e confiar no ad­mi­nis­tra­dor do site cujo domínio foi re­gis­trado. De forma nenhuma essa confiança deve ser com­pro­me­tida pela nova tec­no­lo­gia de so­li­ci­ta­ções do RDAP.

Ao final de 2016, vários núcleos de in­for­ma­ção e co­or­de­na­ção apelaram contra o período de im­ple­men­ta­ção imposto pela ICANN, o que fez com que a or­ga­ni­za­ção optasse por es­ta­be­le­cer contratos junto a re­gis­tra­do­res e pro­ve­do­res relativos à transição ao RDAP.