Resumo

  • A avaliação considera que não há problema significativo de segurança ou estabilidade nos termos da política RSEP somente quando sete requisitos obrigatórios são atendidos e sete decisões de projeto são documentadas; outras quatro práticas são recomendações.
  • A conclusão trata do mecanismo, não de um operador específico. A consulta, um adendo à avaliação, os pedidos de cada operador de registro e uma etapa separada sobre a redação contratual ainda virão.

Um parecer favorável, com limites claros

A conclusão central do relatório da ICANN sobre automação de DNSSEC é condicional. A avaliação da Interisle conclui que a automação CDS/CDNSKEY não gera problemas significativos de segurança ou estabilidade segundo a Registry Services Evaluation Policy (RSEP), desde que sete requisitos obrigatórios sejam cumpridos e sete escolhas de projeto sejam documentadas. Isso dá base a uma determinação preliminar favorável ao mecanismo. Não significa que todos os operadores tenham sido avaliados, que qualquer implementação seja segura ou que o serviço possa ser ativado hoje.

A expressão “automação de DNSSEC” parece designar uma única função técnica. Mas a questão regulatória é se um novo serviço de registro atende a uma estrutura contratual e a critérios delimitados de segurança e estabilidade. A avaliação cobre uma classe de mecanismos sob condições declaradas. Cada operador ainda precisa percorrer seu próprio processo de solicitação, configuração e aprovação contratual.

A consulta pública da ICANN foi aberta em 12 de outubro de 2026. A organização quer saber se o relatório identifica corretamente os problemas de segurança e estabilidade e se as medidas propostas são suficientes, proporcionais e viáveis. As contribuições podem ser enviadas até 23 de novembro; o relatório de síntese está previsto para 7 de dezembro. A ICANN afirma que analisará os comentários, atualizará a avaliação se necessário e publicará um adendo com sua análise das contribuições. A minuta da linguagem de emenda padrão será submetida a comentários em um processo posterior e separado.

São decisões distintas. A consulta atual examina evidências e medidas de mitigação; não é uma votação sobre a utilidade do DNSSEC nem a própria emenda contratual. O calendário mostra que o procedimento ainda está sendo montado.

Da padronização ao controle de serviços de registro

A iniciativa começou com uma decisão do Conselho da ICANN em 14 de setembro de 2025. O Conselho aceitou as recomendações do SSAC no SAC126 e orientou a ICANN a criar um RSEP acelerado para automação de DS, desde que não fossem identificados problemas de segurança ou estabilidade. A resolução do Conselho estabelece um mandato condicionado, não uma dispensa automática do RSEP.

A base técnica está em documentos publicados. As RFCs 7344, 8078 e 9615 tratam da manutenção, remoção e inicialização da relação de confiança; a RFC 9975 esclarece requisitos de consistência; a RFC 10026 traz recomendações operacionais. A avaliação considera esses documentos como um mecanismo composto para operações de DNS por terceiros: a zona filha publica registros CDS ou CDNSKEY; o operador do registro pai ou o registrador patrocinador recebe, valida e pode publicar o registro DS correspondente.

O ponto não é decidir se esses registros devem existir. É definir o que precisa estar demonstrado para uma mudança de serviço superar os critérios de segurança e estabilidade do RSEP. A política define segurança em termos de divulgação ou alteração não autorizada de dados do registro e de certos acessos não autorizados. Estabilidade diz respeito à conformidade com padrões reconhecidos e ao desempenho, tempo de resposta, consistência e coerência das respostas DNS. Essa moldura torna a análise possível, mas não resolve todas as questões de governança, concorrência, qualidade do serviço ou escolha do titular.

O relatório separa os achados conforme seu peso. Sete requisitos obrigatórios são pré-condições; sete itens de divulgação tornam explícitas as escolhas de cada operador; quatro práticas recomendadas reforçam a implantação, mas não são necessárias para um parecer favorável segundo o conjunto atual de padrões. Os 18 itens formam uma lista de verificação. Ela pode reduzir análises técnicas repetidas, desde que solicitantes e avaliadores saibam qual evidência atende a cada ponto e como as exceções serão tratadas.

O relatório enfatiza que suas conclusões dizem respeito ao mecanismo, não a cada operador. Cada registro ainda terá de responder aos itens em sua solicitação. Omissões ou respostas genéricas podem gerar novas consultas ou encaminhamento ao Registry Services Technical Evaluation Panel. Portanto, há uma segunda etapa após a avaliação técnica: o mecanismo comum é examinado em conjunto, mas cada serviço e seus controles continuam sujeitos a análise própria.

O que permanece em aberto

Três preocupações residuais explicam a necessidade das condições. Em uma operação com vários signatários, uma atualização ingênua poderia retirar as chaves de outro provedor. As RFCs citadas não padronizam mecanismos de comunicação que garantam a titulares e operadores de DNS filho uma forma comum de acompanhar os eventos. Além disso, o bootstrapping previsto na RFC 9615 pressupõe que os nomes dos servidores autoritativos estejam em zonas assinadas com DNSSEC, o que limita sua aplicação.

O relatório não conclui que o mecanismo seja inviável. Ele aponta decisões e limites de implantação que os operadores precisam administrar. A análise não inclui casos em que o registrador também opera o DNS, pois podem se resumir a uma coordenação interna; tampouco abrange abordagens por push ou API fora de banda. Não é uma avaliação de todos os caminhos possíveis para automatizar DS.

Separar evidência técnica reutilizável de autorização tem valor prático. Se a análise comum for aceita, cada operador não precisa começar do zero. Mas o registro público ainda não estabelece o texto final da emenda, uma solicitação aprovada, a data de implantação, o número de interessados, os custos, uma mudança na adoção, a redução de incidentes ou benefícios para clientes. Dizer que o Fast Track já reduziu custos ou acelerou a adoção iria além das evidências.

A agenda da ICANN permite acompanhar uma sequência objetiva: como o adendo responde aos comentários; como a futura redação padrão incorpora os 18 itens; e, depois, quais solicitações RSEP são apresentadas e como recebem determinações preliminares. Só então operadores de registro, registradores e titulares poderão avaliar se o caminho é previsível na prática. A questão é transformar uma conclusão técnica delimitada em condições claras e verificáveis, sem tratá-la como autorização geral.