Introdução Cluster

Quando o assunto é computação de alto desempenho, não é difícil pensarmos em servidores sofisticados e caros respondendo por este trabalho. No entanto, é possível obter resultados tão bons quanto ou superiores a partir de alguma solução de cluster - uma tecnologia capaz de fazer computadores mais simples trabalharem em conjunto, como se formassem uma máquina só.
Neste texto, você saberá o que é computação em cluster, verá quais são as principais características do conceito e
conhecerá algumas de suas aplicações, assim como soluções do tipo.

O que é cluster?
Cluster (ou clustering) é, em poucas palavras, o nome dado a um sistema que relaciona dois ou mais computadores para
que estes trabalhem de maneira conjunta no intuito de processar uma tarefa. Estas máquinas dividem entre
si as atividades de processamento e executam este trabalho de maneira simultânea.
Cada computador que faz parte do cluster recebe o nome de nó (ou node). Teoricamente, não há limite máximo de nós,
mas independentemente da quantidade de máquinas que o compõe, o cluster deve ser "transparente", ou seja, ser visto pelo usuário ou por outro sistema que necessita deste processamento como um único computador.
Os nós do cluster devem ser interconectados, preferencialmente, por uma tecnologia de rede conhecida, para fins de
manutenção e controle de custos, como a Ethernet. É extremamente importante que o padrão adotado permita a
inclusão ou a retirada de nós com o cluster em funcionamento, do contrário, o trabalho de remoção e substituição
de um computador que apresenta problemas, por exemplo, faria a aplicação como um todo parar.
A computação em cluster se mostra muitas vezes como uma solução viável porque os nós podem até mesmo ser compostos por computadores simples, como PCs de desempenho mediano. Juntos, eles configuram um sistema de processamento com capacidade suficiente para dar conta de determinadas aplicações que, se fossem atendidas por supercomputadores ou servidores sofisticados, exigiriam investimentos muito maiores.
Não é necessário haver um conjunto de hardware exatamente igual em cada nó. Por outro lado, é importante que todas as máquinas utilizem o mesmo sistema operacional, de forma a garantir que o software que controla o cluster consiga gerenciar todos os computadores que o integram.

Tipos de clusters
Há uma enormidade de aplicações que só podem ser atendidas satisfatoriamente com computação de alto desempenho:
sistemas meteorológicos, ferramentas de mapeamento genético, simuladores geotérmicos, programas de renderização de imagens tridimencionais, entre tantos outros. Com o advento da computação em nuvens, este cenário se torna ainda mais amplo: pode-se ter uma infraestrutura tecnológica respondendo a vários clientes simultaneamente de maneira remota, por exemplo.
Em todos estes casos e em qualquer outro tipo de aplicação crítica - que não pode parar de funcionar ou não pode
perder dados (os sistemas bancários, por exemplo) -, o cluster pode se mostrar como uma solução viável, desde
que o tipo mais adequado seja escolhido.
Há vários tipos de cluster, mas os principais são:
cluster de alto desempenho
cluster de ata disponibilidade
cluster de balanceamento de carga.
Cluster de Alto Desempenho (High Performance Computing Cluster)
Clusters de alto desempenho: são direcionados a aplicações bastante exigentes no que diz respeito ao processamento. Sistemas utilizados em pesquisas científicas, por exemplo, podem se beneficiar deste tipo de cluster por necessitarem analisar uma grande variedade de dados rapidamente e realizar cálculos bastante complexos.
O foco deste tipo é o de permitir que o processamento direcionado à aplicação forneça resultados satisfatórios em tempo hábil, mesmo que haja centenas de milhares de gigaflops envolvidos com a tarefa (1 gigaflop corresponde a 1 bilhão de instruções de ponto flutuante executadas por segundo).
Cluster de Alta Disponibilidade: (High Availability Computing Cluster)
Nos clusters de alta disponibilidade, o foco está em sempre manter a aplicação em pleno funcionamento: não é aceitável que o sistema pare de funcionar, mas se isso acontecer, a paralização deve ser a menor possível, como é o caso de soluções de missão crítica que exigem disponibilidade de, pelo menos, 99,999% do tempo a cada ano, por exemplo.
Para atender a esta exigência, os clusters de alta disponibilidade podem contar com diversos recursos: ferramentas de monitoramento que identificam nós defeituosos ou falhas na conexão, replicação (redundância) de sistemas e computadores para substituição imediata de máquinas com problemas, uso de geradores para garantir o funcionamento em caso de queda de energia, entre outros.
Em determinadas circunstâncias, é tolerável que o sistema apresente algum grau de perda de desempenho, especialmente quando esta situação é consequência de algum esforço para manter a aplicação em atividade.
Cluster para Balanceamento de Carga (Load Balancing)
Em clusters de balanceamento de carga, as tarefas de processamento são distribuídas o mais uniformemente possível entre os nós. O foco aqui é fazer com que cada computador receba e atenda a uma requisição e não, necessariamente, que divida uma tarefa com outras máquinas.
Imagine, por exemplo, que um grande site na internet receba por volta de mil visitas por segundo e que um cluster formado por 20 nós tenha sido desenvolvido para atender a esta demanda. Como se trata de uma solução de balanceamento de carga, estas requisições são distribuídas igualmente entre as 20 máquinas, de forma que cada uma receba e realize, em média, 50 atendimentos a cada segundo.
Não basta ao cluster de balanceamento de carga ter um mecanismo meramente capaz de distribuir as requisições - é necessário que este procedimento seja executado de forma a garantir um "equilíbrio" na aplicação. Para tanto, o mecanismo pode monitorar os nós constantemente para verificar, por exemplo, qual máquina está lidando com a menor quantidade de tarefas e direcionar uma nova requisição para esta.
O balanceamento de carga pode ser utilizado em vários tipos de aplicações, mas o seu uso é bastante comum na internet, já que soluções do tipo têm maior tolerância ao aumento instantâneo do número de requisições, justamente por causa do equilíbrio oriundo da distribuição de tarefas.
Combinação de tipos de clusters
É válido frisar que uma solução de cluster não precisa se "prender" a apenas um tipo. Conforme a necessidade, pode-se combinar características de tipos diferentes no intuito de atender plenamente à aplicação.
Por exemplo, uma loja na internet pode utilizar um cluster de alta disponibilidade para garantir que suas vendas possam ser realizadas 24 horas por dia e, ao mesmo tempo, aplicar balanceamento de carga para suportar um expressivo aumento eventual no número de pedidos causados por uma promoção.

Funcionamento básico dos clusters
Para que um cluster seja constituído, é necessário fazer uso de alguns elementos básicos. O primeiro deles você já conhece: os equipamentos a serem utilizados como nós.
Para isso, pode-se usar máquinas construídas especificamente para funcionar como nós. Neste caso, os computadores teriam apenas dispositivos de hardware imprescindíveis ao cluster.
Cluster avançado construído com equipamentos específicos
Mas, também é possível utilizar computadores "convencionais", como desktops para fins domésticos ou para uso em escritório. Assim, uma universidade ou uma empresa, por exemplo, pode utilizar máquinas que foram substituídas por modelos mais recentes para criar um cluster e, eventualmente, economizar com a aquisição de servidores.
Os nós podem ainda ser não dedicados ou dedicados. No primeiro caso, cada computador que faz parte do cluster não trabalha exclusivamente nele. No segundo, o nó é utilizado somente para este fim, fazendo com que dispositivos como teclados e monitores sejam dispensáveis - se, por algum motivo, for necessário acessar uma máquina em particular, pode-se fazê-lo via terminal, a partir do nó principal, por exemplo.
Outro elemento importante é o sistema operacional. Como já informado, os nós não precisam ser exatamente iguais no que diz respeito ao hardware, mas é essencial que todas os computadores utilizem o mesmo sistema operacional.
Esta homogeneidade é importante para diminuir a complexidade de configuração e manutenção do sistema, e garantir que os procedimentos rotineiros ao cluster, como monitorização, distribuição de tarefas e controle de recursos sejam executados de maneira uniforme. Para reforçar estes aspectos, pode-se até mesmo adotar sistemas operacionais preparados especialmente para clustering.
Do ponto de vista do software, o cluster conta ainda com o elemento que faz o papel de middleware: trata-se de um sistema que permite o controle do cluster em si e, portanto, está intimamente ligado ao sistema operacional. É o middleware que lida, por exemplo, com as bibliotecas que fazem toda a comunicação do cluster - uma delas é o padrão MPI (Message Passing Interface).
Além de trabalhar com o gerenciamento do cluster, o middleware oferece uma interface para que um administrador possa configurar o cluster, ferramentas para manutenção e otimização, recursos de monitoramento e assim por diante.
Por padrão, o middleware é instalado em uma máquina chamada de nó controlador (ou nó mestre). O nome deixa claro: trata-se do já mencionado nó principal, que efetivamente controla o cluster a partir da distribuição de tarefas, do monitoramento e de procedimentos relacionados.
A comunicação entre os nós - que é onde está a delimitação do que constitui o cluster em si - é feita a partir de uma tecnologia de rede local. Os padrões Ethernet (Gigabit Ethernet, Fast Ethernet, etc) são bastante utilizados justamente por serem mais comuns e, portanto, melhor suportados e menos custosos. Mas há outras opções viáveis, entre elas, o Myrinet e o InfiniBand, ambos com características bastante apropriadas para clustering.
Cluster Beowulf
O Beowulf não é, necessariamente, um middleware, como muitas pensam. Na verdade, este nome faz referência a um padrão de clustering disponibilizado pela NASA (National Aeronautics and Space ) em 1994 e amplamente adotado desde então.
Originalmente, Beowulf é o nome de um poema extenso e bastante antigo, cujo manuscrito foi encontrado no século XI. A obra descreve os atos de um herói de mesmo nome que se destaca por sua força descomunal e que, portanto, enfrenta um perigoso monstro para salvar um reino. A história serviu de inspiração para que os pesquisadores Thomas Sterling e Donald Becker, da NASA, batizassem o projeto de cluster no qual trabalhavam de Beowulf.
Um cluster Beowulf se define, basicamente, pela ênfase nas seguintes características:

- entre os nós, deve haver pelo menos um que atue como mestre para exercer o controle dos demais. As máquinas mestres
são chamadas de front-end; as demais, de back-end. Há a possibilidade de existir mais de um nó no front-end para que cada um realize tarefas específicas, como monitoramento, por exemplo;
Esquema básico de um cluster Beowulf
- a comunicação entre os nós pode ser feita por redes do tipo Ethernet, mais comuns e mais baratas, como você já sabe;
- não é necessário o uso de hardware exigente, nem específico. A ideia é a de se aproveitar componentes que possam ser encontrados facilmente. Até mesmo PCs considerados obsoletos podem ser utilizá-los;
- o sistema operacional deve ser de código aberto, razão pela qual o Linux e outras variações do Unix são bastante utilizados em cluster Beowulf. O MOSIX, a ser abordado no próximo tópico, é uma opção bastante usada para este fim;
- os nós devem se dedicar exclusivamente ao cluster;
- deve-se fazer uso de uma biblioteca de comunicação apropriada, como a PVM (Parallel Virtual Machine) ou a MPI (Message Passing Interface). Ambas são direcionadas à troca de mensagens entre os nós, mas o MPI pode ser considerado mais avançado que o PVM, uma vez que consegue trabalhar com comunicação para todos os computadores ou para apenas um determinado grupo.
Perceba que, com estas características, pode-se construir um cluster "poderoso" e, ao mesmo tempo, poupar gastos com equipamentos, licenças de software e manutenção. O cluster montado por Thomas Sterling e Donald Becker para a NASA, por exemplo, era composto por 16 PCs com processador Intel 486 DX4 e sistema operacional Linux conectados por uma rede Ethernet de 10 Mb/s. Como se vê, esta foi uma solução consideravelmente mais barata e, possivelmente, menos complexa que um supercomputador.
É possível saber mais sobre o Beowulf em www.beowulf.org.
Algumas soluções de clusters
Há uma quantidade razoável de soluções para clusters, mas algumas se sobressaem, especialmente aquelas que se relacionam com Linux e outros sistemas baseados em Unix. Vejamos rapidamente opções do tipo que se destacam bastante.
MOSIX
O MOSIX (Multicomputer Operating System for Unix) é uma das opções mais tradicionais quando o assunto é clustering.
Trata-se, resumidamente, de um conjunto de softwares que permite a implementação de clusters em sistemas baseados no Unix, tendo forte ênfase em balanceamento de carga e alto desempenho.
Entre as suas principais características estão: possibilidade de trabalhar com nós dedicados e não dedicados; suporte não apenas a CPUs, mas também a GPUs (a partir da versão 2); migração dinâmica de processos (um nó mais potente pode assumir determinada tarefa para evitar sobrecarga em outro); e possibilidade de remoção e inclusão de nós sem interromper o cluster.
Como o MOSIX também trabalha com nós não dedicados, é possível inclusive fazer com que as máquinas de um escritório passem a trabalhar no cluster após o horário do expediente, por exemplo. Mas, mesmo se houver usuários utilizando os nós, é possível manter o cluster em funcionamento, já que as atividades do MOSIX são totalmente "transparentes", ou seja, seu trabalho no computador não é perceptível.
O MOSIX não é uma solução gratuita. Houve uma versão sua de código aberto chamada OpenMosix que, infelizmente, foi descontinuada em março de 2008.
OpenSSI
O OpenSSI é uma solução aberta para clusters focada em ambientes Linux. O nome tem como base o conceito de
SSI (Single System Image), ou seja, um sistema que considera vários nós, mas se parece, no ponto de vista do usuário, apenas como um único computador.
A "visão" de apenas uma única máquina também é válida para os softwares: este não precisam ser alterados para
"enxergar" cada nó e assim rodar no cluster, facilitando a implementação da solução.
O OpenSSI pode lidar tanto com alto desempenho quanto com alta disponibilidade, além de possuir recursos para balanceamento de carga.

Kerrighed
O Kerrighed é outra opção SSI aberta para clusters que tem como base o Linux. Esta solução se destaca principalmente por fazer uso do conceito de Distributed Shared Memory (DSM) - algo como "Memória Compartilhada
Distribuída" -, onde a memória de cada nó se "soma" a dos demais, como se formassem um volume único à disposição de todo o cluster.
Esta abordagem oferece vários benefícios: parte da memória pode ser disponibilizada para todos os clientes da aplicação; sistemas desenvolvidos para rodar de maneira centralizada podem ser executados de maneira distribuída dentro da solução; o cluster pode se comportar como se fosse uma máquina com múltiplos processadores; entre outros.
Vantagens e desvantagens dos clusters
Neste ponto do texto, você certamente já compreendeu as vantagens de um cluster. Eis as principais:
- pode-se obter resultados tão bons quanto ou até superiores que um servidor sofisticado a partir de máquinas mais simples e mais baratas (ótima relação custo-benefício);
- não é necessário depender de um único fornecedor ou prestador de serviço para reposição de componentes;
Switch Ethernet: tecnologias amplamente disponíveis é comum em clusters
- a configuração de um cluster não costuma ser trivial, mas fazer um supercomputador funcionar poder ser muito mais trabalhoso e exigir pessoal especializado;
- é possível aumentar a capacidade de um cluster com a adição de nós ou remover máquinas para reparos sem interromper a aplicação;
- há opções de softwares para cluster disponíveis livremente, o que facilita o uso de uma solução do tipo em universidades, por exemplo;
- relativa facilidade de customização para o perfeito atendimento da aplicação;
- um cluster pode ser implementado tanto para uma aplicação sofisticada quanto para um sistema doméstico criado para fins de estudos, por exemplo.
Mas, apesar destes benefícios, os clusters não são a solução perfeita para todo e qualquer problema computacional. Há aplicações onde o uso de outra tecnologia se mostra mais adequado. Entre as razões para isso estão:
- a facilidade de expansão do cluster pode ser uma "faca de dois gumes": a quantidade de máquinas pode aumentar tanto que a manutenção se torna mais trabalhosa, o espaço físico pode ficar impróprio, etc;
- a tecnologia de comunicação utilizada pode não oferecer a velocidade de transferência de dados ou o tempo de resposta necessário, dependendo da aplicação;
- um cluster tem como base uma rede local, logo, não se pode acrescentar máquinas que estejam muito distantes geograficamente.
Por estes aspectos, fica evidente que as necessidades e os requisitos de uma aplicação devem ser bem avaliados para que se possa decidir entre a implementação de um cluster ou outra tecnologia. Se o clustering for a opção escolhida, deve-se seguir com a avaliação, desta vez para se decidir sobre as soluções e recursos disponíveis.

Finalizando
A origem da denominação "cluster" não é clara, mas sabe-se que as primeiras soluções de processamento paralelo remontam à década de 1960, havendo, a partir daí, alguns princípios que hoje formam a base da ideia de clustering.
O fato é que o passar do tempo não torna o conceito ultrapassado. Há um motivo especial para isso: os clusters se relacionam intimamente à otimização de recursos, uma necessidade constante em praticamente qualquer cenário computacional. E este aspecto pode se tornar ainda mais atraente quando a ideia de cluster é associada a conceitos mais recentes, como cloud computing e virtualização.

Visão geral do Oracle RAC

Visão geral do Oracle RAC Um cluster consiste em multiplos computadores interconectados ou servidores que têm como objetivo compartilhar/
processar requisições de usuários em aplicações para usuários finais. O Oracle RAC permite que um Database seja
clusterizado e ele utiliza o Oracle Clusterware como infraestrutura para processar várias instâncias como um sistema único.
Abaixo o funcionamento do Oracle RAC:

O que é um Cluster?
As características mais comuns de um Cluster Oracle são:
Servidores interligados que atuam como um único servidor;
O software utilizado pelo cluster mascara a infra-estrutura;
Os discos estão disponíveis para leitura e gravação para todos os servidores do cluster;
Os dados são compartilhados através de softwares;
ASM;
ACFS;
OCFS;
NFS;
RAW;
O sistema operacional é o mesmo em todos os servidores;
Várias instâncias acessando o mesmo banco de dados;
Uma instância por servidor;
Acesso aos dados (datafiles) ao mesmo tempo por todas instâncias;
Controle de acesso aos dados por parte do Oracle RAC;

Os benefícios da utilização do Oracle Real Application Clusters:
Alta disponibilidade: segurança para falhas em servidores e instâncias;
Escalabilidade: adicione mais nodes/servidores em necessidade futuras;
Custo: somente é pago o que é utilizado;
Computação em grade (Grid):
Aumento e diminuição do cluster confirme necessidade;
Adicionar e remover nodes com facilidade;
Utilização de repositório de carga;
Execuções de processos de forma paralela;
Distribuição de carga entre os nodes do cluster.
Interconnect
O Oracle Clusterware necessita de troca de informações entre todos os nodes do Cluster. Para isso é utilizado
o link “Interconnect”. As principais tarefas desta interface de rede são:
Funções Heartbeat/Keep Alive ;
Troca de mensagens;
Troca de informações sobre locks e deadlocks;
Atualização de cache (Cache Fusion);
Exemplos de ligações da interface Interconnect:
Single-Switch:
Interfaces ligadas somente a um switch para o Interconnect dos nodes do clusters;
Pode ser configurado como Ativo/Ativo ou Ativo/Standby via Bonding.

Multi-Switch:
Interfaces ligadas a duas ou mais switchs para o Interconnect dos nodes do clusters;
Pode ser configurado como Ativo/Ativo ou Ativo/Standby via Bonding ou HAIP.

Exemplo de ambiente Oracle RAC
Um exemplo de ambiente utilizando Oracle RAC (Versão 11gR2) é mostrado a seguir na imagem:

Ordem de Startup
Para iniciar o cluster, existe uma ordem para o startup dos serviços – isso garante a inicialização correta do Oracle RAC:

Principais processos do Oracle RAC
Um cluster consiste em vários processos no SO. Os processos GCS, GES e GRD consistem no funcionamento do Oracle
Cache Fusion (responsável pela troca de blocos em memória entre os nodes do cluster.) Abaixo alguns processos do
Oracle RAC:

Cluster Ready Services(CRS)
Processo principal para gerenciamento de alta-disponibilidade do cluster.
Cluster Synchronization Services (CSS)
Gerencia a configuração do cluster controlando seus membros, notificando membros quando um node é edicionado
ou excluído do cluster.
Event Manager (EVM)
Proceso Background que gerencia eventos do cluster.
Cluster Time Synchronization Services (CTSS)
Serviço para sincronização de horário entre os nodes do cluster.
Oracle Notification Services (ONS)
Serviço para gerenciamento de eventos FAN (Fast Application Notifications)
Oracle AgentGerencia serviços quando um evento FAN ocorre. Conhecido como processo RACG até a versão 11.1
Oracle Root Agent
É um processo específico (Oraagent) que funciona juntamente com o processo CRSD para gerenciar recursos do
usuário “root”, como serviços de rede e endereços VIP.
Grid Naming Services (GNS)
É um conexão entre o mDNS e o DNS externo. Gerencia automaticamente nomes do cluster (opcional).
Grid Plug And Play (GPnP)
Permite adição e remoção de nodes no cluster automaticamente sem ação manual. Necessita do GNS configurado.
Multicast Domain Name Services (mDNS)
Permite solicitações do DNS externo.
ACMS: Atomic Controlfile do Memory Service
Num ambiente Oracle RAC, o ACMS contribui para garantir que as atualizações na memória SGA sejam distribuídas
entre os nodes, com sucesso ou falha.
GTX0-j: Global Transaction Process
O processos GTX0-j suporta transações globais num ambiente Oracle RAC. O Database automaticamente calcula o
número desses processos baseando-se na carga de transações XA globais.
LMON: Global Enqueue Service Monitor
O processo LMON monitora filas globais e recursos do cluster e executa recover de operações LMD
(GlobalEnqueue Daemon). Os processos LMD gerenciam as solicitações remotas de cada instance do cluster.
LMS: Global Cache Service Process
O processo LMS mantém registros dos status dos Datafiles e de cada bloco em cache registrados no Global Resource
Directory (GRD). O Processo LMS também controla as mensagens para instâncias remotas e gerencia o
acesso e a transmissão de blocos da Buffer Cache entre as diferentes instances do cluster. Esse processo faz parte da feature
Cache Fusion. LCK0: Instance Enqueue Process
O processo LCK0 administra as requisições de recursos que não são da Cache Fusion, como por exemplo, requisições
library w row cache.
Veja os principais processos do Oracle RAC aqui. (Somente em inglês)
Principais mudançaos no Oracle 11gR2
Em relação a versões anteriores do Oracle Database, existem algumas diferenças, como:
OFA (Optimal Flexible Architecture)
Os novos diretórios no 11g, em $ORACLE_BASE/diag/rdbms/
alert – Diretório do alert log em xml e txt.
incident – Diretório para todos os incidentes do software.
incpkg – Diretório para quando a criado um pacote des incidentes.
trace – Diretório para armazenar os antigos traces gerados nos caminhos background dump (bdump) e user dump (udump).
cdump – Diretório para armazenar os traces de Core Dump, antigo core_dump_dest.
metadata – Metadata sobre os incidentes, problemas e pacotes.
Parâmetros depreciados
Os parâmetros background_dump_dest, core_dump_dest, user_dump_dest foram depreciados. Agora, todos os traces podem
ser encontrados em DIAGNOSTIC_DEST.
ADR – Automatic Diagnostic Repository
Ferramenta para auxiliar na prevenção, detecção e diagnóstico de problemas com bugs em banco de dados.
O ADR centraliza todos os traces e logs de todos os componentes, tais como ASM, CRS, LISTENER.
Senhas
As senhas agora, por padrão, são SENSITIVE CASE. Logo, é preciso muita atenção com usuários de aplicação, pois
isso poderá ser um problema em uma migração. O recurso pode ser desligado alterando o parâmetro sec_case_sentitive_logon = FALSE.
SCAN – Single Access Name
O Single Client Name (SCAN) é uma nova feature do Oracle RAC 11gR2 que dispõe de um nome qualificado para acesso ao
Oracle Database em um cluster. Entre os benefícios, um é a possibilidade de adionar ou remover nodes de um cluster
sem a necessidade de alterar os clients. O SCAN é o responsável por LOAD BALANCING e FAILOVER, mudando
consideralvelmente o Oracle Net de ambiente em Cluster 11gR2.

Overview do SCAN
LOAD BALACING de conexões usando SCAN:

Oracle Grid Infrastructure
Com o Oracle Grid Infrastructure, o ASM e o Clusterware são instalados em uma única home, tornando-se uma
plataforma unificada de infraestrutura do Oracle RAC. Arquivos do Clusterware como OCR e Voting Disks,
podem ser armazenados no ASM, unificando as soluções de armazenamento. Para novas instalações, a opção de armazenamento
dos arquivos de Clusterware em raw devices não é mais suportada. Estas consigurações também se aplicam para a
configuração STANDALONE SERVER. O ACFS – Automatic Storage Management Cluster File System é um novo recurso de armazenamento, suportando todas as
plataformas, provendo uma file system dinâmica, distribuída performaticamente, balanceamento sobre todos os discos
envolvidos. Substituí o antigo OCFS.
O Cluster Time Synchronization Service – CTSS, serviço responsável por manter o sincronismo de tempo entre os nodes.
Oracle Universal Installer do Grid Infrastructure gera scripts automaticamente para fix de pré-requisitos não
atendidos. Online Application Upgrade
Nessa versão é permitido que sejam realizados upgrades online sem qualquer indisponibilidade para aplicações.
Anteriormente, quando um commando DDL era executado e outra sessão tentava realizar um DML no mesmo objeto, ocorria
uma falha. Isto não acontece mais. Foram feitas melhorias nos processos Create e Rebuild index (no waits).
O modelo de dependências do banco mudou para o chamado “finegrained”. Ex: Adicionar uma nova coluna em uma tabela ou um novo
subprograma para uma package spec não invalidará suas dependências.
Matriz de Certificação do Oracle RAC
Para garantir a compatibilidade de software/hardware em uma instalação do Oracle RAC, confira a matriz de
certificação no My Oracle Support:
Conecte no portal Oracle;
Clique na aba “Certificação”;
Cliquem em “Certificação por Produto”;
Selecione “Real Application Clusters”;
Selecione a plataforma.

Cross-Frame Scripting

O Cross-Frame Scripting (XFS) é um ataque client-side variante do ja famoso Cross-Site Scripting (XSS).
Em um ataque de XFS, o atacante explora um determinado cross-frame-scripting bug em um browser para acessar através dele dados
privados em um web-site secundário. O atacante induz o browser do usuário à navegar para a página que o atacante
controla; o atacante pode carregar uma página secundária em um frame HTML; executando um javascript o atacante pode
conseguir dados de websites carregados em um frame secundário.
Principais Fatores de Risco
Os modelos de segurança padrão em browsers permitem que javascripts de uma determinada página possa acessar o
conteúdo de outras páginas que sejam carregadas em diferentes janelas do browser ou frames – desde que as outras
páginas tenham sido carregadas a partir da mesma origem. Entretanto, um bug específico neste modelo de segurança existe
em browsers específicos, permitindo assim que um atacante acesse dados carregados a partir de páginas
carregadas de origens/domínios diferentes.
O browser mais conhecido por conter este tipo de bug é o IE (internet explorer), que permite vazamento de
keyboard events através de HTML framesets. Este bug pode permitir, por exemplo, que um atacante roube dados de login
que o usuário está digitando em um determinado site carregador a partir do Frame-set malicioso.
Exemplos: XFS Attack em um Internet Explorer
Para conseguirmos explorar o bug no IE que permite que os Keyboard Events sejam roubados a partir de um frameset,
um atacante deve criar uma página e hospedá-la em um servidor qualquer, em nosso exemplo ela estará hospedada em
badsite.com. Esta página será controlada pelo atacante, e deverá incluir por exemplo um frame mostrando uma
página de login do site goodsite.com.
O atacante pode esconder as bordas do frame e expandir o frame para cobrir a pagina toda, desta forma o usuário irá
realmente acreditar que está acessando goodsite.com. O atacante registra alguns javascripts no index de badsite.com que
irá obter todos os key events na página. Normalmente estes listeners serão notificados apenas pelos key
events da janela principal do site badsite.com – mas devido o bug existente no browser, este listener irá receber
todos os key events existentes no frame carregado com o login do goodsite.com.
Desta forma todas as teclas pressionadas no browser, dentro deste frame do goodsite.com, enquanto ele tenta logar-se,
poderá ser capturada e depois enviada para badsite.com

Gumblar – iFrames com vírus no seu site
Se é webmaster, provavelmente já ouviu falar acerca de ataques a sites que adicionam iframes em praticamente todos
os ficheiros do site. Já tivemos alguns clientes que se depararam com esta situação e vimos desta forma explicar
como é que é feito esse ataque e como o poderá evitar.
O ataque geralmente não é gerado através de vulnerabilidades dos sites ou dos servidores, mas sim através de uma
infecção de um vírus no computador do administrador/webmaster do site controlado por uma Botnet.
Reconhecido como Gumblar pela ScanSafe e por Troj/JSRedir-R pela Sophos, esta nova botnet apareceu pela primeira
vez em 2009 e é caracterizada por redireccionar as pesquisas dos utilizadores no Google e suspeita-se que a sua
origem sejam ficheiros PDF (Acrobat Reader) ou SWF Flash (Adobe Flash).
Os visitantes de um site infectado com o Gumblar serão redireccionados para um site alternativo com malware. Neste
momento a rede de sites infectados é já bastante grande, abrangendo milhões de sites infectados.
O site com malware irá forçar o browser do utilizador a abrir um PDF infectado que executa e explora uma
vulnerabilidade no Acrobat para ganhar acesso ao computador do utilizador.
O vírus vai encontrar clientes FTP como o FileZilla e o Dreamweaver e como estes guardam a password como
plain text, conseguem obter os dados de acesso FTP ao site do utilizador infectado.
Ao encontrar os dados de acesso FTP desse utilizador, a botnet vai conseguir aceder normalmente ao servidor
FTP usando uma autenticação normal de password e username e infectar os ficheiros do site com uma iframe.
Numa primeira fase vai fazer download de grandes partes do site e injectar código malicioso em ficheiros que
contenham a tag como ficheiros HTML, PHP, JavaScript, ASP e ASPx. O código inserido será um pequeno código
Javascript base64-encoded que irá infectar os computadores dos visitantes do site que executarem o código.
Poderão ser adicionadas iframes no código malicioso que vão conter links para sites maliciosos. O vírus irá também
tentar modificar ficheiros .htaccess e hosts e ainda criar ficheiros com o nome images.php em diretórios
chamadas “images”.
Deverá ter em conta que esta não é uma vulnerabilidade do servidor. É um ataque feito com autenticação por password.
O ataque não é feito a nível global no servidor, limitando-se aos ficheiros da home do utilizador em questão atacado.
Para evitar estes ataques deverá utilizar um cliente de FTP que guarde as passwords no seu computador de forma

segura, manter os plugins do seu browser sempre actualizados e ter um anti-virus instalado que lhe permita

detectar e bloquear a execução desta vírus.
Devido ao número de sites infectados, a propagação deste vírus é bastante rápida e já infectou milhares de
computadores. Ao ser infectado, o seu site será mais um a ajudar a distribuição deste vírus na botnet. Se alguma vez
detectar que o seu site foi atacado por este vírus, deverá entrar em contacto com o seu sysadmin para que
ele possa verificar nos logs do servidor informações relevantes.

CPanel - Manual de Instalação - Certificado SSL

Instalando o seu Certificado:
Estas instruções são para o cPanel 11. Se você tiver outra versão do cPanel, seu processo será parecido, mas é
possível que você tenha que pedir instruções específicas ao seu provedor de hospedagem.
Salve os arquivos do seu certificado no diretório em que você salvou o arquivo TXT da sua chave privativa.
Faça login no painel de controle do cPanel.
Clique em Gerenciador SSL/TLS.
Clique em Gerar, visualizar, fazer upload ou excluir certificados SSL.
Na seção Fazer Upload de Nova Certificado, clique em Escolher arquivo e localize o arquivo do certificado
(dominio_com_br.crt), que você recebeu e salvou no passo 1. Ou, se tiver copiado o conteúdo do certificado do corpo
do e-mail, cole na caixa de texto “Cole o crt abaixo:”. Para acessar o texto do seu certificado,
abra-o em um editor de texto. Ao copiar e colar o seu certificado, inclua as linhas BEGIN e END.
Clique em Fazer Upload.
Clique em Voltar e depois em Retornar ao Gerenciador SSL.
Clique em Configurar um certificado SSL para funcionar com seu site. Se esta opção (a quarta opção)
não estiver visível, é provável que seu provedor de hospedagem não a disponibilize. Nesse caso, será necessário entrar em contato para que eles mesmos instalem o certificado.
Selecione o domínio do menu drop-down Domínio. O sistema tentará buscar ("Fetch") seu certificado e sua chave privativa.
Se a chave privativa não bater com a que você salvou no passo 7 de “Como Gerar uma CSR no cPanel”, copie e cole o conteúdo do arquivo que você salvou no espaço correspondente.
Na caixa de texto Ca Bundle, cole o conteúdo do arquivo dominio_com_br.ca-bundle. Este passo aparece no cPanel como opcional, mas é altamente recomendável que o ca-bundle seja colado aqui, pois a não realização deste passo pode resultar em mensagens de erro ao acessar o site em HTTPS.
Clique em Instalar Certificado. Após este passo, seu certificado deve estar instalado, e o site deve estar configurado para aceitar conexões seguras.
Você ou o provedor de hospedagem talvez precisem reiniciar o Apache para ele funcionar.

MS Exchange 2007- Manual de Instalação - Certificado SSL

Instalando o seu Certificado:

Você receberá o certificado anexado a uma mensagem de correio eletrônico. O arquivo do certificado deve ser copiado
no servidor Exchange 2007. Depois deve ser instalado utilizando o Import-ExchangeCertificate cmdlet.
Não utilize o snap-in de instalação de certificados no MMC para a a instalação do seu certificado porque não
funcionará com o Exchange 2007. Utilize o MMC apenas para a instalação das raízes
Abra o Exchange Management Shell.
Caminho: Start > Programs > Microsoft Exchange Server 2007 > Exchange Management Shell.
Nesse exemplo o certificado foi copiado para o arquivo c:\exchange.comodo.com.crt
Import-ExchangeCertificate -Path c:\exchange.comodo.com.crt | Enable-ExchangeCertificate -Services SMTP
Os flags 'Services' que podem ser utilizados com esse certificado são: SMTP IMAP POP IIS UM
Para habilitar multiplos serviços utilize:
Import-ExchangeCertificate -Path c:\exchange.comodo.com.crt | Enable-ExchangeCertificate -Services "SMTP, POP, IMAP, IIS"
Uma vez que tenha instalado o certificado no site pode ser necessário seguir os passos abaixo para a instalação dos
certificados raiz e intermediário com os outros arquivos que você recebeu.
Seu certificado raiz é o EntrustSecureServerCA.crt ou o AddTrustExternalCARoot.crt
Seu certificado intermediário é o USERTrustLegacySecureServerCA.crt ou COMODOHigh-AssuranceSecureServerCA.crt
Copie esses certificados para o servidor e depois siga os passos:
No Windows clique no Menu Iniciar > Executar > mmc
Selecione File e Add/Remove Snap in
Selecione Add.
Selecione Certificates na caixa Add Standalone Snap-in e clique Add
Selecione Computer Account (NOTA: Esse passo é muito importante, pois qualquer outra escolha não funcionará)
e clique Next
Selecione Local Computer e Finish
Feche a caixa Add Standalone Snap-in, e clique OK no Add/Remove Snap in
Return ao MMC
Para instalar o certificado raiz:
Clique com o botão da direita em Trusted Root Certification Authorities, selecione All Tasks, Import e Next.
Selecione o certificado raiz e clique Next.
Ao final do Assistente selecione Finish.
Para instalar o certificado intermediario:
Clique com o botão da direita em Intermediate Certification Authorities, selecione All Tasks, Import e Next.
Selecione o certificado raiz e clique Next.
Ao final do Assistente selecione Finish.
Você deverá reiniciar o servidor
para finalizar a instalação

Microsoft IIS 7 - Manual de Instalação - Certificado SSL

Instalando o seu Certificado:
Selecione “Administrative Tools”
Inicie “IIS Manager”.
Clique no nome do seu servidor onde o certificado será instalado.
No menu central, de um clique duplo em “Server Certificates” (Certificados de Servidor)

No menu "Actions" (no lado direito), clique em “Complete Certificate Request” (Concluir Solicitação de Certificado)

Isto irá abrir o assistente para a instalação do certificado.

Navegue até a pasta onde salvou o certificado recebido da Comodo Brasil. Este é o arquivo recebido no
.zip que se chama seudominio.crt. Coloque o Friendly Name (Nome Amigavel) desejado. O Friendly Name não é parte do certificado, e
sim apenas um nome para o técnico reconhecer mais facilmente o certificado. Clique em "Ok". Depois que o certificado estiver devidamente instalado no servidor, você terá que designar o certificado ao site
apropriado usando o IIS.
No menu "Connections" na janela principal do Internet Information Services (IIS) selecione o nome do servidor onde o certificado está instalado.
Em "Sites" selecione o site onde irá utilizar o SSL.
No menu "Actions" (do lado direito), clique em "Bindings".

Isso abrirá a janela "Site Bindings".


Na janela "Site Bindings" clique em "Add". Isso abrirá a janela de "Add Site Binding".

Em "Type" escolha https. O endereço IP deve ser o endereço do site ou estar como All Unassigned e a porta padrão para
SSL é a 443. O campo "SSL Certificate" deve especificar o certificado que foi instalado no passo anterior. Clique em "OK".
Uma vez finalizados os passos acima você terá que instalar os certificados raiz e intermediários manualmente.
Instalando o Certificado da raiz intermediária:
Você recebeu 3 Certificados da Comodo. Salve estes certificados no desktop do seu servidor, depois:
Clique no botão Iniciar e selecione Executar. Digite mmc.
Clique em Arquivo e selecione Adicionar/Remover Snap in
Selecione a opção Adicionar, e escolha Certificados e clique em Adicionar
Selecione Conta do Computador e clique em Finalizar
Feche a caixa aberta e clique em Ok no Adicionar/Remover Snap in
Para Instalar o Certificado intermediário:
Clique com o botão direito do seu mouse em Autoridades Certificadoras Intermediárias, selecione Todas as Tarefas,
selecione Importar.
Siga o Wizard de instalação, localizando o Certificado intermediário quando solicitado.
Repita os passos para instalação do certificado raíz.
Você deverá reiniciar o IIS para finalizar a instalação.

Manual de Instalação - Certificado digital - Apache / ModSSL

1º PASSO - Salve os arquivos de certificado recebidos
Você recebeu um arquivo .zip contendo 2 arquivos do seu certificado:
Seu certificado - seudominio_com_br.crt Seu arquivo Apache "bundle" - seudominio_com_br.ca-bundle Descompacte os arquivos e salve o seu certificado no diretório onde você costuma armazenar seus certificados, p. ex.:
/etc/httpd/conf/ssl.crt/ e o ca-bundle onde ficam armazenadas as raízes públicas, p. ex.: /etc/httpd/conf/ca/.
Neste exemplo, usaremos:
/etc/httpd/conf/crt/ - local onde os certificados serão armazenados.
/etc/httpd/conf/key/ - local onde a chave privativa do servidor está armazenada.
/etc/httpd/conf/ca/ - local onde o CA-bundle será armazenado.

2º PASSO - Configure o httpd.conf
É necessário referenciar o ca-bundle, assim como o seu certificado, para que o seu servidor web utilize seu certificado
digital corretamente.
Nas configurações do Virtual Host do seu site, no arquivo httpd.conf (dependendo da configuração, o SSL pode estar
configurado em um include, em um arquivo chamado ssl.conf ou httpd_ssl.conf), você deverá completar as seguintes etapas:
1. Renomeie o arquivo seudominio_com_br.ca-bundle para ca.txt e copie para o diretório escolhido, p.ex.:
/etc/httpd/conf/ca/
2. Adicione a linha a seguir à seção de SSL do httpd.conf. Se a linha já existir, mude o que for necessário para que
ela fique da seguinte forma:
SSLCACertificateFile/etc/httpd/conf/ca/ca.txt

3. Salve o arquivo seudominio_com_br.crt para o diretório escolhido, p. ex: /etc/httpd/conf/crt/. Verifique também que
o arquivo .key gerado juntamente com a solicitação do certificado esteja salvo no local correto, p. ex:
/etc/httpd/conf/key/. Adicione agora as linhas abaixo, referentes ao seu certificado a à chave privativa:

SSLCertificateFile/etc/httpd/conf/crt/seudominio_com_br.crt
SSLCertificateKeyFile/etc/httpd/conf/key/dominio.key
Se você estiver utilizando outro local e outro nome de certificado, terá de alterar os caminho e nomes de arquivo de acordo.
A seção SSL do arquivo httpd.conf atualizado agora deve estar semelhante ao seguinte exemplo:
SSLCertificateFile/etc/httpd/conf/crt/seudominio_com_br.crt
SSLCertificateKeyFile/etc/httpd/conf/key/dominio.key
SSLCACertificateFile/etc/httpd/conf/ca/ca.txt
Salve seu arquivo httpd.conf e reinicie o Apache.

Configurando servidor de DNS no CentOS

O Domain Name System – Sistema de Nomes de Domínio – é de fundamental importância em uma rede. O DNS é um sistema hierárquico em árvore invertida. Tem como origem o ponto (“.”), e a partir daí, os domínios e, abaixo destes, os subdomínios. O nome completo de um host – FQDN = Full Qualified Domain Name – é composto de duas partes: a primeira parte identifica o host dentro do domínio e a segunda parte identifica o domínio. 1 - Pacotes necessários: Execute os comando abaixo para realizar a instalação dos pacotes. yum install bind bind-libs bind-utils caching-nameserver -y
Após a instalação dos pacotes acima, podemos visulizar alguns arquivos padrões:
# ls -l /var/named -rw-r--r-- 1 named named 195 Fev 15 2004 localhost.zone
-rw-r--r-- 1 named named 2518 Fev 15 2004 named.ca
-rw-r--r-- 1 named named 436 Jun 14 2007 named.local
named.ca
Neste arquivo vem por padrão todos os rootserver da internet, ou seja, os servidores de DNS mundiais . Sua função e interligar todos os servidores do mundo ou seja se o seu servidor de DNS não sabe onde fica localizado determinado IP ele faz uma consulta a um rootserver que vai lhe dizer a resposta. named.local
Neste arquivo vem por padrão a zona local da maquina na entrada do DNS ou seja o localhost. localhost.zone
O arquivo de zona reversa ou seja resolver IP pra nome 2 - Um dos primeiros arquivos que iremos alterar será o arquivo host.conf: Esse arquivo define a ordem de consulta da máquina, que no caso mudaremos para DNS depois hosts; # vim /etc/host.conf
order bind,hosts
multi on
3 - O próximo arquivo que iremos alterar é o hosts
# vim /etc/hosts
127.0.0.0.1 localhost.localdomain localhost
10.1.1.1 servername.domain.com.br servername
O arquivo hosts especifica o nome da máquina e domínio. Neste arquivo devemos obrigatoriamente ter pelo menos o localhost e nosso próprio IP.
4 - O próximo arquivo a alterarmos é o resolv.conf
# vim /etc/resolv.conf
search domain.com.br
nameserver 10.1.1.1
nameserver 201.21.192.105
No arquivo resolv.conf você irá configurar qual será o domínio e IP do servidor de DNS que irá utilizar para navegar na internet, ou seja, estamos configurando um servidor de DNS logo utilizaremos nosso próprio servidor e outro externo. Vamos agora ao que interessa:
5 - Criando uma Zona de DNS
Vamos editar o arquivo named.conf, nele são cadastradas as zonas, nele também efetuamos várias configurações opcionais, tipo se você tiver um dns secundário, permitir replicação, recursos de view interna e view externa, e muitas outras opções. Vou mostrar abaixo um exemplo de como inserir uma zona master e uma zona reversa de um domínio: # vim /etc/named.conf
# Nome da zona master zone "domain.com.br" IN {
type master;
check-names ignore;
file "domain.com.br";
};
# Nome da zona Reversa
zone "2.168.192.in-addr.arpa" IN {
type master;
check-names ignore;
file "192.168.2.1";
};
Nos parametros file de cada zona indica o nome do arquivo onde serão cadastrados os hosts e outras opções. 6 - Agora vamos criar os arquivos conforme seus nomes indicados nas zonas acima. # touch /var/named/dominio.com.br
# touch /var/named/192.168.2.1
# chown named.named /var/named/dominio.com.br
# chown named.named /var/named/192.168.2.1
7 - Agora vamos ao conteúdo dos arquivos de zonas
Vamos editar o arquivo de zona master do domínio dominio.com.br:
# vim /var/named/dominio.com.br
Segue abaixo o conteúdo do arquivo dominio.com.br que pode ser usado como template para criação de outros arquivos: $TTL 86400 ; 1 dia
@ IN SOA servidor.dominio.com.br. root.servidor.dominio.com.br. (
2008092181 ; serial
10800 ; refresh (3 horas)
900 ; retry (15 minutos)
604800 ; expire (1 semana)
86400 ; minimum (1 dia)
) NS servidor.dominio.com.br.
IN 1H MX 5 mailserver
mailserver IN 1H A 192.168.2.10
webmail IN 1H A 192.168.2.11
fileserver IN 1H A 192.168.2.12
Esse é o conteúdo da zona master do domínio dominio.com.br, salve o arquivo e saia. Vamos agora editar o conteudo do arquivo de zona reversa do domínio: # vim /var/named/192.168.2.1
$TTL 86400 ; 1 dia
@ IN SOA servidor.dominio.com.br. root.servidor.dominio.com.br. (
2008092181 ; serial
10800 ; refresh (3 hotas)
900 ; retry (15 minutos)
604800 ; expire (1 senama)
86400 ; minimum (1 dia)
) NS servidor.dominio.com.br.
10 PTR mailserver.dominio.com.br.
11 PTR webmail.dominio.com.br.
12 PTR fileserver.dominio.com.br.
Esse é o conteúdo da zona master do domínio 192.168.2.1, salve o arquivo e saia.
Segue abaixo algumas informações sobre os parâmetros do arquivo: - SOA (start of authority) - ele informa quem é responsável pelo conteúdo. - serial: um número que identifica a versão de atualização das informações. - refresh: é o período do ciclo de atualização. A cada ciclo , os servidores secundários comparam seu número serial com o do servidor primário, e se forem diferentes, ele executa uma transferência de zona. - retry: define o tempo que o servidor secundário irá esperar para nova tentativa se o primário não responder. - expiry: tempo máximo que um servidor secundário continua respondendo por uma zona quando não consegue comunicação com o primário. - minimum: tempo mínimo de vida que a zona tem. 8 - Bom, depois de termos editado os arquivos e lido o cada parâmetro significa, vamos agora inicializar o serviço e colocar para rodar no boot da máquina. Para inicializar execute o comando abaixo: # service named start Para que o serviço sempre inicialize no boot execute o seguinte comando: # chkconfig named on 9 - Agora, por último vamos aos testes Iremos fazer abaixo um dos testes mais simples que é executar um ping no nome # ping -c 3 mailserver.dominio.com.br PING mailserver.dominio.com.br (192.168.2.10) 56(84) bytes of data.
64 bytes from mailserver.dominio.com.br (192.168.2.10): icmp_seq=1 ttl=64 time=0.024 ms
64 bytes from mailserver.dominio.com.br (192.168.2.10): icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from mailserver.dominio.com.br (192.168.2.10): icmp_seq=3 ttl=64 time=0.049 ms
# ping -c 3 webmail.dominio.com.br
PING webmail.dominio.com.br (192.168.2.11) 56(84) bytes of data.
64 bytes from webmail.dominio.com.br (192.168.2.11): icmp_seq=1 ttl=64 time=0.024 ms
64 bytes from webmail.dominio.com.br (192.168.2.11): icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from webmail.dominio.com.br (192.168.2.11): icmp_seq=3 ttl=64 time=0.049 ms
# ping -c 3 fileserver.dominio.com.br
PING fileserver.dominio.com.br (192.168.2.12) 56(84) bytes of data.
64 bytes from fileserver.dominio.com.br (192.168.2.12): icmp_seq=1 ttl=64 time=0.024 ms
64 bytes from fileserver.dominio.com.br(192.168.2.12): icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from fileserver.dominio.com.br(192.168.2.12): icmp_seq=3 ttl=64 time=0.049 ms
Para testar se o reverso do seu endereço está funcionando, isso é muito importante para os servidores de email execute o comando abaixo: # host mailserver.dominio.com.br
mailserver.dominio.com.br has address 192.168.2.10
# host webmail.dominio.com.br
webmail.dominio.com.br has address 192.168.2.11
# host fileserver.dominio.com.br
fileserver.dominio.com.br has address 192.168.2.12
Existem outros comandos bem mais completos que consultam outros parâmetros dos registros de dns * dig * nslookup

Consulta Whois - Registro.br

Ferramenta de Whois

Whois   Procure por um nome de domínio
www.  

Versão com informações de contato

Configuração de apontamentos - Padrão locaweb

Configuração de apontamentos

A finalidade deste artigo é apresentar de forma simplificada as configurações de Apontamento MX e afins, indispensáveis para o estabelecimento de um serviço de e-mail. Uma entrada MX especifica um "Mail Exchanger" para um domínio: Um host que irá processar ou encaminhar uma mensagem para um domínio.

1 - Apontamentos do tipo MX:

Apontamentos do tipo MX:

Entrada	Tipo	Prio	Conteúdo
.	MX	10	mx.a.locaweb.com.br
.	MX	10	mx.b.locaweb.com.br
.	MX	20	mx.jk.locaweb.com.br

2 - Apontamentos do tipo CNAME:

2 - Apontamentos do tipo CNAME:

Entrada	Tipo	Prio	Conteúdo
pop	CNAME	0	mail.ita.locaweb.com.br
smtp	CNAME	0	pop.seudomínio
imap	CNAME	0	pop.seudomínio
mail	CNAME	0	pop.seudomínio
webmail	CNAME	0	webmail.ita.locamail.com.br
webmail2	CNAME	0	webmail.ita.locaweb.com.br
calendario	CNAME	0	calendario.locaweb.com.br
autodiscover	CNAME	0	autodiscover.email.locaweb.com.br

3 - Apontamento do tipo TXT:

Apontamento do tipo TXT:

Entrada	Tipo	Prio	Conteúdo
.	TXT	0	v=spf1 include:_spf.locaweb.com.br ?all

Definindo DNS

DNS é a abreviatura de Domain Name System. O DNS é um serviço de resolução de nomes. Toda comunicação entre os computadores e demais equipamentos de uma rede baseada no protocolo TCP/IP (e qual rede não é baseada no protocolo TCP/IP?) é feita através do número IP. Número IP do computador de origem e número IP do computador de destino. Porém não seria nada produtivo se os usuários tivessem que decorar, ou mais realisticamente, consultar uma tabela de  números IP toda vez que tivessem que acessar um recurso da rede. Por exemplo, você digita http://www.microsoft.com/brasil, para acessar o site da Microsoft no Brasil, sem ter que se preocupar e nem saber qual o número IP do servidor onde está hospedado o site da Microsoft Brasil. Mas alguém tem que fazer este serviço, pois quando você digita http://www.microsoft.com/brasil, o protocolo TCP/IP precisa “descobrir” (o termo técnico é resolver o nome) qual o número IP está associado com o endereço digitado. Se não for possível “descobrir” o número IP associado ao nome, não será possível acessar o recurso desejado.

O papel do DNS é exatamente este, “descobrir”, ou usando o termo  técnico, “resolver” um determinado nome, como por exemplohttp://www.microsoft.com Resolver um nome significa, descobrir e retornar o número IP associado com o nome. Em palavras mais simples, o DNS é um serviço de resolução de nomes, ou seja, quando o usuário tenta acessar um determinado recurso da rede usando o nome de um determinado servidor, é o DNS o responsável por localizar e retornar o número IP associado com o nome utilizado. O DNS é, na verdade, um grande banco de dados distribuído em  milhares de servidores DNS no mundo inteiro. Ele possui várias características, as quais descreverei nesta parte do tutorial de TCP/IP.

O DNS passou a ser o serviço de resolução de nomes padrão a partir do Windows 2000 Server. Anteriormente, com o NT Server 4.0 e versões anteriores do Windows, o serviço padrão para resolução de nomes era o WINS – Windows Internet Name Service. Versões mais antigas dos clientes Windows, tais como Windows 95, Windows 98 e Windows Me ainda são dependentes do WINS, para  a realização de determinadas tarefas. O fato de existir dois serviços de resolução de nomes, pode deixar o administrador da rede e os usuários confusos.

Cada computador com o Windows instalado (qualquer versão), tem dois nomes: um host name (que é ligado ao DNS) e um NetBios name (que é ligado ao WINS). Por padrão estes nomes devem ser iguais, ou seja, é aconselhável que você utilize o mesmo nome para o host name e para o NetBios name do computador.

O DNS é um sistema para nomeação de computadores e equipamentos de rede em geral (tais como roteadores,hubs, switchs). Os nomes DNS são organizados de uma maneira hierárquica através da divisão da rede em domínios DNS.

O DNS é, na verdade, um grande banco de dados distribuído em váios servidoress DNS e um conjunto de serviços e funcionalidades, que permitem a pesquisa neste banco de dados. Por exemplo, quando o usuário digita www.abc.com.br na barra de endereços do seu navegador, o DNS tem que fazer o trabalho de localizar e retornar para o navegador do usuário, o número IP associado com o endereço www.abc.com.br Quando você tenta acessar uma pasta compartilhada chamada docs,  em um servidor chamado srv-files01.abc.com.br, usando o caminho \\srv-files01.abc.com.br\docs, o DNS precisa encontrar o número IP associado com o nome srv-files01.abc.com.br. Se esta etapa falhar, a comunicação não será estabelecida e você não poderá acessar a pasta compartilhada docs.

Ao tentar acessar um determinado recurso, usando o nome de um servidor, é como se o programa que você está utilizando perguntasse ao DNS:

“DNS, você sabe qual o endereço IP associado com o nome tal?”

O DNS pesquisa na sua base de dados ou envia a pesquisa para outros servidores DNS (dependendo de como foram feitas as configurações do servidor DNS, conforme descreverei mais adiante). Uma vez encontrado o número IP, o DNS retorna o número IP para o cliente:

“Este é o número IP associado com o nome tal.”

Nota: O DNS implementado no Windows 2000 Server e também no Windows Server 2003 é baseado em padrões definidos por entidades de padronização da Internet, tais como o IETF. Estes documentos são conhecidos como RFCs – Request for Comments. Você encontra, na Internet, facilmente a lista de RFCs disponíveis e o assunto relacionada com cada uma. São milhares de RFCs (literalmente milhares).

Entendendo os elementos que compõem o DNS

O DNS é baseado em conceitos tais como espaço de nomes e árvore de domínios. Por exemplo, o espaço de nomes da Internet é um espaço de nomes hierárquico, baseado no DNS. Para entender melhor estes conceitos, observe o diagrama da Figura a seguir:

Figura - Estrutura hierárquica do DNS

Nesta Figura é apresentada uma visão abrevida da estrutura do DNS definida para a Internet. O principal domínio, o domínio root, o domínio de mais alto nível foi nomeado como sendo um ponto (.). No segundo nível foram definidos os chamados “Top-level-domains”. Estes domínios são bastante conhecidos, sendo os principais descritos na Tabela a seguir:

Top-level-domains:

Top-level-domain	Descrição
com	Organizações comerciais
gov	Organizações governamentais
edu	Instituições educacionais
org	Organizações não comerciais
net	Diversos
mil	Instituições militares

Em seguida, a estrutura hierárquica continua aumentando. Por exemplo, dentro do domínio .com, são criadas sub domínios para cada país. Por exemplo: br para o Brasil (.com.br), .fr para a frança (.com.fr), uk para a Inglaterra (.com.uk) e assim por diante. Observe que o nome completo de um domínio é o nome do próprio domínio e mais os nomes dos domínios acima dele, no caminho até chegar ao domínio root que é o ponto. Nos normalmente não escrevemos o ponto, mas não está errado utilizá-lo. Por exemplo, você pode utilizar www.microsoft.com ou www.microsoft.com. (com ponto no final mesmo).

No diagrama da Figura anterior, representei até o domínio de uma empresa chamada abc (abc...), que foi registrada no subdomínio (.com.br), ou seja: abc.com.br. Este é o domínio DNS desta nossa empresa de exemplo.

Nota: Para registrar um domínio .br, utilize o seguinte endereço: www.registro.br 

Todos os equipamentos da rede da empresa abc.com.br, farão parte deste domínio. Por exemplo, considere o servidor configurado com o nome de host www. O nome completo deste servidor será www.abc.com.br, ou seja, é com este nome que ele poderá ser localizado na Internet. O nome completo do servidor com nome de host ftp será: ftp.abc.com.br, ou seja, é com este nome que ele poderá ser acessado através da Internet. No banco de dados do DNS é que ficará gravada a informação de qual o endereço IP está associado com www.abc.com.br, qual o endereço IP está associado com ftp.abc.com.br e assim por diante. Mais adiante você verá, passo-a-passo, como é feita a resolução de nomes através do DNS.

O nome completo de um computador da rede é conhecido como FQDN – Full Qualifided Domain Name. Por exemplo ftp.abc.com.br é um FQDN. ftp (a primeira parte do nome) é o nome de host e o restante representa o domínio DNS no qual está o computador. A união do nome de host com o nome de domínio é que forma o FQDN.

Internamente, a empresa abc.com.br poderia criar subdomínios, como por exemplo: vendas.abc.com.br, suporte.abc.com.br, pesquisa.abc.com.br e assim por diante. Dentro de cada um destes subdominios poderia haver servidores e computadores, como por exemplo: srv01.vendas.abc.com.br, srv-pr01.suporte.abc.com.br. Observe que sempre, um nome de domínio mais baixo, contém o nome completo dos objetos de nível mais alto. Por exemplo, todos os subdomínios de abc.com.br, obrigatoriamente, contém abc.com.br: vendas.abc.com.br, suporte.abc.com.br, pesquisa.abc.com.br. Isso é o que define um espaço de nomes contínio.

Dentro de um mesmo nível, os nomes DNS devem ser únicos. Por exemplo, não é possível registrar dois domínios abc.com.br. Porém é possível registrar um domínio abc.com.br e outro abc.net.br. Dentro do domínio abc.com.br pode haver um servidor chamado srv01. Também pode haver um servidor srv01 dentro do domínio abc.net.br. O que distingue um do outro é o nome completo (FQDN), neste caso: srv01.abc.com.br e o outro é srv01.abc.net.br.

Nota: Um método antigo, utilizado inicalmente para resolução de nomes era o arquivo hosts. Este arquivo é um arquivo de texto e contém entradas como as dos exemplos a seguir, uma em cada linha:

10.200.200.3           www.abc.com.br
10.200.200.4           ftp.abc.com.br
10.200.200.18         srv01.abc.com.br  srv-files

O arquivo hosts é individual para cada computador da rede e fica gravado (no Windows NT, Windows 2000, Windows Server 2003 ou Windows XP), na pasta system32\drivers\etc, dentro da pasta onde o Windows está instalado. Este arquivo é um arquivo de texto e pode ser alterado com o bloco de Notas.
O DNS é formado por uma série de componentes e serviços, os quais atuando em conjunto, tornam possível a tarefa de fazer a resolução de nomes em toda a Internet ou na rede interna da empresa. Os componentes do DNS são os seguintes:

• O espaço de nomes DNS: Um espaço de nomes hierárquico e contínuo. Pode ser o espaço de nomes da Internet ou o espaço de nomes DNS interno, da sua empresa. Pode ser utilizado um espaço de nomes DNS interno, diferente do nome DNS de Internet da empresa ou pode ser utilizado o mesmo espaço de nomes. Cada uma das abordagens tem vantagens e desvantagens.

• Servidores DNS: Os servidores DNS contém o banco de dados do DNS com o mapeamento entre os nomes DNS e o respectivo número IP. Os servidores DNS também são responsáveis por responder às consultas de nomes envidas por um ou mais clientes da rede. Você aprenderá mais adiante que existem diferentes tipos de servidores DNS e diferentes métodos de resolução de nomes.

• Registros do DNS (Resource Records): Os registros são as entradas do banco de dados do DNS. Em cada entrada existe um mapeamento entre um determinado nome e uma informação associada ao nome. Pode ser desde um simples mapeamento entre um nome e o respectivo endereço IP, até registros mais sofisticados para a localização de DCs (controladores de domínio do Windows 2000 ou Windows Server 2003) e servidores de email do domínio.

• Clientes DNS: São também conhecidos como resolvers. Por exemplo, uma estação de trabalho da rede, com o Windows 2000 Professional, com o Windows XP professional ou com o Windows Vista tem um “resolver” instalado. Este componente de software é responsável por detectar sempre que um programa precisa de resolução de um nome e repassar esta consulta para um servidor DNS. O servidor DNS retorna o resultado da consulta, o resultado é retornado para o resolver, o qual repassa o resultado da consulta para o programa que originou a consulta.

Entendendo como funcionam as pesquisas do DNS

Imagine um usuário, na sua estação de trabalho, navegando na Internet. Ele tenta acessar o site www.http://pablogonzalez853.blogspot.com.br/ O usuário digita este endereço e tecla Enter. O resolver (cliente do DNS instalado na estação de trabalho do usuário) detecta que existe a necessidade da resolução do nome www.http://pablogonzalez853.blogspot.com.br/, para descobrir o número IP associado com este nome. O resolver envia a pesquisa para o servidor DNS configurado como DNS primário, nas propriedades do TCP/IP da estação de trabalho (ou para o DNS informado pelo DHCP, caso a estação de trabalho esteja obtendo as configurações do TCP/IP, automaticamente, a partir de um servidor DHCP – assunto da Parte 10 deste tutorial). A mensagem envida pelo resolver, para o servidor DNS, contém três partes de informação, conforme descrito a seguir:

• O nome a ser resolvido. No nosso exemplo: www.http://pablogonzalez853.blogspot.com.br/

• O tipo de pesquisa a ser realizado. Normalmente é uma pesquisa do tipo “resource record”, ou seja, um registro associado a um nome, para retornar o respectivo endereço IP. No nosso exemplo, a pesquisa seria por um registro do tipo A, na qual o resultado da consulta é o número IP associado com o nome que está sendo pesquisado. É como se o cliente perguntasse para o sevidor DNS: “Você conhece o número IP associado com o nome www.http://pablogonzalez853.blogspot.com.br/?” E o servidor responde: “Sim, conheço. O número IP associado com o nomewww.http://pablogonzalez853.blogspot.com.br/é o seguinte... Também podem ser consultas especializadas, como por exemplo, para localizar um DC (controlador de domínio) no domínio ou um servidor de autenticação baseado no protocolo Kerberos.

• Uma classe associada com o nome DNS. Para os servidores DNS baseados no Windows 2000 Server e Windows Server 2003, a classe será sempre uma classe de Internet (IN), mesmo que o nome seja referente a um servidor da Intranet da empresa.

Existem diferentes maneiras como uma consulta pode ser resolvida. Por exemplo, a primeira vez que um nome é resolvido, o nome e o respetivo número IP são armazenados em memória, no que é conhecido como Cache do cliente DNS, na estação de trabalho que fez a consulta. Na próxima vez que o nome for utilizado, primeiro o Windows procura no Cache DNS do próprio computador, para ver se não existe uma resolução anterior para o nome em questão. Somente se não houver uma resolução no Cache local do DNS, é que será envida uma consulta para o servidor DNS.

Chegando a consulta ao servidor, primeiro o servidor DNS consulta o cache do servidor DNS. No cache do servidor DNS ficam, por um determinado período de tempo, as consultas que foram resolvidas anteriormente pelo servidor DNS. Esse processo agiliza a resolução de nomes, evitando repetidas resoluções do mesmo nome. Se não for encontrada uma resposta no cache do servidor DNS, o servidor pode tentar resolver a consulta usando as informações da sua base de dados ou pode enviar a consulta para outros servidores DNS, até que uma resposta seja obtida. A seguir descreverei detalhes deste procsso de enviar uma consulta para outros servidores, processo este chamado de recursão.

Em resumo, o processo de resolução de um nome DNS é composto de duas etapas:

1.       A consulta inicia no cliente e é passada para o resolver na estação de trabalho do cliente. Primeiro o resolver tenta responder a consulta localmente, usando recursos tais como o cache local do DNS e o arquivo hosts.

2.       Se a consulta não puder ser resolvida localmente, o resolver envia a consulta para o servidor DNS, o qual pode utilizar diferentes métodos (descritos mais adiante), para a resolução da consulta.

A seguir vou descrever as etapas envolvidas nas diferentes maneiras que o DNS utiliza para “responder” a uma consulta enviada por um cliente.

Nota: Vou utilizar algumas figuras da ajuda do Windows 2000 Server para explicar a maneira como o DNS resolve consultas localmente (resolver) e os diferentes métodos de resolução utilizados pelo servidor DNS.

Inicialmente considere o diagrama da Figura a seguir, contido na Ajuda do DNS, no Windows 2003 Server, diagrama este que apresenta uma visão geral do processo de resolução de nomes do DNS.


Figura - O processo de resolução de nomes do DNS.

No exemplo desta figura, o cliente está em sua estação de trabalho e tenta acessar o site da Microsoft: www.microsoft.com. Ao digitar este endereço no seu navegador e pressionar Enter, o processo de resolução do nome www.microsoft.com é iniciado. Uma série de etapas são executadas, até que a resoluçõa aconteça com sucesso ou falhe em definitivo, ou seja, o DNS não consegue resolver o nome, isto é, não consegue encontrar o número IP associado ao endereço www.microsoft.com

Primeira etapa: O DNS tenta resolver o nome, usando o resolver local:

Ao digitar o endereço www.microsoft.com e pressionar Enter, o processo de resolução é iniciado. Inicialmente o endereço é passado para o cliente DNS, na estação de trabalho do usuário. O cliente DNS é conhecido como resolver, conforme já descrito anteriormente, nome este que utilizarei a partir de agora. O cliente tenta resolver o nome utilizando um dos seguintes recursos:

• O cache DNS local: Sempre que um nome é resolvido com sucesso, o nome e a informação associada ao nome (normalmente o endereço IP), são mantidos na memória, o que é conhecido como cache local do DNS da estação de trabalho do cliente. Quando um nome precisa ser resolvido, a primeira coisa que o resolver faz é procurar no cache local. Encontrando no cache local, as informações do cache são utilizadas e a resolução está completa. O cache local torna a resolução mais rápida, uma vez que nomes já resolvidos podem ser consultados diretamente no cache, ao invés de terem que passar por todo o processo de resolução via servidor DNS novamente, processo este que você aprenderá logo a seguir. Pode acontecer situações onde informações incorretas foram gravadas no Cache Local e o Resolver está utilizando estas informações. Você pode limpar o Cache local, usando o comando ipconfig /flushdns Abra um prompt de Comando, digite o comando ipconfig /flushdns e pressione Enter. Isso irá limpar o Cache local.

• O arquivo hosts: Se não for encontrada a resposta no cache local do DNS, o resolver consulta as entradas do arquivos hosts, o qual é um arquivo de texto e fica na pasta onde o Windows Server foi instalado, dentro do seguinte caminho: \system32\drivers\etc (para o Windows NT 4, Windows 2000, Windows Server 2003 e Windos XP). O hosts é um arquivo de texto e pode ser editado com o bloco de notas. Este arquivo possui entradas no formato indicado a seguir, com um númeo IP por linha, podendo haver um ou mais nomes associados com o mesmo número IP:

10.200.200.3           www.abc.com.br     intranet.abc.com.br
10.200.200.4           ftp.abc.com.br         arquivos.abc.com.br
10.200.200.18         srv01.abc.com.br     pastas.abc.com.br    pastas

Se mesmo assim a consulta não for respondida, o resolver envia a consulta para o servidor DNS configurado nas propriedades do TCP/IP como servidor DNS primário ou configurado via DHCP, como servidor DNS primário.

Segunda etapa: Pesquisa no servidor DNS.

Uma vez que a consulta não pode ser resolvida localmente pelo resolver, esta é enviada para o servidor DNS. Quando a consulta chega no servidor DNS, a primeira coisa que o servidor DNS faz é consultar as zonas para as quais ele é uma autoridade.

Por exemplo, vamos supor que o servidor DNS seja o servidor DNS primário para a zona vendas.abc.com.br (diz-se que ele é a autoridade para esta zona) e o nome  a ser pesquisado é srv01.vendas.abc.com.br. Neste caso o servidor DNS irá pesquisar nas informações da zona vendas.abc.com.br (para a qual ele é a autoridade) e responder a consulta para o cliente. Diz-se que o servidor DNS respondeu com autoridade (authoritatively).

No nosso exemplo (Figura anterior) não é este o caso, uma vez que o nome pesquisado é www.microsoft.com e o servidor DNS não é a autoridade, ou seja, não é o servidor DNS primário para o domíno microsoft.com. Neste caso, o servidor DNS irá pesquisar o cache do servidor DNS (não confundir com o cache local do DNS no cliente).

À medida que o servidor DNS vai resolvendo nomes, ele vai mantendo estas informações em um cache no servidor DNS. As entradas são mantidas em cache por um tempo que pode ser configurado pelo administrador do DNS. O cache do servidor DNS tem a mesma função do cache local do resolver, ou seja, agilizar a consulta a nomes que já foram resolvidos previamente. Se for encontrada uma entrada no cache do servidor DNS, esta entrada será utilizada pelo servidor DNS para responder a consulta enviada pelo cliente. e o processo de consulta está completo.

Caso o servidor DNS não possa responder usando informações de uma zona local do DNS e nem informações contidas no cache do servidor DNS, o processo de pesquisa continua, usando um processo conhecido como recursão (recursion), para resolver o nome. Agora o servidor DNS fará consultas a outros servidores para tentar responder a consulta enviada pelo cliente. O processo de recursão é ilustrado na Figura a seguir, da ajuda do DNS. Em seguida comentarei os passos envolvidos no processo de recursão.

Figura - Resolução de nomes usando recursão

O servidor DNS irá iniciar o processo de recursão com o auxílio de servidores DNS da Internet. Para localizar estes servidores, o servidor DNS utiliza as configurações conhecidas como “root hints”. Root hints nada mais é do que uma lista de servidores DNS e os respectivos endereços IP, dos servidores para o domínio root (representado pelo ponto .) e para os domínios top-level (.com, .net, gov e assim por diante). Esta lista é criada automaticamente quando o DNS é instalado e pode ser acessada através das propriedades do servidor DNS. Na Figura a seguir é exibida uma lista de root hints configuradas por padrão, em um servidor DNS, baseado no Windows 2000 Server:

Figura - Lista de root hints do servidor DNS.

Com o uso da lista de servidores root hints, o servidor DNS consege localizar (teoricamente), os servidores DNS responsáveis por quaisquer domínio registrado.

Vamos novamente considerar um exemplo, para entender como o processo de recursão funciona. Imagine que a consulta enviada pelo cliente é para descobrir o endereço IP associado ao nome srv01.vendas.abc.com. O cliente que fez esta consulta está usando um computador da rede xyz.com, o qual está configurado para usar, como DNS primário, o DNS da empresa xyz.com.

Primeiro vamos assumir que o nome não pode ser resolvido localmente no cliente (usando o cache DNS local e o arquivo hosts) e foi enviado para o servidor DNS primário da empresa xyz.com. Este DNS é dono, é autoridade apenas para o domínio xyz.com e não para vendas.abc.com (lembrando sempre que a primeira parte do nome é o nome da máquina, conhecido como nome de host). Com isso o servidor DNS primário da empresa xyz.com.br irá pesquisar no cache do servidor DNS. Não encontrando a resposta no cache, é iniciado o processo de recursão, com os passos descritos a seguir:

1.       O servidor DNS retira apenas a parte correspondente ao domínio (o nome todo, menos a primeira parte. No nosso exemplo seria vendas.abc.com, srv01 é o nome de host). Usando a lista de servidores DNS configurados como root hints, o servidor DNS localiza um servidor que seja o dono, a autoridade para o domínio  root da Internet, representado pelo ponto (o processo é assim mesmo, de trás para frente).

2.       Localizado o servidor responsável pelo domínio root, o servidor DNS da empresa xyz.com  envia uma consulta interativa para o servidor DNS responsável pelo domínio root, perguntando: “Você sabe quem é o servidor DNS responsável pelo domínio .com?”. O servidor DNS root responde com o endereço IP de um dos servidores DNS responsáveis pelo domínio .com. Ou seja, o servidor DNS root não sabe responder diretamente o nome que está sendo resolvido, mas sabe para quem enviar, sabe a quem recorrer. Talvez daí venha o nome do processo recursão.

3.       O servidor DNS do domínio xyz.com recebe a resposta informando qual o servidor DNS responsável pelo domínio .com.

4.       O servidor DNS do domínio xyz.com envia uma consulta para o servidor DNS responsável pelo .com (informado no passo 3), perguntando:“Você é a autoridade para abc.com ou saberia informar quem é a autoridade para abc.com?”

5.       O servidor DNS responsável pelo domínio .com não é a autoridade para abc.com, mas sabe informar quem é a autoridade deste domínio. O servidor DNS resonsável pelo .com retorna para o servidor DNS do domínio xyz.com, o número IP do servidor DNS responsável pelo domínio abc.com.

6.       O servidor DNS do domínio xyz.com recebe a resposta informando o número IP do servidor responsável pelo domínio abc.com.

7.       O servidor DNS do domínio xyz.com envia uma consulta para o servidor DNS
responsável pelo abc.com (informado no passo 6), perguntando: “Você é a autoridade para vendas.abc.com ou saberia informar quem é a autoridade para vendas.abc.com?”

8.       O servidor DNS responsável pelo abc.com não é a autoridade para vendas.abc.com, mas sabe informar quem é a autoridade deste domínio. O servidor DNS resonsável pelo abc.com retorna para o servidor DNS do domínio xyz.com, o número IP do servidor DNS responsável pelo domínio vendas.abc.com.

9.       O servidor DNS do domínio xyz.com recebe a resposta informando o número IP do servidor responsável pelo domínio vendas.abc.com.

10.     O servidor DNS do domínio xyz.com envia uma consulta para o servidor DNS responsável pelo vendas.abc.com (informado no passo 9), perguntando: “Você é a autoridade para vendas.abc.com ou saberia informar quem é a autoridade para vendas.abc.com?”

11.     O servidor DNS para vendas.abc.com recebe a consulta para resolver o nome srv01.vendas.abc.com. Como este servidor é a autoridade para o domínio, ele pesquisa a zona vendas.abc.com, encontra o registro para o endereço serv01.vendas.abc.com e retornar esta inforamação para o servidor DNS do domínio xyz.com.

12.     O servidor DNS do domínio xyz.com recebe a resposta da consulta, faz uma cópia desta resposta no cache do servidor DNS e retornar o resultado para o cliente que originou a consulta.

13,     No cliente o resolver recebe o resultado da consulta, repassa este resultado para o programa que gerou a consulta e grava uma cópia dos dados no cache local do DNS.

Evidentemente que a descrição do processo demora muito mais tempo do que o DNS realmente leva para resolver um nome usando este método. Claro que a resolução é rápida, senão ficaria praticamente impossível usar a Internet. Além disso, este método traz algumas vantagens. Durante esta espécie de “pingue-pongue” entre o servidor DNS e os servidores DNS da Internet, o servidor DNS da empresa vai obtendo informações sobre os servidores DNS da Internet e grava estas informações no cache local do servidor DNS. Isso agiliza futuras consultas e reduz, significativamente, o tempo para a resolução de nomes usando o processo de recursão. Estas informações são mantidas na memória do servidor e com o passar do tempo podem ocupar um espaço considerável da memória. Toda vez que o serviço DNS for parado e iniciado novamente, estas informações serão excluídas da memória e o processo de cache inicia novamente.

Considerações e tipos especiais de resoluções

O processo descrito anteriormente, termina com o servidor DNS (após ter consultado vários outros servidores) retornando uma resposta positiva para o cliente, isto é, conseguindo resolver o nome e retornando a informação associada (normalmente o número IP associado ao nome) para o cliente. Mas nem sempre a resposta é positiva, muitos outros tipos de resultados podem ocorrer em resposta a uma consulta, tais como:

• An authoritative answer (resposta com autoridade): Este tipo de resposta é obtido quando o nome é resolvido diretamente pelo servidor DNS que é a autoridade para o domínio pesquisado. Por exemplo, um usuário da Intranet da sua empresa (abc.com.br), tenta acessar uma página da intranet da empresa, por exemplo: rh.abc.com.br. Neste caso a consulta será enviada para o servidor DNS da empresa, o qual é a autoridade para a zona abc.com.br, com isso o servidor DNS da empresa, responde diretamente à consulta, informando o número IP do servidor rh.abc.com.br. É também uma resposta positiva só que com autoridade, ou seja, respondida diretamente pelo servidor DNS que é a autoridade para o domínio pesquisado, sem a necessidade de usar recursão.

• A positive answer  (resposta positiva): É uma resposta com o resultado para o nome pesquisado, isto é, o nome pôde ser resolvido e uma ou mais informações associadas ao nome são retornadas para o cliente.

• A referral answer (uma referência): Este tipo de resposta não contém a resolução do nome pesquisado, mas sim informações e referência a recursos ou outros servidores DNS que podem ser utilizados para a resolução do nome. Este tipo de resposta será retornado para o cliente, se o servidor DNS não suportar o método de recursão, descrito anteriormente. As informações retornadas por uma resposta deste tipo são utilizadas pelo cliente para continuar a pesquisa, usando um processo conhecido como interação (o qual será descrito mais adiante). O cliente faz a pesquisa em um servidor DNS e recebe, como resposta, uma referência a outro recurso ou servidor DNS. Agora o cliente irá interagir com o novo recurso ou servidor DNS, tentando resolver o nome. Este processo pode continuar até que o nome seja resolvido ou até que uma resposta negativa seja retornada, indicando que o nome não pode ser resolvido. O processo de interação será descrito mais adiante.

• A negative answer (uma resposta negativa): Esta resposta pode indicar que um dos seguintes resultados foi obtido em resposta à consulta: Um servidor DNS que é autoridade para o domínio pesquisado, informou que o nome pesquisado não existe neste domínio ou um servidor DNS que é autoridade para o domínio pesquisado, informou que o nome pesquisado exsite, mas o tipo de registro não confere.

Uma vez retornada a resposta, o resolver interpreta o resultado da resposta (seja ela positiva ou negativa) e repassa a resposta para o programa que fez a solicitação para resolução de nome. O resolver armazena o resultado da consulta no cache local do DNS.

Dica Importante: O administrador do DNS pode desabilitar o recurso de recursão em um servidor DNS em situações onde os usuários devem estar limitados a utilizar apenas o servidor DNS da Intranet da empresa.

O servidor DNS também define tempos máximos para determinadas operações. Uma vez atingido o tempo máximo, sem obter uma resposta à consulta, o servidor DNS irá retornar uma resposta negativa:

• Intervalo de reenvio de uma consulta recursiva – 3 segundos: Este é o tempo que o DNS espera antes de enviar novamente uma consulta  (caso não tenha recebido uma resposta) feita a um servidor DNS externo, duranto um processo recursivo.

• Intervalo de time-out para um consulta recursiva – 15 segundos: Este é o tempo que o DNS espera antes de determinar que uma consulta recursiva, que foi reenviada falhou.

Estes parâmetros podem ser alterados pelo Administrador do DNS.

Como funciona o processo de interação

O processo de interação é utilizado entre o cliente DNS (resolver) e um ou mais servidores DNS, quando ocorrerem as condições indicadas a seguir:

• O cliente tenta utilizar o processo de recursão, discutido anteriormente, mas a recursão está desabilitada no servidor DNS.

• O cliente não solicita o uso de recursão, ao pesquisar o servidor DNS.

• O cliente faz uma consulta ao servidor DNS, informando que é esperada a melhor resposta que o servidor DNS puder fornecer imediatamente, sem consultar outros servidores DNS.

Quando o processo de interação é utilizado, o servidor DNS responde à consulta do cliente com base nas informações que o servidor DNS tem sobre o domínio pesquisado. Por exemplo, o servidor DNS da sua rede interna pode receber uma consulta de um cliente tentando resolver o nome www.abc.com. Se este nome estiver no cache do servidor DNS ele responde positivamente para o cliente. Se o nome não estiver no cache do servidor DNS, o servidor DNS responde com uma lista de servidores de referência, que é uma lista de registros do tipo NS e A (você aprenderá sobre os tipos de registro na parte prática), registros estes que apontam para outros servidores DNS, capazes de resolver o nome pesquisado. Ou seja, o cliente recebe uma lista de servidores DNS para os quais ele deve enviar a consulta. Observem a diferença básica entre o processo de recursão e o processo de interação. Na recursão, o servidor DNS é que entra em contato com outros servidores (root hints), até conseguir resolver o nome pesquisado. Uma vez resolvido o nome, ele retorna a resposta para o cliente. Já no processo de interação, se o servidor DNS não consegue resolver o nome, ele retorna uma lista de outros servidores DNS que talvez possam resolver o nome pesquisado. O cliente recebe esta lista e envia a consulta para os servidores DNS informados. Este processo (esta interação) continua até que o nome seja resolvido ou que uma resposta negativa seja recebida pelo cliente, informando que o nome não pode ser resolvido. Ou seja, no processo de interação, a cada etapa do processo, o servidor DNS retorna para o cliente, uma lista de servidores DNS a serem pesquisados, até que um dos servidores responde positivamente (ou negativamente) à consulta feita pelo cliente.

Como funciona o cache nos servidores DNS

O trabalho básico do servidor DNS é responder às consultas enviadas pelos clientes, quer seja utilizando recursão ou interação. A medida que os nomes vão sendo resolvidos, esta informação fica armazenada no cache do servidor DNS. Com o uso do cache, futuras consultas à nomes já resolvidos, podem ser respondidas diretamente a partir do cache do servidor DNS, sem ter que utilizar recursão ou interação. O uso do cache agiliza o processo de resolução de nomes e também reduz o tráfego de rede gerado pelo DNS.

Quando as informações são gravadas no cache do servidor DNS, um parâmetro chamado Time-To-Live (TTL) é associado com cada informação. Este parâmetro determina quanto tempo a informação será mantida no cache até ser descartada. O parâmetro TTL é utilizado para que as informações do cache não se tornem desatualizadas e para minimizar a possibilidade de envio de informações desatualizadas em resposta às consultas dos clientes. O valor padrão do parâmetro TTL é 3600 segundos (uma hora). Este parâmetro pode ser configurado pelo administrador do DNS, conforme será mostrado na parte prática, nas partes de 21 a 50, as quais constituem o Módulo 2 deste curso.

Aviso Importante: Por padrão o Servidor DNS utiliza um arquivo chamado Cache.dns, o qual fica gravado na pasta systemroot\System32\Dns, onde systemroot representa a pasta onde o Windows 2000 Server ou Windows Server 2003 está instalado. Este arquivo não tem a ver com o Cache de nomes do servidor DNS. Neste arquivo está contida a lista de servidores root hints (descritos anteriormente). O conteúdo deste arquivo é carregado na memória do servidor, durante a inicialização do serviço do DNS e é utilizado para localizar os servidores root hints da Internet, servidores estes utilizados durante o processo de recursão, descrito anteriormente.