Resumo

  • A resposta DNS NOTIFY confirma que o secundário recebeu o aviso; ela não carrega informação útil sobre o conteúdo da zona.
  • Comparação do serial SOA, IXFR/AXFR, carga da geração e respostas autoritativas são etapas posteriores.
  • Um recibo de publicação deve preservar todos esses estados e seu prazo de validade.

Receber o gatilho não conclui o trabalho

O RFC 1996 permite avisar mudanças sem esperar o intervalo de refresh. Ao receber a resposta correspondente, o mestre pode retirar o secundário da fila de repetição daquele evento. Essa é uma prova precisa do transporte da notificação.

Ela não informa o serial local, a decisão de transferir, o fim da transferência ou a versão ativa no processo que responde consultas. O próprio RFC diz que a resposta não contém informação útil. Um painel verde de NOTIFY mede a entrega do gatilho, não a publicação da zona.

Depois de um NOTIFY SOA válido, o secundário consulta um mestre conhecido, compara os seriais e inicia IXFR ou AXFR quando o serial remoto avançou. Cada transição mantém seu próprio resultado.

A zona precisa aparecer na resposta

Uma seção de resposta no NOTIFY é apenas uma dica insegura e não pode atualizar os dados locais. O RFC 1982 define a aritmética de serial, inclusive uma distância em que a comparação fica indefinida. Guardar os dois valores e o resultado real é melhor do que guardar apenas “mais novo”.

IXFR leva alterações; AXFR pode levar a zona inteira. O RFC 5936 trata AXFR como mecanismo de coerência entre servidores autoritativos. Mesmo uma transferência concluída não prova reload, ativação em cada processo nem convergência em todos os pontos anycast.

É necessário consultar diretamente a autoridade, conferir o SOA e um RRset alterado em cada servidor e em pontos representativos. Cache recursivo e TTL pertencem a outra camada.

Fontes