Resumo

  • O bit SEP indica o uso operacional previsto de uma chave DNSKEY. Pode ajudar ferramentas a preparar registros DS, mas não prova autenticidade nem cria uma cadeia de confiança.
  • As RFCs 4034 e 4035 impedem que validadores mudem o comportamento de verificação por causa do bit 15. Uma chave com SEP ainda precisa do bit Zone Key para validar assinaturas de conjuntos de registros.
  • Edward Lewis é um dos três coautores da RFC 3757. O registro comprova essa contribuição normativa, não autoria exclusiva, implementação de produto ou emprego atual.

Um sinal com fronteiras claras

Se o registro DS publicado pela zona pai não corresponder à DNSKEY da zona filha, um resolvedor que valida DNSSEC pode rejeitar a delegação e deixar de entregar aquela resposta como autenticada. Não é uma afirmação sobre um incidente específico: é a consequência prevista pelo processo de validação. O bit SEP não evita essa incompatibilidade. Ele apenas ajuda certas ferramentas a selecionar a chave que o operador pretende usar — uma diferença pequena na tela de configuração, mas decisiva para separar intenção de prova.

A RFC 3757, publicada em abril de 2004 por Olaf Kolkman, Jakob Schlyter e Edward Lewis, incluiu SEP nos bits de DNSKEY. O documento prevê que o indicador ajude a gerar registros DS e a identificar chaves destinadas a configuração estática. Também declara que o protocolo de verificação DNS não usa SEP. Portanto, embora o nome pareça forte, o bit não certifica que a chave pertence à zona nem que a relação com o pai foi estabelecida.

Considere a preparação de um DS. Uma ferramenta de assinatura pode selecionar uma chave marcada com SEP entre as DNSKEY publicadas pela zona filha. O operador ainda precisa conferir se o DS calculado corresponde à chave correta, e o responsável pela zona pai precisa publicar o registro. O bit na filha não confirma nenhuma dessas etapas no pai. Também não transforma uma assinatura em válida. O resolvedor validador deve seguir as regras do DNSSEC, sem conceder peso criptográfico à preferência operacional.

As RFCs 4034 e 4035 substituíram a RFC 3757 em 2005 e preservaram o limite. A RFC 4034 descreve SEP como uma dica útil para programas de assinatura ou depuração. A RFC 4035 determina que o comportamento de validação não pode mudar porque o bit foi ativado. SEP tampouco substitui Zone Key: para validar assinaturas de RRsets, a DNSKEY precisa do bit Zone Key. Um indica o tratamento pretendido pela operação; o outro identifica a elegibilidade para uma função de validação.

A RFC 6781 explica por que SEP continua relevante para quem administra chaves. Um arranjo comum marca a KSK, que participa da troca com o pai, mas não a ZSK. Há, porém, implantações com um único tipo de chave para funções que o modelo dividido separa. Uma ferramenta que pressuponha sempre KSK e ZSK distintas pode classificar ou selecionar registros de modo inadequado. A RFC recomenda atenção ao comportamento das ferramentas, mas isso não prova que um validador tenha falhado.

O SEP também não é o bit REVOKE da RFC 5011. Essa RFC descreve atualizações automáticas de âncoras de confiança e um estado de revogação próprio. Misturar os dois bits apagaria a diferença entre uma orientação operacional e uma etapa de outro mecanismo.

A contribuição de Lewis deve ser descrita com a mesma precisão. A RFC 3757 o lista entre três autores; seu perfil no IETF Datatracker relaciona o documento, e a página de autor da Internet Society oferece contexto profissional limitado. Isso não demonstra que ele tenha criado SEP sozinho ou implementado uma solução específica. A referência a ARIN na RFC é histórica, não prova de vínculo empregatício atual. As fontes normativas também não medem prevalência, taxas de erro nem incidentes.

O que sustentam é mais restrito: SEP pode ajudar a organizar o trabalho com chaves, enquanto confiança depende da relação DS publicada e da validação protocolar.

Fontes