Na maioria das pesquisas de Sistema de Nomes de Domínio (DNS), geralmente os clientes realizam uma pesquisa direta, que é a pesquisa baseada no nome DNS de outro computador conforme ele está armazenado em um registro de recurso de host (A). Este tipo de consulta pressupõe um endereço IP como os dados do recurso da resposta recebida.

O DNS também oferece um processo de pesquisa inversa, na qual os clientes usam um endereço IP conhecido e pesquisam o nome de um computador baseado em seu endereço. A pesquisa inversa assume a forma de uma pergunta, como "Você pode me dizer o nome DNS do computador que usa o endereço IP 192.168.1.20?"

O DNS não foi originalmente projetado para oferece suporte a este tipo de consulta. Um problema de oferecer suporte ao processo de consulta inversa é a diferença entre como o namespace DNS organiza e indexa nomes, e como os endereços IP são atribuídos. Se o único método para responder a pergunta anterior fosse pesquisar em todos os domínios no namespace DNS, a consulta inversa demoraria demais e exigiria muito processamento para ser útil.

Para resolver este problema, um domínio especial, o domínio in-addr.arpa, foi definido nos padrões DNS e reservado no namespace DNS da Internet para oferecer uma forma prática e confiável de realizar consultas inversas. Para criar o namespace inverso, subdomínios dentro do domínio in-addr.arpa são formados, usando a ordem inversa dos números na notação decimal com ponto de endereços IP.

Esta ordem inversa dos domínios de cada valor de octeto é necessária porque, ao contrário dos nomes DNS, quando os endereços IP são lidos da esquerda para a direita, eles são interpretados da maneira oposta. Quando um endereço IP é lido da esquerda para a direita, ele é visualizado por suas informações mais generalizadas (um endereço de rede IP) na primeira parte do endereço até as informações mais específicas (o endereço IP do host) que estejam contidas nos últimos octetos.

Por este motivo, a ordem dos octetos de endereços IP precisa ser invertida quando a árvore de domínio in-addr.arpa é criada. Os endereços IP da árvore DNS in-addr.arpa podem ser delegados para organizações quando elas recebem um conjunto específico ou limitado de endereços IP dentro das classes de endereços definidos para Internet.

Finalmente, a árvore de domínio in-addr.arpa, como está incorporada ao DNS, requer que seja definido um tipo de registro de recurso adicional — o registro de recurso de ponteiro (PTR). Este registro de recurso cria um mapeamento na zona de pesquisa inversa que geralmente corresponde ao registro de recurso de host (A) nomeado para o nome do computador DNS de um host em sua zona de pesquisa direta.

O domínio in-addr.arpa se aplica a todas as redes TCP/IP baseadas no endereçamento de protocolo Internet versão 4 (IPv4). O Assistente de Nova Zona automaticamente assumirá que você está usando este domínio ao criar uma nova zona de pesquisa inversa.

Se você estiver instalando o DNS e configurando zonas de pesquisa inversa para redes de Protocolo Internet versão 6 (IPv6), poderá especificar um nome exato no Assistente de Nova Zona. Deste modo, você poderá criar zonas de pesquisa inversa no Gerenciador DNS que podem dar suporte a redes IPv6, que usam um nome de domínio especial diferente, o domínio ip6.arpa.

Informações adicionais estão disponíveis sobre IPv6 e DNS, incluindo exemplos de como criar e usar os nomes de domínio ip6.arpa, na RFC (Solicitação de Comentários)  3596, "Extensões DNS com suporte para IP versão 6". Para obter mais informações, consulte diretamente esta RFC, que pode ser encontrada no site RFC Editor (https://go.microsoft.com/fwlink/?LinkId=240 [a página pode estar em inglês]).

Exemplo: consulta inversa (para redes IPv4)

A ilustração a seguir mostra um exemplo de uma consulta inversa que é iniciada por um cliente DNS para saber o nome de outro host (host-a) com base em seu endereço IP: 192.168.1.20.

Exemplo: Pesquisa inversa de DNS

O processo de consulta inversa segue estas etapas:

  1. O cliente consulta o servidor DNS para um registro de recurso de ponteiro (PTR) que mapeia para o endereço IP de 192.168.1.20 para o host-a.

    Como a consulta é para os registros de recursos de ponteiro (PTR), o resolvedor inverte o endereço e acrescenta o domínio in-addr.arpa no final do endereço inverso. Isto forma o nome de domínio totalmente qualificado (FQDN) (20.1.168.192.in-addr.arpa.) para ser pesquisado em uma zona de pesquisa inversa.

  2. Depois de ser localizado, o servidor DNs autoritativo para 20.1.168.192.in-addr.arpa poderá responder com as informações do registro de recurso de ponteiro (PTR). Isto inclui o nome de domínio DNS do host-a, o que conclui o processo de pesquisa inversa.

Lembre-se que, se o nome inverso consultado não puder ser respondida pelo servidor DNS, poderá ser usada a resolução DNS normal (recursão ou iteração) para localizar um servidor DNS que seja autoritativo para a zona de pesquisa inversa e que contenha o nome consultado. Neste sentido, o processo de resolução de nomes usado em uma pesquisa inversa é idêntico àquele de uma pesquisa direta.

Consultas inversas

O uso de consultas inversas é uma prática antiquada, proposta originalmente como parte do padrão DNS para pesquisar um nome de host com base em seu endereço IP. Elas usam uma operação de consulta DNS fora do padrão, e seu uso está limitado a algumas das primeiras versões do Nslookup, um utilitário de linha de comando para solução de problemas e testes do serviço de Servidor DNS.

O serviço de Servidor DNS reconhece e aceita mensagens de consulta inversa, respondendo-as com uma resposta de consulta inversa falsa. Para servidores DNS executados em Windows NT® Server 4.0, este suporte está disponível por padrão se o computador servidor foi atualizado para Service Pack 4 (SP4) ou posterior.

Observação

A configuração de registros de recursos de ponteiro (PTR) e zonas de pesquisa inversa para identificar hosts por consulta inversa é estritamente uma parte opcional da implementação padrão do DNS. Você não é obrigado a usar zonas de pesquisa inversa, embora elas sejam usadas para realizar verificações de segurança por alguns aplicativos de rede.


Sumário