Resumo

  • A RFC 8767 admite dados DNS vencidos apenas como alternativa limitada depois que uma tentativa recente e legítima não obtém informação autoritativa utilizável.
  • TTL original, prazo máximo de uso vencido, espera do cliente, TTL devolvido, validade DNSSEC, sinal EDE e novos pedidos são relógios independentes.
  • David C. Lawrence é um dos três autores da RFC. A autoria documenta contribuição coletiva, não autoridade sobre zonas, resolvedores, implementações ou decisões de implantação.

Uma consulta chega no instante em que o registro deixa de ser atual. A memória do resolvedor ainda guarda o RRset, porém os servidores autoritativos não oferecem uma resposta aproveitável dentro do tempo do cliente. Devolver o valor anterior pode evitar falha. Também pode esconder uma mudança que o titular do nome já publicou.

Essa ambiguidade desaparece dos painéis com facilidade. Houve resposta, o aplicativo avançou e a disponibilidade parece intacta. Mas a continuidade foi fornecida por uma exceção, não pela recuperação da fonte.

Publicada em março de 2020, a RFC 8767 tem David C. Lawrence, Warren Kumari e Puneet Sood como autores. O documento conserva o sentido do TTL e cria uma transição controlada para dados vencidos. A cópia atua durante a interrupção, sem adquirir a autoridade do sistema que a originou.

O que permanece armazenado não permanece atual

A RFC 1035 usa o TTL para limitar o tempo de cache de um registro. A RFC 2181 reforça que o resolvedor não pode tratá-lo como atual depois do limite. O valor faz parte da intenção publicada pela zona; não é apenas uma sugestão de limpeza de memória.

Um programa pode manter os bytes após a expiração para diagnóstico ou contingência. Entretanto, retenção e permissão de resposta são estados distintos. A RFC 8767 não diz que todo objeto retido pode ser entregue; exige condições adicionais.

Dados recebidos com TTL zero não participam do mecanismo. A origem disse que não deveriam ser reutilizados. Criar depois um prazo stale seria contrariar uma instrução explícita.

O primeiro recibo nasce quando o RRset entra no cache: nome, tipo, classe, servidor de origem, conteúdo, TTL recebido, horário de entrada, expiração comum e condição DNSSEC. Sem isso, “última resposta boa” é uma descrição sem objeto nem idade verificável.

A fonte recebe a primeira oportunidade

Antes do fallback, a RFC exige uma tentativa recente de boa-fé. O resolvedor consulta o caminho autoritativo e aguarda conforme o orçamento do cliente. Só recorre à cópia vencida quando não recebe algo utilizável. Se uma tentativa muito recente já comprovou a falha, consultas posteriores podem evitar a mesma espera.

A ordem impede que conveniência vença autoridade. Uma troca emergencial de endereço, a retirada de um serviço ou uma alteração de validação DNS precisa aparecer assim que a origem estiver saudável. Preferir sempre o cache antigo por ser mais rápido prolongaria o estado anterior por decisão unilateral do intermediário.

Boa-fé precisa ser observável: alvos, transporte, início, fim, resposta, erro, validação e eventual memória de falha. Timeout, SERVFAIL, NXDOMAIN autoritativo e assinatura inválida não são rótulos equivalentes.

Responder ao cliente também não prova recuperação. A RFC manda continuar atualizando. O evento só termina quando chega uma resposta autoritativa fresca, ela é avaliada e substitui o estado excepcional.

Seis tempos cercam uma única resposta

O TTL original determina a frescura comum. Para evitar que um valor enorme crie retenção sem fim, a RFC sugere um teto da ordem de sete dias para o TTL recebido usado no cálculo stale.

O prazo máximo stale é política do resolvedor. Deve ser configurável, com sugestão inicial de um a três dias. Depois dessa fronteira, o registro deixa de ser elegível mesmo que continue guardado.

O tempo de espera do cliente funciona em segundos. Quanto menor, menor a latência percebida e maior a chance de uma resposta autoritativa apenas lenta perder a corrida.

O TTL devolvido acompanha a resposta excepcional. Precisa ser positivo e a recomendação é trinta segundos. Ele limita o cache seguinte; não zera a idade original nem renova o RRset.

As assinaturas DNSSEC carregam datas próprias. Um registro pode vencer no cache e ainda ter assinatura válida, ou a assinatura pode expirar antes do limite local. Configuração de cache não amplia tempo criptográfico.

Por fim, a frequência de nova tentativa equilibra recuperação e carga. Repetir rápido demais agrava a falha; esperar demais prolonga o valor antigo. Os seis relógios precisam de campos próprios.

DNSSEC autentica uma história, não a atualidade

A RFC 4035 obriga o resolvedor validante a examinar a cadeia e o período de RRSIG. Um RRset vencido pode continuar Secure se a prova ainda for válida. Isso indica que o dado foi assinado pelo titular em certo momento, não que ainda representa sua intenção atual.

A RFC 8767 observa que falhas de validação ficam mais prováveis com o envelhecimento. Também descreve um risco sem falsificação: manter a autoridade indisponível pode prolongar o uso de uma resposta anterior. O adversário explora a diferença entre autenticidade passada e vontade presente.

O consumidor define a tolerância. Chegar temporariamente a uma página e emitir um certificado com desafio DNS têm consequências diferentes. A RFC recomenda que autoridades certificadoras não usem resolvedores stale para essa validação.

Ausência também envelhece. Uma resposta positiva antiga pode manter tráfego em destino retirado; um NXDOMAIN antigo pode esconder um nome recém-criado. A RFC 8914 reserva Stale NXDOMAIN Answer porque “não existe” também precisa de prova atual.

EDE expõe a exceção sem consertá-la

Lawrence também coassinou a RFC 8914, que define Extended DNS Errors. O código 3 é Stale Answer e o 19, Stale NXDOMAIN Answer. Um cliente preparado pode reconhecer que não recebeu dados correntes.

O EDE não muda sozinho o RCODE, não autentica o RRset, não demonstra a causa da falha, não estende assinatura nem garante leitura pelo aplicativo. Muitos consumidores usarão apenas o endereço ou a negativa.

Seu papel é testemunhal. O operador pode medir respostas por motivo e idade, e aplicações sensíveis podem recusar a condição. Mas o resolvedor ainda precisa preservar a decisão completa.

Contar códigos 3 sem ligá-los ao objeto, atualização, idade, TTL, DNSSEC e recuperação mostra que uma exceção foi declarada, não que foi correta.

A execução transforma escolhas locais em fatos

A RFC 8767 registra um patch inicial para BIND 9.7.0, uso em produção relatado pela Akamai desde 2011 e suporte posterior no BIND 9.12, Unbound e Knot Resolver. O mecanismo ganhou forma com experiência operacional coletiva.

Isso não uniformizou configurações. A documentação atual do Unbound informa comportamento RFC 8767 por padrão desde a versão 1.23.0. Ela descreve espera de 1,8 segundo ou substituição de SERVFAIL, prazo padrão de um dia, TTL de resposta de trinta segundos e continuidade das tentativas.

São opções atuais de um produto, não ordens universais. O operador pode alterá-las e outras implementações diferem.

A prova vem do programa em operação: software, versão, valores efetivos, transição por consulta e pacote enviado. Os testes devem incluir origem saudável, silêncio, SERVFAIL, erro DNSSEC, retorno antes e depois do limite, valor novo e TTL zero. O manual define expectativa; o traço define fato.

A biografia de Lawrence delimita uma contribuição

O IETF Datatracker apresenta David C. Lawrence como “tale” e relaciona as RFCs 3425, 7871, 8767 e 8914. No registro atual, ele copreside Adaptive DNS Discovery, representa a IETF no Conselho da ICANN e atua como revisor técnico.

A página atual do Conselho da ICANN o identifica como representante sem voto da IETF desde 14 de novembro de 2024. A biografia cita RPI e Usenet, UUNET, a reescrita de BIND na ISC, Nominum, treze anos na Akamai, a seleção como DNSSEC Root Key Trusted Community Representative em 2010, DNS-OARC e CVFiber.

Os fatos mostram participação duradoura em implementação, padrões e ligação institucional. Não provam invenção individual, controle de resolvedores nem comando sobre a ICANN. A RFC tem três autores e resulta de consenso mais amplo.

Assim como a cópia não recebe autoridade da origem, o autor não recebe controle das implantações que usam o mecanismo.

O recibo termina quando o dado fresco substitui a exceção

Primeiro vêm o RRset, origem, TTL, entrada, expiração, conteúdo e DNSSEC. Depois, a tentativa recente: alvos, transporte, horários, resultado e memória de falha reutilizada.

A decisão registra prazo máximo, limite calculado, idade, espera do cliente, TTL de saída, EDE, exceção aplicada e próxima atualização. Uma proibição para consumidores de alto risco também precisa aparecer.

O fechamento contém a primeira resposta autoritativa utilizável, validação, novo conteúdo, instalação, retirada do estado stale e efeito percebido. Se o valor novo divergir, não se apaga o histórico do que foi servido durante a interrupção.

É a diferença entre proteger o registro e promover o guardião. O resolvedor preserva a função, mas não se torna fonte. A alternativa só é legítima enquanto procedência, idade, limite e retorno forem demonstráveis.

Fontes