Resumo

  • draft-hardaker-dnsop-nothing-new-00 propõe usar TC, um sinal NN e um RR LARGE com identificador de 16 bits para evitar buscar novamente um RRset volumoso que parece não ter mudado.
  • É um Internet-Draft individual, expressamente incompleto e não implementável. O Datatracker não registra stream nem status RFC pretendido, enquanto o cabeçalho diz Standards Track.
  • A seção de segurança argumenta que um atacante capaz de falsificar NN já poderia provocar uso de cache antigo descartando pacotes; o novo caminho pode chegar ao mesmo resultado mais cedo. Velocidade não é autenticidade nem atualidade.
  • A operação precisa separar aviso, falha de atualização, política de stale, identidade do RRset, validade DNSSEC, convergência autoritativa, decisão de transporte e resultado do cliente.

Chegar antes muda o evento observado

O problema de tamanho é plausível. Respostas DNS grandes podem não caber em UDP e exigir nova consulta em transporte confiável. Chaves e assinaturas pós-quânticas podem ampliar essa pressão, embora a revisão 00 não prove implantação, volume ou economia.

A proposta procura evitar retransmitir dados que o resolvedor já possui. Com TC, o servidor autoritativo poderia enviar NN e afirmar que o registro solicitado não mudou recentemente. Um RR LARGE forneceria uma versão curta. Se ela combinasse com o cache, a busca completa seria dispensada.

O ganho não é apenas de bytes. A decisão também chega antes do timeout que, de outro modo, revelaria falha de atualização e talvez ativasse uma política de stale. Essa antecipação altera a trilha de evidência.

Timeout diz: tentei atualizar e não concluí. NN diz: um servidor afirmou que atualizar não acrescentaria nada. Os mesmos bytes podem ser servidos ao final, mas diagnóstico, confiança e escalonamento não são iguais.

Stale é uma política de continuidade, não um selo de atualidade

RFC 8767 permite servir dados antigos em condições delimitadas para preservar resiliência. A política define tentativas, tempos e limites. Ela não renomeia o passado como presente.

O argumento de segurança do draft usa esse ponto. Um agente no caminho capaz de falsificar a pequena indicação também poderia descartar respostas até o resolvedor usar cache antigo. NN talvez apenas elimine a espera. Isso limita o ganho marginal do atacante, mas não autentica quem falou nem prova que a aceleração é inofensiva.

Um sistema precisa conservar estados distintos: cache dentro do TTL, cache com assinatura ainda válida, retenção após NN autenticado, retenção após NN não autenticado, stale após falha e atualização por transporte confiável. Somar tudo como cache hit apaga a causa.

Também é preciso registrar o contrafactual: o que o resolvedor faria sem NN? Tentaria TCP? Quanto tempo esperaria? Qual alerta surgiria? Sem isso, a organização não consegue medir se o mecanismo poupou trabalho ou ocultou uma divergência.

O sinal pequeno pode ficar sem assinatura

O draft diz que a assinatura do RR LARGE deve ser incluída se couber na resposta. Se não couber, recomenda enviar LARGE sem ela. Assim, um dado não autenticado pode influenciar a decisão de não adquirir o dado grande e assinado.

Há quatro verificações diferentes: autenticidade de NN, autenticidade de LARGE, validade do RRSIG do RRset em cache e autorização da política para reutilizá-lo. Um campo secure=true não representa as quatro.

Mesmo uma assinatura válida tem alcance limitado. Ela liga um RRset a uma cadeia DNSSEC e a uma janela temporal. Não informa a intenção atual do operador, a convergência de todas as autoridades nem a escolha correta da linhagem em cache.

O recibo deve guardar presença e resultado da assinatura, chave e cadeia usadas, início e expiração do RRSIG, hash integral do RRset e evidência de qualquer geração posterior. Só então “validável” não vira silenciosamente “mais recente”.

Um identificador de 16 bits precisa de contexto

LARGE carrega 16 bits e exige unicidade apenas durante a vida das assinaturas dos dados representados. Não é um número universal e eterno.

O texto aceita hashes, contadores, timestamps ou valores derivados do conteúdo. Hash truncado pode colidir. Contador exige estado durável e coordenação. Tempo exige resolução e regra de reinício. Derivação exige formato canônico.

Valores iguais só sustentam igualdade de objeto quando nome, tipo, classe, view, método e época coincidem. Restaurar configuração, reiniciar contador ou misturar views pode fazer objetos diferentes parecerem iguais.

Por isso, o valor curto deve apontar para o hash completo, autoridade emissora, perfil gerador, janela RRSIG e linhagem do cache. A rede usa o atalho; a auditoria preserva a identidade.

O serial SOA conta outra superfície

O draft desaconselha usar automaticamente o serial SOA. Uma zona dinâmica pode avançá-lo muitas vezes enquanto o DNSKEY grande continua igual. Versão de zona e versão de RRset são objetos diferentes.

Se um único número representa tudo, quem produz o número decide quais mudanças contam. Essa concentração parece conveniência técnica, mas altera a autoridade sobre o significado do estado.

Views também precisam permanecer no recibo. Dados diferentes podem ser corretos para públicos diferentes. Um identificador retirado de sua view cria falsa continuidade ou falsa colisão.

Um servidor não prova o conjunto

Primário, secundários e instâncias anycast podem servir gerações distintas durante transferência, carregamento ou falha parcial. NN é a fala do nó alcançado, não quórum.

Se o cache e a autoridade A têm a geração antiga, enquanto B já tem a nova, a combinação em A é honesta e ainda assim incompleta. Convergência precisa de um denominador nomeado.

Políticas rotineiras podem aceitar uma amostra. Mudança de DNSKEY, delegação ou recuperação pode exigir várias autoridades, fetch completo ou hold manual. O risco deve estar declarado, não implícito na cor do painel.

Anycast torna a cautela ainda mais importante. Repetir uma consulta no mesmo caminho não enumera instâncias globais. Observação representativa é útil; não é universal.

TC não declara que TCP falharia

TC informa truncamento. Não informa indisponibilidade de TCP, ausência de informação nova ou custo excessivo. RFC 7766 mantém suporte a TCP no contrato DNS completo.

Não buscar é uma ação do resolvedor. Ela deve registrar entradas, política, alternativa e resultado. A formulação correta é “fetch suprimido sob P”, não “fresh comprovado”.

Testes devem manter TCP saudável enquanto reutilizam identificador, dividem autoridades, expiram assinatura e falsificam NN. O objetivo é observar se a implementação respeita a política e preserva desconhecido, não forçar um veredito único.

Durante transições irreversíveis, o custo de uma falsa combinação é maior. Retirar chave, servidor ou caminho antigo após uma pequena pista pode eliminar a única rota ainda coerente. A economia deve ser subordinada ao recibo exigido pela ação.

O cliente continua além do cache

Depois da decisão, o resolvedor admite ou mantém uma geração, constrói uma resposta e a entrega. O cliente pode usar outro cache; a aplicação pode falhar por outra dependência ou continuar funcionando com dados antigos.

Resultado de serviço não prova que a decisão de frescor estava correta. Decisão DNS correta não garante resultado de serviço. Guardar ambos sem substituição permite separar coincidência de causalidade.

Indicadores úteis incluem decisão por consulta, idade e hash da geração, autoridade observada, divergência, tentativas de transporte e resultado de cliente. Um SLO de latência não deve certificar a realidade que não mediu.

O documento ainda não é mecanismo operacional

No congelamento, Datatracker chamava a revisão 00 de Internet-Draft individual ativo e explicitava ausência de endosso formal. Não havia stream, AD responsável, telechat ou status RFC pretendido. O cabeçalho dizia Standards Track; a divergência permanece.

O próprio texto se declara muito incompleto e não implementável. IANA está TBD. Parte de DNSSEC contém ideias não escritas; formato, localização e sinalização ao parent permanecem em discussão.

Não é possível afirmar alocação, produto, interoperabilidade, uso de PQC, economia medida ou incidente. O artigo analisa a fronteira que uma futura otimização teria de preservar.

O grafo de recibos impede que rapidez vire verdade

O grafo começa com query e geração em cache. Acrescenta autoridade e view, TC/NN, LARGE, autenticação e perfil gerador. A comparação liga o valor curto ao hash completo e à janela de assinatura. A política registra por que não houve fetch.

Transporte, admissão em cache, resposta ao cliente e observação da aplicação vêm depois. Nenhum resultado posterior reescreve o significado original.

Uma declaração defensável diz: “X enviou NN em T; Y combinou com o RRset Z, assinado até E; P suprimiu um fetch”. Ela é mais estreita que “o DNS estava atual” e mais útil em incidentes.

Liderança precisa decidir quando uma pista barata pode autorizar a não aquisição de evidência cara. Reduzir latência e carga é legítimo. Também é legítimo exigir prova adicional em mudanças de confiança. Chegar mais rápido ao cache antigo não o torna mais atual.

Fontes