Resumo

  • Uma manifestação apresentada em 16 de outubro pede que a ICANN alinhe sua avaliação da automação de registros DS no DNSSEC à RFC 10026, orientação operacional já publicada pelo IETF.
  • O relatório de junho diz em um trecho que a automação deve parar diante de um bloqueio do registry, mas depois afirma que a automação executada pelo próprio registry pode prosseguir. O requisito obrigatório HR-4 menciona apenas o bloqueio do registrador.
  • A ICANN diz que vai analisar as manifestações e poderá atualizar a avaliação. O prazo termina em 23 de novembro, e o relatório de comentários está previsto para 7 de dezembro; não há decisão final nem texto contratual publicado.

A pergunta não é se a automação de DNSSEC deve existir, mas qual ator é limitado por um bloqueio de registro quando se altera um registro DS na zona pai. É esse o ponto levantado na consulta pública sobre a avaliação de segurança e estabilidade da ICANN para automação de DS.

Quynh Nguyen escreveu, em 16 de outubro, que a avaliação cobre as principais questões, mas deveria adotar uma posição única sobre serverUpdateProhibited. Ela informa que se manifesta em caráter individual; o comentário não é uma conclusão da ICANN nem consenso da comunidade. Ainda assim, a regra pode afetar o desenho do Fast-Track RSEP que a organização pretende oferecer aos operadores de registry interessados em automatizar a manutenção de DS. A ICANN diz que a avaliação servirá de base técnica para esse processo.

O relatório da Interisle Consulting Group está datado de 23 de junho de 2026. Na seção 4.4, ele adota a posição de que a manutenção automática de DS deveria ser suspensa quando serverUpdateProhibited está ativo. O mesmo trecho registra que o rascunho do IETF então citado defendia o contrário para a automação conduzida pelo registry: o status manda o servidor EPP rejeitar pedidos de atualização feitos pelo registrador, mas não impede que o próprio registry altere os dados.

O rascunho virou a RFC 10026, publicada em julho como Best Current Practice 246. A seção 6.1(2) determina que, quando o registry realiza a manutenção de DS, a automação não deve ser suspensa apenas pela presença de serverUpdateProhibited. A seção 6.2.1 explica a diferença entre os atores: o status impede atualizações EPP do registrador, mas não o processo executado pelo registry; uma notificação ao registrador ajuda a tornar a mudança visível.

Há também uma tensão dentro da própria avaliação. A seção 4.7 diz que a implantação pode seguir sob clientUpdateProhibited e serverUpdateProhibited; a seção 6.1 volta a dizer que esses bloqueios não exigem a suspensão da manutenção rotineira quando o registrador pode optar por não participar da automação do registry. Mas o requisito HR-4 só afirma expressamente que clientUpdateProhibited não deve, sozinho, interromper a automação. Nguyen pede que a ICANN publique uma regra coerente com a RFC 10026.

A cronologia acrescenta outra referência. Em 31 de agosto, o SSAC publicou a SAC126v2, atualizando seu parecer para refletir a RFC 10026. O comitê diz que a norma resolveu a questão da seção 4.4 da versão anterior e que a SAC126v1 foi retirada. A avaliação de junho, portanto, antecede tanto a RFC final quanto a orientação atualizada do SSAC.

A manifestação propõe ainda critérios e prazos de nova tentativa quando um servidor autoritativo é considerado permanentemente inacessível; tratamento para rotações de chave atrasadas por respostas inconsistentes; divulgação dos efeitos da remoção de um DS; e regras mínimas de notificação e auditoria para mudanças aceitas e rejeitadas. São propostas de uma pessoa, não obrigações já adotadas.

A página da consulta diz que a ICANN publicará um resumo, analisará as contribuições e poderá atualizar a avaliação em um adendo. O prazo termina em 23 de novembro de 2026; o relatório é esperado em 7 de dezembro. A minuta contratual do Fast-Track será submetida a uma consulta posterior. Nem o relatório nem o comentário aprovam uma implantação ou antecipam o texto que virá.

Fontes