Resumo

  • O IQUERY invertia a mensagem DNS: fornecia um resource record em Answer e solicitava ao servidor os owner names correspondentes em Question.
  • Como o DNS distribuía autoridade pela árvore de nomes, e não por valores arbitrários de RDATA, uma resposta localmente correta não tinha como demonstrar completude no namespace distribuído.
  • Varreduras exaustivas, índices auxiliares, cache inadequado, respostas enormes e exposição de dados tornaram cara uma promessa já limitada; PTR sob IN-ADDR.ARPA transformou a reversão de endereço em uma consulta nominal comum e delegável.

A resposta vinha antes da pergunta

Uma query DNS normal leva QNAME, QTYPE e QCLASS na seção Question. O servidor coloca os records correspondentes em Answer. O IQUERY começava ao contrário: Question podia estar vazio, enquanto Answer continha algo como A IN 10.1.0.52. O cliente queria saber quais nomes fariam daquele dado uma resposta.

O RFC 1035 reservou o opcode 1 para a operação. O owner name e o TTL do RR fornecido não tinham significado, e o rótulo curto da raiz podia ocupar o lugar do nome desconhecido. A response trazia zero, um ou vários conjuntos QNAME, QTYPE e QCLASS em Question e ajustava o registro inicial à primeira correspondência.

No formato da mensagem, havia simetria. Uma consulta padrão avançava de um nome para um recurso; a inverse query partia do recurso em direção aos nomes. As mesmas seções representavam as duas orientações.

A arquitetura por trás do pacote não era simétrica. Um resolver que conhece um nome pode seguir referrals desde a raiz até a zona responsável. Um endereço, um destino MX ou uma string em outro record não aponta para todas as zonas que talvez contenham aquele valor. Antes de pesquisar, o cliente já precisava adivinhar qual servidor teria o conjunto adequado.

O limite foi reconhecido no nascimento do DNS

O RFC 882 dizia em 1983 que o domain system não podia garantir completude nem unicidade das inverse queries, pois era organizado por domain name, não por host address ou outro resource type. Para obter garantia, um resolver precisaria de um servidor conhecido por possuir os dados corretos ou teria de consultar todos os servidores do domínio relevante.

Essa ressalva não era apenas uma limitação de desempenho da época. Faltava um caminho para localizar autoridade usando o valor pesquisado. No caso do nome, a delegação faz parte do próprio sistema e conduz ao próximo responsável. Um valor arbitrário não possui parent, referral ou fronteira que reduza o universo de busca.

O RFC 883 tratava o IQUERY como dependente do ambiente. Uma organização podia configurar seus resolvers para usar servidores com cópias amplas das próprias zonas. A ferramenta seria útil à administração e ao diagnóstico, sem se converter numa visão autorizada da Internet inteira.

Três relações devolvidas por um servidor podem ser totalmente verdadeiras. Ainda assim, uma quarta relação pode estar numa zona que ele nunca carregou. A exatidão do observado não fornece completude e não transfere autoridade sobre o ausente.

O contrato cabia no que aquela máquina sabia

O RFC 1035 restringiu a resposta aos nomes que possuíam o RR e que o name server conhecia. Nenhuma máquina conhecia todo o domain space; portanto, a lista jamais poderia ser presumida completa. O texto destinava IQUERY principalmente a database management e debugging e rejeitava seu uso geral para mapear host address em host name.

Zero resultados significavam somente que o servidor escolhido não encontrou uma correspondência no corpus visível. Não provavam inexistência global. Um resultado demonstrava uma associação visível, não exclusividade. Uma lista longa podia continuar limitada às zonas autoritativas locais, ao conteúdo incidental do cache ou aos RR types para os quais existia índice.

Uma negativa DNS comum tem uma fronteira mais clara. O nome consultado localiza uma zona autoritativa; dentro dela, o servidor pode afirmar a inexistência daquele nome. O IQUERY não definia o conjunto “todos os registros com este valor”. Provar ausência exigiria excluir todo lugar onde o valor pudesse aparecer.

Por isso, a força de uma busca depende também do universo declarado, de quem o controla, do instante observado e da capacidade de localizar partições omitidas. Sem essa proveniência, uma lista organizada parece fazer uma afirmação maior do que os dados autorizam.

Inverter o acesso criava outro banco de dados

Name servers organizam naturalmente os RR sob owner names, porque as consultas usuais começam em QNAME. Responder rapidamente por conteúdo de RDATA requer um acesso secundário.

O RFC 883 descrevia tabelas de inversão por zona e chave. Cada mudança de zona podia exigir sua atualização. O RFC 1035 apresentava duas alternativas: uma busca exaustiva da base ou uma base separada indexada pelos valores da principal. A primeira paga CPU a cada request; a segunda paga memória, sincronização e complexidade continuamente.

As comparações também dependiam do tipo. RDATA pode guardar endereço, domain name, character string ou uma estrutura própria. O RFC 1035 recomendava comparação sem diferença de caixa quando possível, mas reconhecia que o servidor podia manter octetos cujo caráter textual desconhecia. Procurar “o mesmo valor” não era uma operação universal.

O incentivo era assimétrico. O solicitante enviava uma pequena chave; o operador financiava índice, scan, montagem e transmissão. A mensagem não mostrava benefício para a zona nem continha um limite natural para o número de correspondências.

Publicar RR individuais para resolução interoperável não é a mesma obrigação que oferecer análise livre sobre todos os valores. O IQUERY acrescentava essa superfície ao servidor que já sustentava os dados operacionais.

Cache não converte uma visão local em autoridade global

O DNS cresce por reutilizar RRsets até o fim de seus TTLs. Resultados de IQUERY não cabiam bem nessa lógica. O RFC 1035 alertava que eles não podiam ser armazenados pelo mesmo mecanismo das respostas comuns.

Um host multihomed pode possuir vários RR de endereço do mesmo tipo. Encontrar seu nome por um endereço não revela necessariamente o conjunto todo. Se o cache guarda aquela relação extraída como se fosse o RRset completo associado ao QNAME reconstruído, uma seleção por valor vira uma afirmação incompleta por nome.

O corpus original também se perde. Talvez a response refletisse certas zonas e parte do cache de uma máquina. Ao circular, o resultado deixa de informar quais partições nunca foram pesquisadas. Repetir uma visão torna seu acesso barato, mas não amplia seu escopo.

Na query normal, lookup key, delegação, autoridade, cache key e TTL se alinham ao redor do nome. O IQUERY reutilizava o envelope e desfazia esse alinhamento. Toda otimização precisava conservar uma cláusula fácil de esquecer: apenas o que aquele servidor sabia naquele momento.

PTR nomeou a chave reversa

O reverse mapping de endereços não venceu graças a uma pesquisa global melhor. O RFC 1034 descreve IN-ADDR.ARPA: os octetos de um IPv4 aparecem em ordem inversa sob um domínio especial, e um PTR nesse owner name aponta para outro domain name.

Para 10.1.0.52, o resolver constrói um nome previsível na árvore reversa e envia uma consulta padrão. Partes da árvore podem ser delegadas. Servidores autoritativos podem ser encontrados, o RRset pode usar TTL normal, e uma resposta negativa fica ligada a uma zona identificada.

A indirection é a correção arquitetural. PTR não promete que todo endereço terá registro, que haverá um único nome ou que o nome autenticará uma máquina. Ele faz algo mais restrito: coloca a declaração reversa sob um nome para o qual o DNS já sabe localizar responsabilidade.

IQUERY pedia ao sistema que descobrisse um índice desconhecido a partir do valor. PTR exige que o responsável pelo reverse space publique uma relação explícita em um nome conhecido. A busca aberta se torna recuperação delegada.

O cliente honesto precisava de completude; o abuso não

Em 2002, o RFC 3425 declarou o IQUERY totalmente obsolete. O recurso não fora implementado de modo geral e os operadores costumavam desativar suporte antigo. O documento cita bugs em código pouco exercitado, carga de banco e exposição de grandes conjuntos de nomes.

Alguns valores poderiam corresponder a listas imensas. Procurar todos os domínios delegados ao nameserver de um grande provedor poderia devolver dezenas de milhares de tuples e ocupar megabytes. Uma request pequena acionava computação e transferência desproporcionais, úteis para denial of service.

Inverse MX queries também agregavam muitos nomes ligados à mesma infraestrutura de correio. O fato de cada RR ser público não significa que o operador ofereceu um catálogo em massa por qualquer dimensão. IQUERY reduzia o custo da coleta e deslocava parte dele para o servidor.

O usuário legítimo desejava certeza e não podia obtê-la. Quem buscava abuso não precisava dela: consumir CPU, memória ou banda, provocar resposta grande ou extrair um conjunto local já bastava. A fraqueza probatória não limitava o dano operacional.

Aposentar o número preservou um significado único

O RFC 3425 não reutilizou o opcode 1. Ele substituiu a seção relevante do RFC 1035, marcou a operação como obsoleta, recomendou Not Implemented e pediu que o valor permanecesse aposentado para sempre.

Reatribuir o número poderia fazer software antigo interpretar tráfego novo com a semântica abandonada. A aposentadoria permanente preserva a história inequívoca e encerra a expectativa de serviço sem criar outra colisão.

O texto também observou que nenhum cliente conhecido dependia de IQUERY para um serviço significativo e que PTR sob IN-ADDR.ARPA havia atendido por anos o reverse mapping comum. A retirada respeitava dependências reais, em vez de esconder um serviço ainda necessário.

DNSSEC revelava outra dificuldade. O RFC 3425 considerava extremamente difícil proteger responses IQUERY sem assinatura no momento da resposta. Uma zona assinada autentica RRsets nomeados e provas negativas numa estrutura de nomes. Uma busca arbitrária precisa ainda provar que nenhuma correspondência foi omitida de um universo que o IQUERY nunca definiu globalmente.

O servidor era testemunha, não o namespace inteiro

Um DNS server pode ser participante real, autoritativo para zonas e portador de records exatos. Isso o torna testemunha de um perímetro definido. Ter uma cópia pesquisável não o transforma no principal de nomes externos que compartilham o valor.

As notas de Lu Heng separam participação de autorização e administração de um registro de autoridade sobre o objeto descrito. IQUERY expõe a mesma fronteira no protocolo. Enxergar dados permite relatar o que foi visto; não permite negar o que estava ausente do campo de visão.

A solução não foi erguer um catálogo central maior. O DNS preservou uma camada comum pequena: nomes, delegações, RR types, TTLs e relações reversas publicadas explicitamente. Cada participante declara dentro de zonas delimitadas; cada resolver segue regras comuns sem transformar um intermediário em observador onisciente.

Limites da evidência

Os cinco RFCs estabelecem o formato, os limites declarados, a alternativa PTR e a decisão normativa de aposentadoria. Eles não medem o tráfego opcode 1 atual, não enumeram todas as implementações históricas e não excluem usos diagnósticos em redes privadas.

NOTIMP é a resposta esperada, mas não prova que o servidor jamais analisou o pacote. Um timeout pode vir de filtragem ou perda. Uma resposta positiva demonstra processamento local, não completude global.

PTR também não é credencial de identidade. Dados forward e reverse podem faltar, divergir ou ser múltiplos. A vantagem examinada é localizar responsabilidade por uma declaração, não tornar toda declaração automaticamente verdadeira.

IQUERY oferecia a direção da pergunta, mas não a direção da autoridade. Um bit invertia a mensagem; não conseguia inverter as delegações de um sistema distribuído. O DNS se tornou mais confiável quando abandonou a simetria sedutora e colocou relações reversas de volta sob nomes.

Fontes