Tutorial DNS - Parte 2 - Detalhes mais técnicos

Na primeira parte deste tutorial falei sobre os fundamentos básicos do serviço de DNS. Os servidores podem ser autoritativos, sendo "donos" de uma ou mais zonas, e/ou recursivos, respondendo consultas por domínios diversos.Na sequência temos mais alguns detalhes do seu funcionamento.

GLUE Records

Quando um servidor recursivo está fazendo uma consulta ele pode se deparar com um pequeno problema. Tomemos o exemplo em que o usuário quer saber o endereço IP de "joaolucasmacedo.blogspot.com.br". Se ele já não tem este registro salvo em cache ele vai começar a pesquisa perguntando à algum servidor raiz pelo nome. Como eles não podem responder diretamente pela zona "blogspot.com.br" vão indicar pelo menos os servidores responsáveis pela zona ".br", que são "A.dns.br", "B.dns.br", "C.dns.br", até o "E.dns.br". Em seguida o recursivo vai perguntar à um destes pela zona blogspot.com.br.
Mas existe um pequeno detalhe. Qual o endereço IP de "A.dns.br" por exemplo? Para continuar a pesquisa ele terá que fazer outra pesquisa pelo nome "A.dns.br", para saber seu endereço IP, para conseguir perguntar sobre a zona "blogspot.com.br". Então ele perguntará ao root sobre "A.dns.br", e receberá a mesma resposta:
 - Olha, eu não sei quem é "A.dns.br", mas pergunte ao dono da zona ".br", que é "A.dns.br".

Vejamos um possível "diálogo" entre eles:
Recursivo: Quem é "joaolucasmacedo.blogspot.com.br?
Root server: Não sei, mas pergunte ao dono da zona ".br". É o "A.dns.br".
Recursivo: Quem é "A.dns.br"?
Root server: Não sei, mas pergunte ao dono da zona ".br". É o "A.dns.br".
Recursivo: Quem é "A.dns.br"?
Root server: Não sei, mas pergunte ao dono da zona ".br". É o "A.dns.br".
( ... )
 O processo não teria fim. Você não sabe o endereço IP de um servidor de uma zona, e este servidor é um host dentro da própria zona, à exemplo de A.dns.br, que é um host dentro da própria zona em que ele tem autoridade.
Por isso quando uma sub-zona é delegada à um outro servidor também devem ser registrados os seus endereços IP. Cada servidor autoritativo, quando informa sobre outro servidor de nomes autoritativo de uma zona abaixo dele, já responde com o nome do dito cujo e seu respectivo endereço IP.
 - Olha, não sei que é "joaolucasmacedo.blogspot.com.br", mas pergunte ao dono da zona ".br". É o "A.dns.br" que tem o IP 200.160.0.10 .
Isto é chamado de GLUE record. Sem este detalhe o processo seria impossível. Por isso mesmo os servidores já devem saber "de fábrica" os endereços IP dos root servers.

Você pose simular uma pesquisa recursiva usando o comando NSLOOKUP, percorrendo a árvore de domínios e encontrando os servidores autoritativos de cada sub-zona.
Exemplo:  nslookup joaolucasmacedo.blogspot.com.br j.root-servers.net
Perguntando ao root server J sobre "joaolucasmacedo.blogspot.com.br"
Naturalmente ele não me dá a resposta, mas uma dica("Saved by"), informando os servidores da zona ".br" e seus respectivos endereços IP(GLUE records). Em seguida você pode fazer a pergunta para qualquer um dos servidores indicados:
nslookup joaolucasmacedo.blogspot.com.br a.dns.br
Perguntando à "a.dns.br" sobre "joaolucasmacedo.blogspot.com.br"
Da mesma maneira ele não me responde diretamente mas dá a dica para os donos da zona.
"Olha, segundo meus registros, esta zona "blogspot.com.br" é dos servidores abaixo. Pergunte à eles .'-)."
Repare que não há GLUES neste caso, já que a zona dos servidores indicados está fora do escopo da zona dos servidores ".br". Estes serão informados pelos servidores da zona ".com". Caso necessário outra pesquisa análoga será feita até descobrir os endereços IP dos servidores do Google informados na figura acima.
Por fim, agora que sabemos quem é a autoridade máxima da zona "blogspot.com.br", podemos perguntar diretamente à ele o endereço IP de "joaolucasmacedo.blogspot.com.br". Escolha qualquer um dos servidores indicados e execute o comando:
nslookup joaolucasmacedo.blogspot.com.br ns3.google.com
Veja que temos algumas informações interessantes. Ele informa 2 endereços, um IPv6 e outro IPv4. E ainda, que na verdade, "joaolucasmacedo.blogspot.com.br" é um ALIAS(apelido, codinome, alcunha) para o host "blogspot.l.googleusercontent.com". Os detalhes dos tipos de registros serão explicados nos próximos artigos.

A porta 53

Como vimos, o serviço de DNS é extremamente simples, mas gera várias requisições recursivamente gerando um tráfego considerável. Por isso o sistema é distribuído em várias camadas e utilizamos servidores fazendo cache. É mais inteligente que as solicitações sejam feitas por pacotes UDP para agilizar o processo. Cada solicitação DNS é feita saindo de uma porta qualquer(acima de 1023) direcionada à porta 53/UDP do servidor. Naturalmente, servidor responde com pacotes originados na porta 53 destinados à porta de origem do cliente. Se a resposta do servidor ultrapassar o tamanho de um pacote UDP, um flag no cabeçalho DNS é definido para que o cliente saiba que é uma resposta truncada, e que vem mais pela frente.
A porta 53/TCP também é usada, mas geralmente entre servidores DNS para sincronizar as informações de zonas. Por exemplo um servidor mestre atualizando os registros no escravo.
Outra alternativa, não muito comum, é usar conexões TCP para consultas de clientes. Acaba não sendo muito utilizado na prática por consumir ainda mais recursos do servidor, mas é uma coisa que vem sendo repensada ultimamente porque as respostas com endereços IPv6 tornam-se maiores, como aquelas usando DNS-SEC, que vêm com chaves de segurança.
É comum os administradores de rede bloquearem a saída de pacotes à porta 53 para impedir que os clientes da rede usem outros servidores que não os desejados. Da mesma forma filtrarem tráfego na porta 53/TCP para impedir sincronização entre servidores DNS que não os da estrutura da empresa.

Servidores Master e Slave

 Você deve ter reparado que para cada zona existem vários servidores autoritativos. Um deles é tido como "Master" e outro(s) como "Slave"(escravo). As zonas são declaradas e configuradas normalmente em um servidor mestre, em seguida a declaração é feita nos escravos. Os escravos são informados de que, nesta condição, a configuração é obtida do servidor mestre para cada zona que ele atua como slave. Cada alteração feita é sincronizada entre eles para garantir redundância e balanceamento. Esta operação é feita na porta 53/TCP. Sendo slave o servidor precisa apenas ser informado do endereço IP do seu mestre, e para quem faz solicitações à ele as respostas são dadas normalmente de forma autoritativa.
Veja um trecho o arquivo de configuração do Bind de um servidor slave:
zone "examplo.com.br" { 
 type slave; 
 masters { 198.51.100.1; }; 
};
A zona é declarada com o endereço IP do servidor meste.

Zonas reversas

Outra funcionalidade do serviço de DNS é fazer o inverso, traduzir endereços IP para nomes de domínio. Se o cliente já sabe o endereço IP, mas quer ter certeza de que determinado nome está associado àquele endereço pode fazer a pesquisa reversa. Isto é de suma importância para servidores de email por exemplo. Se ele recebe um email do servidor de endereço IP 192.0.2.55 dizendo ser uma mensagem de "obama@whitehouse.gov", ele precisa ter certeza de que este endereço IP realmente pertence ao servidor de email do domínio "whitehouse.gov", caso contrário a mensagem é caracterizada como SPAM.
Primeiramente o endereço IP é colocado de forma invertida e adicionado a zona "in-addr.arpa", assim: "55.2.0.192.in-addr.arpa".
Esta zona "in-addr.arpa" é especial e específica pare resoluções reversas. A pesquisa é feita da mesma maneira que uma pesquisa normal.
Se as zonas dos nomes de domínio são delegadas a partir dos servidores raiz, os endereços IP são delegados a partir dos registros regionais de internet(RIRs). Cada bloco de endereços IP é atribuído à um registro(como o Lacnic), os registros regionais atribuem sub-blocos à empresas(sistemas autônomos) ou à registros nacionais, como o Nic.br. Por exemplo o endereço IP 200.160.0.10, que é do servidor "A.dns.br", é derivado do bloco 200. Então a zona "200.in-addr.arpa" é delegada aos servidores reversos do Lacnic.
Para tirar a prova pergunte à um root server sobre o servidor de nomes(NS) da zona "in-addr.arpa":
nslookup -type=NS in-addr.arpa a.root-servers.net
Tendo agora os endereços dos servidores raiz da zona reversa("in-addr.arpa") podemos perguntar à eles sobre o autoritativo da zona "200.in-addr.arpa", e ao responsável desta zona qual é o autoritativo da zona "160.200.in-addr.arpa", e assim por diante até chegar no servidor reverso que contém a informação direta do host solicitado e seu endereço IP. Tudo depende de que os sistemas autônomos responsáveis por determinados blocos de endereços IP deleguem aos servidores DNS recursivos as zonas reversas adequadamente.
A tarefa de "amarrar" cada bloco de endereços IP aos usuários dele, e cada endereço à um host dentro da sua rede é bem cuidadosa e foge do escopo deste artigo. Não é necessário alongar muito mais por aqui. Primeiro porque os blocos de endereços IPv4 são extremamente fragmentados, o que pode causar confusão. Em segundo lugar, nem todos os endereços IP são mapeados com nomes DNS. Seria uma tarefa irracional e desnecessária, sem falar sobre os endereços IPv6 que são virtualmente infinitos. A zona reversa para IPv6 é a "ip6.arpa".
Abaixo apresento uma figura com 2 consultas DNS reversas sobre o host "a.dns.br":
Para consultas do tipo reversa você pode usar o parâmetro "-type=PTR" seguida do nome em zona reversa.
E ainda outra imagem com a consulta reversa para o IPv6 do mesmo host:

Caso não tenha ficado claro para você, apresento o esquema de forma enumerada usando o primeiro exemplo do endereço IP 192.0.2.55:
1) O DNS recursivo inverte o IP e adiciona o sufixo ".in-addr.arpa", tornando 192.0.2.55 em "55.2.0.192.in-addr.arpa".
2) O DNS recursivo solicita à um root server o registro reverso(PTR).
O root server envia o endereço do autoritativo de conta da zona do bloco classe A 192("192.in-addr.arpa"). Geralmente o DNS de um RIR(Registro Internet regional).
3) o DNS recursivo pergunta ao DNS do RIR pele registro reverso "55.2.0.192.in-addr.arpa". O servidor do RIR vai enviar os dados do autoritativo da organização que recebeu os sub-blocos. Geralmente o provedor de acesso ou conteúdo.
4) O DNS recursivo pergunta ao servidor do provedor pelo registro PTR de "55.2.0.192.in-addr.arpa".
O servidor do provedor vai finalmente informar o nome. Ou então, caso os IPs estiverem alocados para um cliente, informará os servidores DNS reversos deste cliente.
5) Finalmente o DNS recursivo pergunta ao servidor DNS da organização sobre o nome de "55.2.0.192.in-addr.arpa". Então o servidor da organização responsável pelo bloco de endereços IP responde com o nome adequado.

O Whois

Whois é um serviço complementar ao DNS que fornece informações de contato sobre domínios registrados na Internet. Ele trabalha similar ao DNS, mas na porta 43, e com uma hierarquia de servidores começando pela IANA. O serviço de whois serve para que saibamos quem, ou qual empresa, registou determinado domínio e quais as informações para entrarem em contato com eles, e ainda os servidores DNS autoritativos da zona. Você pode usar o serviço de whois via web em algum site que o ofereça, como no Registro.br, ou mesmo executando o comando whois no Linux. No Windows não há comando nativo, mas podemos usar o executável do Sysinternals Suite, disponível aqui:
Ele informa a empresa responsável pelo domínio e informações de contato como email do administrador, servidores DNS e até o CNPJ.
Muito se discute sobre a questão da privacidade, cada país de acordo com a sua zona(.BR por exemplo) tem políticas para as informações que devem ser disponibilizadas no serviço.

Comentários

Postagens mais visitadas deste blog

Script para configurar Proxy.

Entendendo as VLAN's