Resumo

  • A RFC 8767 permite que um resolvedor recursivo use certos dados vencidos quando não consegue atualizá-los de forma autoritativa; registros recebidos com TTL zero continuam inelegíveis para esse recurso.
  • A continuidade muda temporariamente a cadeia de controle: o operador da zona publicou o TTL, mas o operador do resolvedor define a espera, classifica a falha e limita por quanto tempo a resposta antiga poderá circular.
  • Os códigos EDE conseguem indicar uma resposta stale, porém são diagnósticos. Eles não autenticam o dado antigo nem autorizam seu uso em nome do cliente.

Análise

Considere uma troca de endereço feita por motivos de segurança. O operador publica um novo A ou AAAA e deixa o TTL do registro anterior expirar. A maioria dos resolvedores aprende a mudança. Um deles, no entanto, chega ao fim do TTL enquanto todos os servidores autoritativos estão indisponíveis. Responder com erro interrompe o serviço. Responder com o endereço antigo pode preservar o acesso, mas também pode desfazer exatamente a retirada que a zona tentou realizar.

O TTL historicamente organiza essa relação. A RFC 1035 o descreve como o intervalo durante o qual um registro pode permanecer em cache antes de a fonte voltar a ser consultada e o dado ser descartado. A RFC 2181 esclarece que ele é um tempo máximo de vida, não uma obrigação de conservar o registro até o último segundo. Em operação normal, a zona publica o limite e o resolvedor deixa de reutilizar a informação quando ele termina.

A RFC 8767 abre uma exceção para a impossibilidade de atualizar. Se o dado expirou e não pode ser renovado junto a uma fonte autoritativa, o resolvedor pode mantê-lo e tratá-lo como se ainda estivesse válido. Isso não autoriza uma estratégia permanente de responder primeiro com o cache velho e verificar depois. É preciso ter ocorrido uma tentativa recente e de boa-fé de obter a informação atual, e a resolução deve continuar mesmo depois de a resposta stale ser enviada ao cliente.

TTL zero permanece fora da exceção. Um registro marcado com zero só pode servir à transação em andamento e não pode ser guardado como reserva futura. Quando dados vencidos são efetivamente devolvidos, cada registro precisa receber no pacote um TTL positivo. A recomendação é 30 segundos: o valor evita problemas conhecidos de implementações com TTL zero e reduz a repetição imediata de consultas por caches que estejam mais abaixo na cadeia.

Quatro relógios distribuem a decisão. O temporizador de resposta ao cliente define quanto o usuário espera antes de o resolvedor considerar o dado stale; o método de exemplo sugere cerca de 1,8 segundo. O temporizador de resolução limita o trabalho total para buscar uma resposta atual. O temporizador de nova verificação de falha controla a frequência com que autoridades problemáticas serão testadas outra vez. O máximo stale determina quanto tempo um registro vencido permanece candidato, com uma faixa sugerida de um a três dias.

Esses valores não precisam ser iguais entre operadores. A RFC 8767 trata serve-stale como uma operação local e deixa as variáveis para implementações e implantações. Dois resolvedores em conformidade podem tomar decisões opostas para o mesmo nome durante a mesma indisponibilidade. Um preserva a resposta antiga; o outro falha. A divergência mostra qual risco foi priorizado — interrupção ou obsolescência — e não necessariamente um defeito de protocolo.

O significado da resposta autoritativa encerra a exceção. NoError ou NXDomain autoritativos, com o bit AA, atualizam os dados e substituem o estado anterior. Outros códigos geralmente não afirmam o que existe agora naquele nome; por isso, devem ser tratados como falha de atualização, preservando o cache que já existia. SERVFAIL não prova que o endereço antigo continua correto. Ele apenas informa que nenhuma resposta atual útil foi obtida.

O cache de falhas da RFC 9520 cumpre uma função diferente. O documento exige que falhas de resolução sejam armazenadas por pelo menos um segundo e por no máximo cinco minutos, impedindo que consultas equivalentes disparem trabalho repetido para cima enquanto a entrada estiver válida. Esse cache guarda a falha do processo. Serve-stale guarda uma resposta antiga. O primeiro controla a tempestade de novas tentativas; o segundo muda o dado entregue ao usuário.

A RFC 8914 oferece uma forma de identificar a escolha. O código Extended DNS Error 3 significa Stale Answer, e o código 19 identifica Stale NXDOMAIN Answer. A informação ajuda na telemetria, mas não cria confiança adicional. EDE não é autenticado, a menos que a transação DNS esteja protegida, e seu conteúdo não pode alterar o processamento do protocolo. O código explica por que o resolvedor respondeu, sem provar que o valor antigo ainda é seguro.

O custo varia conforme o registro. Um A ou AAAA antigo pode sustentar um serviço inalterado ou mandar tráfego para um sistema aposentado. Um CNAME antigo pode reabrir uma dependência removida. A RFC 8767 também alerta que assinaturas podem expirar, que dados NSEC ou NSEC3 stale podem atrasar novos registros TLSA ou DS e que um invasor capaz de interromper o acesso às autoridades pode tentar prolongar a utilidade de informações antigas.

Esses riscos estão no padrão; não são evidência sobre um operador específico. O pacote factual não demonstra configuração, taxa de adoção, redução de indisponibilidade nem dano em nenhuma frota identificada. Ele demonstra a cadeia de controle: a zona publica dados e TTL; o operador recursivo decide retenção, temporizadores e classificação de falha; o cliente recebe as consequências.

Fontes