Resumo

  • A RFC 2845 fez o MAC de uma resposta DNS assinada incluir o MAC da consulta que a provocou.
  • Numa troca DNS/TCP com várias mensagens, um MAC acumulado cobria o MAC anterior e as mensagens seguintes, em ordem; havia TSIG na primeira, na última e, no mínimo, a cada cem mensagens.
  • A RFC 8945 depois passou a exigir TSIG em toda mensagem de resposta enviada, mas manteve uma tolerância de compatibilidade limitada para os verificadores. Nenhuma versão transforma autenticação de transação em confidencialidade, veracidade dos dados ou autorização local.

A resposta não era um pacote sem contexto

IDs e códigos de resposta do DNS descreviam uma troca, mas não autenticavam o outro lado nem protegiam a transação contra alteração. Publicada em maio de 2000, a RFC 2845 acrescentou o TSIG: um registro de metadados anexado à mensagem DNS e verificado com um segredo compartilhado. O alcance era deliberadamente ponto a ponto. Os dois participantes precisavam ter a mesma chave configurada; distribuir essa chave ficava fora da especificação.

A decisão essencial estava na entrada do cálculo do MAC. O cliente autenticava primeiro sua consulta. Ao devolver uma resposta assinada, o servidor incluía no cálculo o MAC da consulta, a resposta e as variáveis TSIG da resposta. Assim, o verificador não tratava a resposta como um objeto novo, sem contexto: a checagem criptográfica voltava até a consulta que a iniciou. O horário assinado e a tolerância também eram cobertos, impedindo que um intermediário simplesmente alterasse os campos de tempo e preservasse um MAC válido.

Essa ligação dizia respeito aos bytes cobertos e à relação entre chaves. Como os participantes compartilhavam o segredo, uma verificação bem-sucedida mostrava que a mensagem conferia com a chave configurada; não identificava a pessoa ou o processo que a possuía. O TSIG não criptografava o DNS nem decidia se o servidor deveria permitir uma atualização. A RFC 2136 definia DNS UPDATE; a política local ainda tinha de decidir se aquele par autenticado podia mudar a zona.

A transferência virou uma sequência

O caso mais difícil era uma resposta dividida em várias mensagens, como uma transferência de zona por TCP. Se cada pacote fosse verificado isoladamente, a ordem e a relação entre eles desapareceriam. A RFC 2845 exigia TSIG na primeira e na última mensagem e, no mínimo, um ponto de verificação assinado a cada cem mensagens. Entre os pontos, cada mensagem DNS entrava na próxima computação do MAC em sua ordem, junto com o MAC anterior e os campos de tempo pertinentes.

O verificador checava, portanto, a continuidade de um trecho limitado do fluxo — não uma assinatura independente em cada mensagem intermediária. Se a verificação falhasse, a RFC exigia fechar a conexão TCP e tratar a transferência como interrompida; não determinava um procedimento exato para tentar de novo. Um ponto válido cobre parte da sequência recebida, não o que o servidor gravou depois nem o que um secundário chegou a servir.

A regra mudou; o limite permaneceu

A RFC 4635 acrescentou identificadores HMAC-SHA além do HMAC-MD5 original. Em 2020, a RFC 8945 substituiu as RFCs 2845 e 4635 como o padrão de Internet STD 93. A regra para envio ficou mais rigorosa: um emissor conforme assina todas as mensagens da resposta. A regra de compatibilidade para quem verifica é outra: deve aceitar até 99 mensagens intermediárias sem TSIG, mas exigir assinatura na primeira e na última. Essa tolerância não permite que um emissor atual deixe de assinar.

A RFC 8945 também explicita o limite da evidência: o TSIG autentica a transmissão entre dois pares que compartilham um segredo, não a origem ou a correção dos dados de origem. Isso é diferente do DNSSEC, que autentica dados por outro modelo de confiança. TKEY pode estabelecer chaves em algumas implantações, mas a distribuição de chaves não é uma função fornecida pelo TSIG. O conjunto de normas descreve um mecanismo delimitado, não um selo universal de confiança.

Fontes: RFC 1035; RFC 2104; RFC 2845; RFC 8945; RFC 4635; RFC 2136; RFC 2930.