Resumo

  • Um Internet-Draft individual de agosto de 2026 recomenda que servidores DNS normalmente respondam a ANY com NOTIMP, salvo uma razão local específica para manter a interpretação antiga ou uma resposta mínima. A proposta não é um RFC nem consenso do IETF.
  • A unidade de migração deve ser a finalidade do cliente: identificar a decisão que usa a resposta, oferecer o RRtype ou diagnóstico adequado, testar o resultado e atribuir prazo às exceções. EDE pode esclarecer a recusa, mas não comprovar que uma dependência foi substituída.

Na infraestrutura, conveniência costuma envelhecer melhor que documentação. Uma consulta útil durante um incidente entra no roteiro de suporte. Depois vira script, ganha um alerta e passa a influenciar uma decisão operacional. O autor original sai da equipe, mas a linha continua. Quando alguém decide retirar o comportamento do servidor, descobre que a mudança tem consumidores, embora nenhum deles tenha um contrato explícito.

DNS ANY reúne as condições para esse tipo de dívida. O nome sugere um pedido por todos os registros de um nome. A prática não oferece uma coleção uniforme. Um servidor autoritativo conhece sua zona; um resolvedor recursivo pode conhecer apenas o que buscou; um cache reflete consultas e tempos diferentes. Uma delegação acrescenta dúvidas sobre a fronteira dos dados. A ausência de um registro numa resposta ANY não é uma declaração confiável de que ele não existe.

O documento draft-jabley-dnsop-no-longer-support-any-00, publicado em 6 de agosto de 2026, propõe reduzir ainda mais essa ambiguidade. Recomenda o retorno normal de RCODE 4, NOTIMP, salvo uma razão local concreta para continuar com a interpretação dos RFC 1034 e 1035 ou com as respostas mínimas permitidas pelo RFC 8482. Também propõe um Extended DNS Error para explicar que o servidor não suporta consultas ANY.

Sua autoridade precisa ser descrita sem atalhos. Trata-se de um Internet-Draft individual ativo, não adotado como consenso de DNSOP e não publicado como RFC. O Datatracker não o coloca em uma trilha RFC e registra apenas a existência do rascunho. A intenção Standards Track na abertura expressa um objetivo dos autores; não comprova aprovação institucional. Operadores podem examinar a proposta agora, mas não devem usar um futuro possível como se já fosse obrigação vigente.

A resposta ambígua tem um custo real

Respostas grandes ajudam determinados ataques de reflexão e amplificação. O RFC 5358 tratou o abuso de servidores recursivos abertos; o RFC 8482 discute a redução das respostas ANY e seus motivos. Além do volume de saída, há custo para reunir e construir dados. Mensagens maiores podem interagir mal com a fragmentação UDP; recorrer a TCP altera a carga e as condições de falha, sem tornar a capacidade gratuita.

A proposta de uma recusa explícita merece consideração por reduzir uma obrigação pouco definida do serviço público. Ainda assim, retirar ANY não resolve toda amplificação DNS. Outros RRtypes podem produzir respostas grandes. Exposição recursiva, capacidade autoritativa, limites de resposta e os demais controles de abuso continuam sendo decisões separadas. A avaliação deve atribuir à mudança o benefício específico que ela entrega, não uma segurança total que não pode prometer.

Tampouco o motivo de segurança elimina os usos legítimos. Um engenheiro pode utilizar ANY numa inspeção inicial. Uma ferramenta antiga pode esperar um conjunto específico. Um diagnóstico interno pode tentar enxergar o cache. Reconhecer essas situações não significa manter o comportamento para qualquer cliente da internet. Significa descobrir qual necessidade é válida, quem responde por ela e qual alternativa cabe no contexto.

Se um script recebe NOTIMP, o servidor mostrou uma fronteira. Não mostrou se o script sabe contorná-la corretamente. O cliente pode falhar, repetir, consultar outro destino ou continuar com um resultado antigo. Esse último comportamento gera uma falsa tranquilidade: o problema aparece só quando o cache vence, uma delegação muda ou uma contingência entra em ação.

Descobrir a decisão antes de escolher o substituto

Para uma verificação de correio, a necessidade está em MX e nas consultas posteriores exigidas pela lógica do diagnóstico. Para verificar delegação, é preciso tratar NS, referências e endereços pertinentes. Um protocolo de descoberta deve pedir os tipos que seu desenho define. Uma inspeção de cache deve usar uma interface autorizada, com alcance e atualidade conhecidos. Uma resposta ANY externa nunca foi inventário completo de um resolvedor.

Isso impede uma solução preguiçosa: trocar ANY por uma sequência indiscriminada de todos os tipos lembrados pelo desenvolvedor. Essa sequência pode aumentar tráfego e coleta sem reproduzir a decisão correta. O objetivo é obter a informação suficiente para uma finalidade autorizada, não reconstruir uma resposta volumosa por outro caminho.

Antes de alterar o padrão, a equipe deve abrir uma janela de observação limitada. Serviço receptor, classe de origem, carga interna identificada quando houver, periodicidade, transporte, tamanho de resposta e pistas de ownership podem transformar tráfego recorrente em tarefas de migração. Não é necessário armazenar todo nome consultado para sempre. Minimização, retenção definida e acesso restrito mantêm a coleta vinculada ao trabalho, em vez de transformá-la em vigilância permanente.

Cada grupo precisa de uma descrição funcional. Quem pode mudar o cliente? Que decisão usa o resultado? O que acontece hoje quando faltam registros? O software distingue cache de autoridade? Com que frequência o caminho realmente roda? As respostas podem revelar que a dependência já era frágil, pois se apoiava numa interpretação que servidores arbitrários nunca foram obrigados a compartilhar.

Tráfego sem responsável deve permanecer como “desconhecido”. Pode ser scanner, parceiro não inventariado ou sistema esquecido. A categoria não ganha direito automático à compatibilidade pública, mas também não pode sumir para melhorar o indicador de conclusão. Uma autoridade precisa conhecer e aceitar o risco residual, ou ordenar mais investigação.

Dar a cada finalidade um destino verificável

Uma finalidade necessária recebe uma substituição: RRtype explícito ou interface apropriada, versão de cliente, população de implantação e teste da decisão. Uma finalidade dispensável é retirada, com remoção da chamada e observação dos ciclos em que poderia voltar. Um diagnóstico legítimo é limitado a uma superfície local autenticada ou a um perímetro de rede controlado.

Quando não há correção imediata, pode existir exceção temporária. Ela precisa ter dono, escopo, fontes permitidas, justificativa, controle compensatório, data de vencimento e condição de desligamento. Um binário sem manutenção exige um plano de troca do ativo. Renovar o prazo automaticamente não é migração; é institucionalizar o comportamento antigo sem admitir a escolha.

Há ainda a finalidade não atribuída. Seu destino é uma investigação limitada ou uma aceitação explícita de risco, não uma nota vaga de compatibilidade. A política pública não pode depender eternamente de identificar toda origem arbitrária, mas a organização deve ser honesta quanto ao que sabe e ao que decidiu não resolver.

Com esse registro, o rollout pode ser dividido. Clientes gerenciados já corrigidos recebem a recusa; um pequeno grupo conhecido conserva um comportamento provisório. Servidores autoritativos públicos e diagnósticos internos não precisam de uma exceção idêntica só porque usam o mesmo software. A diferença deve carregar evidência local, controle e prazo locais.

EDE esclarece, não certifica

NOTIMP tem a vantagem de ser uma recusa explícita na camada de resposta DNS. Em vez de devolver dados que o cliente talvez interprete como um conjunto completo, o servidor indica que não implementa aquela consulta naquele contexto. Contar recusas ajuda a localizar origens e relacioná-las ao inventário. Mas RCODE 4 não sabe a intenção do cliente nem se existe um substituto funcional.

Resolvedores, encaminhadores e outros elementos reais do caminho podem influenciar o que chega à aplicação. O cliente também pode mudar transporte ou destino. Uma tela de suporte talvez mostre apenas uma falha genérica. A taxa de recusa mede o comportamento implantado, não a capacidade preservada.

O mecanismo EDE do RFC 8914 não muda isso. Ele acrescenta informação ao processamento normal do RCODE; não o substitui. Pode haver mais de um EDE. Encaminhamento e reescrita dependem das implementações. O texto extra é opcional, voltado a pessoas e pode ser descartado quando a mensagem precisa ser reduzida.

A explicação proposta no rascunho pode permitir que um operador reconheça rapidamente uma política deliberada. Ela não deve virar uma API de controle baseada numa frase em inglês. Um programa não deveria selecionar seus RRtypes interpretando esse texto. Uma equipe não deveria marcar a migração como concluída só porque a frase atravessou o resolvedor.

A evidência durável está na versão efetivamente instalada, nas consultas enviadas e no resultado da decisão. Diagnóstico melhor e substituição funcional são conquistas distintas. Misturá-las produziria uma métrica fácil de satisfazer e incapaz de revelar a dependência que importa.

Ensaiar a falha que o negócio verá

Enviar ANY e receber RCODE 4 basta para testar o servidor. Para testar a transição, é preciso reproduzir a decisão do consumidor. O diagnóstico de correio encontra e interpreta os dados corretos? A verificação de delegação distingue resposta autoritativa de referência e segue os endereços necessários? A descoberta obtém todos os RRsets que seu protocolo exige? A inspeção de cache tem autorização e entende a atualidade dos dados?

Incluam-se conjuntos vazios, truncamento, falha de validação DNSSEC, atraso de TCP, cache parcial e o caminho de encaminhamento que existe de fato. Autoritativo e recursivo devem ser medidos separadamente. Se versões antigas e novas convivem, a população precisa ser dividida: uma maioria saudável pode esconder um grupo pequeno que sustenta um processo importante.

Também se devem cobrir os ciclos lentos. Rotinas mensais, recuperação de desastre, mudança de zona e ativação de equipamentos raramente usados podem revelar a dependência depois do rollout. Dois dias sem incidente não comprovam a adaptação de uma chamada que ainda não ocorreu. O prazo de observação é determinado pela finalidade, não pelo calendário da entrega do servidor.

Fontes

  1. Registro atual do rascunho
  2. Histórico do rascunho
  3. Revisão 00 em HTML
  4. Revisão 00 em texto
  5. XML da revisão 00
  6. Mandato de DNSOP
  7. Documentos de DNSOP
  8. RFC 1034: conceitos do DNS
  9. RFC 1035: implementação do DNS
  10. RFC 6895: DNS e IANA
  11. RFC 8482: respostas mínimas a ANY
  12. RFC 8914: erros DNS estendidos
  13. RFC 5358: abuso de servidores recursivos
  14. RFC 9364: segurança e operação DNS
  15. RFC 9499: terminologia DNS
  16. RFC 7766: DNS sobre TCP
  17. Parâmetros DNS de IANA
  18. Códigos EDE de IANA
  19. Lu Heng: especificação inicial mínima e decisão local
  20. Lu Heng: o espelho da política