Resumo

  • A replicação original do DNS fazia o secundário consultar periodicamente o SOA do primário. O intervalo poupava carga, mas também determinava por quanto tempo dois servidores autoritativos podiam servir versões diferentes.
  • DNS NOTIFY não instalava uma nova zona. Ele chamava o secundário para verificar o serial; IXFR podia então enviar a sequência de remoções e inclusões desde a versão que o cliente já possuía.
  • A via rápida continuou limitada por aritmética serial modular, retorno a AXFR, gravação estável, processamento completo, ativação atômica e autenticação TSIG opcional. O alerta acelerava a análise, não a substituía.

Os minutos em que a autoridade discordava de si mesma

Vários servidores autoritativos tornam uma zona resistente à perda de uma máquina ou caminho. No instante de uma alteração, porém, a redundância produz uma pergunta: quanto tempo cada réplica pode responder por um presente diferente?

RFC 1034 descreveu um primário onde as mudanças eram coordenadas e secundários que consultavam o registro SOA em intervalos. Eles comparavam o SERIAL; uma versão mais nova no primário iniciava a transferência. REFRESH marcava a consulta normal, RETRY o retorno após falha e EXPIRE o limite depois do qual uma cópia incapaz de atualizar deveria deixar de se declarar autoritativa. RFC 1035 definiu esses campos em 32 bits e reservou AXFR para a zona inteira.

O desenho economizava trabalho. Uma zona sem mudanças exigia somente pequenas consultas SOA. O secundário mantinha a iniciativa e sabia quando retirar uma cópia cuja atualidade já não podia confirmar. Entretanto, a incoerência passou a ter duração configurável. Um REFRESH curto aumentava consultas em períodos quietos; um intervalo longo deixava a versão anterior sobreviver.

Isso não é a mesma coisa que o cache de um resolvedor. Mesmo depois da convergência autoritativa, um recursivo pode conservar um RR até o TTL acabar. Antes da convergência, dois recursivos vazios podem receber respostas diferentes por alcançarem autoritativos distintos. NOTIFY e IXFR tratam dessa primeira camada de replicação.

Perguntar sempre ou descobrir tarde

Com zonas maiores, o modelo juntava duas despesas desproporcionais. Detectar cedo uma pequena edição exigia sondagens frequentes mesmo sem alterações. Incorporá-la podia exigir AXFR de todo o conjunto. Nem o custo da vigilância nem o transporte refletiam o tamanho real da mudança.

RFC 1996 registrou a troca: períodos longos reduziam carga no mestre, mas prolongavam a incoerência. DNS NOTIFY acrescentou uma interrupção ao mecanismo de consulta. Depois de carregar uma versão, o mestre podia avisar um conjunto de secundários de que havia algo novo a conferir.

O aviso não trazia uma zona confiável para instalação. O receptor consultava o SOA de um mestre configurado, comparava o serial e só então começava uma transferência. Dados opcionais no NOTIFY eram uma dica insegura. O emissor ganhou capacidade de antecipar a verificação, não de modificar o estado alheio diretamente.

Por padrão, o conjunto notificado seguia os servidores NS, menos o MNAME do SOA. A administração podia substituir a lista e incluir secundários ocultos. As relações de transferência precisavam formar um grafo sem ciclos. Um secundário já atualizado podia ser mestre de réplicas seguintes, espalhando carga sem criar uma única conexão central para cada destino.

Bater à porta não é entrar

NOTIFY era de melhor esforço. Em UDP, o mestre podia repetir o pedido até receber resposta ou atingir o limite. Como uma réplica podia ouvir o mesmo evento de vários mestres, precisava suprimir duplicatas enquanto a atualização corria. Várias batidas não deveriam produzir várias transferências simultâneas contra a origem.

A resposta confirmava recebimento, não convergência. Origem falsificada podia provocar consultas SOA desnecessárias; implementação antiga podia responder NOTIMP. Se o aviso desaparecesse, o ciclo normal de REFRESH continuava sendo a recuperação. Por isso, chamar o mecanismo de “push da zona” é exagero. O que foi empurrado era urgência; a evidência e a execução ficavam separadas.

O número que dá a volta

Tudo depende de saber qual geração vem depois. Um serial de 32 bits volta a zero; comparação inteira comum faria o futuro parecer menor. RFC 1982 definiu uma aritmética circular de sequência.

A soma é modular e limitada. Valores próximos podem ser ordenados mesmo atravessando zero; valores separados exatamente por metade do espaço não possuem ordem definida. Em um período EXPIRE, o serial não deve avançar mais que 2^31−1, senão uma réplica antiga pode parecer mais recente.

O serial não é data, assinatura nem título de propriedade. Não revela quem aprovou uma edição ou se ela está correta. Ele oferece somente posição relativa dentro de transições permitidas. Essa afirmação estreita é suficiente para decidir uma transferência, desde que não seja confundida com um relógio comum.

Mandar a edição em vez do acervo

NOTIFY reduziu o tempo de descoberta. RFC 1995 criou IXFR para reduzir o volume. O cliente envia o SOA e o serial da cópia que já tem. Se o servidor preservou o histórico, devolve sequências ordenadas de registros removidos e adicionados até a versão corrente.

Modificar um RR significa retirar sua forma antiga e acrescentar a nova. Cada sequência tem SOAs que delimitam a transição, e as sequências avançam do estado do cliente ao estado atual. Não é um remendo sem contexto: é um caminho de X a Y. O cliente só substitui a zona depois de processar todo o caminho.

O histórico não precisava ser eterno. O servidor podia apagar versões antigas, especialmente se a resposta IXFR ficasse maior que AXFR, e descartar diferenças além de EXPIRE. Podia condensar gerações intermediárias. Se o ponto inicial do cliente deixasse de ser reconhecido, enviava a zona completa.

Esse retorno preservava a segurança. Diferenças exigem memória compartilhada. AXFR restaura um estado comum quando o diário foi purgado, o secundário passou muito tempo fora ou a mudança é grande demais. A eficiência era opcional; a capacidade de reconstrução, não.

Primeiro persistir, depois servir

RFC 1995 determinou que a nova versão fosse gravada de forma estável antes de responder a IXFR ou AXFR. Caso contrário, um mestre poderia distribuí-la, falhar e voltar sem os dados que as réplicas já tinham adotado. A aceleração produziria uma geração sem origem recuperável.

RFC 5936 esclareceu a obrigação do cliente AXFR. A cópia deve ser recebida separadamente, verificada e ativada numa operação atômica. Se a transferência falhar, permanece em serviço a versão válida anterior. IXFR segue o mesmo princípio: nenhuma fração da cadeia vira autoridade pública.

O fluxo contém portas independentes: o aviso provoca conferência; o serial demonstra diferença; IXFR ou AXFR entrega estado candidato; a validação completa permite a troca. A mensagem mais rápida nunca recebeu licença para atravessar as quatro de uma vez.

Autenticar a transação não é autenticar a verdade

Transferências podem expor dados e alimentar diretamente outra autoridade. RFC 5936 recomenda controle de acesso e integridade. RFC 8945 define TSIG, que usa segredo compartilhado e código de autenticação para transações DNS.

Num AXFR TCP com várias mensagens, TSIG pode encadear MACs e revelar alteração. Ele demonstra posse da chave acordada. Não cifra o canal, não distribui segredos e se torna difícil de administrar entre muitos pares.

Acima de tudo, TSIG protege o transporte, não a veracidade da zona. Um mestre comprometido ou equivocado pode assinar corretamente um conteúdo errado. A validação do MAC não prova propriedade legal do nome, autorização institucional de cada RR ou correção da decisão editorial. A ferramenta é forte justamente quando seu limite permanece explícito.

A divisão silenciosa de poder

NOTIFY e IXFR parecem otimizações, mas resolvem uma questão de autoridade distribuída: como um operador induz outro a mudar depressa sem controlar sua execução? O protocolo dividiu o ato em enunciados pequenos: houve mudança; minha série é Y; de seu X até Y existem estas diferenças; se o histórico acabou, aqui está a cópia completa; esta transação veio de quem possui o segredo combinado.

Nenhum enunciado era suficiente sozinho. O secundário verificava o início, escolhia a fonte, completava os dados e decidia a ativação. Assim a versão velha podia morrer cedo sem que o primeiro pacote recebido se tornasse automaticamente verdade.

A rapidez também distribui enganos mais cedo. Uma edição ruim pode alcançar todas as bordas antes da primeira queixa; diário curto pode concentrar AXFR depois de falha longa; serial mal administrado pode bloquear réplicas. A inovação não dispensou governança. Ela empurrou validação e reversibilidade para antes da convergência.

A zona aprendeu a bater. O secundário passou a acordar mais cedo, mas manteve a responsabilidade de abrir, conferir e responder pelo conteúdo que colocava no ar.

Fontes e limites de evidência

RFC 1034 e RFC 1035 estabelecem sondagem, temporizadores SOA e AXFR. RFC 1982 define aritmética serial. RFC 1995 define IXFR e retorno integral. RFC 1996 define NOTIFY e o grafo configurado. RFC 5936 exige ativação completa e atômica. RFC 8945 define TSIG e seus limites.

Essas especificações não fornecem uma data mundial de implantação, parâmetros universais nem tempos globais medidos. Elas sustentam a conclusão arquitetônica: sinal, evidência de versão, transferência e execução local foram mantidos como funções diferentes.