DNS

Ontem estava lendo uns emails e o meu cunhado perguntou-me, - Cléber me tire uma dúvida, como é que o computador sabe o endereço certinho dum site? Esta foi a pergunta, sem tirar nem pôr nada, respondi a ele que o “computador converte este nome para um tipo de endereço que os servidores da internet conhecem, é assim que “ele acha os sites”. Claro que esta resposta foi dada a um usuário normal de computador e que não precisa saber muito sobre o funcionamento do DNS, mas, como este não é o nosso caso iremos tratar hoje sobre este assunto essencial para o profissional de TI e depois faremos duas práticas, uma num servidores W2K3 e outra em um roteador cisco.

Princípio

Nos primórdios, na época da ARPANET (Advanced Research Projects Agency Network) a forma de mapear os nomes aos endereços IP era através do arquivo, hosts.txt, para que você possa ter uma idéia de como é este arquivo, siga este passo-a-passo:

1. Iniciar
2. Executar
3. Digite exatamente este caminho, %systemroot%\system32\drivers\etc\hosts , e quando perguntar qual programa abrir, abra com o notepad, você verá um texto semelhante a este abaixo:

# Copyright (c) 1993-1999 Microsoft Corp.
#
# Este é um arquivo HOSTS de exemplo usado pelo Microsoft TCP/IP para #Windows.
#
# Este arquivo contém os mapeamentos de endereços IP para nomes de host. #Cada
# entrada deve ser mantida em uma linha individual. O endereço IP deve
# ser colocado na primeira coluna, seguido do nome de host correspondente.
# O endereço IP e o nome do host devem ser separados por pelo menos um
# espaço.
#
# Adicionalmente, comentários (como estes) podem ser inseridos em linhas
# individuais ou após o nome de computador indicado por um símbolo '#'.
#
# Por exemplo:
#
# 102.54.94.97 rino.acme.com # servidor de origem
# 38.25.63.10 x.acme.com # host cliente x

127.0.0.1 Localhost

Na época da ARPANET estava tudo bem, pois eram algumas centenas de endereços, só que as coisas começaram a mudar de figura, “em muito pouco tempo”, como diz o King Size do Rio de Janeiro, milhares de computadores começaram a se conectar nesta rede, a partir daí foi criado uma solução escalável, o DNS.
Se você quiser ver este assunto na fonte, consulte as RFC 1034 e 1035. O objetivo principal deste é o de mapear um nome em um endereço IP. Vou parafrasear a explicação de Andrew S. Tanenbaum, por achar muito completa, irei apenas enxertar algumas coisinhas, segue:
"Para mapear um nome em um endereço IP, um programa aplicativo chama um procedimento de biblioteca denominado resolvedor (cliente DNS) e repassa a ele o nome como um parâmetro. O resolvedor envia um pacote UDP (Porta 53) a um servidor DNS local, que procura o Nome e retorna o endereço IP ao resolvedor. Em seguida, o resolvedor retorna o endereço IP ao programa aplicativo que fez a chamada. Munido do endereço IP, o programa pode então estabelecer uma conexão TCP com o destino ou enviar outros pacotes UDP até ele."

Como dissemos no início a internet cresceu de maneira vertiginosa, por isso foi necessário criar no DNS uma forma de escalável, por isso, foi projetado os domínios (nome que serve para localizar e identificar conjuntos de computadores em uma rede) de maneira hierárquica, a figura abaixo ilustra muito bem isto:

Ai entra o conceito de FQDN (Fully Qualifield Domain Name), ou domínio absoluto, como queiram, é um nome de domínio totalmente qualificado, trocando em miúdos através deste é possível identificar a posição do nó na hierarquia do DNS, por exemplo, imaginem este endereço, teste.com.br, o “teste” é o nome do computador, “com.br” o nome de dois domínios, se este domínio existisse eu poderia colocar, ao digitar o endereço, um ponto no final do endereço que por default é omitido, que funcionaria que é uma beleza. Já no caso do domínio relativo ou PQDN (Partially-Qualified Domain Names) não coloca o nome completo do endereço, isto causa algumas restrições, uma delas é que este tipo de referência a um dispositivo no domínio só é exeqüível dentro de um contexto de um domínio específico e não pode usar o ponto no final.

Vamos falar agora sobre o Registro de Recurso, o RR.

Quando um computador solicita alguma informação ao DNS na verdade ele está pegando informação deste registro, ele é composto de 5 campos como segue abaixo com a explicação de cada campo resumidamente:

Domain_name = Informa o nome do domínio ao qual esse registro se aplica.

Time_to_live = Para a maioria dos registros de recursos, esse campo é opcional. Ele indica um período de tempo usado por outros servidores DNS para determinar por quanto tempo as informações de um registro devem ser armazenadas em cache antes de expirar e serem descartadas. Por exemplo, a maioria dos registros de recursos criados pelo serviço do servidor DNS herda um TTL mínimo (padrão) de 1 hora do registro de recurso de início de autoridade (SOA), o que impede um armazenamento em cache por tempo demasiado por outros servidores DNS. Para um registro de recurso individual, você pode especificar um TTL específico para o registro que substitua o TTL mínimo (padrão) herdado do registro de recurso SOA. Valores iguais a zero (0) para o TTL também podem ser usados para registros de recursos que contêm dados voláteis que não devem ser armazenados em cache para uso posterior após a consulta DNS em curso ser concluída..

Class = Contém texto mnemônico padrão indicando a classe do registro de recurso. Por exemplo, uma configuração igual a "IN" indica que o registro de recurso pertence à classe Internet.

Type = Contém texto mnemônico padrão indicando o tipo do registro de recurso. Por exemplo, um mneumônico "A" indica que o registro de recurso armazena informações de endereço de host. Este campo é obrigatório. Têm também o SOA – que fornece o nome da principal fonte de informações sobre a zona do DNS; o CNAME que nada mais é que nomes alternativos dado, por exemplo, não sei se vocês perceberam mas a maioria dos sites começam com WWW, na verdade o WWW é um alias de um outro nome, só para exemplificar dêem um ping para o endereço do WWW.google.com.br e verá que um outro nome responderá, o PTR é usado para permitir pesquisas de endereços IP e retornar o nome da máquina correspondente, tem mais types, se você quiserem poderão pesquisar nas RFC 1034 e 1035 citadas acima.

Vamos falar um pouco agora sobre os tipos de consultas, há dois tipos a recursiva e a autoritativa.

Quando o servidor DNS recebe uma consulta, ele primeiro verifica se tem autoridade para responder à consulta com base nas informações de registro de recurso contidas em uma zona configurada localmente no servidor. Se o nome consultado corresponde a um registro de recurso nas informações de zona local, o servidor responderá autoritativamente, usando essas informações para resolver o nome consultado.

Se não houver informações de zona para o nome consultado, o servidor verificará se pode resolver o nome usando informações de consultas anteriores armazenadas localmente em cache. Se uma correspondência for encontrada, o servidor responderá com essa informação. Novamente, se o servidor preferencial puder responder ao cliente solicitante com uma resposta positiva correspondente em seu cache, a consulta será concluída.

Se o nome consultado não encontrar uma resposta correspondente no servidor preferencial -- nas informações em cache ou de zona -- o processo de consulta poderá continuar usando recursão para resolver totalmente o nome. Isso envolve a ajuda de outros servidores DNS para resolver o nome. Por padrão, o serviço de cliente DNS solicita que o servidor use um processo de recursão para resolver totalmente nomes solicitados pelo cliente antes de retornar uma resposta. Na maioria dos casos, o servidor DNS é configurado, por padrão, para fornecer suporte ao processo de recursão.

Posted in: Redes