An­te­ri­or­mente, era possível saber quem era o pro­pri­e­tá­rio de um domínio através de um serviço Whois, baseado no protocolo com o mesmo nome. No entanto, em 2015, a IETF (Internet En­gi­ne­e­ring Task Force) e a ICANN (Internet Cor­po­ra­tion for Assigned Names and Numbers) definiram as primeiras Request for Comments (RFC) do protocolo RDAP (Re­gis­tra­tion Data Access Protocol), que acabará por subs­ti­tuir o Whois.

O que é o RDAP (Re­gis­tra­tion Data Access Protocol)?

O Protocolo de Acesso a Dados de Registo (RDAP) foi criado pelo Grupo de Trabalho de En­ge­nha­ria da Internet (Internet En­gi­ne­e­ring Task Force, IETF). Após apenas 4 anos de projeto, em 26 de julho de 2016 foi lançada a primeira versão do perfil do protocolo (1.0), cujas ca­rac­te­rís­ti­cas e aplicação estão descritas em di­fe­ren­tes Requests for Comments (RFC 7480-7484 e RFC 8056). O protocolo RDAP oferece a pos­si­bi­li­dade de obter in­for­ma­ções adi­ci­o­nais sobre recursos fun­da­men­tais da Internet, tais como

  • nomes de domínio,
  • endereços IP ou
  • Números de Sistema Autónomo (ASN),

mas também de obter registos re­la­ci­o­na­dos. Para tal, esta al­ter­na­tiva ao Whois oferece a base para formular pedidos às di­fe­ren­tes au­to­ri­da­des de registo de domínios, in­for­ma­ções que abrangem, por exemplo, os dados de contacto dos pro­pri­e­tá­rios dos domínios, os dados de contacto dos res­pon­sá­veis ad­mi­nis­tra­ti­vos (Admin C) ou o endereço do servidor de nomes utilizado, incluindo os ad­mi­nis­tra­do­res das suas bases de dados.

Por que razão está a ser de­sen­vol­vido o RDAP?

O protocolo Whois foi publicado em 1982 pela IETF com o objetivo de im­ple­men­tar um serviço de consulta para a rede de com­pu­ta­do­res ARPANET e o facto de continuar a ser utilizado hoje, após mais de um quarto de século, é, para muitos es­pe­ci­a­lis­tas, um obstáculo. Neste sentido, o aspeto mais cri­ti­cá­vel é que o Whois já não satisfaz os re­qui­si­tos técnicos nem da Internet nem da Web.

Isto refere-se, por exemplo, ao problema de o protocolo de consultas não se en­car­re­gar da co­di­fi­ca­ção e, por con­se­guinte, não suportar alfabetos não latinos (o que exclui a uti­li­za­ção, por exemplo, do acento cir­cun­flexo). A situação é ainda agravada pelo facto de o acesso aos dados de domínio não ser efetuado através de uma ligação segura nem ser regulável, e de os uti­li­za­do­res anónimos terem acesso total ao correio ele­tró­nico e aos endereços.

A im­ple­men­ta­ção do Whois++ e o protocolo IRIS (Internet Registry In­for­ma­tion Service) do grupo Denic in­tro­du­zi­ram as primeiras melhorias, embora estas não tenham con­se­guido es­ta­be­le­cer-se como al­ter­na­ti­vas du­ra­dou­ras ao Whois. Após um longo período em que também surgiram dis­cus­sões na co­mu­ni­dade da ICANN sobre a im­por­tân­cia de realizar im­ple­men­ta­ções, o relatório de segurança SAC 051 do Security and Stability Advisory Committee (SSAC), de setembro de 2011, foi de­ter­mi­nante para a criação do grupo de trabalho do RDAP.

Em janeiro de 2023, a ICANN realizou uma votação a nível mundial para decidir se o WHOIS seria ofi­ci­al­mente subs­ti­tuído pelo RDAP. Uma vez que foi atingido o número ne­ces­sá­rio de votos para que isso acon­te­cesse, foi tomada a decisão de im­ple­men­tar ofi­ci­al­mente a mudança para o RDAP. A partir de janeiro de 2025, os registos DNS e os re­gis­ta­do­res deixarão de ser obrigados a ser com­pa­tí­veis com o WHOIS.

Como funciona o RDAP?

Para uma im­ple­men­ta­ção do RDAP, é im­por­tante com­pre­en­der o fun­ci­o­na­mento do protocolo tanto do lado do cliente como do lado do servidor. Para tal, pode consultar-se os RFC 7480 a 7484, que descrevem em pormenor uma im­ple­men­ta­ção mínima do protocolo. Além disso, existem outros RFC que descrevem extensões do protocolo RDAP. A seguir, é explicado o pro­ce­di­mento do protocolo através de HTTPS, tal como descrito na RFC 7840.

Dica

Para facilitar a im­ple­men­ta­ção do protocolo aos pro­gra­ma­do­res, a ICANN dis­po­ni­bi­li­zou um guia para a im­ple­men­ta­ção do RDAP.

Tarefas do cliente

A im­ple­men­ta­ção do RDAP no lado do cliente não é, de forma alguma, complexa. O RDAP baseia-se no HTTP e, por isso, utiliza os métodos HTTP já exis­ten­tes na trans­mis­são de dados. Os clientes podem enviar pedidos ao servidor uti­li­zando os métodos GET e HEAD. Tanto os pedidos GET como os HEAD devem incluir um cabeçalho «Accept», onde se es­pe­ci­fica quais os tipos de ficheiros JSON aceites pelo cliente.

Funções do servidor

Do lado do servidor, a im­ple­men­ta­ção é um pouco mais complexa, uma vez que o servidor tem de lidar com uma série de casos especiais. Caso a so­li­ci­ta­ção seja bem-sucedida, o servidor deverá devolver os dados so­li­ci­ta­dos no formato so­li­ci­tado com o código de estado HTTP 200 (OK). Nas so­li­ci­ta­ções GET, o servidor deve responder com os dados do pro­pri­e­tá­rio so­li­ci­tado e, nas so­li­ci­ta­ções HEAD, deve indicar se dispõe de dados para esse domínio.

Se o servidor souber onde se encontram os dados so­li­ci­ta­dos, mas não tiver acesso aos mesmos, res­pon­derá com um dos códigos de estado 301, 302, 303 ou 307. A URL onde os dados podem ser en­con­tra­dos é então enviada no cabeçalho HTTP «Location».

Se o servidor não conseguir processar o pedido porque os dados so­li­ci­ta­dos não estão dis­po­ní­veis, res­pon­derá com o código de estado 404 (não en­con­trado). Se os dados so­li­ci­ta­dos estiverem dis­po­ní­veis, mas o servidor responder por outro motivo, ele res­pon­derá com um código de estado da série 400. As so­li­ci­ta­ções que contenham erros e, portanto, não possam ser con­si­de­ra­das so­li­ci­ta­ções RDAP, serão res­pon­di­das com o código de estado 400 (Bad Request). Neste caso, é possível enviar in­for­ma­ções adi­ci­o­nais no corpo da entidade de so­li­ci­ta­ção HTTP.

Para obter in­for­ma­ções mais de­ta­lha­das sobre o pro­ce­di­mento, bem como sobre as opções de segurança e extensão do protocolo, pode consultar os RFC cor­res­pon­den­tes:

Em que é que o Protocolo de Acesso aos Dados de Registo difere do Whois?

O RDAP apresenta-se, em muitos aspetos, como uma versão melhorada do Whois. O grupo de trabalho da IETF trabalhou in­ten­sa­mente nas de­fi­ci­ên­cias do protocolo anterior e centrou-se sobretudo nos aspetos de segurança, es­tru­tu­ra­ção e in­ter­na­ci­o­na­li­za­ção ao de­sen­vol­ver o novo protocolo de consulta. Assim, esta al­ter­na­tiva ao Whois destaca-se pelas seguintes novidades:

  • Semântica es­tru­tu­rada de perguntas e respostas (incluindo mensagens de erro pa­dro­ni­za­das)
  • Acesso seguro aos dados de contacto so­li­ci­ta­dos (por exemplo, via HTTPS)
  • Ca­pa­ci­dade de expansão (por exemplo, através da in­tro­du­ção de elementos de saída)
  • Mecanismo de bo­ots­trap­ping (ajuda na procura do servidor DNS au­to­ri­ta­tivo adequado)
  • Trans­mis­são pa­dro­ni­zada das so­li­ci­ta­ções
  • Baseado na Web (HTTP) e em con­for­mi­dade com REST (Re­pre­sen­ta­ti­o­nal State Transfer)
  • Tradução simples dos dados de saída
  • Pos­si­bi­li­dade de fornecer acesso di­fe­ren­ci­ado aos dados de contacto

O Protocolo de Acesso a Dados de Registo (RDAP) é também mais flexível do que o seu an­te­ces­sor em muitos aspetos: enquanto o Whois está ligado ao TCP e a uma porta TCP es­pe­cí­fica (43) como protocolo baseado em texto, o RDAP recorre aos padrões web HTTP ou HTTPS para a trans­fe­rên­cia de dados. Assim, todos os dados são for­ne­ci­dos no formato JSON pa­dro­ni­zado e são legíveis por máquinas. Assim, a al­ter­na­tiva ao Whois oferece maior liberdade na consulta de dados e sim­pli­fica a pro­gra­ma­ção de serviços de consulta que comunicam com as di­fe­ren­tes au­to­ri­da­des de registo e emitem os dados so­li­ci­ta­dos em várias línguas.

RDAP Whois
Baseado em HTTP Baseado em texto
Formato JSON pa­dro­ni­zado Sem formato de co­di­fi­ca­ção
Os dados de saída são legíveis por máquinas e fáceis de traduzir Os dados de saída estão em formato de texto e não podem ser pro­ces­sa­dos me­ca­ni­ca­mente
As respostas re­di­re­ci­o­nam au­to­ma­ti­ca­mente para outras au­to­ri­da­des de registo As respostas não contêm dados de registo adi­ci­o­nais
Pos­si­bi­li­dade de definir per­mis­sões de acesso para vários grupos Não permite o acesso di­fe­ren­ci­ado aos dados

As au­to­ri­za­ções de acesso continuam a alimentar o debate

Uma das novas fun­ci­o­na­li­da­des mais im­por­tan­tes im­ple­men­ta­das no Protocolo de Acesso aos Dados de Registo é, sem dúvida, a pos­si­bi­li­dade de definir di­fe­ren­tes per­mis­sões de acesso para grupos de uti­li­za­do­res. Desta forma, a au­to­ri­dade de registo pode regular com precisão o tipo de dados que cada um pode utilizar. Assim, seria possível, por exemplo, conceder aos uti­li­za­do­res anónimos um acesso limitado, enquanto os uti­li­za­do­res au­ten­ti­ca­dos teriam acesso a todo o registo de dados. Neste ponto, muitos res­pon­sá­veis con­si­de­ram ne­ces­sá­rio fornecer os es­cla­re­ci­men­tos per­ti­nen­tes.

Entre outras questões, surge, por exemplo, a de como se podem evitar as ações de cri­mi­no­sos que per­ma­ne­cem anónimos com o objetivo de obter acesso aos dados. Além disso, não existem di­re­tri­zes sobre se, em casos como estes, devem ser con­ce­di­das au­to­ri­za­ções in­ter­na­ci­o­nais para aceder aos dados de domínio. Acima de tudo, prevalece a proteção dos dados dos uti­li­za­do­res e a confiança daqueles que registam os seus domínios, algo que não deve ser afetado pelo novo método de pedidos RDAP. Na sequência do recurso, no final de 2016, de vários registos contra o prazo de im­ple­men­ta­ção imposto pela ICANN, a or­ga­ni­za­ção está a planear in­tro­du­zir a al­ter­na­tiva RDAP através de contratos com as entidades de registo e os for­ne­ce­do­res de domínios.

Ir para o menu principal