Unidade B - Instalar e configurar servidores DNS

B.2. DNS (Domain Name server)

Sabemos que para encontrarmos um host na rede é necessário referenciar seu endereço IP. Entretanto dificilmente teríamos condições de memorizar os endereços IP de todos os computadores com os quais desejamos nos comunicar. Para facilitar esta tarefa, as redes contam com um serviço de resolução de nomes que permite associar o endereço IP a um nome mais intuitivo. Este serviço entra em ação, por exemplo, quando acessamos uma página web (como o “www.ifsul.edu.br”) ou quando buscamos um computador da rede pelo seu hostname. Em ambos os casos o serviço de resolução se encarrega de traduzir esses nomes para endereços IP, permitindo então que esses hosts sejam acessados.

O serviço de resolução de nomes mais utilizado atualmente é o DNS (Domain Name Server). Trata-se de um sistema de gerenciamento de nomes hierárquico e distribuído baseado numa estrutura de árvore (semelhante à de diretórios) na qual são definidos domínios nivelados hierarquicamente ligados a um nó de raiz, que é representado por um ponto. O diretório raiz possui apontadores para os demais diretórios do nível inferior que, por sua vez, possuem apontamentos para diretórios do nível subjacente e assim sucessivamente. O nome DNS pode ser composto por até 127 níveis e compreende o conjunto de domínios associados ao hostname que se deseja acessar. Esse nome, composto pelo conjunto de nós da arborescência separados por pontos, é conhecido como endereço FQDN ou Fully Qualified Domain Name (adaptando para o português: nome de domínio completo).

Na internet, o endereço FQDN indica os servidores que deverão ser acionados para responder a uma determinada consulta. Na rede mundial, o DNS conta com uma infraestrutura hierárquica, composta por servidores raiz de alto nível, responsáveis por resolver solicitações DNS. A busca pelo endereço IP de um determinado domínio inicia-se pelo servidor raiz, que repassa essa requisição para o servidor de alto nível responsável pelo primeiro domínio indicado no nome informado alocado após a identificação do servidor raiz. Essa indicação, muitas vezes, é subentendida pelos softwares clientes. Vejamos o caso de um navegador web: ao requisitarmos acesso ao endereço “www.ifsul.edu.br” na realidade estamos solicitando a resolução do endereço “ www.ifsul.edu.br.” onde o último ponto da direita (que não precisa ser informado) indica o nível mais alto do nome DNS informado, ou seja, o diretório raiz, onde a busca deve começar. Esse ponto faz menção a um servidor raiz que é o primeiro host consultado nesse processo. Tal servidor possui apontadores para os servidores do nível subjacente (os servidores de alto-nível ou Top Level Domains) responsáveis pela resolução de nomes em domínios geográficos (ar,br,ca,jp,etc) e domínios de uso geral (com, edu, gov, etc).

Os domínios de uso geral identificam a natureza das atividades da organização referenciada pelo servidor DNS de alto-nível. Ao nos referenciarmos a uma entidade que responda pelo domínio “edu” estamos procurando uma instituição de ensino. Os domínios “com” referenciam empresas com fins lucrativos, “gov” órgãos governamentais e assim por diante. Existem servidores de alto nível específicos destinados a resolver solicitações para cada um destes domínios. Com isso, aperfeiçoa-se a carga do banco de dados desses servidores, possibilitando consultas mais rápidas. Os domínios regionais também possuem mais um nível subjacente, em que com o mesmo intuito organizam o seu banco de dados de acordo com o ramo de atividade da instituição cadastrada. Os bancos de dados regionais possuem registros dos servidores DNS autorizativos que respondem pelos domínios destinados às organizações. A figura B 1.2 descreve suscintamente esta infraestrutura:

Voltando ao exemplo, vamos supor que um host queira acessar a página do IFSUL. Ao disparar a sua solicitação, primeiramente será consultado o servidor local, que verificará se esta informação não se encontra na cache do DNS. Caso o servidor não possua esse registro, a requisição é encaminhada para um servidor raiz que, por sua vez, a encaminha para o DNS responsável pelo domínio “br” (no Brasil mantidos pelo Registro.br) que devolverá ao cliente o endereço lógico do servidor DNS autorizativo do IFSUL o qual, quando consultado, devolverá ao servidor local uma resposta definitiva com o IP do servidor que ele deseja acessar repassada ao host que originou a solicitação. A partir desse momento, estabelece-se a conexão entre ambos e o serviço solicitado (neste caso acesso HTTP) passa a ser realizado (Figura B.2.2):

Evidentemente, seria muito custoso para a rede local sempre realizar a resolução de nomes acessando servidores remotos. Por essa razão, podemos configurar para realizarem cache, ou seja, armazenar localmente o resultado de buscas realizadas por clientes de rede. Caso um registro solicitado esteja na cache do servidor local e outra consulta chegar ao mesmo servidor, para o mesmo nome de máquina, o servidor de nomes poderá fornecer o endereço IP desejado, mesmo que não tenha autoridade para esse nome. A cache melhora o desempenho do serviço, diminuindo a demora a consultas e reduzindo as mensagens encaminhada para a internet.

Nos servidores DNS locais também é possível programar domínios internos (válidos somente na rede local), pelos quais os mesmos respondam autoritariamente. Caso o servidor local receba alguma consulta de um cliente sobre um domínio configurado em sua zona local, responderá diretamente ao mesmo sem precisar realizar outros encaminhamentos. Caso contrário, será disparado o processo de consulta já descrito anteriormente.

O Bind por padrão aceita consulta locais a e a outros domínios dos quais não possui autoridade através do recurso de cache. Este é exatamente o comportamento desejado para um servidor DNS local. Entretanto, caso o servidor responda autorizando -o por um domínio válido na internet, por questões de segurança, esse recurso deve ser desabilitado. Consulte mais detalhes neste artigo: http://www.hardware.com.br/tutoriais/servidores-dns_2/pagina3.html

 

 

O Bind por padrão aceita consulta locais a e a outros domínios dos quais não possui autoridade através do recurso de cache. Este é exatamente o comportamento desejado para um servidor DNS local. Entretanto, caso o servidor responda autorizando -o por um domínio válido na internet, por questões de segurança, esse recurso deve ser desabilitado. Consulte mais detalhes neste artigo: http://www.hardware.com.br/tutoriais/servidores-dns_2/pagina3.html

 

Se a quantidade de consultas que o servidor DNS recebe é excessiva e prejudica o seu desempenho, é possível configurar um servidor secundário para auxiliá-lo nessa tarefa. Além de distribuir melhor a carga de trabalho entre os servidores, o servidor secundário pode eventualmente substituir o servidor principal, caso este apresente problemas.

B.2.2. Instalação e configuração do servidor DNS no Debian/Linux

Nesta unidade nos centraremos na implementação de um servidor DNS local, o que nos permitirá compreender como este serviço funciona. O serviço DNS no Debian é exercido pelo software BIND (Berkeley Internet Name Domain). Para instalá-lo utiliza-se o comando:

#apt-get install bind9

Após a instalação, os principais arquivos de configuração são copiados /etc/bind/.  Nesta pasta encontram-se vários arquivos importantes como o db.root que contém informações sobre todos os servidores DNS raiz do mundo e o named.conf que é o arquivo de configuração local. Simplesmente realizando o processo de instalação, já teremos um servidor que realiza a cache DNS plenamente operacional.

Entretanto, se a intenção é configurar um domínio local, devemos realizar ajustes na zona local do servidor. Podemos, então, definir um domínio (ou conjunto de domínios) pelo qual o servidor irá responder. No Debian convencionou-se que a definição dos domínios locais ocorre no arquivo named.conf.local. Além dos domínios também é necessário especificar a zona reversa responsável por realizar o processo inverso, ou seja, a tradução de endereços IP para nomes DNS. Esse recurso é utilizado por diversos serviços de rede (como servidores FTP e de e-mail) para confirmar a identidade dos hosts de rede. O primeiro passo é fazer a declaração de ambos ao final do arquivo indicado. Veja o exemplo:

zone "meudominio"
{
   type master;
   file "/etc/bind/db.meudominio";
};
   zone "1.168.192.in-addr.arpa" {
   type master;
   file "/etc/bind/db.1.168.192";
};

O bloco de comandos zone indica o nome do domínio (entre aspas), o tipo (master) e o arquivo de registros de recursos. Todas as instruções dentro do bloco são encerradas por ponto-e- vírgula (;). O tipo master indica que este será o servidor DNS principal do domínio especificado, não sendo necessário consultar nenhum outro servidor. Se estivéssemos configurando um servidor DNS secundário, deveríamos identificá-lo como escravo (type slave).

A zona reversa deve sempre ser declarada com base no endereço de rede do servidor e lido da direita para a esquerda, ao qual se deve adicionar o sufixo  “.in-addr.arpa” (domínio especial destinado à consulta reversa). A cláusula file, por fim, em ambos os casos, indica os arquivos que contêm as configurações do domínio. Nestes são declaradas as instruções que permitem realizar a resolução de nomes conhecidas como registros de recursos (RR). Os registros de recursos mais comuns são:

Vejamos um exemplo do uso desses registros na configuração de um domínio chamado “minha empresa”. No diretório /etc/bind deve-se criar um novo arquivo:

#gedit db.minhaempresa

E adicionar nele os registros de configuração do domínio. Veja o exemplo:

  1. $TTL 604800
  2. @ IN SOA debian.minhaempresa. root.debian.minhaempresa. (
  3. 1  604800  86400  2419200   604800)
  4. @       IN NS   debian.minhaempresa.
  5. @       IN MX 1 debian.minhaempresa.
  6. @       IN A    192.168.1.10 
  7. debian    IN A 192.168.1.10 
  8. www     IN A 192.168.1.10
  9. mail      IN   A 192.168.1.10
  10. site   CNAME www

A primeira linha $TTL 604800 indica o prazo de validade (o tempo de vida do registro em cache) de cada registro obtido por hosts que realizam consultas a informações a esse domínio. Este valor se aplica a todos os registros do arquivo. Após esse período, (604800 segundos, ou sete dias) os hosts que possuírem informações sobre esse domínio deverão descartá-las.

O registro SOA indica o nome do servidor DNS (debian.minhaempresa.), e-mail do responsável pela zona e cinco campos numéricos utilizados para sincronizar o funcionamento de um servidor DNS primário e um eventual servidor secundário. O primeiro campo contém a versão do arquivo de configuração, o que permite que o servidor secundário identifique quais atualizações foram realizadas na zona. Caso os valores sejam diferentes, o servidor secundário realizará a atualização das suas configurações. Os demais campos contêm informações acerca do comportamento do servidor secundário numa eventual falha do servidor primário. O segundo campo indica por quanto tempo o servidor secundário deve esperar até que o servidor primário volte a funcionar. Caso o servidor permaneça em falha o servidor secundário deve aguardar o tempo especificado no terceiro campo e tentar novamente. O quarto campo indica por quanto tempo o servidor secundário pode responder por requisições no lugar do primário. O último campo indica o tempo mínimo para realizar e para devolver o domínio ao servidor principal, quando este retornar. Mesmo que não exista um servidor, é necessário declarar esses valores.

Também podemos verificar que a partir do registro SOA temos linhas iniciadas pelo símbolo @. Este símbolo referencia o domínio especificado no named.conf.local (neste caso “minhaempresa”). Nessa linha, por exemplo, estamos declarando que o responsável domínio (minhaempresa) na internet (IN) é o host “debian.minhaempresa.” (SOA). O ponto (“.”) Ao final do nome indica que este é o nome exato pelo qual o servidor responde. Na terceira linha “@ IN NS  debian.minhaempresa. “ estamos indicando que o servidor do domínio “minhaempresa” é o host que atende pelo “debian.minhaempresa.”. Na sequência, temos o servidor, o e-mail e a associação do endereço IP ao domínio declarados da mesma forma. O numero “1” após a clausula “MX” (linha 5) indica a hierarquia do servidor de mensagens eletrônicas, nesse caso estamos informando que este é o servidor de e-mail primário.

A partir da sexta linha temos a declaração de nomes relativos que, pela ausência do ponto (“.”), são associadas ao domínio e ao endereço IP indicado. Por exemplo, a linha “www   IN A 192.168.1.10” indica que o nome “www.minhaempresa” refere-se ao endereço IP 192.168.1.10. O registro “mail” se comportará da mesma forma. Na última linha, temos um exemplo de uso do registro CNAME onde se criou um apelido para o nome “www” fazendo com que o servidor DNS também responda pelo nome “site.minhaempresa”.

No exemplo apenas foram criados registros para um servidor, mas também é possível utilizar o mesmo arquivo para criar registros referenciando outros servidores e clientes de rede. Basta adicioná-los ao final do arquivo. Veja o exemplo a seguir, com a declaração de dois hosts: um servidor FTP e um cliente windows:

ftp       IN A 192.168.1.20 
windows   IN A 192.168.1.100

Uma vez que o arquivo de domínio foi criado, é necessário agora criar a zona reversa. O arquivo da zona reversa tem o mesmo formato das utilizadas no arquivo de zona, exceto pelo fato de conter entradas PTR ao invés de A ou CNAME. Também no diretório /etc/bind/ deve-se criar um novo arquivo:

#gedit db.1.168.192

E adicionar neste os registros da zona reversa. Veja o exemplo:

  1. $TTL 604800
  2. @ IN SOA debian.minhaempresa. root.debian.minhaempresa. (
  3. 604800  86400  2419200  604800)
  4. @   IN  NS   debian.minhaempresa.
  5. 10   IN  PTR  debian.minhaempresa.

Na declaração dos ponteiros não é necessário informar o endereço IP completo, mas apenas o valor do octeto destinado à identificação do host, já que o endereço de rede está declarado na zona reversa. No exemplo anterior, a coluna com valor “10” faz menção ao endereço 192.168.1.10 que é o endereço do servidor DNS. Nesse arquivo também devem ser declaradas as informações da zona reversa dos demais hosts da rede como, por exemplo:

20   IN  PTR  ftp.minhaempresa.
100  IN  PTR  windows.minhaempresa.

Para que a checagem do DNS reverso funcione corretamente, é necessário realizar um ajuste no arquivo “/etc/hosts”, devemos adicionar uma entrada indicando o endereço IP do servidor, o seu nome no domínio e seu hostname (o mesmo que está declarado no arquivo/etc/hostname) .Veja o exemplo:

192.168.10 debian.minhaempresa  debian

Finalmente, deve-se configurar o arquivo /etc/resolv.conf, onde se deve indicar o domínio e o servidor responsável pela resolução de nomes neste domínio. Veja o exemplo:

domain minhaempresa
search minhaempresa.com.br
nameserver 192.168.1.10

Após realizar as configurações necessárias nos arquivos da zona, para efetivar as alterações, devemos reiniciar o serviço de DNS:

#invoke-rc.d bind9 restart

Assim como no DHCP os demais serviços de rede, além da opção restart, pode gerenciar o serviço DHCP, através dos comandos: invoke-rc.d bind9 start e invoke-rc. bind9 stop.

Se tudo correr bem, teremos um servidor local respondendo pelo domínio especificado. O servidor deve ser capaz de responder a requisições locais:

#ping www.minhaempresa
Disparando www.minhaempresa[192.168.1.10] com 32 bytes de dados:
Resposta de 192.168.1.10: bytes=32 tempo<1ms TTL=128
Resposta de 192.168.1.10: bytes=32 tempo<1ms TTL=128
Resposta de 192.168.1.10: bytes=32 tempo<1ms TTL=128
Resposta de 192.168.1.10: bytes=32 tempo<1ms

E também encaminhar requisições remotas:

#ping www.ifsul.edu.br

Disparando www.ifsul.edu.br [200.19.252.49] com 32 bytes de dados:
Resposta de 200.19.252.49: bytes=32 tempo 646ms TTL=44
Resposta de 200.19.252.49: bytes=32 tempo 815ms TTL=44
Resposta de 200.19.252.49: bytes=32 tempo 796ms TTL=44
Resposta de 200.19.252.49: bytes=32 tempo 574ms TTL=44

Para se verificar se a zona reversa está correta podemos utilizar o comando dig. Veja o exemplo:

# dig –x 192.168.1.10
;; ANSWER SECTION:
10.1.168.192.in-addr.arpa. IN 86400 IN PTR minhaempresa.

Caso algum desses testes não responda a contento, podemos fazer uso de duas ferramentas que podem diagnosticar problemas: named-checkconf e named-checkzone. Esses utilitários, respectivamente, verificam se há problemas na declaração da zona e no arquivo de registro. Veja os exemplos:

# named-checkconf /etc/ named.conf.local
# named-checkzone /etc/db.minhaempresa