Resumo

  • O GSS-TSIG negocia um contexto GSS por TKEY e protege mensagens DNS por TSIG, mas não concede autorização para modificar a zona.
  • Um controle confiável precisa comprovar separadamente principal, política, ação permitida, gravação, propagação e observação final.

Considere o percurso de uma solicitação de mudança. Primeiro existem credenciais locais. Depois ocorre a negociação de um contexto. A mensagem chega assinada e sua integridade é verificada. Só então uma política local decide se aquele principal pode executar a operação pedida. Ainda restam a alteração do estado, a distribuição desse estado e a consulta que confirma o que ficou visível. São seis fatos, não um.

A RFC 3645 descreve duas etapas técnicas. Na primeira, cliente e servidor carregam tokens opacos de GSS-API em registros TKEY e chamam GSS_Init_sec_context e GSS_Accept_sec_context. Na segunda, o contexto estabelecido alimenta GSS_GetMIC e GSS_VerifyMIC, com assinaturas transportadas em TSIG. A edição em texto registra o limite central: o escopo é autenticação, não autorização.

Isso impede um atalho frequente na gestão de mudanças. A autenticação identifica o principal associado à mensagem. A autorização compara esse principal, o nome, o tipo de registro e a operação com regras vigentes. A resposta do protocolo indica como o pedido foi tratado. O banco da zona mostra se houve mutação. Servidores secundários e resolvedores mostram onde ela chegou. Nenhuma dessas evidências substitui as demais.

As normas componentes reforçam a divisão. A RFC 2743 define a abstração GSS-API; a RFC 2930 usa TKEY para estabelecimento de chaves; a RFC 2845 criou o modelo original de TSIG, atualizado pela RFC 8945; e a RFC 4121 especifica o mecanismo Kerberos v5 para GSS. Juntas, elas oferecem interoperabilidade. Não substituem a política da organização que administra a zona.

O contexto de segurança também não é uma credencial eterna. Ele passa de não inicializado a negociação e estabelecido, pertence à relação descrita entre cliente e servidor e tem vida finita. A quantidade de trocas depende do mecanismo subjacente; os laços definidos limitam a dez as tentativas. O cliente verifica a resposta final assinada antes de considerar o contexto estabelecido. Falha ou expiração exige tratamento explícito, não confiança herdada.

Para interoperabilidade, RFC 3645 recomenda SPNEGO e exige suporte a Kerberos v5 no perfil indicado, embora outros mecanismos possam coexistir. A proteção final é tão forte quanto o mecanismo escolhido. Portanto, um log com apenas a palavra gss-tsig é insuficiente. Devem aparecer mecanismo negociado, nome-alvo, origem das credenciais, nome da chave, duração do contexto, estado de repetição e sequência, par e resultado da verificação.

A decisão de permissão está na RFC 3007: o administrador configura a política, o servidor a executa e a checagem considera o principal e a ação desejada. Sem concessão, o padrão é não permitir mudança. A RFC 2136 define pré-requisitos e operações de Dynamic Update. Uma assinatura válida entrega uma identidade à política; não entrega a resposta da política.

O que o leitor vê é ainda outra camada. A RFC 4033 apresenta as garantias de origem e integridade de dados do DNSSEC. Validar uma resposta DNSSEC não revela automaticamente quem recebeu permissão para produzir sua história. Do outro lado, autenticar uma atualização não demonstra que o estado foi persistido e propagado até uma consulta posterior.

O registro IANA de algoritmos TSIG coordena o nome gss-tsig. O registro de parâmetros DNS, sob procedimentos tratados na RFC 6895, coordena valores compartilhados. Registro é prova de nomenclatura, não de contexto ativo, autoridade local ou alteração feita.

O alcance histórico pode ser conferido na página do RFC Editor, no Datatracker, no histórico e na consulta de erratas. Essas fontes sustentam a leitura da norma, mas não autorizam afirmações sobre adoção atual ou falhas de um produto específico.

Os ensaios de Heng Lu sobre camadas da realidade, especificação comum mínima e primazia do código em execução dão a chave institucional. O padrão coordena o mínimo comum; a autoridade permanece na política local; o servidor real e as observações posteriores mostram o resultado. O erro começa quando uma camada técnica limitada reivindica o poder das demais.