Resumo

  • Publicada em 29 de setembro, a revisão 03 de draft-brown-epp-deleg acrescenta <deleg:all/> dentro de <deleg:rem>. Um cliente pode propor a retirada de todos os registros DELEG do domínio indicado, sem enumerá-los. A revisão 02 não oferecia essa forma.
  • O texto continua sendo um Internet-Draft individual, não uma RFC aprovada nem prova de adoção por algum registro. “Todos” refere-se a DELEG daquele domínio; a ordem não cancela o domínio nem remove os NS convencionais.

Uma lista de registros a remover também funciona como delimitação da decisão. Quem aprova a alteração consegue ler quais itens foram apontados. Com uma instrução para remover “todos”, a contagem final depende do estado encontrado pelo servidor na hora da execução. Essa é a mudança material da nova revisão do rascunho EPP DELEG. Ela descreve uma possibilidade de protocolo, não uma exclusão observada em produção.

Na seção 5.2.2, a atualização de domínio pode conter registros deleg:deleg individualmente nomeados para remoção ou o elemento vazio <deleg:all/>, que indica a retirada do conjunto DELEG completo. O exemplo do documento mostra uma atualização que retira todos e não acrescenta outros. A versão anterior só permitia identificar os itens. Se a opção vier a ser implementada, um cliente poderá pedir o estado DELEG vazio sem primeiro listar todos os registros presentes.

É indispensável preservar o complemento da palavra “todos”. A operação pertence à extensão DELEG. Ela não é uma exclusão do objeto domínio, dos objetos de host ou de todos os dados de DNSSEC. A seção 6 prevê DELEG coexistindo com os tradicionais registros NS. Além disso, uma resposta positiva de EPP não demonstraria, por si só, que os servidores autoritativos já publicaram o novo estado, muito menos que os resolvedores abandonaram cópias em cache. Aprovisionamento, publicação em DNS e observação pelos leitores precisam de provas separadas.

A revisão 03 também reorganiza a representação dos parâmetros. Os atributos antigos em deleg:params dão lugar a elementos deleg:param; o namespace XML proposto passa de deleg-0.01 a deleg-0.02; e os campos priority e target deixam o esquema antigo. A BTW havia examinado a divergência entre esses campos na revisão 02 e a proposta RDAP correspondente. A nova redação reduz aquela divergência textual específica, mas não prova uma transformação operacional completa entre EPP, DNS e RDAP. A questão deste artigo é a autorização para uma remoção coletiva recém-proposta.

A seção de segurança propõe rejeitar nomes de parâmetros desconhecidos e valores inválidos, enquanto clientes e servidores atualizariam periodicamente as listas de chaves registradas. Validar dados não autentica a intenção de esvaziar um conjunto inteiro. Tampouco a menção a chaves registradas confirma que o registro da IANA já existe: a revisão 11 do texto central DELEG ainda solicita a criação de um registro de Delegation Information. São modelos em discussão, não obrigações comprovadamente implantadas.

O Datatracker classifica a extensão EPP como Internet-Draft individual ativo, sem fluxo RFC, responsável de área ou teleconferência de aprovação, com estado IESG “I-D Exists”. O anúncio de 29 de setembro atesta a disponibilização da revisão, não consenso, produto, implantação ou incidente. A consequência institucional é prospectiva: credenciais que ajustam entradas isoladas não deveriam virar, sem decisão explícita, credenciais para remover a coleção inteira.

Fontes