Rastreie a proposta DNS sem criar um mandato de migração
Um administrador que avalia DKIM2 precisa de um inventário de registros preciso, e não de um novo valor TXT copiado de um título. Erros DNS podem afetar a assinatura existente, mesmo quando a alteração pretendida é apenas experimental. Comece separando seletor chaves públicas, o registro de política de domínio proposto e os existentes DMARC política. Ocupam nomes diferentes e respondem a perguntas diferentes; “o registro DKIM2 ” é muito impreciso para uma solicitação de alteração.
A fonte atual é draft-ietf-dkim-dkim2-dns-03, datado de 2 de novembro de 2026. É um WG Internet-Draft ativo destinado à publicação do Standards Track. Sua proposta de atualização para RFC 6376 está condicionada à aprovação, e não a uma substituição já concluída do implantado DKIM regras. Combine-o com o core spec-09 datado de 1º de novembro e retenha ambas as revisões ao revisar uma implementação.
Identifique os nomes das chaves seletoras antes dos nomes das políticas
A seção 3 do DNS-03 mantém as chaves do seletor abaixo de _domainkey . Em um domínio fictício isolado lab.cedar.example , o seletor s01 identifica, portanto, s01._domainkey.lab.cedar.example . A chave é mantida em um registro de recurso TXT . Várias sequências de caracteres dentro desse registro são concatenadas sem adição de espaços em branco; isso é diferente de publicar vários registros de chave concorrentes com o mesmo nome de proprietário.
O rascunho filtra registros que começam com outro valor v e trata mais de um registro restante como um erro. Os administradores devem preservar o conjunto completo de registros, não apenas a primeira string TXT exibida pela interface de gerenciamento. Um seletor pode suportar rotação ou assinatura delegada, portanto identifique quaisquer consumidores existentes antes de escolher um nome experimental. A ilustração aqui não contém chave gerada e não autoriza publicação.
O tipo de chave e a codificação merecem sua própria revisão. DNS-03 descreve rsa, ed25519 e mldsa44 para seus usos especificados, com o último vinculado ao mecanismo DKIM2 proposto, em vez do uso definido do DKIM clássico. O rascunho também esclarece as codificações de chave pública RSA e propõe a descontinuação de várias tags mais antigas. As alterações de registro solicitadas em um rascunho não são evidência de que todos os verificadores aceitam essas alterações hoje.
Leia o registro de política de domínio com atenção
O registro de política de domínio proposto está no próprio _domainkey.lab.cedar.example , não em um seletor e nem em _dmarc.lab.cedar.example . A seção 5 do DNS-03 exige que sua primeira tag seja v=DKIM1. Apesar do nome da proposta, inventar v=DKIM2 não corresponderia a essa sintaxe fixada. Uma ilustração documental é v=DKIM1; f=strict, mas não é uma instrução pronta para colar ou um valor de produção aprovado.
O sinalizador estrito diz respeito se os subdomínios podem tornar um campo De usando o domínio do registro Autêntico de acordo com as regras de correspondência do rascunho. Não é o mesmo que DMARC p=reject, e não é a tag de alinhamento estrito do DMARC . Quando a flag ou registro estiver ausente, a proposta permite a autorização do subdomínio descrito. A política aplica-se apenas ao seu próprio domínio; ele não herda para cima ou para baixo na árvore DNS .
Núcleo -09 seção 3.8 distingue falha de recuperação temporária de uma política ausente e identifica um erro de múltiplos registros. Um laboratório deve preservar esses estados separadamente. Tratar um tempo limite como “nenhuma restrição publicada” apagaria as informações de que o avaliador proposto necessita. Não substitua o comportamento de caminhada em árvore DMARC por esta pesquisa de política diferente.
Revise a revisão, não um trecho de discussão antigo
Mais cedo discussão sobre política de remetente considera sinalização auth= e implantações mistas. Esse é um histórico útil, não a sintaxe do Registro de Política de Domínio DNS-03. Um administrador deve manter uma matriz de alterações mostrando o documento de origem, revisão, nome do proprietário, etiqueta e consumidor esperado. Isto evita que exemplos de propostas separadas sejam combinados em um recorde nenhuma implementação realmente espera.
Há também um problema explícito de qualidade da fonte a ser resolvido: a prosa do tipo de serviço da seção 4.6 do DNS-03 usa um sublinhado onde seu ABNF lista um curinga asterisco. Não normalize silenciosamente essa discrepância ou apresente a sintaxe copiada como resolvida. Retenha o conflito exato para revisão especializada e comparação de implementação. O trabalho de padrões em andamento pode conter tais inconsistências; um guia cuidadoso deve expô-los antes que uma mudança atinja uma zona de autoridade.
Escopo de um experimento e sua remoção juntos
O Registro de publicação NIST SP 800-81 Revisão 3 identifica as orientações de implantação DNS de março de 2026 e observa possíveis atualizações. Ele apóia o tratamento DNS como uma infraestrutura sensível à segurança, mas não é um endosso DKIM2 ou uma evidência de que este experimento específico seja compatível. O guia detalhado e suas erratas não foram revisados aqui para reivindicações em nível de cláusula.
Um experimento aprovado deve usar um namespace isolado designado, chaves separadas e um proprietário explícito. Registre os valores exatos propostos, TTLs, consumidores afetados, versão de implementação e pré-requisitos de reversão antes da execução. Proteja as chaves privadas fora do artigo e do pacote de evidências. Os registros de linha de base e os acordos de delegação devem permanecer identificáveis para que uma etapa de limpeza não possa remover acidentalmente a chave de um serviço existente.
Defina evidências de remoção antes de criar qualquer coisa: quais registros experimentais e configurações de assinatura serão retirados, quem verifica o estado autoritativo, quais caches podem reter dados anteriores e como as mensagens residuais são tratadas. A exclusão em um servidor oficial não é prova de que todas as respostas armazenadas em cache desaparecem imediatamente. Nenhuma chave, registro, delegação ou conta foi alterada durante a elaboração deste artigo.
Preservar o portão de construção compatível
A comissão exata é: Pin draft sintaxe e uma implementação de teste compatível; isolar o experimento e remover documentos. A sintaxe está fixada, mas uma compilação testada compatível não foi estabelecida. O rascunho de perfil de implantação individual relata o código beta para seu próprio perfil e avisa que as informações do contribuidor não foram verificadas. Isso não é suficiente para certificar a compatibilidade com o núcleo -09 e o DNS-03.
A porta de comissionamento permanece aberta para fixação de implementação, execução autorizada e remoção verificada. A aceitação técnica, o impacto no consumidor existente, as verificações da rota de produção, a revisão visual e a aprovação da publicação pelo proprietário também permanecem pendentes. O resultado útil é uma revisão limitada e um plano de experimento, com a sintaxe do rascunho atual claramente separada de qualquer reivindicação de que os administradores devam implantá-la.