SPF Record Wizard

October 22nd, 2010 by Tiago Souza

Quero indicar a leitura de um post interessante do blog do nosso colega Vinícius Apolinário, segue o link:

http://www.admderedes.com.br/blog/post/Microsoft-Sender-ID-Framework-SPF-Record-Wizard.aspx

Isso é bem legal pois te ajuda a criar o registro SPF no seu servidor DNS.

Visitem.

[]s
Tiago Souza

Share

Post to Twitter

Four Reasons to Upgrade Your DNS Server to Windows Server 2008 R2

October 5th, 2010 by Tiago Souza

Four Reasons to Upgrade Your DNS Server to Windows Server 2008 R2

Four Reasons to Upgrade Your DNS Server to Windows Server 2008 R2

Share

Post to Twitter

Mais um artigo publicado no Linha de Código

October 9th, 2009 by Tiago Souza

Pessoal, o portal Linha de Código publicou mais um artigo meu, dessa vez sobre DNS Forwarders (Encaminhadores).

Vejam no seguinte link:

http://www.linhadecodigo.com.br/Artigo.aspx?id=2535

Obrigado pessoal do Linha de Código pelo espaço disponibilizado.


Tiago Souza

Share

Post to Twitter

Overview DNS

October 6th, 2009 by Tiago Souza

Pessoal, já citei esse link em parte de um artigo referente ao exame 70-291 e achei legal colocar aqui num post separado. Pra quem está precisando dar uma revisada em DNS, seja para esse exame ou não, esse link é muito interessante.

http://technet.microsoft.com/pt-br/library/bb727007%28en-us%29.aspx

Abraços.


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 8 – Migrar um servidor DNS primário

July 20th, 2009 by Tiago Souza

Uma dica rápida que relembrei agora lendo o training kit:

Para migrar um servidor primário, configure primeiro um servidor secundário, transfira a zona para esse servidor secundário e promova-o como primário em seguida.

Depois que o servidor secundário for promovido você pode excluir o o servidor primário original.


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 7 – Stub Zones x Conditional Forwarding

June 3rd, 2009 by Tiago Souza

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.


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 6 – Stub Zones

June 2nd, 2009 by Tiago Souza


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

 

Referências

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

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

BAIXE EM PDF

pdf.png


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 5 – Conditional Forwarding

May 26th, 2009 by Tiago Souza


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

BAIXE EM PDF

pdf.png


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 4 – Forwarders – Encaminhadores

May 25th, 2009 by Tiago Souza


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
BAIXE EM PDF:

pdf.png


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 3

May 22nd, 2009 by Tiago Souza


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 usar resolver, 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. O 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 de www.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

BAIXE EM PDF:
pdf.png

Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 2

February 19th, 2009 by Tiago Souza

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.


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Parte 1

February 18th, 2009 by Tiago Souza

Vamos iniciar a partir de um nível bem básico para que possamos desenvolver um raciocínio que lógico que seja subsequente ok?

O que é o DNS?

DNS é a sigla para Domain Name System (Sistema de nomes de domínio). Ele é também um serviço que faz a resolução de nomes, o que chamamos tecnicamente de “resolver nomes“, o que nada mais é que traduzir um nome para um endereço IP, ou vice-versa (no caso do DNS reverso que descobre qual o nome através do IP), é descobrir que o endereço http://www.portaltecnologia.net é um IP e aí sim criar uma conexão TCP/IP com o servidor que hospeda esse endereço. É importante também dizer que ele é um sistema hierárquico e distribuído, ou seja, há uma hierarquia que deve ser seguida para que ele funcione. Você tem um nome completo de host sendo computador.empresa.com, que é chamado de FQDN (Fully qualified domain name), e o endereço de seu site também como exemplo, obdecendo essa hierárquia. Falaremos mais adiante.

Abaixo você pode ver o exemplo da estrutura hierárquica de nomes. Logo vou explicar mais sobre.

dns_estrutura2.jpg

E o porque usamos o DNS?

É simples, porque ao invés de digitar o nome do site em nosso browser, teríamos que o fazer pelo número de endereço IP dele, agora imagine se lembrar de todos os números IPs para cada site, com o nome se torna muito mais fácil certo? Você também pode criar nome de hosts para os dispositivos e computadores de sua rede para que identifique-o mais facilmente.

No próximo capítulo da série vou explicar mais conceitos, como os domínios, a estrutura hierárquica da internet, nomes de host, nomes NetBIOS, etc.

Até a próxima.


Tiago Souza

Share

Post to Twitter

Série MCSA: DNS Introdução

February 18th, 2009 by Tiago Souza

Eu vou logo partindo do DNS, que é o assunto que mais vai cair no exame 70-291. Eu vou confessar que não sou um especialista em DNS, sei bem a teoria, tive isso como assunto na faculdade por muito tempo. Mas para explicar melhor o que eu quero dizer sobre isso eu separei um trecho do blog do amigo Vinicius, pois é muito interessante e resume bem o que eu quis dizer:

“Essa prova é considerada por muitos um bicho de sete cabeças. Isso por que trata de assuntos que as pessoas não estão acostumadas a mexer no dia-a-dia, como DNS. Eu considero esta prova difícil justamente por isso. DNS é algo que um administrador de rede precisa se preocupar, normalmente, na implementação. Depois disso, não se mexe muito com DNS a ponto de virar um expert no assunto. Na verdade, se formos fazer uma pesquisa, tenho quase certeza de que vamos concluir que muitos administradores de rede não sabem fazer nem configurações de zona DNS. Simplesmente configuram o Active Directory e deixam que este faça as configurações padrão. O amigo Gilson Banin, ontem no TechED, fez uma observação que é verdade. Existem vários casos onde encontramos configuração de DNS, nas máquinas cliente, com DNS do provedor. Ou seja, o cara que fez essa configuração, muito provavelmente nem sabe que o servidor DNS da rede interna que tem que resolver os nomes da internet.”

É bem isso mesmo, concordo com o que ele disse. Você também nunca espera um problema com o DNS, mas acho importante saber a fundo no que é baseado toda a internet e sua rede em domínio, como o serviço de mensageria da sua empresa utiliza desse serviço, o porque você executa um ipconfig /flushdns (para limpar o cache local) e a estação passa a acessar o site que até então não conseguia.

Pretendo abordar muitos conceitos, se alguém tiver dúvidas, dicas e críticas serão bem-vindas. Espero conseguir criar uma boa base para pesquisa sobre DNS que ajude outros membros no estudo do exame 70-291.

Abraços, até o próximo da série.


Tiago Souza

Share

Post to Twitter