DNS

O básico de resolução de nomes

Resolução de nomes

Temos 2 tipos de nomes para resolver na rede TCP/IP, host name e NetBIOS, vamos falar um pouco deles.

Nomes de host: Para você saber o que representa o nome de host, perceba o nome FQDN de um computador da rede, “computador.empresa.com”, podemos dizer que o nome de host é o nome mais a esquerda do nome, nesse caso “computador”. Ele é usado pra identificar um host, representar o dispositivo na internet ou na intranet. Ele é usado como alias para identificar um dispositvo que tem um IP. Ele pode conter até 255 caracteres.

Nomes NetBIOS: São nomes exclusivos para um dispositivo ou computador e não faz parte de uma estrutura hierárquica. Eles identificam um recurso único na rede e você pode usá-los para acessá-los remotamente, via caminho UNC (\\computador). São usados somente na intranet. É aconselhável que você use o mesmo nome de hostname no nome NetBIOS. Ele é um endereço de 16 bytes.

No próximo capítulo vou explicar como ocorre o processo de resolução de um nome DNS.

[]s
Tiago Ferreira de Souza

Share

Post to Twitter

DNS: Tipos de consulta

Tipos de consulta DNS

Introdução

Vamos ver as formas básicas de pesquisa DNS, quando um cliente deseja acessar algum recurso ou servidor através de seu nome, e se um cliente deseja acessar um endereço externo, como por exemplo: www.portaltecnologia.net. Como o servidor da continuidade nessa busca para entregar o resultado para o cliente.

Consulta básica DNS

A figura abaixo ilustra uma pesquisa básica de um computador na sua rede que solicita acesso a um recurso do servidor através do seu nome. Vamos supor que você está usando um programa interno que consulta os recursos através do nome do servidor.

simplequery.jpg

O cliente pergunta para o servidor DNS configurado em seu protocolo TCP/IP,“Qual o endereço IP de servidor.portaltecnologia.local?”, o servidor retorna o número correspondente e assim a conexão é criada.

Nessa etapa de pergunta o cliente também envia algumas informações, sendo:

  • Um nome de domínio DNS específico, declarado como nome de domínio totalmente qualificado (FQDN)
  • Um tipo de consulta específica, que pode especificar um tipo de registro de recurso ou um tipo especializado de operação de consulta.
  • Uma classe específica para o nome de domínio DNS. Para servidores DNS do Windows, isso deve ser especificado como a classe Internet (IN).

O cliente faz essa consulta através do serviço DNS client chamado de “resolver”, ou resolvedor se preferirem. Sempre que me referir ao cliente DNS vou usarresolver, que é como está na documentação do produto.

No exemplo acima, o servidor precisa procurar um registro (RR – Resource Record), em seu banco de dados conhecido como Host (A), que mapeia nome nome para endereço IP. O cliente pergunta algo como: “Você tem um recurso (A) para o nome servidor.portaltecnologia.net?”. O cliente, recebendo a resposta, recebe o endereço IP do computador solicitado através do nome.

Resolvedor Local

O processo de consulta de nomes se dá em duas partes, vamos começar falando do resolvedor local, o cliente DNS originando a consulta.

O resolvedor (cliente DNS) deseja procurar por um endereço externo, vamos supor http://www.portaltecnologia.net. Ele vai seguir alguns passos agora, vamos a eles:

  • Consulta seu cache de resolvedor local: Primeiro ele consulta o seu cache para saber se esse nome já havia sido resolvido anteriormente. Sempre que um nome é resolvido ele é gravado localmente em um cache, o que otimiza a consulta no caso de precisarmos usá-la novamente, tornando-a mais rápida.
  • Arquivo Hosts: Vamos supor que não há nada gravado no cachê local, o que ele faz agora? Ele passa a consultar o arquivo hosts. Esse é um arquivo de texto encontrado no seguinte local: C:\WINDOWS\system32\drivers\etc (caso o C:\ seja a unidade que o Windows foi instalado).

Quando o resolvedor não consegue resolver o nome nessas etapas ele passa a consulta para o servidor DNS, configurado no protocolo TCP/IP na interface de rede. Esse processo é conhecido como “Recursive Query” (pesquisa recursiva). Servidores DNS fazem pesquisas “recursiva” e “interativa” (Recursive e Iterative Query). Na recursiva o cliente só vai aceitar a resposta completa, seja ela positiva ou negativa, mas nenhum apontamento ou referência.

Ilustração do processo de pesquisa DNS:

recursivequery.gif

Q = Question – Pergunta
A = Answer – Resposta

 

Processo de Recursão:

iterativequery.gif

Servidor DNS – Recursive e Iterative Query

Quando a pesquisa chega ao servidor ele executa alguns passos, vamos enumerá-los pra tentar tornar o processo mais claro.

  1. Vamos iniciar da parte que o cliente faz a consulta recursiva para o endereço www.portaltecnologia.net para o servidor DNS local configurado em sua interface de rede. Ele abre o browser e digita o endereço.
  2. servidor DNS recebe a consulta e enumera as zonas que ele tem autoridade no domínio (as que foram criadas nesse servidor como primárias). Se ele for autoridade ele já responde nessa etapa com uma resposta autoritativa. Ele será autoridade quando estamos, por exemplo, pesquisando o nome “servidor.portaltecnologia.local” e esse servidor DNS tem a zona “portaltecnologia.local” criada.
  3. Vamos continuar supondo que ele não é autoridade para esse domínio. Ele vai pesquisar agora no seu cache de servidor. A medida que o servidor vai resolvendo nomes ele armazena os resultados em um cache, semelhante ao cliente (resolver). Se houver o registro no cache a resposta é dada nessa parte, vamos supor que não há ainda a resposta, para dar seguimento a pesquisa.
  4. Como ele não encontrou o resultado, o servidor DNS vai tentar outras maneiras de pesquisa para resolver o nome para o cliente, fazendo uso do processo conhecido como Recursão (Recursion). Onde ele aciona outros servidores DNS para auxiliá-lo nessa pesquisa. (nesse artigo não vamos citar os encaminhadores – Forwarders, fica para o próximo).
  5. Nesse momento ele utiliza uma lista de servidores chamada de Root Hints(Dicas de Raiz) para fazer pesquisas Iterativas, onde agora, nesse tipo de pesquisa ele aceita referências, partes da resposta, ao contrário da pesquisa recursiva que só aceita a resposta completa sem apontamentos. Os Root Hints contém uma lista de resource records usados pelo DNS server para contatar os servidores autoritativos para o domínio root na internet, sendo que o internet root name server responde nesse momento apontando para o servidor autoritativo abaixo dele no namespace, sendo no caso o .net, que é um top-level domain.
  6. Quando o servidor DNS autoritativo responsável pelo .net recebe essa pesquisa Iterativa ele responde com o número IP apontando para o servidor que ele conhece, responsável pelo domínio“portaltecnologia.net”.
  7. Agora o servidor DNS envia outra consulta iterativa para o DNS server responsável por “portaltecnologia.net”, onde este responde com o endreço IP do host “www.portaltecnologia.net”.
  8. Agora o servidor DNS local retorna para o cliente o endereço IP dewww.portaltecnologia.net, e o usuário consegue abrir uma conexão e visualizar a página.

Nesse caso, a reposta para o cliente foi positiva, mas poderiam haver outras, no caso de não conseguir resolver o endereço, seriam elas:

  • Authoritative Answer (Resposta autoritativa) – Quando é resolvido pelo servidor DNS que é autoridade pelo domínio consultado, como exemplo citado acima onde o usuário está tentando acessar o “servidor.portaltaltecnologia.local” através do servidor que hospeda a zona “portaltecnologia.local”.
  • Positive Answer (Resposta Positiva) – Contém a resposta correta para um nome pesquisado.
  • Referral Answer (Resposta com Referência) – Não contém a resposta, mas sim uma referência de onde a resposta pode ser pesquisada. Ela será retornada para o cliente se o servidor DNS local não estiver com a recursão habilitada. Nesse caso o cliente faz a pesquisa nos servidores que estão sendo passados pra ele como referência.
  • Negative Answer (Resposta Negativa) – Aqui encontra-se duas possibilidades para uma resposta desse tipo. Primeira, o servidor reportou que o nome pesquisado não existe no Namspace. Segunda, o nome pesquisado até existe, mas o registro está incorreto.

dnsqueries.gif

Dicas

  • Recursão é o processo que o DNS server contata outros DNS Servers que possam auxiliar na resolução de um nome pesquisado
  • O arquivo pré-configurado de Root Hints encontra-se em Windows\System32\Dns, e está nomeado como Cache.dns
  • Quando você adiciona uma entrada manual no arquivo hosts, ela é automaticamente carregada no cachê do resolvedor local
  • O cachê é o processo que guarda os nomes pesquisados para tornar uma consulta futura mais rápida
  • Ipconfig /flushdns – Limpa o cachê DNS
  • Não se esqueça que antes do resolver consultar o servidor DNS ele consulta o cachê local e o arquivo hosts

Referências

http://technet.microsoft.com/pt-br/library/bb727007(en-us).aspx

http://technet.microsoft.com/en-us/library/dd197427(WS.10).aspx

http://technet.microsoft.com/pt-br/library/cc775637(WS.10).aspx

http://www.microsoft.com/learning/en/us/Books/5433.aspx

[]s
Tiago Ferreira de Souza

Share

Post to Twitter

Forwarders – Encaminhadores

Forwarders – Encaminhadores

Introdução

No último artigo explicamos o processo de resolução de nomes de acordo com os tipos de pesquisas como recursive e iterative. Agora vamos entrar no processo de forwarders (encaminhadores).

Forwarder

A figura abaixo ilustra o processo de encaminhamento de pesquisa.

forwarder2.gif

O servidor DNS configurado como Forwarder recebe as consultas externas encaminhadas dos servidores DNS internos e faz a pesquisa na internet ao invés dos próprios servidores que originaram a pesquisa.

O que significa que os DNS servers que encaminham a consulta não utilizam os Root Hints nem a internet em um primeiro momento, esse trabalho fica somente para o Forwarder que devolve o resultado para os servidores solicitantes.

Perceba na ilustração que você não expõe os servidores internos na internet para resolver nomes externos, eles continuam resolvendo os nomes locais do domínio. O Forwarder criará também um grande cache de informações de consultas externas, que agiliza as consultas futuras, o que pode ainda reduzir o trafego na internet para resolução de nomes depois que já foram resolvidos uma vez.

Quando aqueles 2 servidores DNS internos estão configurados para encaminhar resoluções externas e recebem uma solicitação de resolução eles trabalham da seguinte maneira:

1.       O cliente envia uma consulta para resolução de “www.portaltecnologia.net” para os servidores configurados na sua interface, que no caso são os dois do exemplo acima na intranet.

O servidor da início na consulta pesquisando suas zonas e seu cache e percebe que não é autoridade para o domínio.

2.       Ele consulta então a aba Forwarders e encontra um servidor DNS encaminhador e envia uma consulta recursiva para ele (aquela que só aceita a resposta completa e não referência do resultado)

3.       Os servidores aguardam a resposta do Forwarder antes que consultem os Root Hints e façam consultas interativas eles mesmos

Sobre o uso de Encaminhadores – Forwarders

  • São indicados quando se há link WAN de baixa velocidade na resolução de nomes
  • Pode ser usado um servidor DNS da internet como Forwarder, exemplo o do seu ISP
  • Útil porque cria um grande cache de nomes externos que pode ser usado para consultas futuras
  • Aumenta a segurança, pois os servidores expostos, com as portas DNS abertas, serão somente os encaminhadores, que não contém informações das zonas locais
  • Podem ser usados na borda entre um firewall e sua rede interna

forwarder_firewall.jpg

Forwarders em modo Exclusivo

Você pode “forçar” para que seus servidores DNS internos usem apenas encaminhadores, fazendo com que eles não consultem os root hints ou qualquer outro servidor.

Para isso basta usar a opção: “Do not use recursion for this domain” (Não usar recursão para este domínio).

donotuserecursion.JPG

Nesse caso se o servidor configurado como Forwarder não conseguir resvolver uma consulta ele retornará um erro.

Então a consulta ficaria assim:

  1. Cliente consulta nome externo nos DNS servers configurados no protocolo TCP/IP
  2. Servidores consultam cache e zonas
  3. Uma consulta recursiva é enviada para o Forwarder

Forwarders em modo Não-Exclusivo

Nesse modo quando  um servidor envia uma consulta para um servidor DNS configurado como Forwarder e este não consegue resolver a consulta, os próprios servidores utilizam de consulta interativa, que comentamos no artigo anterior, exemplo: root hints, para resolver um nome.

Então a consulta nesse caso ficaria assim:

  1. Cliente consulta nome externo nos DNS servers configurados no protocolo TCP/IP
  2. Servidores consultam cache e zonas
  3. Uma consulta recursiva é enviada para o Forwarder
  4. Não resolvendo os servidores que encaminharam a consulta agora fazem consultas interativas para tentar resolver o nome

Referências

http://technet.microsoft.com/pt-br/library/bb727007(en-us).aspx

[]s
Tiago Ferreira de Souza

Share

Post to Twitter

Conditional Forwarding

Conditional Forwarding – Encaminhadores Condicionais

Introdução

No último artigo explicamos o processo de encaminhamento para resolução de nomes, os servidores configurados como Forwarder. Agora vamos falar sobre outro tipo de encaminhadores, Conditional Forwarding, ou como alguns conhecem em português, encaminhadores condicionais.

Conditional Forwarding

O processo é parecido com o de encaminhamento, mas nesse caso você deve configurar não somente o endereço IP do encaminhador, mas deve associar o nome do domínio DNS que é autoridade para a zona juntamente com o endereço IP. O exemplo abaixo mostra como funciona o processo de encaminhadores padrão, vamos analisar primeiro para ver a diferença.

Processo de Forwarder:

forward.JPG

Processo de Conditional Forwarder:

cforward.JPG

Percebam que o nome de domínio DNS está associado ao endereço IP.

Esse processo é comumente usado em casos de fusão de empresas que estão separadas fisicamente, parceiros de negócios, onde uma precisa consultar os registros na intranet da outra e vice versa. Nesse caso é só configurar o serviço de conditional forwarding em cada uma das empresas parceiras. Seu servidor DNS que está configurado para fazer conditional forwarding para seu parceiro não utiliza recursão, o processo para antes de chegar aos root hints, o que agiliza a resolução.

Você elimina a necessidade de se ter zonas secundárias. As Stub Zones também tem um efeito semelhante, mas explico no próximo artigo.

Como configurar

Para configurar o servidor como conditional forwarding precisamos obter o nome do domínio e o endereço IP do servidor DNS de destino.

Vamos usar como exemplo o domínio “portaltecnologia” novamente. Precisamos descobrir o nome do servidor autoritativo para esse domínio e associar o endereço IP na guia Forwarders do console DNS.

1 – Vamos abrir o console DNS (dnsmgmt.msc)

2 – Vamos pedir propriedades de servidor

3 – Vamos até a aba Forwarders

cforwad1.JPG

4 – Vamos clicar em New e nessa parte vamos adicionar o nome do domínio

cforwad2.JPG

5 – Com o nome do domínio selecionado vamos associar o endereço IP

cforwad3.JPG

6 – Pronto, a condição está criada, agora vamos ver como o servidor entende que deve processar essa solicitação

Ordem de resolução

Vou tentar enumerar o processo de resolução através do processo de contional forwarding para ficar mais claro.

1 – Você digita algum nome para ser resolvido na zona da empresa parceira

2 – O resolver não encontra informações para resolver e a consulta é transferida para o servidor. O servidor percebe que não tem a informação na sua base, somente os nomes de sua organização

3 – Então ele checa na aba forwarders para encontrar algum forwarder configurado

4 – É encontrado um nome de domínio com um endereço IP associado para o servidor autoritativo para esse nome

5 – A consulta é então encaminhada para esse servidor que responde com autoridade e devolve a resolução para o seu servidor

6 – O servidor responde para o cliente que então pode acessar o recurso, com mais rapidez que se utilizasse o processo de recursão

Conclusão

  • Usamos em casos de fusões de empresas que se tornam parceiras e estão separadas fisicamente, onde os usuários necessitam resolver nomes na intranet do outro local e vice versa
  • Agiliza o processo nesse caso, pois o servidor que tem um conditional forwarding configurado não faz uso da recursão, pois já conheçe qual o servidor autoritativo para o nome de destino, isso funciona como um atalho nesse caso

 

Referências

http://technet.microsoft.com/pt-br/library/cc757172(WS.10).aspx

http://www.windowsnetworking.com/articles_tutorials/DNS_Conditional_Forwarding_in_Windows_Server_2003.html

[]s
Tiago Ferreira de Souza

Share

Post to Twitter

Stub Zones

Introdução

Vamos dar continuidade a série sobre a certificação 70-291 e o assunto DNS. Já falamos de Forwarders, Conditional Forwarding e agora seguindo a lógica vamos pra Stub Zones.

Stub Zones

É uma cópia de uma zona, mas não como um servidor secundário, ele só copia os registros necessários para identificar um servidor DNS autoritativo, como:

  • Cópia do registro SOA – Start of Authority
  • Cópia do registro NS – Name Servers
  • Cópia de registros A dos name servers autoritativos

Quando usamos uma zona stub e um resolver (cliente DNS) da nossa rede faz uma consulta para um registro que está armazenado nessa zona, nosso servidor DNS envia uma consulta iterativa para os servidores DNS autotirativos contidos na zona stub, e ele vai utilizá-lo como se estivesse utilizando seu próprio cache. Caso não seja encontrado registro a pesquisa então será feita usando os root hints. Portanto essa zona stub não resolve o nome e sim encaminha para um servidor autoridade que pode resolver.

Esses registros da zona stub são armazenados em cache de acordo com o TTL(time to live) de cada registro e expiram de acordo com o SOA da zona stub. Esses dados são atualizados pois o processo que ocorre aqui é a transferência de zona, como se fosse um servidor que hospedasse uma zona secundária, o processo é bem semalhante, com a diferença que citamos acima, os registros transferidos são somente os essenciais (SOA, NS e A).

A stub zone é read only como a secondary, então não podemos modificar os registros, eles são só modificados na zona primária.

Como criar zonas de Stub

Vou demonstrar como criar uma zona stub. Vou usar o site do technet para abrir um virtual lab só para pegar as telas, não vou conseguir mostrar a zona criada por completo.

  1. Abra o console DNS – start > run > dnsmgmt.msc
  2. Botão direito no servidor DNS e vamos clicar em “New Zone

stub1.JPG

  1. No Wizar vamos clicar em NEXT e vamos escolher a opção de Stub Zone, gravada no Active Directory (se o servidor for domain controller)

stub2.JPG

  1. Vamos manter o padrão de replicação “To all domain controllers in the Active Directory domain nome do domínio

stub3.JPG

  1. Vamos colocar o nome do domínio alvo, no nosso exemplo, parceiro.dominio.local

stub4.JPG

  1. Vamos entrar com o endereço IP desse parceiro

stub5.JPG

  1. Pronto a zona stube foi criada com sucesso

stub6.JPG

Como funcionam os Updates na Stub Zone

Depois da implementação da stub zone, quando ele carrega os registros necessários você pode ter updates de algumas formas. De acordo com a transferência de zona configurada ou você pode atualizar das seguintes maneiras:

  • Reload - Faz um recarregamento da zona do DNS local
  • Transfer from Master – O DNS Server que hospeda a stub zone determina se o serial number do SOA expirou e faz uma transferência do master server
  • Reload from Master – Recarrega da master, indepentende do serial number do SOA

Conclusão

  • São cópias read only dos registros SOA, NS e A dos NS do servidor autoridade do domínio de destino (master)
  • A stub zone é fácil de criar e pode tornar a resolução de nomes entre florestas mais eficiente e simplifica o gerenciamento
  • Inclusão dinâmica de registros através da transferência de zona, o que é uma vantagem em relação ao conditional forwarding, que se houver mudança no servidor master não teríamos como saber, seria manual
  • Será preciso acesso administrativo ou contato com o administrador do servidor master para configuração da transferência de zona
  • Não consulta Root Hints pois já contém os registros da zona de destino, ele a uitliza como se fosse um cache, só os consulta se a consulta ao servidor configurado na stub zone falhar
[]s
Tiago Ferreira de Souza
Share

Post to Twitter

Stub Zones x Conditional Forwarding

Uma rápida explicação sobre a diferença de Stub Zone e Conditional Forwarding.

Stub Zone – Faz uma cópia da zona primária, mas somente dos registros necessários (SOA, NS e A de NS) para identificar o servidor DNS autoritativo dessa zona. É atualizado dinâmicamente através da transferência de zonas. Bem como no processo de Conditional Forwarding é usada para facilitar a pesquisa de nomes em namespaces distintos, onde os servidores locais não são autoritativos e em casos de fusões de empresas e parceiros de negócios com outros namespaces. Zona Stub não resolve nome, apenas sabe pra quem encaminhar consultando os registros.

Conditional Forwarding – É um Forwarder (encaminhador) tendo além do nome de domínio configurado um endereço IP como condição para encaminhar pesquisas diretamente para o servidor autoridade para o nome pesquisado. Precisa ser configurado manualmente, onde você deve conhecer o nome de domínio bem como IP do servidor DNS autoridade. Também usado para resolver nomes em casos de fusões e parceiros de negócios, tornando esse processo mais ágil, pois não utiliza os root hints a princípio.

Há uma vantagem do uso da zona stub com relação ao processo de conditional forwarding, pois depois de configurado (fácil de configurar) o processo de atualização é dinâmica, se houver alteração na zona primária ela será refletida para zona stub. No caso do conditional forwarding você deve alterar manualmente os dados no servidor, o que exige trabalho administrativo. Porém como a stub zone utiliza a transferência de zonas, se isso estiver sendo feito através da Internet poderá demandar mais link WAN.

Basicamente é isso, no próximo artigo pretendo explicar o processo de atualização dinâmica.

[]s
Tiago Ferreira de Souza

Share

Post to Twitter