Configurando um servidor DNS e DHCP na rede

Galera, como todos meus outros artigos digo que isso não é receita de bolo e que eu sei que na internet está cheio de artigos ensinando a montar o mesmo servidor. Mas todos esses artigos da internet ensinam a fazer um ou outro servidor, então resolvi montar os dois e postar minha experiência. E lembrem-se: aprender é fundamental.

[ Hits: 68.619 ]

Por: Perfil removido em 16/02/2011


Sobre os serviços instalados



Como dito foi criado um servidor de DNS com a segurança de chroot, interagindo com meu Active Directory e também o serviço de DHCP da rede. Um pouco sobre os dois serviços.

Sobre o BIND

BIND (Berkeley Internet Name Domain ou, como chamado previamente, Berkeley Internet Name Daemon) é o servidor para o protocolo DNS mais utilizado na internet, especialmente em sistemas do tipo Unix, onde ele pode ser considerado um padrão. Foi criado por quatro estudantes de graduação, membros de um grupo de pesquisas em ciências da computação da Universidade de Berkeley, e foi distribuído pela primeira vez com o sistema operacional 4.3BSD. O programador Paul Vixie, enquanto trabalhava para a empresa DEC, foi o primeiro mantenedor do BIND. Atualmente o BIND é suportado e mantido pelo Internet System Consortium.

Para a versão 9, o BIND foi praticamente reescrito. Ele passou a suportar, dentre outras funcionalidades, a extensão DNSSEC e os protocolos TSIG e Ipv6.

Sobre os tipos de servidores de resolução de nomes:

Resolvedor não é um servidor de DNS. É um cliente de um servidor recursivo. Os servidores autoritativos não atendem a consultas do resolvedor. O resolvedor, geralmente fica no sistema operacional ou nos programas tipo SSH, e muitos outros que provocam o sistema operacional pesquisar os resolvedores. Existem inúmeros bons programas que implementam servidores de DNS: Bind, Ubound, Djdns, etc. São ótimos! Cada um com suas vantagens e desvantagens.

Por exemplo, o djdns, pelo menos até pouco tempo não implementava o DNSSEC. O BIND é um dos mais completos, pois é autoritativo e recursivo, além de implementar o DNSSEC. O Ubound somente implementa servidor recursivo tratando eficientemente o DNSSEC.

Mas quem precisa de um servidor autoritativo?

Somente quem precisar difundir domínio na Internet. O autoritativo é o servidor que está autorizado a responder por um domínio. A autoridade para responder pelo domínio é dada pelos registros de domínios oficiais de uma determinada região do mundo. No nosso caso, o Brasil quem fornece a autoridade para que um servidor autoritativo responda por um domínio é o Registro.br.

Como já falamos, a autoridade do Registro.br é reconhecida pelos servidores root, pois o Registro.br é um NIR (National Internet Register), responsável pelo Brasil e autorizado pelo LACNIC, que é um dos cinco RIRs (Regional Internet Register) do mundo. O Registro.br exige no mínimo dois autoritativos para repassar a autoridade. O Registro.br não faz nenhuma exigência em relação aos recursivos, isto é, nem dá bola para eles.

Por ser o autoritativo autorizado pelo Registro.br, a responder por um domínio, ele é um servidor que deve ficar disponível para qualquer consulta feita na Internet, ou seja, ele é um servidor aberto, sob o ponto de vista de consultas aos domínios. Ai que mora o perigo! Se o servidor autoritativo não estiver muito bem preparado e não usar o DNSSEC, sua vulnerabilidade passa a ser enorme. Ele está suscetível à chamada poluição de DNS (ou comprometimento, ou envenenamento).

E de um servidor recursivo, quem precisará?

Todos aqueles que possuem usuários ou máquinas com acesso à Internet, na rede sob seu controle. Por exemplo, tenho o Speedy na minha casa.

Variando de 1 a 5 equipamentos, implemento um recursivo por lá? Não. Uso o openDNS, se ele falhar uso o DNS da Telefônica, ou seja, não tenho atividades sensíveis em minha casa.

E na minha empresa? Ah, nela sim. O servidor recursivo tem uma característica interessante, diferentemente do autoritativo ele consulta o autoritativo, mas não está liberado para toda a Internet, ou não deveria. Somente está liberado para as demandas de sua rede. Entretanto, ele traz as informações de domínios vindas dos autoritativos. Se algum autoritativo está comprometido, ele passará tais informações para frente.

Nesse caso, somente o DNSSEC poderá aliviar a tensão do comprometimento, já que é impossível criptografar o tráfego entre recursivos e autoritativos, pelo menos por enquanto.

Sobre o DHCP

O DHCP ("Dynamic Host Configuration Protocol" ou "protocolo de configuração dinâmica de endereços de rede") permite que todos os micros da rede recebam suas configurações de rede automaticamente a partir de um servidor central, sem que você precise ficar configurando os endereços manualmente em cada um.

O protocolo DHCP trabalha de uma forma bastante interessante. Inicialmente, a estação não sabe quem é, não possui um endereço IP e não sabe sequer qual é o endereço do servidor DHCP da rede. Ela manda então, um pacote de broadcast endereçado ao IP "255.255.255.255", que é transmitido pelo switch para todos os micros da rede.

O servidor DHCP recebe este pacote e responde com um pacote endereçado ao IP "0.0.0.0", que também é transmitido para todas as estações.

Apesar disso, apenas a estação que enviou a solicitação lerá o pacote, pois ele é endereçado ao endereço MAC da placa de rede. Como vimos na introdução, quando uma estação recebe um pacote destinado a um endereço MAC diferente do seu, ela ignora a transmissão.

Dentro do pacote enviado pelo servidor DHCP estão especificados o endereço IP, máscara, gateway e servidores DNS que serão usados pela estação.

O interessante é usar um sniffer como o Wireshark para vermos a troca completa de informações entre o servidor DHCP e as estações.

    Próxima página

Páginas do artigo
   1. Sobre os serviços instalados
   2. Instalação dos serviços
   3. Configuração, explicação, chroot e testes no dns
   4. Script para automação da instalação
   5. Configuração, explicação e teste do servidor DHCP
Outros artigos deste autor

FreeBSD Release 10.0 - Introdução ao sistema

Instalando o modem Onda MSA110UP em distribuições Linux que utilizam o NetworkManager

Desknotes e Walkpcs

Pós-instalação do Solus OS para um desktop voltado ao usuário final

O vale do silício no Brasil

Leitura recomendada

i3 - Tilling Window Manager

Mapa da Cultura no Debian 7.0 - Instalação com Nginx usando Phusion Passenger

Alternativas ao Microsoft Visio para Linux

LFTP - Sophisticated File Transfer Program

Instalando Compiz-Fusion no KUbuntu 8.04

  
Comentários
[1] Comentário enviado por manoserpa em 16/02/2011 - 08:38h

Opa!

Estava pesquisando sobre isso ontem e hoje de manhã vi esse link no Twitter.

Valeu.

[2] Comentário enviado por removido em 16/02/2011 - 12:43h

Muito bom o artigo. Legal mesmo.


Abraço.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts