Resumo

  • A RFC 8767 permite que um resolvedor recursivo use dados expirados quando uma tentativa séria de atualização autoritativa falha; essa continuidade é concedida pelo operador do resolvedor, não pelo publicador da zona.
  • A decisão só permanece auditável quando TTL original, idade vencida, limite máximo, TTL devolvido, validade DNSSEC, classe da falha, grupo de resolvedores e recuperação são registrados separadamente.

O endereço foi removido da zona depois de um incidente de segurança. Seu TTL anterior terminou. Mesmo assim, parte dos usuários continua recebendo o destino antigo. Não é preciso supor que todos os servidores autoritativos estejam atrasados. Basta que o resolvedor desses usuários não consiga atualizar o cache e prefira uma cópia vencida a uma resposta de erro.

O caso é ilustrativo. Não descreve um operador real nem tenta transformar uma opção de resiliência em defeito. Ele mostra uma dívida criada pela continuidade: o sistema ganha tempo para permanecer disponível, mas precisa provar por quanto tempo e com qual risco usa uma afirmação que o publicador já não garante como atual.

A RFC 8767 chama essa prática de Serve Stale. Quando o TTL expira, a fonte deveria ser consultada outra vez. Se a atualização autoritativa não puder ser concluída, o resolvedor pode tratar temporariamente os dados retidos como se ainda não tivessem expirado. A expressão preserva o limite: usar “como se” não torna o dado novo.

O fim do TTL transfere a responsabilidade

Durante a vida normal do cache, a autorização vem do TTL publicado pela zona. Depois do vencimento, a mesma resposta passa a depender de uma política local do resolvedor. É uma mudança de autoridade, mesmo que os bytes não mudem.

Isso exige dois livros de tempo. Um TTL máximo de cache pode limitar valores recebidos muito longos; a RFC recomenda uma escala de dias a semanas e cita sete dias. Já o temporizador máximo stale começa depois do vencimento normal e define por quanto tempo a cópia expirada ainda pode ser considerada. O documento discute um valor configurável e observa que um a três dias podem atravessar muitos incidentes. Não obriga todas as redes a aceitar a mesma idade.

O registro operacional precisa conter quando a resposta entrou no cache, qual era o TTL original, quando venceu, quantos segundos já estava expirada, qual era o limite stale e qual TTL foi colocado na resposta ao cliente. Sem isso, um TTL visível de trinta segundos pode parecer uma publicação recente, embora represente apenas o intervalo curto atribuído a uma cópia antiga.

Essa separação também evita atribuir ao publicador uma escolha que ele não fez. A zona decidiu o horizonte normal. O operador recursivo decidiu usar a exceção. Se a segunda escolha não for visível, a disponibilidade vira uma extensão silenciosa da política de publicação.

Quatro relógios, quatro tipos de risco

A RFC 8767 não define um algoritmo único. Seu método de exemplo usa quatro temporizadores para manter separados tempo do usuário, trabalho de resolução, pressão sobre a autoridade e idade absoluta.

O relógio de resposta ao cliente limita a espera antes de considerar dados vencidos; o exemplo recomenda 1,8 segundo. O relógio de resolução limita todo o esforço iterativo, com uma faixa comum de dez a trinta segundos. O relógio de nova verificação impede que uma falha recente gere tentativas incessantes e recomenda trinta segundos no exemplo. O máximo stale encerra definitivamente a elegibilidade da cópia.

Um único botão “Serve Stale” não informa nenhuma dessas escolhas. Responder cedo demais pode preferir dados antigos a uma autoridade apenas lenta. Reconsultar tarde demais pode prolongar o uso depois que a autoridade voltou. Reter por dias ajuda numa interrupção grave, mas aumenta o espaço para endereços abandonados, dados de delegação antigos e pressão de memória.

Antes de usar o cache vencido, o resolvedor deve ter feito uma tentativa recente e de boa-fé. A técnica não é licença para responder sempre primeiro com o passado. Depois de enviar a resposta stale ao cliente, a resolução deve continuar até o limite do próprio processo. A exceção compra tempo; não encerra a investigação.

Falha de atualização não é uma causa única

Uma resposta autoritativa NOERROR ou NXDOMAIN com AA atualiza o estado segundo a RFC 8767. O tratamento de NXDOMAIN é essencial: se o publicador retirou de fato um nome, o resolvedor não pode conservar a resposta positiva só porque ela mantém o serviço aparentemente estável. Não há método geral para separar uma remoção legítima de uma remoção acidental.

Timeout, rede inalcançável, SERVFAIL, REFUSED, mensagem inválida, falha DNSSEC e delegação quebrada também não são sinônimos. Cada um aponta para um responsável diferente. A RFC 2308 limita a cinco minutos o armazenamento de indicações de servidor falho ou morto.

Por isso, a cadeia de evidência deve listar cada servidor autoritativo tentado, endereço, transporte, horário, RCODE, AA, validação e erro de rede. Deve registrar a tentativa de atualizar a delegação e o contexto RD, CD e DO, além da chave de cache e da natureza positiva, NODATA ou NXDOMAIN da resposta.

Resolvedores distintos podem produzir respostas diferentes para a mesma consulta porque possuem históricos, caminhos e políticas diferentes. A métrica agregada “consultas bem-sucedidas” esconde justamente essa divisão de autoridade.

O TTL curto de saída não quita a dívida

Ao enviar registros expirados, o resolvedor precisa colocar um TTL positivo na resposta; a RFC 8767 recomenda trinta segundos. TTL zero já criou problemas de interoperabilidade, e valores muito pequenos podem provocar novas consultas em massa durante a falha. O TTL curto controla a procura a jusante.

Ele não reinicia a idade do RRset. Se um encaminhador guardar a resposta, o cliente seguinte verá os trinta segundos, mas não verá quando o dado original venceu. A proveniência precisa acompanhar o resolvedor que concedeu a exceção, a idade real do cache e a última atualização tentada.

Os Extended DNS Errors da RFC 8914 oferecem sinais úteis. O código 3 é Stale Answer; o 19 distingue Stale NXDOMAIN Answer; o 22 informa No Reachable Authority. Eles podem acompanhar até uma resposta NOERROR.

EDE, porém, é contexto. Não altera o processamento do RCODE, pode ser removido ou recriado por um intermediário e não é autenticado sem proteção adicional da transação ou do canal. Ver o código 3 prova que o emissor descreveu a resposta como stale; não prova sozinho a idade ou os pedidos autoritativos feitos.

A assinatura obedece a outro prazo

Um RRset que validou ao entrar no cache pode não validar mais quando for reutilizado. Início e expiração do RRSIG são independentes do TTL e da janela máxima stale. Quanto maior a retenção, maior a chance de a assinatura atravessar seu limite temporal.

O bit AD deve refletir a validação atual, não uma lembrança. Devem ser preservados horários do RRSIG, momento da validação, âncoras de confiança e condições CD/DO. Mesmo uma assinatura ainda válida não garante que o endereço antigo continue seguro: autenticidade criptográfica e controle atual do destino são questões separadas.

Dados negativos ampliam o cuidado. Um NXDOMAIN vencido pode esconder um nome recém-criado. NSEC ou NSEC3 antigo pode atrasar novos DS e TLSA. O uso agressivo da cache validada na RFC 8198 sintetiza respostas com material negativo ainda elegível. Serve Stale pergunta se material já expirado pode continuar quando a atualização falha.

Fontes