Resumo

  • O TTL de um HINFO sintético precisava equilibrar menos consultas ANY repetidas com a possibilidade de mudar a política mais tarde. Não havia um valor único adequado a todos os operadores.
  • Uma resposta pequena e não vazia oferecia algo que resolutores já sabiam guardar. Um novo código de recusa, ao contrário, podia provocar tentativas em outros servidores autoritativos.
  • ANY não garantia um inventário completo. A seleção de conjuntos não negava a existência dos tipos omitidos, e um HINFO sintético em cache podia mascarar o HINFO verdadeiro.

A economia precisava durar — mas não para sempre

Uma resposta que desaparecesse logo não reduziria muito as próximas consultas. Uma resposta conservada por tempo excessivo poderia continuar representando uma escolha que o operador já quisesse abandonar. O TTL colocava essas duas necessidades na mesma decisão.

O RFC 8482, publicado em janeiro de 2019, trata diretamente desse compromisso. Para o HINFO sintetizado em uma resposta ANY, recomenda escolher uma duração suficiente para conter perguntas frequentes do mesmo iniciador sobre o mesmo nome, reconhecendo que um prazo longo demais dificultaria mudanças futuras na política.

Não se tratava de um número mágico. O valor deveria ser configurável segundo condições locais. A memória remota era parte da utilidade do mecanismo, mas não uma extensão da memória que o operador pudesse apagar instantaneamente.

O RFC 2181, de julho de 1997, já delimitava o significado do TTL: tempo máximo de retenção, não obrigação de guardar até o último segundo. Implementações podem impor um teto. Por isso, nem a permanência nem o esquecimento ocorrem necessariamente de modo idêntico em todos os caches.

O que havia para guardar

HINFO era um formato antigo. O RFC 1035, de novembro de 1987, define duas cadeias de caracteres para CPU e sistema operacional. A finalidade era fornecer informações gerais de host, inclusive para protocolos como FTP que podiam adotar procedimentos especiais entre máquinas ou sistemas semelhantes.

Na forma sintética recomendada por RFC 8482, o campo CPU recebe a cadeia RFC8482 e o campo OS recebe uma cadeia vazia. O segundo campo continua presente com comprimento zero. Não foi retirado do registro, e não informa que o computador observado não tem sistema operacional.

Quando o servidor constrói deliberadamente essa resposta pelo mecanismo, o número do RFC também não é o resultado de uma descoberta de processador. Ele ocupa um formato conhecido para criar uma resposta curta que um cliente comum pode tratar e armazenar.

O caminho inverso, porém, não é seguro. RFC 8482 adverte que um receptor não deve concluir com certeza, apenas a partir desses dados, que qualquer HINFO recebido foi sintetizado conforme a especificação. A cadeia não funciona como selo autenticado de política nem como prova de implementação.

Essa cautela não proíbe o cache normal. O documento permite guardar a resposta pelas regras usuais e descreve separadamente a opção de suprimir novas consultas ANY quando há HINFO correspondente em cache, ou responder normalmente com o conteúdo já disponível. Armazenar uma estrutura conhecida e certificar sua origem são operações diferentes.

A pergunta ampla já carregava uma suposição

ANY era o nome comum para o tipo de consulta 255, apresentado com um asterisco em RFC 1035. A palavra podia sugerir uma promessa de reunir tudo, mas a pergunta DNS continuava tendo um nome, um tipo e uma classe determinados.

O RFC 1034 distingue QNAME, QTYPE e QCLASS. ANY no campo de tipo não é um curinga no nome e não equivale a AXFR, a consulta de transferência de zona. Pedir registros de um nome não enumera todos os nomes existentes na zona.

O algoritmo histórico também separa dados de zona e dados em cache. O que um resolutor tem disponível pode ser apenas parte do que uma fonte autoritativa conhece. Uma consulta ANY não transforma automaticamente esse conjunto local em um inventário completo.

Na tabela atual de parâmetros DNS da IANA, o tipo 255 já é descrito como pedido de alguns ou todos os registros disponíveis no servidor. HINFO permanece registrado como tipo 13, informação de host. O registro de tipos comprova números e significados, não quantos operadores usam hoje uma política específica.

Uma recusa desconhecida podia sair cara

RFC 8482 reconhece motivos legítimos para ANY, como depuração e verificação do estado de um servidor para certo nome. Também registra tentativas de obter MX, A e AAAA em uma única consulta. A aplicação, entretanto, precisava de alternativa quando não recebesse o conjunto esperado; não podia pressupor acesso à autoridade e retorno de tudo.

Para quem responde, o formato convencional podia ter outros custos. Uma consulta UDP pequena capaz de gerar resposta grande é atraente para reflexão com origem falsificada. Certas implementações gastavam trabalho adicional para montar a resposta. O interesse em limitar coleta ampla de dados também aparecia entre as motivações.

Reduzir o tamanho podia diminuir a utilidade do servidor como amplificador, mas não tornava secretos os demais dados públicos da zona. O documento não oferece aqui um censo atual de ataques, e a presença de ANY não é prova de intenção maliciosa.

Uma alternativa discutida consistia em criar um novo código de resposta para informar que a forma convencional não seria fornecida. Segundo a experiência relatada no RFC, resolutores que não reconheciam o código tentavam a pergunta nos outros servidores autoritativos disponíveis.

O operador podia, assim, recusar trabalho de uma maneira que produzisse mais trabalho no conjunto de servidores. A resposta pequena e não vazia seguia outra lógica: dar ao cliente algo que ele já sabia conservar, evitando repetir imediatamente a busca. Não é uma afirmação de que todo erro provoca o mesmo comportamento em toda implementação.

Três possibilidades, nenhuma obrigação universal

RFC 8482 é um documento na trilha de padronização que atualiza RFC 1034 e RFC 1035. Seus mecanismos nesta seção se aplicam a nomes existentes, classe IN e tipo ANY. As regras normais continuam valendo fora das alterações especificadas.

A primeira possibilidade é devolver um RRset disponível, ou um subconjunto pequeno dos conjuntos existentes naquele nome. Não há um sinal adicional que diga ao cliente que outros conjuntos ficaram de fora. Se TXT não aparece, isso não demonstra que TXT inexiste.

RRset também não significa um registro isolado escolhido ao acaso. RFC 2181 define o conjunto por nome, classe e tipo iguais, com dados possivelmente diferentes. Escolher o conjunto de endereços requer respeitar sua unidade; se um conjunto necessário não cabe inteiro, aplicam-se as regras de truncamento.

Selecionar menos tipos é, portanto, diferente de cortar membros de um conjunto. E o bit TC não serve como atestado de inventário completo do nome. A inexistência de truncamento não preenche a falta de uma garantia de que todos os tipos foram incluídos.

A segunda possibilidade é sintetizar HINFO quando não existe CNAME no nome correspondente. A recomendação do único registro com CPU e OS descritos não obriga a inserir permanentemente a ficha na zona. Tampouco autoriza fabricar existência para um nome ausente.

A terceira tenta adivinhar a intenção, devolvendo os conjuntos CNAME, MX, A e AAAA presentes e omitindo outros, como TXT ou DNSKEY. A heurística pode satisfazer algumas aplicações, mas gerar respostas maiores e errar sobre o que o solicitante precisava.

São opções. A especificação não aboliu ANY nem determinou que toda resposta passasse a ser HINFO. Operadores e implementadores podiam escolher conforme seu ambiente.

Uma ficha pequena podia ocupar a vaga da verdadeira

O problema mais particular da opção HINFO nasce depois da primeira resposta. Um registro sintético guardado em cache pode atender a uma consulta posterior por HINFO e mascarar a informação real que continua na zona.

RFC 8482 reconhece esse efeito e recomenda outro método ou tipo aos operadores que dependem do uso convencional de HINFO. A avaliação dos autores de que esse tipo era pouco usado se baseava em observações daquele período; não elimina a existência de usuários nem constitui uma medição independente de 2026.

O empréstimo de uma estrutura antiga economizava coordenação, mas não removia seus significados anteriores. O cache não tinha como separar automaticamente dois usos que chegavam pela mesma forma sem que as regras correspondentes sustentassem essa distinção.

É nesse ponto que TTL deixa de parecer mero detalhe. O tempo que poupa consultas também pode prolongar a interferência sobre uma pergunta específica. Alterar o servidor não permite fingir que a resposta anterior nunca saiu dele.

O silêncio sobre um tipo não era uma resposta negativa

O RFC 2308, de março de 1998, diferencia NXDOMAIN, erro de nome, de NODATA, ausência do tipo pedido para um nome válido inferida do conteúdo da resposta. NODATA não é um código próprio. A retenção de respostas negativas possui condições específicas, incluindo informações SOA.

Um HINFO ou um pequeno conjunto não vazio em resposta a ANY não expressa por si só nenhuma dessas negativas para todos os tipos omitidos. Uma aplicação precisa perguntar pelos tipos de que depende, em vez de transformar uma seleção incompleta em prova de ausência.

As condições de transporte também podem variar. RFC 8482 permite, por exemplo, resposta convencional em TCP e mínima em UDP. Não exige essa combinação nem promete que usar TCP dará acesso a todos os registros que não vieram antes.

Pequena não significava dispensada de segurança

O bit DO explicado no RFC 3225, de dezembro de 2001, informa capacidade para aceitar registros de segurança DNSSEC. Ele não declara que a validação já aconteceu nem que a resposta ANY é exaustiva.

RFC 8482 mantém os requisitos pertinentes de assinatura. No caso sintético, se DO está ativado e o respondente sabe que a zona é assinada, é necessário um RRSIG válido; com DO desativado, recomenda-se omiti-lo naquele caso. As opções de subconjunto e de estimativa da intenção também conservam suas condições de assinatura.

A autenticidade do conjunto devolvido não equivale à enumeração dos outros tipos. Uma resposta pode cumprir sua obrigação de assinatura e continuar sendo somente a resposta limitada que o servidor escolheu fornecer.