Resumo

  • A RFC 3425 aposentou permanentemente o opcode DNS 1, IQUERY, e orientou o servidor a responder Not Implemented; a recusa dizia respeito à operação, não à existência de um nome.
  • O mapeamento reverso permaneceu em registros PTR explícitos e delegados. NOTIMP, NXDOMAIN, NODATA, resposta PTR e validação DNSSEC são evidências diferentes.

Uma recusa antes da busca

Um utilitário antigo envia opcode 1 e recebe NOTIMP. Se o inventário grava “nome reverso inexistente”, acrescenta um fato que o servidor não afirmou.

Publicada em novembro de 2002, a RFC 3425 declarou IQUERY totalmente obsoleto, substituiu a seção 6.4 da RFC 1035 e recomendou Not Implemented para esse pedido. O servidor pode ter se comportado exatamente como o padrão determinava sem consultar nome algum.

Não houve NXDOMAIN, NODATA nem prova de ausência de PTR. Houve uma decisão anterior: essa operação não pertence mais ao serviço.

IQUERY procurava o valor dentro de uma base local

Na RFC 1035, o cliente colocava um valor de Resource Record na answer section. O servidor deveria devolver triplas de tipo, nome e classe encontradas em seus dados. Não era uma consulta a um owner name de in-addr.arpa.

Responder de forma geral exigia percorrer a base ou manter outro índice por valor. A RFC 1035 já reconhecia o custo. A RFC 3425 descreveu a escala: servidores autoritativos por milhões de nomes poderiam gerar respostas enormes.

O exemplo mais expressivo buscava todos os domínios delegados a um nameserver de um grande ISP. O retorno poderia conter dezenas de milhares de triplas. Uma entrada curta disparava enumeração, processamento e saída volumosos, além de percorrer código pouco exercitado e expor blocos de nomes.

A pergunta não sabia seguir delegações

No DNS normal, o nome permite caminhar até a autoridade. IQUERY dependia do conteúdo do servidor contatado. Se outra autoridade guardasse dados relacionados, o primeiro servidor não tinha uma referência natural para encaminhar a inversão.

Dois servidores poderiam produzir listas diferentes sem erro, pois suas bases eram diferentes. Um servidor poderia recusar IQUERY mesmo hospedando RRsets relevantes. Logo, sua resposta não podia sustentar “todos os nomes associados a este valor”.

Inverter uma base e consultar um namespace delegado são atos com escopos distintos.

PTR transformou o reverso em nome explícito

O caminho usado em produção foi publicar o mapeamento como dado DNS. Para IPv4, forma-se um owner name sob in-addr.arpa e pergunta-se pelo PTR. RFC 1033, RFC 1034 e RFC 1035 definem o ambiente; RFC 2317 mostra que blocos menores que /24 também dependem de delegação explícita.

PTR não garante completude, propriedade nem identidade. Ele torna a pergunta roteável e registrável: owner name, cadeia de delegação, autoridade, TTL e, quando disponível, estado DNSSEC. A ausência passa a ter um mecanismo negativo próprio.

“Não encontrado” escondia quatro estados

NOTIMP fala da operação. NXDOMAIN fala da existência do owner name. NODATA diz que o nome existe sem o tipo solicitado. Timeout diz apenas que a janela terminou sem resposta aceitável.

RFC 8020 refinou o uso do NXDOMAIN autoritativo, sem transformar rejeição de opcode em inexistência. RFC 8499 ajuda a manter os termos separados.

Depois de NOTIMP para IQUERY, o cliente deve formular o PTR correto. Depois de NXDOMAIN, preserva autoridade e cache negativo. Depois de falha de validação, conserva a falha. Fundir tudo em campo vazio impede qualquer diagnóstico posterior.

A aposentadoria ocupou o número

A RFC 3425 registrou opcode 1 como IQUERY obsoleto e pediu aposentadoria permanente. O registro IANA de parâmetros DNS e a RFC 6895 preservam esse significado.

Um número aposentado não fica disponível para uma nova função. Reutilizá-lo tornaria pacotes antigos ambíguos. A reserva mantém a interpretação histórica. Ela não prova, contudo, que todo código legado sumiu; padrão, implementação, configuração e tráfego observado continuam independentes.

DNSSEC precisava de um RRset nomeado

A RFC 3425 observou que proteger IQUERY com DNSSEC seria muito difícil sem assinar respostas na hora. A inversão sintetizava listas potencialmente grandes; não recuperava simplesmente um RRset pronto.

RFC 4033, RFC 4034 e RFC 4035 organizam validação sobre dados explícitos e provas negativas. Um PTR validado sustenta a afirmação da zona, mas não prova sozinho alocação do endereço, controle do host, confirmação direta, alcance, autenticação ou resultado do serviço.

NOTIMP para IQUERY também não vira negação autenticada só por estar num pacote DNS.

Recusar corretamente era preservar clareza

A RFC 3425 não acabou com o DNS reverso. Ela encerrou uma inversão local de alto custo e autoridade difusa, mantendo o PTR delegado como pergunta explícita.

O legado está no sujeito de cada recibo. Operação recusada, nome inexistente, tipo ausente, RRset validado, identidade e serviço são proposições diferentes. Guardá-las separadas permite que o erro seja útil. Reduzi-las a “sem nome” fabrica uma ausência que ninguém observou.

Fontes e limites

O registro principal inclui RFC Editor HTML, texto, página informativa, Datatracker, histórico, referências e errata. O contexto vem de RFC 1033, RFC 1034, RFC 1035, RFC 2317, RFC 6895, RFC 8499, RFC 4033, RFC 4034, RFC 4035, RFC 8020 e do registro IANA. A leitura por camadas segue Heng Lu sobre camadas de realidade e primazia do código em execução.

As fontes não medem implantação atual, servidor vulnerável nomeado, ataque real, cobertura PTR, identidade, alcance, autorização nem sucesso de aplicação.