Resumo

  • A consulta pergunta se a avaliação de segurança e estabilidade da automação DNSSEC de registros DS identifica os riscos e propõe controles suficientes, proporcionais e executáveis.
  • A conclusão favorável depende de sete requisitos obrigatórios e de sete divulgações por operador; ela não aprova automaticamente qualquer implementação.

O efeito dos bloqueios de registro é o ponto que a ICANN precisa esclarecer antes de acelerar a rota para DNSSEC. O aviso da consulta pública define o prazo e o escopo da análise.

Com data de 23 de junho, o relatório de 41 páginas avalia uma arquitetura delimitada. O operador da zona filha publica registros CDS ou CDNSKEY; o agente parental, em geral um registro ou registrador, valida o sinal antes de alterar o DS na zona pai. O escopo inclui manutenção, provisionamento inicial e a passagem para uma delegação sem DNSSEC. Notificações push, APIs fora de banda e atualizações CSYNC não estão incluídas. A conclusão, portanto, não se estende a qualquer forma de alteração de delegação nem certifica a operação de uma empresa. A avaliação da Interisle entende que o mecanismo não apresenta questão significativa de segurança ou estabilidade se as condições indicadas forem cumpridas.

São sete os requisitos que sustentam essa conclusão. Antes de publicar um DS, o sistema parental precisa verificar a correspondência com a DNSKEY da zona filha e a assinatura da chave; também deve consultar todos os servidores autoritativos e suspender a mudança diante de respostas inconsistentes. O operador deve manter uma interface manual, permitir que registradores optem por não usar a automação, tratar corretamente a retirada de todos os DS e avisar o registrador quando o próprio registro fizer a alteração.

Outros sete itens precisam ser documentados, como intervalo de varredura, limite de latência, política para múltiplos signatários e destinatários dos avisos. Quatro práticas recomendadas complementam a lista, mas não condicionam a conclusão positiva.

A lista separa o piso normativo das decisões locais. A consistência entre servidores, prevista no RFC 9975, é uma obrigação. Já a frequência de consulta, o canal de notificação e a janela de reversão variam por arquitetura. Precisam ser divulgados porque determinam quanto tempo uma chave incompatível pode passar despercebida e quem consegue iniciar a recuperação. O relatório observa que os RFCs em escopo não impõem um meio comum para comunicar atualizações aprovadas, rejeitadas ou divergentes. Um mecanismo pode ser tecnicamente verificável e ainda deixar registrantes sem uma confirmação útil.

A data do estudo abre outra linha de revisão. O documento está datado de 23 de junho; o RFC 10026 tornou-se Best Current Practice do IETF em julho. A página atual da consulta já lista o RFC 10026 entre os materiais de apoio, enquanto o texto da avaliação datada de junho preserva a cronologia anterior do rascunho. o RFC 10026 aborda verificações de aceitação, comunicação de resultados, bloqueios de registro e atualizações simultâneas. Isso não torna o estudo de junho inútil, mas permite aos participantes perguntar como os dezoito itens se alinham ao BCP 246 publicado e que evidência uma futura solicitação deverá apresentar.

A diferença aparece na análise de bloqueios do relatório. Ele adota a posição do SAC126: serverUpdateProhibited deve suspender a automação conduzida pelo registro, enquanto clientUpdateProhibited, por si só, não deve interrompê-la. A versão final do RFC 10026 segue a posição oposta para o bloqueio do registro: a automação do próprio registro não deve parar somente por esse estado, que o registro pode substituir; a opção de exclusão pelo registrador é o controle para manifestar preferência contrária. A lista consolidada de requisitos menciona expressamente o bloqueio do cliente, mas não formula uma regra paralela para o bloqueio do registro. Como a página atual da ICANN cita o RFC 10026, os comentários podem pedir qual regra valerá nos pedidos futuros e nas cláusulas contratuais.

Em setembro de 2025, o conselho da ICANN orientou a organização a criar uma rota RSEP rápida para operadores de registro, condicionada à ausência de problemas significativos de segurança ou estabilidade. O conselho tratou os registradores de modo diferente: eles podem implantar o serviço sem aprovação da ICANN. O RSEP mantém uma avaliação preliminar e permite encaminhamento a um painel técnico. A avaliação é uma base para comparar pedidos futuros, não uma decisão sobre um operador específico ou uma regra contratual em vigor. A resolução do conselho e a política RSEP descrevem o processo.

Os comentários podem testar três pontos: se os requisitos obrigatórios refletem o BCP atual; se as divulgações permitem entender prazos, avisos e recuperação; e se as cláusulas futuras continuam exigindo a análise do desenho de cada operação. Como a consulta sobre a minuta virá em outra etapa, o resumo de dezembro e o texto contratual serão provas diferentes de como a ICANN transforma a avaliação em processo. A lista só melhora a previsibilidade se facilitar a comparação sem esconder escolhas de implementação.