Resumo

  • O fim do TTL encerra a reutilização normal e exige nova consulta à fonte. A exceção da RFC 8767 surge somente quando o resolvedor não consegue completar um refresh autoritativo e ainda conserva uma resposta antiga elegível.
  • Quatro tempos governam o mecanismo: prazo útil do cliente, trabalho total de resolução, intervalo de nova tentativa e idade stale máxima. Um único sinal “habilitado” não demonstra nenhum deles.
  • RRset anterior, falha atual, validade RRSIG, TTL curto enviado, EDE, refresh continuado e resultado da aplicação são camadas diferentes. Juntá-las transforma decisão local em falsa declaração presente do dono da zona.

O endereço antigo ainda respondia

Uma operadora muda o portal de recarga para outra nuvem. O endereço antigo fica em paralelo durante a janela de migração. Depois, uma falha de rede impede determinado resolvedor de alcançar todos os servidores autoritativos. Seu cache ainda contém o A anterior, expirado há cinquenta minutos.

Responder com erro interrompe recargas de toda a região. Responder com o endereço antigo pode preservar o serviço se a sobreposição continuar. Também pode enviar credenciais a um IP que já saiu da custódia do portal. O resolvedor não conhece o contrato da migração. Ele sabe apenas o que recebeu no passado, quando o TTL terminou e como suas tentativas de atualizar falharam.

Serve-stale não descobre qual cenário é verdadeiro. Ele escolhe qual consequência é tolerável sob incerteza. Por isso precisa ser tratado como autoridade de emergência delimitada, não como otimização invisível de cache.

O TTL termina uma permissão e inicia uma obrigação

A RFC 1035 vinculou o TTL ao intervalo antes de consultar novamente a fonte e descartar o registro. A RFC 2181 o descreveu como vida máxima. A RFC 8767 altera a definição: quando o TTL expira, a fonte deve ser consultada; se a informação não puder ser atualizada autoritativamente, o registro pode ser usado como não expirado segundo as condições especificadas.

A ordem preserva a autonomia do publicador. O resolvedor não ganha licença geral para ignorar TTLs curtos. Entregar sempre o objeto antigo e só depois perguntar ao upstream transforma contingência em preferência normal pelo passado.

TTL zero permanece fora: dado exclusivo da transação corrente não deve ser cacheado e nunca vira reserva stale. Também não se deve confundir o limite sugerido de sete dias para TTL recebido com o máximo após expiração. O primeiro controla a vida comum publicada; o segundo, a extensão local assumida pelo resolvedor.

Quatro relógios governam a exceção

O client response timer define quanto o resolvedor tenta obter frescor antes de perder a janela útil do cliente. A RFC usa cerca de 1,8 segundo como exemplo. Curto demais confunde autoridade lenta com autoridade indisponível; longo demais oferece uma resposta correta depois que a aplicação desistiu.

O query resolution timer limita o trabalho recursivo completo, frequentemente de dez a trinta segundos na discussão. Ele deve continuar depois que o stale foi enviado. Satisfazer o cliente não encerra a obrigação de reparar o cache.

O failure recheck timer impede que cada consulta repita um fracasso conhecido. Uma falha recente pode autorizar resposta stale imediata até a próxima tentativa. O exemplo recomenda não tentar com frequência superior a trinta segundos e menciona teto de cinco minutos. A RFC 9520 exige cachear falhas de um segundo a cinco minutos e usar backoff em problemas persistentes.

O maximum stale timer limita por quanto tempo o objeto sobrevive depois do TTL. Um a três dias é a sugestão. Mais retenção ajuda em indisponibilidade longa, mas prolonga endereços, delegações e negativas antigas, além de consumir memória.

Auditar exige início, fim e motivo de cada relógio. O nó esperou por refresh ou reutilizou failure cache? O fetch prosseguiu? O objeto foi substituído, removido sob pressão ou restaurado depois de restart? Configurações semelhantes não bastam.

Qual resposta realmente atualiza o estado

Segundo a RFC 8767, resposta autoritativa com AA e NOERROR ou NXDOMAIN deve atualizar o cache. Outros RCODEs normalmente são falha de refresh e deixam o estado anterior intacto.

Um SERVFAIL transitório não apaga a última informação útil. Já um NXDOMAIN autoritativo novo pode encerrar uma antiga resposta positiva. O resolvedor não sabe se a remoção foi intencional ou erro; não possui direito de veto sobre a negativa presente.

REFUSED é ambíguo: retirada deliberada, ACL incorreta ou servidor que não responde pela zona. A implementação pode decidir se REFUSED de todas as autoridades impede stale. O comportamento precisa ser testado por release.

A RFC 9520 cria ainda o cache de falha de resolução. Ele reduz novas consultas, mas não afirma existência nem valor. O ledger deve exibir simultaneamente a resposta expirada e a falha temporária que justifica não consultar o upstream a cada cliente.

Trinta segundos não rejuvenescem o RRset

Ao responder com dados expirados, o resolvedor deve colocar TTL maior que zero; trinta segundos são recomendados. Esse valor é uma pequena licença downstream para a projeção do resolvedor, não uma renovação emitida pela zona.

Uma captura precisa do TTL original, inserção, expiração comum, idade stale, TTL retornado e causa. TTL=30 isolado pode ser um dado fresco no fim da vida ou uma memória de horas.

A RFC 8914 define EDE 3 para Stale Answer, EDE 19 para Stale NXDOMAIN e EDE 7 para Signature Expired. EDE descreve, mas não muda o processamento do RCODE nem obriga a aplicação a reagir. Em cadeias de forwarding, a opção pode desaparecer, tornando indispensável observar cada salto.

Negativas antigas podem impedir uma correção

Um A stale preserva um destino anterior. Um NXDOMAIN stale preserva ausência. NSEC ou NSEC3 expirado pode continuar cobrindo um nome, DS ou TLSA recém-publicado. A resposta chega rápida e limpa, mas a mudança de segurança fica invisível.

As classes não têm o mesmo custo. Conteúdo, controle de certificado, delegação, endpoint de emergência e revogação pedem políticas distintas. Se o produto não oferece granularidade segura, reduzir o escopo é melhor do que fingir que uma flag global respeita diferenças.

Métricas também separam positive, NXDOMAIN e NODATA. Um contador agregado não mostra se stale preservou alcance ou bloqueou uma presença nova.

A assinatura não segue o maximum stale

A RFC 4035 exige que a hora do validador esteja entre inception e expiration do RRSIG. Guardar o RRset não amplia essa janela. O mesmo objeto pode estar stale e ainda seguro, depois stale com assinatura expirada.

É preciso medir stale com assinatura válida, stale com assinatura vencida, validation failure cacheado e qualquer exceção insegura. “DNSSEC ligado” não informa qual estado chegou ao cliente.

Um atacante que mantenha as autoridades inacessíveis pode prolongar binding antigo. A RFC 8767 discute endereços abandonados e risco para certificados validados por domínio. O recurso não cria o abandono, mas escolhe a duração de sua ação durante a falha.

A execução varia entre BIND e Unbound

BIND documenta retenção, resposta, TTL enviado, idade máxima, refresh e rndc serve-stale como controles separados. A documentação atual apresenta trinta segundos para reply TTL e um dia para maximum stale quando ativo. O client timeout é desligado por padrão e, na versão documentada, só aceita zero quando habilitado: retorno imediato.

Unbound usa serve-expired-* para idade, reply TTL, espera e reset. Sua documentação atual distingue resposta imediata do modo que tenta refresh antes. Versão e comportamento observado, não o nome comum, formam o contrato.

O canary inclui autoridade rápida, lenta, inalcançável, SERVFAIL, REFUSED, NXDOMAIN; positive e negative; RRSIG válido e expirado; TTL zero; pressão de cache; restart; override. A prova vai do cache e pacote upstream ao response, EDE, refresh posterior, substituição e conexão.

Fontes