Resumo

  • A RFC 9520 obriga o resolvedor a guardar uma falha de resolução por pelo menos um segundo e nunca por mais de cinco minutos. Um acerto nesse cache bloqueia trabalho de saída; não comprova NXDOMAIN nem NODATA.
  • A falha só existe quando nenhum servidor e nenhum transporte disponível entrega dado, encaminhamento descendente ou resposta negativa útil.
  • O registro defensável preserva tentativas, limite de retransmissão, clientes agrupados, chave e escopo do cache, recuo, consultas ancestrais evitadas, pressão de recursos e a primeira sonda de recuperação.

O silêncio de uma rede virou carga para outra

Em 4 de outubro de 2021, um comando de manutenção desconectou sem intenção os centros de dados do Facebook de sua rede de backbone. O relato da Meta explica que os locais de DNS autoritativo retiraram seus anúncios BGP ao perder contato com os data centers. Os servidores DNS permaneciam operacionais, mas a Internet já não conseguia alcançar seus endereços.

O impacto não ficou confinado àquela rede. A Verisign mediu cerca de 7 mil consultas normais por segundo para facebook.com, instagram.com e whatsapp.net em sua infraestrutura .com e .net. Durante a interrupção de quase seis horas, o total passou de 900 mil por segundo. Fontes recursivas mais ativas do Google e da Cloudflare chegaram a aproximadamente 7 mil e 2 mil vezes suas taxas habituais para esses nomes.

As delegações dos pais continuavam corretas. Perguntá-las novamente não restauraria a rota retirada pelo filho. Mesmo assim, a política de repetição transferiu o custo de uma zona inalcançável para camadas superiores saudáveis. O resolvedor não criou a falha inicial, mas ajudou a definir seu raio de impacto.

A RFC 9520 responde com uma autoridade estreita. Depois que todas as opções deixam de produzir informação útil, o resolvedor precisa armazenar a falha. Enquanto uma nova solicitação corresponder à entrada ainda válida, ela não pode gerar trabalho equivalente para cima. O significado é “não repetirei agora uma resolução que acabou de falhar”, e não “o nome não existe”.

NXDOMAIN e NODATA são negativas informativas. A falha de resolução é ausência de informação útil sobre a existência do dado. Confundi-las transforma uma decisão de capacidade em uma declaração de conteúdo que a zona jamais fez.

Falhar uma rota não é esgotar a resolução

Um resolvedor costuma conhecer vários NS, vários endereços por NS e, às vezes, vários transportes por endereço. Um timeout, um SERVFAIL ou um REFUSED isolado não fecha essa matriz.

A RFC considera útil a resposta que contém o dado solicitado, um encaminhamento para zona descendente ou uma indicação válida de ausência no nome consultado. Se qualquer servidor disponível entregar uma delas, não houve falha de resolução. Antes de inserir a entrada, o operador deve conseguir listar opções elegíveis, ordem, início, fim e resultado de cada tentativa.

Para a mesma pergunta, endereço e transporte, só são permitidas duas novas tentativas após o primeiro envio: três consultas no total. Outro transporte conhecido pode ser usado no mesmo endereço se estiver disponível e de acordo com a política de segurança. A norma não fixa timeout único; registra que valores comuns ficam aproximadamente entre três e trinta segundos.

A escolha continua local porque latência, handshake, anycast e compromisso com clientes variam. Mas ela deve ser observável. Um campo servidor falhou sem caminhos remanescentes e sem cronologia não sustenta a conclusão.

O mesmo SERVFAIL pode esconder falhas diferentes

Um autoritativo pode emitir SERVFAIL por não possuir dados válidos da zona. Um recursivo pode emitir o mesmo código após esgotar upstreams ou falhar em DNSSEC. REFUSED costuma representar política ou escopo. Timeout diz apenas que o prazo local terminou; ICMP, TCP ou TLS podem encerrar o transporte antes.

Loops de delegação e de alias, FORMERR e falhas de validação têm causas próprias. O cache pode preservá-las separadamente, mas seu efeito comum continua pequeno: suspender trabalho de saída correspondente por tempo limitado. Ele não converte REFUSED em SERVFAIL, dado bogus em dado validado nem silêncio em ausência.

Os Extended DNS Errors da RFC 8914 permitem informar Cached Error, No Reachable Authority ou DNSSEC Bogus. O contexto melhora operação e suporte, mas não altera o processamento do RCODE. EDE explica; não assina nem cria autoridade.

Muitos clientes não precisam gerar muitas transações

Enquanto a primeira consulta aguarda timeout, centenas de clientes podem pedir o mesmo QNAME, QTYPE e QCLASS. Um resolvedor que agrega solicitações idênticas liga todos a uma única resolução em andamento. Sem agregação, cada cliente produz sua própria saída e seus próprios retries.

O experimento apresentado no DNS-OARC 35, citado pela RFC 9520, observou cerca de 50 consultas por segundo para um domínio de botnet quando os autoritativos respondiam normalmente. Com todos retornando SERVFAIL, o volume chegou a cerca de 60 mil por segundo; raiz e TLD também receberam mais tráfego embora a delegação não tivesse mudado.

A agregação reduz também o risco descrito pela RFC 5452: várias transações equivalentes abertas aumentam as chances de uma resposta forjada acertar alguma. Há três controles distintos: unir demanda simultânea, limitar envios por caminho e guardar a falha depois de esgotar opções.

Cada um age em momento próprio. A união decide quantas transações existem. O limite decide o trabalho por caminho. O cache decide quando novas demandas voltam a sair. “Cache negativo habilitado” não demonstra a presença dos outros dois.

A economia de tráfego cria dívida de recuperação

Toda falha deve ser guardada por pelo menos um segundo e, no máximo, cinco minutos. A duração mínima deve ser configurável. Falhas persistentes podem aumentar o intervalo de maneira linear ou exponencial, sempre abaixo do teto.

Períodos maiores protegem upstreams durante falhas duradouras, mas podem atrasar a descoberta de reparo. Períodos menores recuperam mais cedo e gastam mais enquanto a falha continua. O backoff reduz trabalho e contrai dívida de recuperação.

Cada entrada precisa de chave, escopo, causas, inserção, duração, etapa, expiração e versão de configuração. Ao expirar, uma única sonda controlada deve testar o serviço, em vez de liberar a multidão acumulada. A primeira resposta útil remove a justificativa da supressão. A métrica importante é o atraso entre a disponibilidade real e a resposta entregue ao cliente.

O desenho da chave define o alcance. Uma falha DNSSEC pode estar ligada a nome, classe e tipo; um endereço inalcançável pode produzir estado por IP. O SERVFAIL de um servidor não condena todos. A RFC 2308 definia escopos específicos quando o cache era opcional. A RFC 9520 torna a função obrigatória e deixa a estrutura ao implementador, que precisa documentá-la.

O pai não é um botão de conserto

Quando todos os servidores de uma zona ficam mudos, alguns resolvedores voltavam ao pai para pedir novamente o conjunto NS. A RFC 4697 proibiu essa repetição agressiva. A RFC 9520 amplia a regra: todos os tipos de consulta ao pai e aos demais ancestrais devem ser limitados como o trabalho dirigido à zona em falha.

Um pai saudável pode repetir uma delegação exata sem ter como reparar a rede do filho. Suprimir a pergunta não declara a delegação errada; declara apenas que repeti-la dentro da janela atual não oferece informação nova.

O operador deve contar as consultas a ancestrais evitadas. O número mostra onde a falha teria deslocado carga. Depois da expiração, uma sonda ainda pode descobrir novo endereço ou delegação. A supressão é legítima porque termina.

DNSSEC precisa lembrar uma falha cujo TTL não merece confiança

A RFC 4035 já permitia um BAD cache para evitar validações repetidas. Como dados que falharam não carregam TTL confiável, o resolvedor atribui duração local curta e protege a memória contra abuso.

A RFC 9520 transforma a possibilidade em obrigação. Falhas DNSSEC devem ser guardadas. Isso não autoriza retornar o RRset inválido como seguro; autoriza lembrar que tentativas recentes não produziram dado aceitável.

Um EDE pode explicar erro em cache ou validação bogus. Ainda são necessários cadeia, horário, alcance e próxima sonda. Texto inteligível não substitui evidência criptográfica.

Serve Stale entrega dado antigo; o cache de falha retém trabalho

A RFC 8767 permite servir dado expirado quando a atualização falha e a política local aceita. Recomenda espaçar novas verificações da autoridade, frequentemente em trinta segundos. É continuidade com conteúdo antes útil.

A RFC 9520 também atua sem conteúdo antigo: nome novo, tipo novo ou Serve Stale desativado. Uma resposta stale diz que um dado pode ser reutilizado temporariamente. A falha em cache diz que nenhuma via trouxe dado útil e o trabalho ficará local até expirar. Conteúdo e contenção são promessas diferentes.

O cache de proteção também é superfície de ataque

Um atacante pode gerar muitos nomes ou tipos que falham e consumir memória e CPU. São necessários limites e métricas para cardinalidade, bytes, inserções, expulsões, concentração e rótulos aleatórios.

Mensagens de falha também não são dados DNS assinados. Uma falsificação correspondente pode levar o resolvedor a parar de consultar uma autoridade real durante o backoff. O teto de cinco minutos limita um evento, mas spoofing repetido pode renová-lo. Poucas transações abertas, evidência de transporte e comparação entre servidores são essenciais.

O cache é, portanto, um disjuntor com obrigação de prova. Sem limite, retry vira ataque involuntário. Sem escopo e expiração, o disjuntor vira negação.

O recibo mínimo da decisão

Guardar QNAME, QTYPE, QCLASS, primeiro horário e grupo de clientes. Enumerar corte da zona, NS, endereços, ponto de observação e transportes. Cada tentativa recebe início, fim, ordinal, resultado bruto e teste de utilidade.

Depois do esgotamento, separar RCODE, transporte, DNSSEC e EDE. Acrescentar chave, escopo, inserção, duração, estágio, expiração e prioridade de expulsão. Anotar consultas ancestrais evitadas, dados stale disponíveis e resposta efetiva ao cliente.

Na frota, comparar consultas de entrada, grupos unidos e saídas. Publicar amplificação, latência, CPU, memória e cardinalidade. Após expirar, identificar sonda, destino, primeira resposta útil e atraso visível de recuperação.

Esse recibo mantém a decisão junto a quem suporta seus custos. Não pede ao pai ou à IETF que certifique um timer local. Exige que o operador prove por que parou e quando voltou.

Fontes