Resumo

  • A RFC 1591 dizia que a IANA criaria o Internet DNS Names Review Board (IDNB) para resolver disputas não solucionadas sobre quem deveria administrar um domínio de topo; suas decisões seriam vinculantes.
  • Documentos do ccNSO de 2017 e 2024 registram que o IDNB nunca foi criado. Uma política diferente para revisão de ccTLD, com resultado não vinculante, foi aprovada em 2025; em maio de 2026, o relatório ICANN86 ainda a classificava como em planejamento de implementação.

Uma frase da RFC 1591 parece oferecer a palavra final. Se as partes que disputavam a administração de um domínio de topo não chegassem a um acordo, o Internet DNS Names Review Board atuaria como painel de revisão. Suas decisões seriam vinculantes. Jon Postel incluiu essa previsão no memorando de março de 1994 sobre estrutura e delegação do Sistema de Nomes de Domínio.

O conselho chama atenção porque a RFC não se limitava a listar requisitos técnicos para um registro. Ela também esboçava como resolver a disputa sobre quem deveria administrar um domínio e previa uma instância capaz de decidir o conflito. Mas documentos posteriores do ccNSO dizem que a IANA nunca criou o IDNB — e que nenhuma outra entidade o fez. O texto descrevia um órgão planejado, não uma instituição comprovadamente operacional.

A própria RFC definia seu alcance. Classificada como “Informational”, ela afirmava que não especificava nenhum padrão da Internet. Atribuía à IANA a coordenação geral do DNS e dizia que o Internet Registry central — então o InterNIC — cuidava de boa parte da administração diária. Cada domínio deveria ter um administrador designado. Para um ccTLD, o contato administrativo deveria residir no país, e o gestor precisava operar servidores de nomes com competência.

O memorando descrevia esse gestor como guardião do domínio, responsável tanto perante a comunidade nacional quanto perante a comunidade global da Internet. Propriedade, dizia, era a pergunta errada; importavam as responsabilidades e o serviço. O gestor também deveria tratar os solicitantes de modo equitativo, sem privilegiar os clientes de uma empresa de redes ligada a ele. Subdomínios poderiam manter seus próprios servidores, desde que as informações fossem verdadeiras e corretas.

A escolha do administrador dependia de participação, mas não se encerrava nela. As partes “significativamente interessadas” deveriam concordar que o candidato era adequado. A IANA tentaria obter consenso e, em geral, não mudaria uma delegação existente sem a concordância de todos os concorrentes, salvo má conduta substancial do gestor. Os interessados deveriam ter “alguma voz” na escolha. Se a disputa não fosse resolvida ou um candidato não pudesse representar o país inteiro, a IANA e o registro central poderiam delegar somente uma parte do domínio. Para o desacordo restante, a RFC nomeava o IDNB como painel cujas decisões seriam vinculantes.

Essa sequência separava a voz das partes do ato de decidir. Ser ouvido não significava resolver automaticamente a disputa. O gestor tinha deveres operacionais; a IANA mantinha o papel de coordenação descrito no memorando; e o IDNB deveria ser a etapa decisória quando o acordo falhasse. Saber se o conselho existiu, portanto, define se o procedimento escrito tinha um destino concreto.

Em junho de 1996, outro Internet-Draft de Postel levou a ideia do IDNB a uma proposta para novos domínios internacionais, como COM, ORG e NET. O texto ampliava a atuação do conselho para recursos técnicos sobre o processo proposto e dividia tarefas entre IANA, IETF, ISOC e um grupo ad hoc. Mas o Datatracker o classifica como um Internet-Draft individual, sem endosso do IETF e sem posição formal no processo de padronização. O documento expirou em dezembro de 1996. Ele prova que a ideia foi reaproveitada numa proposta, não que o órgão tenha sido criado nem que a proposta tenha virado política.

A ausência foi registrada expressamente depois. Uma carta de grupo de trabalho do ccNSO, adotada em março de 2017, diz que o IDNB nunca foi estabelecido pela IANA nem por qualquer outra entidade. O documento também apontava que decisões de delegação, transferência e revogação de ccTLD não tinham mecanismo de revisão ou recurso naquele momento. O relatório final do ccNSO de setembro de 2024 repetiu a informação e disse que essas decisões ainda não estavam sujeitas a revisão independente. Esses registros descrevem uma lacuna institucional; não provam que toda disputa ficou sem resposta nem esclarecem casos específicos.

O desfecho posterior não foi a criação tardia do IDNB. Em 8 de junho de 2025, o Conselho da ICANN aprovou uma política diferente de revisão de ccTLD, desenvolvida pelo ccNSO. O anúncio descreveu uma via independente para revisar decisões específicas do Operador da Função IANA, mas destacou que o resultado não seria vinculante. O Relatório de Perspectivas de Políticas do ICANN86, publicado em 14 de maio de 2026, ainda indicava “planejamento de implementação”. O escopo, o contexto institucional e o efeito dessa política diferem do conselho imaginado em 1994. Não são o mesmo mecanismo.

A distinção histórica é simples, mas importante. A RFC 1591 reconhecia o interesse das partes afetadas na escolha do gestor, colocava serviço e equidade acima de reivindicações de propriedade e previa uma instância vinculante caso o acordo falhasse. Ainda assim, mencionar um conselho num documento não significa que ele tenha sido instalado. Os esforços seguintes tiveram de partir dessa ausência e percorrer outro processo de política. A participação oferece conhecimento, objeções e provas; um mecanismo de revisão também exige órgão, escopo, procedimento e consequência definidos. Na história do DNS, essas peças não chegaram juntas.

Fontes