>_Dns 1.2

BIND9

O BIND (Berkeley Inernet Name Domain) é o servidor de nomes utilizado na grande mairia dos servidores da Internet, provendo uma estável e robusta arquitetura sobre a qual as organizações podem construir sua estrutura de nomes.

Configurações do BIND

Com os arquivos instalados vem o momento da configuração de várias diretivas do software. O arquivo de configuração é o named.conf.

Neste exemplo que segue iremos mostrar as configurações vitais de um servidor DNS, logging, zonas, servidores secundários, diretivas de segurança e outros.

Algumas diretivas são, nesta versão, obrigatórias e precisam ser configuradas para que o servidor possa ser inicializado:

  • “$TTL” – Cada arquivo de zona deve conter essa diretiva;

Usado como padrão para todos os registros que não possuem TTL especificado. Deve constar na primeira linha do arquivo de zona.

  • “Serial Number” – O número serial deve ser um valor inteiro (Integer);

Versões anteriores a 9 permitiam usar o números seriais como este: “3.002”.

Ocorreram muitas modificações no arquivo de configuração named.conf. Para saber detalhadamente quais foram as mudança de sintaxe, novas opções e opções que não são mais suportadas, pesquise na documentação distribuída com o BIND:

Para uma melhor explicação do named.conf foi feita uma divisão em seções, onde cada seção trata de um tipo de configuração: opção de configuração, logging, zonas e outras.

As cláusulas que são suportadas pelo BIND

acl – Define uma lista de controle de acesso, os grupos de usuários ou hosts identificados por chaves, que podem ser referenciados em vista e de outras cláusulas ou declarações.

controler – Descreve e controla o acesso ao canal de controle usado pelo administrador remoto ao usar o utilitário rndc.

include – Include pode aparecer em qualquer lugar em um arquivo named.conf, dentro ou fora de uma cláusula. Permite a inclusão de arquivos externos em named.conf por conveniência administrativa ou por motivos de segurança.

key – Define o compartilhamento de chaves usado para controlar e autenticar operações como Dynamic DNS (DDNS) e do canal de controle remoto (a cláusula de controles).

logging –  Configura o local, o nível e o tipo de registro que executa o BIND. A menos que você estiver usando o syslog, você precisa de uma declaração de registro para BIND.

lwres – Define as propriedades do BIND quando executado como um resolvedor leve.

options – Grupos declarações que controlam o comportamento global ou genérica e que têm alcance de todos as zonas.

server – Define as propriedades ou comportamento, se este servidor irá utilizar quando estiver acessando ou para responder a um servidor remoto definido.

trusted-keys – confiança-chaves.

view – Controles funcionalidade BIND e comportamento com base no endereço de host (es).

zone – Define as zonas específicas que o seu servidor de nome irá suportar. Além disso, há uma série de zonas especiais que você pode precisar incluir.

Seção “acl”

Com as ACL’s (Access Control Lists) podemos criar listas de endereços IP’s e designarmos nomes a essas listas, com o único objetivo de quando formos nos referenciar a endereços IP usarmos nomes em vez de números. Algumas acl’s já existem e podem ser usadas:

  • any – Todos os hosts;
  • none – Nenhum host;
  • localhosts – Todos os IP’s das interfaces da máquina;
  • localnets – A rede inteira a qual a máquina faz parte;

Ferramentas úteis

Juntamente com o BIND 9 é distribuído várias ferramentas que ajudam a solucionar problemas de configuração, além de outras já conhecidas.

named-checkconf

Verifica a sintaxe do arquivo de configuração do BIND.

# named-checkconf [arquivo]

named-checkczone

Verifica a sintaxe e consistência dos arquivos de zona.

Sintaxe:

named-checkzone [-dq] [-c class] zona [arquivo]

Exemplo:

# named-checkzone rnp.br rnp.db

Irá verificar se o arquivo de zona “rnp.db” está correto para a zona “rnp.br”.

# apitude instal bind9

O arquivo deconfiguraçã do BIND9 chama-se named.conf, e nas distribuições Red Hat e Suse ele fica exatamente no diretório /etc. No Debian, entretanto, este arquivo foi fragmentado em três. O arquivo principal ainda chama-se named.conf mas contém apenas configurações estáticas. Ele utiliza a cláusula include para anexar os arquivos named.conf.options e named.conf.local. Sendo que desses dois, o primeiro server paa personalozar todas opções referentes ao funcionamento do próprio BIND, enquanto que o segundo serve para declarar todas as zonas pelas quais este servidor deve responder.

O arquivo db.root (/var/named/named.ca no RedHat) relaciona os endereços dos 13 servidores raiz, e é lido como zona hint.
O BIND vai utilizar a porta 53/UDP para receber consultas, a porta 53/TCP para transferir zonas para servidores escravos, a porta 953/TCP para recebe comandos via rndc ( que dependem de chaves criptografadas), e portas udp altas podem ser dinamicamente atribuídas para efetuar consultas em outros servidores.

Observe a recursividade e as portas envolvidas utilizando o tcpdump.

# aptitude install tcpdump

Execute o sniffer tcpdump para verificar os pacotes saindo de uma porta alta até a porta 53/udp.

# tcpdump -i ethX -nv port 53

No terminal digite.

# dig @localhost -t any google.com

Os logs do serviço BIND serão lançados, por padrão, no arquivo /var/log/daemon.log
No caso do CentOS fica em /var/log/messages

# tail /var/log/daemon.log

Servidor cache

As bibliotecas do resolvedor da maioria dos sistemas operacionais não são capazes de executar o processo de resolução completo, chamado recursivo, como vimos acima. Ao invés disso elas dependem de um servidor intermediário com essa capacidade.

Quando nos conectamos de casa diretamente à internet, o serviço DHCP do provedor se encarrega de nos atribuir o endereço de seus servidores cache. Caso contrário, nosso resolver não teria a quem consultar e não conseguiríamos navegar. No entanto, muitos administradores de rede utilizam os IPs dessses provedores para configurar várias estações de trabalho de uma rede. O efeito disto é que cada estação vai fazer suas próprias consultas individuais, multiplicando o volume de dados trafegados através do link de internet, desperdiçando tempo e ocupando largura de banda.

Quanto maior a rede, pior o impacto. A alternativa para evitar estes problemas é manter um servidor DNS caching only. Servidores cache reservam o resultado de suas buscas na memória pelo tempo limite estabelecido pela autoridade sobre o domínio consultado. Dessa forma, independente da quantidade de máquinas da rede, as consultas serão feitas na internet apenas uma vez a cada intervalo de autalização.

1 – O servidor BIND recém instalado já está operando como servidor cache. Para testar:

# dig @localhost -t soa google.com

Observe os dados no rodapé da consulta.
Observe o query time no rodapé da saída dig.

2 – Para que a partir de agora todas nossas aplicações utilizem o potencial de nosso servidor cache, edite o arquivo /etc/resolv.conf e mantenha apenas as linhas a seguir.

# vim /etc/resolv.conf

Restringindo consultas

Um cuidado muito importante que devemos tomar com servidores cache é limitar quem está autorizado a utilizar esse serviço. Por padrão, o nosso BIND está liberado para acesso público, ou seja, se houver uma interface conectada diretamente a Internet, qualquer outro computador no mundo pode mandar nosso servidor procurar um determinado endereço. Ficamos vulneráveis a abusos.

# dig @192.168.0.20 -t txt google.com

Para evitar este comportamento, edite o arquivo /etc/bind/named.conf.options e acrescente a seguinte declaração.

# vim /etc/bind/named.conf.options

allow-tranfer { any; };
allow-query { 127.0.0.1; 192.168.200.20; } ;

A opção allow-transfer indica se eu vou permitir algum outro servidor ser meu slave, ou seja, pegar meus arquivos de zonas, se eu não colocar essa opção, por default será allow-transfer { any; };. Caso eu tenha algum servidor slave eu colocaria o IP dele no lugar do any.

Para carregar as modificações no BIND execute o comando abaixo:

# named-checkconf
# /etc/init.d/bind9 reload

OBS: uma configuração importante que devemos considerar é o fato de apenas permitirmos que máquinas da nossa rede interna, por exemplo, utilizem nosso servidor DNS para fazer consultas na Internet. Desta forma evitamos que qualquer outro usuário da Internet utilize dos nossos recursos de link e máquina para navegar. A configuração é a seguinte:

vim  /etc/bind/named.conf.options

options {
directory “/etc/bind”; # Aqui mudaremos onde o bind9 está instalado, no debian este é o padrão (working directory).
version “N/A”; # Esconde a versão do nosso bind e nos protegermos contra possiveis exploits.

forwarders { # Requisições que não seja internas serão feitas em outro servidor DNS.
XXX.XXX.XXX.XXX; # Servidor DNS para consultas externas.
};

auth-nxdomain yes; # Aqui estamos dizendo que nosso domínio existe, este DNS é autoritativo (o principal da rede).

listen-on { # Escutar os seguintes IPs (interfaces).

127.0.0.1; # IP do servidor DNS interno (lo).
XXX.XXX.XXX.XXX; # IP do servidor DNS interno (ethX).
};

allow-query { # Aceitar consultas provenientes de.
127.0.0.0/8; # Rede localdomain.
XXX.XXX.XXX.XXX/XX; # Rede interna.

};
};

Neste caso, é importante que a classe da rede esteja bem configurada para o servidor DNS, por isso eu recomendo um pacote bem bacana o ipcalc.

# aptitude install ipcalc

Novamente será necessário carregar as modificações no BIND execute o comando abaixo:

# /etc/init.d/bind9 reload

Dessa forma, nosso servidor só responderá para nossa rede interna.

Dica *** Para carregar as modificaçoes nos arquivos confs do BIND execute o comando abaixo:

# rndc reconfig

Repita a experiência em uma outra maquina na rede interna. (não esqueça de  corrigir o arquivo /etc/resolv.conf com o IP do servidor DNS)

# dig @192.168.0.20 -t txt google.com

É possível ser ainda mais econômico em termos de banda se ao invés de executar uma busca recursiva a cada nova consulta, encaminhar a consulta para o servidor disponibilizado pelo provedor.

No nosso caso, isso foi feito na configuração do arquivo named.conf.options na cláusula forwardes com o ip do provedor OPEN-DNS.

# vim /etc/bind/named.conf.options
forwarders { 208.67.220.220; } ;

Veja os logs do nosso servidor DNS

# tail -f /var/log/daemon.log

Feito todo este procedimento, já temos um servidor de DNS simples para consulta da nossa rede interna. O próximo passo será configurar o servidor de zonas, mas isso fica para o post parte 3.

Até

 

>_Dns 1.2
Tagged on:

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

%d blogueiros gostam disto: