Resumo

  • A RFC 9660 entrega o identificador de versão dentro da resposta que ele descreve, sem depender de uma consulta SOA posterior que pode atingir outro estado.
  • O token vale para uma resposta observada; não resume toda a zona, não prova convergência e não recebe proteção de RRSIG sem um mecanismo adicional de integridade.

O painel não mostra erro. Dois pontos de medição perguntam pelo mesmo nome ao mesmo endereço anycast e recebem NOERROR. Mesmo assim, um obtém o endereço novo e outro, o antigo. O ZONEVERSION da primeira resposta informa SOA-SERIAL 4120; o da segunda, 4119.

Uma consulta SOA feita depois pode apagar a pista. Se a rota mudar ou o site atrasado atualizar, os dois testes seguintes verão 4120. O operador terá o serial atual, mas não o serial que gerou a resposta antiga.

O cenário é ilustrativo, sem atribuição a operador ou produto. A vantagem da RFC 9660 está na simultaneidade: resposta e versão viajam juntas. A limitação também é precisa. 4119 não explica a causa, 4120 não certifica o conteúdo, e uma observação não representa todas as autoridades.

A consulta não pede uma versão preferida

O solicitante coloca o código EDNS 19 no pseudo-RR OPT com OPTION-LENGTH zero. Não há dados no pedido. Ele não diz “use 4120”; pergunta qual versão o servidor empregou para formar a resposta atual.

Comprimento diferente de zero ou mais de uma opção ZONEVERSION tornam a solicitação inválida. Um servidor autoritativo que implementa o recurso responde FORMERR. Esse resultado deve corrigir o instrumento de medição antes de acusar a zona. Os bytes exatos da consulta fazem parte da prova.

Mesmo uma solicitação válida não obriga resposta. O servidor precisa entender a opção, ser autoritativo por uma zona envolvente pertinente e optar por atendê-la. Ausência do token significa apenas que aquela troca não ofereceu correlação.

A opção é hop-by-hop. Um encaminhador não pode copiar cegamente pergunta e resposta de upstream. O valor só mantém sentido enquanto permanece ligado ao servidor que produziu aquele pacote.

LABELCOUNT define a jurisdição do número

A resposta começa com um octeto LABELCOUNT, um octeto TYPE e VERSION. O contador usa os rótulos à direita do QNAME original para identificar a zona envolvente; zero indica a raiz.

Em host.branch.example, dois rótulos indicam branch.example e um indica example. O contador não pode ultrapassar o total do nome. Guardar “serial 4120” sem QNAME e LABELCOUNT remove a zona à qual a informação pertence.

O recurso também pode aparecer numa delegação descendente gerada pela zona pai, em NXDOMAIN ou NODATA autoritativos e em certos SERVFAIL quando a zona relevante ainda é identificável. Uma resposta pode trazer várias zonas ou tipos, mas apenas um valor por par TYPE–LABELCOUNT.

Por isso, a chave de telemetria inclui pergunta, zona derivada, tipo, valor, servidor, posição, horário e pacote, não uma coluna genérica de “versão DNS”.

SOA-SERIAL não é relógio linear nem hash

TYPE 0, SOA-SERIAL, é o tipo público definido pela RFC 9660. VERSION copia os quatro octetos do SERIAL no SOA; com os dois octetos iniciais, a opção de resposta mede seis.

O serial só tem escopo dentro da zona. A RFC 1982 define aritmética circular de 32 bits. Depois da volta, um valor numericamente menor pode ser mais novo, e alguns pares não têm ordem definida. Comparação inteira simples cria falsos alertas de reversão.

O número também não resume os dados. Um erro pode publicar conteúdos diferentes sob o mesmo serial. Contexto e política podem produzir respostas distintas na mesma versão. É necessário comparar RRsets, seções, flags, TTL e validação DNSSEC.

Para verificar a zona completa, a RFC 8976 define ZONEMD. ZONEVERSION liga uma resposta a um identificador; ZONEMD verifica um digest do conteúdo inteiro. Um não substitui o outro.

Anycast exige uma lista explícita de observações

Um endereço anycast pode levar a instâncias diferentes. Uma resposta bem-sucedida comprova o que um caminho alcançou naquele momento. A investigação começa inventariando NS, endereços, prefixos anycast, coortes de serviço e pontos de medição.

Cada consulta direta desativa recursão e conserva origem, destino, transporte, relógio, QNAME, RCODE, AA, bytes da resposta, TTL, opção e resultado de validação. Repetições separam uma mudança passageira de rota de uma diferença persistente.

NSID pode ajudar a distinguir instâncias, mas significado e unicidade pertencem ao operador. Sua presença não autentica o valor, nem substitui endpoint e posição.

Se três posições repetem 4120 e os mesmos dados, enquanto uma quarta mantém 4119 e o endereço antigo, há evidência de divergência delimitada. A causa virá do journal de transferência, saída do assinador, versão carregada e mapeamento do tráfego, não de uma suposição anexada ao token.

DNSSEC não assina os bytes de ZONEVERSION

DNSSEC pode validar os RRsets assinados. Os bytes EDNS do token ficam fora da cobertura de RRSIG. Num caminho inseguro, um intermediário pode alterar ou retirar a opção sem invalidar os dados assinados.

Assim, “RRset validado” e “par resposta–versão com custódia protegida” são resultados distintos. Transporte autenticado e criptografado, TSIG ou SIG(0) podem proteger a troca; a evidência deve guardar endpoint ou chave e o veredito. Ainda assim, não certificam conteúdo correto ou convergência.

OPT não é dado de zona. ZONEVERSION não deve ser armazenado, transferido ou cacheado como RR comum, nem reaproveitado para rotular outra resposta.

Fontes