Resumo

  • A AFPUB-2012-DNS-001-DRAFT-01, apresentada por Tim McGinnis em 10 de abril de 2012, propôs condicionar novas delegações de DNS reverso ao registro adequado da atribuição ou subalocação correspondente na base da AFRINIC.
  • A proposta identificou um problema operacional real: cadastros de atribuições downstream incompletos reduzem a utilidade do registro público de responsabilidade e dificultam a correspondência entre o espaço administrado, quem o utiliza e a zona reversa solicitada.
  • O remédio escolhido transformava uma divergência cadastral em indisponibilidade de um serviço técnico valioso, mas a Draft 1 não especificava teste de falso negativo, decisão motivada, prazo de correção, revisão independente nem rollback rápido.
  • A seção 3.3 foi uma contenção importante: delegações reversas aprovadas antes de eventual ratificação não seriam removidas; apenas alocações posteriores seriam atingidas. A Draft 1, portanto, não autorizava a retirada retroativa das delegações já existentes.
  • A discussão de 18 de maio de 2012 registrou dúvidas sobre eficácia, carga de trabalho e consentimento para varreduras, além de não consenso. Os números apresentados — mais de 60% dos provedores com atribuições registradas e perto de 40% sem nenhuma — permaneceram afirmações atribuídas, sem denominador, consulta, data de extração ou auditoria publicada.
  • A solução durável é uma secretaria registral enxuta: autenticar pedidos, apontar o objeto e a zona exatos, aceitar prova corretiva, manter histórico, preservar o último estado funcional verificado e encaminhar disputas de direito a um foro independente. Recusar ou retirar DNS reverso nunca deve ser descrito como exercício legítimo de punição estatal.

Uma proposta curta com uma consequência concreta

O título “No Reverse Unless Assigned” condensava uma ideia fácil de comunicar: não haveria DNS reverso sem uma atribuição registrada. A aparente simplicidade, entretanto, escondia duas operações diferentes. Uma era melhorar a qualidade de um cadastro público de redes. A outra era decidir se um operador poderia obter uma nova delegação na hierarquia de DNS reverso. O primeiro objetivo dizia respeito à qualidade do livro de registros; o segundo tocava uma dependência técnica usada por serviços, sistemas de reputação, ferramentas administrativas e pessoas que precisam associar um endereço a um nome.

A minuta inicial, identificada como AFPUB-2012-DNS-001-DRAFT-01, foi submetida em 10 de abril de 2012 por Tim McGinnis. O texto dizia alterar a AFPUB-2005-v4-001. O registro preservado da AFRINIC mostra três dispositivos operacionais. A seção 3.1 tratava da condição para novas delegações reversas. A seção 3.2 previa lembretes a LIRs que já tivessem DNS reverso para suas alocações, mas nenhum registro de atribuição ou subalocação. A seção 3.3 protegia delegações aprovadas antes da ratificação e limitava o alcance às alocações posteriores.

Essas três peças precisam ser lidas juntas. Isolar a seção 3.1 produz a impressão de uma regra geral e imediata. Ignorar a seção 3.3 produz um erro histórico ainda maior, como se a Draft 1 houvesse proposto apagar delegações existentes. Não propôs. Ela condicionava a concessão de uma nova delegação e previa contato com detentores de delegações já existentes, mas dizia expressamente que as delegações anteriores não seriam removidas. Essa cláusula de anterioridade não resolvia os defeitos de processo, porém reduzia o universo de mudanças capazes de atingir um estado operacional em funcionamento.

Uma segunda minuta surgiu depois e pertence a outro objeto editorial. Nada de seu desenho posterior deve ser projetado retroativamente sobre o texto de 10 de abril de 2012.

O foco, portanto, não é decidir se o DNS reverso é “bom” ou “ruim”, nem oferecer uma aula geral sobre DNS. É testar uma decisão administrativa precisa: quando um cadastro não mostra o que a secretaria espera encontrar, que constatação é suficiente para recusar uma nova configuração técnica? Quem recebe aviso? Qual informação precisa constar desse aviso? Como o solicitante prova que o cadastro está atrasado, foi interpretado na granularidade errada ou já está sendo corrigido? Quem revisa um erro da própria equipe? E como se evita que uma ferramenta de coordenação passe a funcionar como instrumento de coerção?

O problema de cadastro que a Draft 1 tentou alcançar

A justificativa da proposta partia de uma observação defensável. Um registro público de informações de rede tem valor quando permite identificar, de maneira suficientemente atual, a responsabilidade operacional por blocos atribuídos ou subalocados. A Draft 1 descrevia a base como um meio de publicar informações de contato sobre redes públicas por meio do registro de atribuições. Também citava a seção 9.5 da política anterior, segundo a qual o registro na base Whois da AFRINIC participaria da validade de uma atribuição.

Esse vocabulário exige cuidado. A base pode ser evidência importante de uma relação administrativa. Pode ajudar uma equipe de resposta a incidentes a localizar contato. Pode mostrar como um detentor organizou o uso downstream de um bloco. Pode permitir à secretaria verificar se o pedido de delegação se refere ao espaço correto. Não se segue daí que a linha ausente na base prove que o espaço está abandonado, ocioso, usado ilegalmente ou sujeito a perda. Um registro é uma representação de fatos operacionais; não é o próprio fato, muito menos uma sentença sobre direitos.

Na AFRINIC-16, em 18 de maio de 2012, a motivação foi apresentada em termos de exatidão das atribuições downstream. O relato oficial atribui ao autor a informação de que mais de 60% dos provedores haviam registrado atribuições, enquanto perto de 40% não haviam registrado nenhuma. Também registra a ideia de criar um incentivo antes do momento em que um membro voltasse a pedir mais espaço e encontrasse a verificação então associada a um patamar de 80%.

Os números ajudam a entender a preocupação, mas não sustentam conclusões mais fortes. O relato não publica o denominador, a consulta usada, a data da fotografia da base, o critério para definir “provedor”, a distribuição por tipo de titular nem uma auditoria independente. “Perto de 40% sem nenhuma atribuição registrada” não equivale a “perto de 40% sem uso downstream”, assim como uma base incompleta não permite calcular, por si só, a extensão do uso não documentado. O dado é uma afirmação atribuída durante uma apresentação, não um censo validado.

Mesmo assim, o mecanismo proposto respondia a uma dificuldade de incentivos reconhecível. Se a conferência mais rigorosa aparecesse apenas quando o membro solicitasse mais endereços, um detentor sem pedido iminente poderia adiar a limpeza de seus registros. Vincular a correção a um serviço desejado criaria um momento adicional de verificação. Esse é o argumento mais forte a favor da Draft 1: a AFRINIC precisaria configurar a delegação em seu lado da hierarquia e poderia pedir evidência cadastral precisa antes de fazê-lo.

O argumento sustenta uma validação técnica. Não sustenta uma teoria de punição. A diferença está no propósito e no processo. Uma validação pergunta: “Temos evidência suficiente para criar corretamente esta delegação específica?” Uma alavanca punitiva diz, na prática: “Negaremos um serviço porque queremos forçar o cumprimento de uma obrigação administrativa separada.” A mesma ação externa — não configurar uma delegação — pode encobrir racionalidades muito diferentes. É por isso que motivo declarado, fato constatado, escopo da zona, possibilidade de correção e revisão importam tanto.

O que o DNS reverso faz — e o que ele não faz

No IPv4, o DNS reverso usa zonas sob IN-ADDR.ARPA e registros PTR para associar endereços a nomes. Em termos simplificados, a consulta parte da representação invertida do endereço e procura um registro que aponte para um nome. A delegação da zona permite que a organização responsável publique ou administre essas respostas na parte apropriada da árvore.

Isso não participa da decisão básica de roteamento de pacotes. Um endereço sem PTR não deixa automaticamente de receber ou enviar tráfego. A ausência de DNS reverso não prova uma interrupção da Internet, e a documentação selada não identifica qualquer incidente, cliente ou fluxo de correio prejudicado pela Draft 1. A proposta não obteve consenso no registro de 2012 capturado, e não há base para inventar uma recusa ou um apagão que ela tenha causado.

Ao mesmo tempo, “a rede roteia” é um padrão estreito demais para medir o valor operacional. Orientações técnicas históricas recomendam consistência entre registros PTR e os registros de nomes correspondentes e alertam que mapeamentos ausentes ou incompatíveis podem provocar problemas de acesso ou serviço. Sistemas podem usar a presença ou coerência do reverso como um sinal entre vários. Operadores podem depender dele para diagnóstico, identificação, registro de eventos e administração. Diferentes serviços tratam a ausência de formas diferentes; nenhum efeito universal deve ser presumido.

Essa posição intermediária é essencial. Exagerar o papel do PTR transforma toda recusa em queda de conectividade, o que os fatos não permitem. Minimizar seu papel como um detalhe cosmético ignora por que a proposta o considerou um incentivo. DNS reverso é uma superfície operacional estreita, mas valiosa. Justamente por ser valiosa, sua gestão precisa de disciplina de continuidade.

A seção 3.1 e a ambiguidade de “aquele espaço”

A seção 3.1 propunha que a AFRINIC deixasse de conceder delegação reversa para espaço de endereços IP administrado por ela, a menos que uma atribuição ou subalocação daquele espaço estivesse devidamente registrada na base. A frase contém a condição, mas não contém um método completo para avaliá-la.

Primeiro, “devidamente registrada” pode significar existência, correção formal, correspondência exata, atualidade, autenticação ou uma combinação desses elementos. Um objeto pode existir e conter um contato desatualizado. Pode refletir uma subalocação mais ampla que engloba a zona solicitada. Pode haver uma atualização autenticada em processamento. Pode ter ocorrido um erro de digitação ou uma incompatibilidade entre o formato consultado pela equipe e a forma em que o solicitante registrou os dados. A Draft 1 não hierarquizava essas possibilidades.

Segundo, “aquele espaço” não definia a granularidade da correspondência. A minuta não dizia, no material selado, como alinhar o objeto cadastral com a zona reversa específica. Não é legítimo preencher essa lacuna com critérios de versões posteriores. Sem regra de correspondência, duas equipes poderiam olhar a mesma base e chegar a conclusões diferentes: uma aceitaria um objeto abrangente; outra exigiria uma entrada que coincidisse de forma mais estreita com o pedido.

Terceiro, o texto passava depressa da ausência percebida para a consequência. Não especificava uma declaração de motivos que identificasse o objeto procurado, a consulta realizada, o horário da verificação, a zona afetada e o requisito não atendido. Sem isso, o solicitante teria de adivinhar qual linha corrigir. A organização talvez atualizasse o objeto errado, fragmentasse desnecessariamente um registro ou abrisse sucessivos contatos com a secretaria enquanto a delegação permanecesse pendente.

Quarto, a proposta não distinguia indisponibilidade temporária, atraso de replicação, falha de autenticação e inexistência substantiva. Em um sistema vivo, esses estados não são equivalentes. Uma leitura ausente em um momento não autoriza a conclusão de que nenhum registro foi enviado. Um objeto que não corresponde ao filtro adotado não prova que o operador omitiu a informação. Uma divergência precisa ser investigada como divergência, não convertida em juízo moral.

A seção 3.2 e o vazio entre lembrete e decisão

A seção 3.2 previa contato com LIRs que tivessem DNS reverso para alocações sem atribuições ou subalocações registradas. MyAFRINIC e email apareciam como canais imaginados, e os detalhes ficavam a cargo da equipe da Secretaria. A escolha de canais conhecidos poderia favorecer autenticação e rastreabilidade. Mas “enviar lembretes” é só o começo de um processo.

Um aviso útil precisa dizer mais do que “seu cadastro está incompleto”. Ele deve identificar o intervalo ou objeto relevante, a zona reversa relacionada, o estado observado, o requisito aplicado e a ação necessária. Deve informar como contestar a correspondência, como demonstrar que uma atualização já foi submetida, qual prazo de atendimento a secretaria assume e o que acontece enquanto a divergência é examinada.

O texto não dava essas respostas. Tampouco definia se o email seria apenas informativo, se a mensagem na conta seria o canal determinante, como lidar com contato desatualizado ou como confirmar o recebimento. Silêncio não pode ser convertido automaticamente em abandono, concordância ou confissão. Uma caixa postal pode falhar; uma conta pode estar em transição; uma pessoa pode ter mudado de função. O cadastro precisa ser corrigido, mas a própria imperfeição do cadastro aconselha contra presumir que a comunicação foi perfeita.

Também faltava um caminho de revisão. Se a equipe interpretasse de modo incorreto o objeto ou a zona, a mesma equipe que produziu a negativa seria chamada a reconsiderá-la sem critérios públicos. Revisão independente não precisa transformar cada pedido técnico em litígio. Pode ser uma segunda análise separada, com registro do fundamento, autoridade limitada para suspender a consequência e prazo curto. O ponto é impedir que um erro inicial se consolide por inércia.

A seção 3.3 como contenção de continuidade

A seção 3.3 dizia que a AFRINIC não removeria delegações reversas de alocações de LIR aprovadas antes da ratificação; apenas alocações posteriores seriam afetadas. Essa é a fronteira histórica mais importante da Draft 1. O texto não propôs uma campanha retroativa de retirada. LIRs com delegações anteriores seriam lembrados sobre o cadastro, mas o estado funcional seria preservado.

Do ponto de vista de continuidade, a escolha tinha mérito. Uma delegação já testada contém informação sobre o último estado conhecido que funcionou. Mantê-la enquanto o cadastro é reparado evita que uma divergência administrativa produza uma mudança operacional adicional. O livro pode receber correções sem que a página operacional seja rasgada antes de se saber qual dado está errado.

O grandfathering, contudo, criava uma diferença entre situações semelhantes conforme o momento da alocação. Um operador anterior poderia manter a delegação durante a correção; um operador posterior poderia encontrar a barreira ao pedi-la. Isso não torna a proteção errada. Mostra apenas que preservar o passado funcional não substitui um devido processo para pedidos novos. O novo solicitante também precisa saber exatamente por que sua delegação não pode ser configurada, o que corrigir e como obter uma revisão rápida.

A contenção deve, portanto, ser reconhecida sem ser idealizada. A seção 3.3 reduzia o raio de impacto e bloqueava a leitura retroativa. Não criava teste de falso negativo, padrão de prova, prazo, revisão nem rollback. Era um limite útil dentro de uma arquitetura incompleta.

O debate de 18 de maio e o não consenso

O relatório da AFRINIC-16 registra que Tim McGinnis apresentou a proposta depois de se retirar da função de co-chair para aquele item. Isso delimitava os papéis na discussão, mas não altera a natureza privada do processo. A publicação, a reunião, a lista e a atuação dos co-chairs registram uma deliberação institucional; não criam por si sós autoridade pública sobre operadores, usuários ou direitos em disputa.

Participantes questionaram se o mecanismo produziria o efeito desejado. A observação de que a Internet pode funcionar sem DNS reverso atacava diretamente a força do incentivo. Se alguns operadores pudessem simplesmente dispensar o serviço, a medida talvez atingisse sobretudo aqueles cujas práticas ou clientes valorizavam o reverso, sem necessariamente corrigir os piores cadastros. Uma alavanca desigual pode melhorar algumas linhas do banco de dados e ainda assim não oferecer uma medida confiável de completude geral.

Também surgiram preocupações com a carga da equipe. Transformar um requisito aparentemente automático em processo seguro exige trabalho: verificar objetos, responder a contestação, acompanhar atualizações, distinguir falha de sistema de falta material e registrar decisões. Se a política não contabiliza essa capacidade, o incentivo à exatidão pode produzir uma fila de delegações pendentes e correções sem prazo.

A discussão incluiu ainda a possibilidade de varredura de portas e a necessidade de consentimento. O registro não autoriza concluir que a varredura foi adotada ou praticada. O episódio revela uma questão de método: a vontade de medir uso ou validar um cadastro não dá à secretaria licença geral para sondar redes. Qualquer verificação ativa precisaria de finalidade estreita, consentimento, segurança, minimização e transparência. Para a Draft 1, o caminho mais seguro era basear a decisão no pedido autenticado e em evidência fornecida ou verificável no próprio sistema registral, não em investigação ampla do comportamento da rede.

O relatório registra ausência de consenso e retorno à lista. Os slides da AFRINIC-17 ainda identificavam a Draft 1 como versão corrente em 29 de novembro de 2012 e reproduziam seus dispositivos. O relatório anual de 2012 inclui a proposta entre as discutidas e diz que as propostas na AFRINIC-17 não obtiveram consenso. Esses documentos provam texto, datas, apresentação e resultado registrado. Não provam que a proposta era legítima, que foi implementada, que seus números estavam corretos ou que o processo representava todos os sujeitos potencialmente afetados.

O não consenso também não é sentença técnica. Ele não demonstra que registros incompletos eram irrelevantes, nem que toda condição para uma nova delegação seria indevida. Mostra que a Draft 1 não atravessou o processo capturado como uma regra consensual. A análise de mérito precisa continuar a partir do que o texto propôs e deixou de propor.

Uma secretaria fina, não um poder de punição

A AFRINIC pode ser descrita, neste contexto, como operadora privada de serviços de registro, escriturária e coordenadora técnica regional. Ela mantém registros, autentica solicitações e realiza configurações em sistemas sob sua operação. Essas tarefas podem ser indispensáveis para a coordenação cotidiana. Indispensabilidade funcional não é soberania.

Uma reunião de política não transforma participantes em legisladores. Consenso alegado não cria jurisdição estatal. Dependência técnica não converte equipe privada em polícia, Ministério Público ou tribunal. O fato de um cadastro ser oficial dentro de um sistema não autoriza a entidade que o mantém a decidir, por conta própria, controvérsias de direito ou a confiscar recursos. E a palavra “enforcement”, usada pela própria Draft 1 para descrever seu mecanismo, registra a intenção do texto; não fornece o poder público que o termo pode sugerir.

É legítimo que uma secretaria se recuse temporariamente a executar uma alteração que não consegue configurar com segurança. Se o pedido não está autenticado, se a zona não corresponde ao espaço administrado ou se falta informação indispensável para construir a delegação correta, a equipe pode pedir esclarecimento. Essa recusa deve ser entendida como estado técnico pendente e limitado ao pedido, nunca como pena por desobediência.

O limite aparece quando a ausência de uma linha é tratada como licença para impor perda operacional, inferir culpa ou resolver disputa de titularidade. Nesse ponto, o livro deixa de descrever e passa a condenar. A arquitetura correta protege o livro sem proteger o excesso do gatekeeper: mantém registros precisos e serviços contínuos, mas nega à entidade privada o papel de soberano.