Centro de Difusão de Tecnologia e Conhecimento
BIND Berkeley Internet Name System
Eliphas L. G. Siqueira
Conteúdo Introdução ao DNS ....................................................................................................... 3
Instalação............................................................................................................................ 3 DNS para cache .............................................................................................................. 3 DNS autoritativo ............................................................................................................ 3 Definição de zonas para o domínio ......................................................................... 4
Criação dos mapas de zonas ............................................................................................ 4 Criação de mapas de resolução reversa ................................................................ 6 Como testar a configuração ....................................................................................... 7 Teste de mapas de zonas ............................................................................................ 8 Teste final ......................................................................................................................... 8
Introdução ao DNS O DNS (Domain Name System - Sistema de Nomes de Domínios) é um sistema de gerenciamento de nomes hierárquico e distribuído operando segundo duas definições: examinar e atualizar seu banco de dados; resolver nomes de servidores em endereços de rede (IPs). O sistema de distribuição de nomes de domínio foi introduzido em 1984 e com ele os nomes de hosts residentes em um banco de dados puderam ser distribuídos entre servidores múltiplos, baixando assim a carga em qualquer servidor que provê administração no sistema de nomeação de domínios. Ele baseia-se em nomes hierárquicos e permite a inscrição de vários dados digitados além do nome do host e seu IP. Em virtude do banco de dados de DNS ser distribuído, seu tamanho é ilimitado e o desempenho não degrada tanto quando se adiciona mais servidores nele. A implementação do DNS-Berkeley, foi desenvolvido originalmente para o sistema operacional BSD UNIX 4.3. O servidor DNS traduz nomes para os endereços IP e endereços IP para nomes respectivos, e permitindo a localização de hosts em um domínio determinado. Num sistema livre o serviço é implementado pelo software BIND. Esse serviço geralmente se encontra localizado no servidor DNS primário. O servidor DNS secundário é uma espécie de cópia de segurança do servidor DNS primário. Quando não é possível encontrar um domínio através do servidor primário o sistema tenta resolver o nome através do servidor secundário. Existem 13 servidores DNS raiz no mundo todo e sem eles a Internet não funcionaria. Destes, dez estão localizados nos Estados Unidos da América, um na Ásia e dois na Europa. Para Aumentar a base instalada destes servidores, foram criadas réplicas localizadas por todo o mundo, inclusive no Brasil desde 2003. Ou seja, os servidores de diretórios responsáveis por prover informações como nomes e endereços das máquinas são normalmente chamados servidores de nomes. Na Internet, o servidor de nome usado é o DNS, que apresenta uma arquitetura cliente/servidor, podendo envolver vários servidores DNS na resposta a uma consulta.
Instalação A instalação do BIND é feita através do seguinte comando, como superusuário do sistema: #apt-get install bind9
Após a instalação do pacote bind9, o daemon "named" será iniciado e o BIND já entrará em funcionamento. Os arquivos de configuração do servidor de nomes ficam armazenados no diretório /etc/bind e os arquivos de zonas a serem criados deverão ser colocados no diretório /var/cache/bind, de acordo com o valor do parâmetro directory da seção options no arquivo de configuração principal do servidor de nomes BIND, o arquivo /etc/bind/named.conf.
DNS para cache A idéia de um servidor de nomes somente para cache, como o próprio nome sugere, é somente aproveitar o cache da resolução de nomes do servidor. Em um servidor de nomes desse tipo, não é necessário criar mapas de zonas e lidar com nenhum tipo adicional de configuração, uma vez que o pacote bind9 já é iniciado com um funcionamento adequado para atuar como um servidor de nomes somente para cache logo após a sua instalação.
DNS autoritativo Um servidor de nomes autoritativo é um servidor de nomes que possui autoridade para um ou mais domínios e, sendo assim, responde às pesquisas de resolução de nomes para hosts que fazem parte dos domínios em questão. Ao contrário do caso do servidor de nomes somente para cache, a criação de um servidor de nomes autoritativo para um domínio requer
configuração do BIND e, adicionalmente, a criação dos mapas de zonas para resolução comum e reversa para o domínio. Definição de zonas para o domínio
O domínio para o qual desejamos que o BIND responda pesquisas de resolução de nomes deverá ser cadastrado no arquivo de configuração principal do BIND, o arquivo /etc/bind/named.conf , como uma zona, utilizando a seguinte sintaxe: zone "dominio.com.br" { type master; file "db.dominio.com.br"; allow-transfer { 200.1.2.4; }; notify yes; };
O trecho acima declara uma nova zona, de nome dominio.com.br, a qual será utilizada para definir a estrutura do domínio de mesmo nome, ou seja, o dominio.com.br. 1 - O parâmetro type especifica o tipo de servidor de nomes que nossa instalação do BIND será para essa zona específica: master ou slave . Master indica que nosso servidor de nomes será o servidor principal do domínio em questão e slave indica que o servidor de nomes será um servidor escravo, que somente receberá atualizações de mudanças feitas na zona diretamente na configuração do servidor master. 2 - O parâmetro file indica o nome do arquivo onde a zona será definida, relativo ao diretório padrão de mapas e zonas definido pelo parâmetro directory no início do arquivo /etc/bind/named.conf , ou seja, o diretório /var/cache/bind. 3 - O parâmetro allow-transfer especifica os endereços de IP do servidor de nomes que estão autorizados a transferir a zona em questão. É interessante listar, separados por dois pontos, os endereços de IP dos servidores de nomes escravos aqui. 4 - O parâmetro notify especifica se o BIND deverá enviar notificações de mudanças nos dados da zona para seus servidores de nomes escravos. Habilitar esta opção é uma boa idéia, uma vez que, dessa forma, os servidores de nomes escravos serão avisados automaticamente caso mudanças sejam feitas nos mapas de zonas do servidor de nomes principal e iniciarão uma transferência de zona para ficarem com seus mapas de zonas atualizados em relação ao servidor de nomes principal. Criação dos mapas de zonas
Após a definição da zona no arquivo /etc/bind/named.conf , é necessário criar o mapa da zona, ou seja, o arquivo contendo toda a configuração da zona, com o mapeamento entre os endereços IP e nomes de hosts. O arquivo deverá ser criado no diretório /var/cache/bind, com o nome definido no parâmetro file da zona cadastrada no arquivo /etc/bind/named.conf . Tecnicamente, qualquer nome pode ser definido para os arquivos dos mapas de zonas. Vamos adotar um padrão bem conhecido, ficando: db.dominio.com.br, onde dominio.com.br é o domínio gerenciado pela zona em questão. Um exemplo de arquivo de mapa de zona seria: $TTL 43200 $ORIGIN dominio.com.br. @ IN SOA servidor.dominio.com.br. hostmaster.servidor.dominio.com.br. ( 2007010601; serial 3600; refresh 900; retry 1209600; expire 43200; default_ttl ) @ IN MX 5 mx01
@ IN NS ns1 @ IN NS ns2 @ IN A 200.1.2.3 servidor IN A 200.1.2.3 ns1 IN A 200.1.2.3 ns2 IN A 200.1.2.4 mx01 IN A 200.1.2.5 www IN A 200.1.2.6 ftp IN A 200.1.2.7 webmail IN CNAME ns1 pop IN CNAME ns1 smtp IN CNAME ns1
O mapa de zona de exemplo acima, que gerencia o domínio de exemplo dominio.com.br, define diversos registros: 1 - o registro do tipo MX, mx01, define o servidor de e-mails responsável pelas mensagens do domínio dominio.com.br. Porém, o nome desse host é definido mais abaixo, onde ao host com o endereço 200.1.2.5 é atribuído o nome mx01.dominio.com.br . É aconselhável, por motivos de segurança, definir o registro MX da zona apontando para o nome de um registro do tipo A e não para um registro do tipo CNAME; 2 - os registros de exemplo do tipo NS, ns1 e ns2, definem que nossa zona terá dois servidores de nomes que poderão responder com autoridade. Um exemplo é criar um segundo servidor de nomes no host de endereço IP 200.1.2.4 apontando pelo registro NS ns2 e configurá-lo como um servidor de nomes escravo para que o mesmo transfira automaticamente os mapas de zona do domínio de exemplo, dominio.com.br , eliminando a necessidade de criar o mapa de zonas no servidor escravo uma segunda vez; 3 - os registros do tipo A: servidor, ns1, ns2, mx01, www e ftp apenas indicam os nomes de exemplo dos hosts com os endereços IP 200.1.2.3, 200.1.2.4, 200.1.2.5, 200.1.2.6 e 200.1.2.7. ; 4 - os registros de exemplo do tipo CNAME indicam nomes alternativos (apelidos) através dos quais alguns hosts também são conhecidos, como por exemplo, webmail.dominio.com.br, pop.dominio.com.br e smtp.dominio.com.br serem apelidos para o host de nome servidor.dominio.com.br. Em adição, o cabeçalho da zona é formado pelos seguintes elementos: 1 - $TTL Cada registro em uma zona é conhecido também como um RR, ou Registro de Recurso (do inglês Resource Record). Cada RR pode possuir um tempo de vida, definido como um registro inteiro de 32 bits representado em unidades de segundos. Um TTL define um limite de tempo que o registro deve ser mantido em cache. É usado principalmente por resolvers (programas que buscam informações em servidores de nomes em resposta à requisições de clientes) quando os mesmos fazem caches de RRs. Esse tempo de vida é obtido do \$TTL geral da zona na primeira linha do arquivo de zona caso os RRs listados no arquivo de zona não especifiquem cada um seu próprio TTL. 2 - Registro SOA
O registro SOA indica o início de uma zona com autoridade. Esse registro é composto de vários campos, como pode ser visto no exemplo de zona anterior. Segue abaixo o registro SOA do exemplo anterior para melhor vizualização e uma explicação posteri or: @ IN SOA servidor.dominio.com.br. hostmaster.servidor.dominio.com.br. ( 20070106; serial 3600; refresh 900; retry
1209600; expire 43200; default_ttl )
Na primeira linha indicamos, após o nome totalmente qualificado do servidor de nomes, hostmaster.servidor.dominio.com.br que, na verdade, seria o endereço de e-mail (com o símbolo de @ substituído por um ponto) do contato responsável pela zona. Por causa disso é importante existir uma conta de e-mail hostmaster (ou um alias hostmaster apontando para a caixa postal do administrador responsável) que possa ser contactada em caso de problemas relacionados à resolução de nomes em sua zona. Após a abertura dos parênteses, temos cinco campos diferentes. A seguir, uma explicação da utilidade de cada um deles: 1 - Serial
O primeiro campo é conhecido como serial. O campo serial deve conter um número inteiro que deve ser incrementado a cada modificação feita na zona. Quando os servidores de nomes escravos checam a zona em busca de modificações, o campo serial é o campo checado. Se o mesmo possui um valor maior que o valor da cópia que possuem localmente, os servidores de nomes escravos entendem que a zona foi modificada e que uma nova transferência de zona é necessária. Um bom padrão para o serial costuma ser: ANOMESDIAXX, em que XX representa a quantidade de vezes que a zona foi modificada no dia. 2 - Refresh, Retry e Expire
O segundo, terceiro e quarto campos são conhecidos como refresh, retry e expire, respectivamente. Esses campos controlam o período de tempo em que os servidores de nomes secundários irão buscar por informações atualizadas sobre a zona no servidor de nomes principal. Sempre que uma zona é carregada em um servidor secundário, o servidor de nomes secundário espera a quantidade de segundos especificada no campo refresh antes de checar a existência de um novo serial no servidor de nomes principal. Caso a checagem, por qualquer motivo, não possa ser completada, novas checagens serão iniciadas a cada retry segundos. Por exemplo: se o campo retry contém um valor de 3600, novas tentativas de checagem ocorrerão de 1 em 1 hora, pois 3600 segundos equivalem à 1 hora. A checagem é, na verdade, uma simples pesquisa pelo campo SOA da zona no servidor de nomes primário. Caso o campo serial na cópia da zona existente no servidor de nomes secundário esteja igual ao serial da zona existente no servidor de nomes principal,é porque nenhuma mudança ocorreu e a espera pelo intervalo de refresh segundos será reiniciada. Caso o servidor de nomes secundário não consiga executar uma checagem pelo serial do servidor de nomes principal por todo o tempo especificado no campo expire, o mesmo assumirá que sua cópia da zona é obsoleta e a descartará. Criação de mapas de resolução reversa
Em alguns casos, além da criação dos mapas de zonas, é necessária a criação de mapas de resolução reversa, ou seja, mapas que possibilitem que o nome de um host seja encontrado dado o endereço de IP do mesmo. Isso é conseguido através do uso de um domínio especial, o domínio in-addr.arpa, e de registros do tipo PTR no mapa de resolução reversa. Porém, ao contrário dos mapas de zonas, mapas de resolução reversa são criados para uma rede específica e não para um domínio. Sendo assim, apesar de um servidor de nomes poder possuir mapas de zonas de diversos domínios, o mesmo poderá possuir um mapa de resolução reversa somente para a rede (interna ou externa) para a qual o mesmo possui autoridade. As entradas do tipo PTR no domínio in-addr.arpa são feitas especificando somente o último octeto de um endereço IP, relacionando o mesmo ao nome do host correspondente. Um exemplo de mapa de resolução reversa para a rede interna (inválida na internet) de exemplo 192.168.1.0 seria: $TTL 43200
@ IN SOA servidor.dominio.com.br. hostname.servidor.dominio.com.br. 2007010601; serial 3600; refresh 900; retry 1209600; expire 43200; default_ttl ) @ IN NS servidor.dominio.com.br. 3 IN PTR ns1.dominio.com.br. 4 IN PTR ns2.dominio.com.br. 5 IN PTR mx01.dominio.com.br. 6 IN PTR www.dominio.com.br. 7 IN PTR ftp.dominio.com.br.
O mapa de resolução reversa acima é um mapa de exemplo para a rede de exemplo utilizada no exemplo da seção anterior. Assim como no caso do mapa de zonas, o mapa de resolução reversa de nomes de uma rede deve ser definido no arquivo de configuração principal do BIND, em /etc/bind/named.conf. Um exemplo de como o mapa de rede de exemplo que utilizamos pode ser definido é: zone "1.168.192.in-addr.arpa" { type master; file "db.192.168.1"; };
No exemplo acima, podemos ver que a zona especial in-addr.arpa é utilizada. Para definir o mapa reverso de nossa rede de exemplo, informamos essa zona especial, in-addr.arpa, após os três primeiros octetos de nossa rede de exemplo invertidos (ou seja, como nossa rede de exemplo é 192.168.1.0, os três primeiros octetos invertidos são 1.168.192). Como especificamos os octetos que definem a rede junto ao nome da zona para defini-la no arquivo /etc/bind/named.conf , (em nosso caso, os três primeiros octetos) agora precisamos informar somente o último octeto de cada endereço IP para definir um registro do tipo PTR, como pode ser visto acima no arquivo de mapas de resolução reversa para nossa rede de exemplo.
Como testar a configuração É imprescindível que sejam efetuados testes nos arquivos de configuração alterados antes de reiniciar os serviços relacionados. Teste do named.conf
Uma maneira de testar facilmente se a configuração do servidor de nomes está correta é utilizar as ferramentas fornecidas pelo próprio pacote bind9 para esta finalidade. Para testar a validade das configurações feitas no arquivo de configuração principal do servidor de nomes no arquivo /etc/bind/named.conf , utilize a ferramenta de nome namedcheckconf. Essa ferramenta pode ser utilizada da seguinte forma: #named-checkconf /etc/bind/named.conf
Caso nenhum erro seja apresentado, o arquivo de configuração /etc/bind/named.conf estará configurado sintaticamente correto. Caso exista algum erro de sintaxe no arquivo, o mesmo será exibido. Por exemplo, considere o erro a seguir: #named-checkconf /etc/bind/named.conf /etc/bind/named.conf:84:missing ';' before 'zone'
O erro acima indica que o caractere de ponto e vírgula (;) está faltando antes da declaração de uma nova zona, além de indicar em qual linha do arquivo o erro pode ser encontrado. Teste de mapas de zonas
Similarmente ao utilitário named-checkconf , visto na seção anterior, outra ferramenta de grande ajuda na detecção e resolução de problemas relacionados à mapas de zonas é o utilitário de nome named-checkzone, também fornecido junto com o pacote bind9. A maneira correta de utilizá-lo é executando-o da seguinte forma: #named-checkzone
Veja a seguir um exemplo de saída do utilitário named-checkzone verificando a sintaxe do mapa da zona de exemplo domínio.com.br: #named-checkzone dominio.com.br /var/cache/bind/db.dominio.com.br zone dominio.com.br/IN: loaded serial 2007010601 OK
Repare que a saída do comando simula o carregamento da zona dominio.com.br, indica o serial atual da mesma e exibe um sinal de OK caso nenhum erro de sintaxe seja detectado no mapa de zona. Assim como no caso do utilitário named-checkconf , o utilitário named-checkzone auxilia a encontrar problemas em um arquivo de mapa de zonas caso erros de sintaxe sejam encontrados. Teste final
Existem diversas ferramentas dedicadas ao teste de funcionamento de resposta a requisições de resolução de nomes de servidores de nomes. Porém, a ferramenta mais utilizada é o utilitário dig. No Debian, esse utilitário é fornecido pelo pacote dnsutils. Para instalá-lo, utilize o comando a seguir: #apt-get install dnsutils
Após instalado, o utilitário dig pode ser utilizado da seguinte forma: #dig
Onde deve ser substituído pelo tipo de registro do domínio que se deseja pesquisar (por exemplo, o(s) registro(s) NS do domínio) e deve ser substituído pelo próprio nome do domínio. Um exemplo de consulta aos registros NS do domínio cdtc.org.br seria: #dig NS cdtc.org.br ; <<>> DiG 9.3.2 <<>> NS cdtc.org.br ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25907 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITI ONAL: 0 ;; QUESTION SECTION: ;cdtc.org.br. IN NS ;; ANSWER SECTION: cdtc.org.br. 1798 IN NS dns1.cdtc.org.br.
cdtc.org.br. 1798 IN NS dns2.cdtc.org.br. cdtc.org.br. 1798 IN NS dns0.cdtc.org.br. ;; Query time: 92 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Jan 7 21:55:35 2007 ;; MSG SIZE rcvd: 86
Como pode ser visto no exemplo da pesquisa acima, a seção QUESTION SECTION indica que a pesquisa pelo registro NS do domínio cdtc.org.br foi feita. Na seção ANSWER SECTION, podemos ver que as respostas foram 3 registros NS apontando para os hosts dns0.cdtc.org.br , dns1.cdtc.org.br e dns2.cdtc.org.br . Perceba também que algumas informações sobre a pesquisa são exibidas a seguir, como o tempo de pesquisa (92 milisegundos), data e horário da pesquisa e o tamanho da mensagem recebida do servidor de nomes contendo a resposta da pesquisa. Devemos lembrar que, por padrão, o servidor de nomes para o qual a pesquisa será enviada é o servidor de nomes para o qual o sistema operacional onde a pesquisa está sendo feita aponta. Isso pode ser conferido no arquivo /etc/resolv.conf . Para especificar a qual servidor de nomes a requisição de pesquisa deve ser enviada, acrescente um parâmetro adicional à linha de comando que executa o utilitário dig, contendo o caractere @ seguido do endereço IP do servidor de nomes desejado. Um exemplo de pesquisa especificando o servidor de nomes para o qual enviar a requisição de pesquisa seria: #dig NS cdtc.org.br @1.2.3.4
Ou seja, pesquise pelo registro NS do domínio cdtc.org.br no servidor de nomes que possui o endereço IP 1.2.3.4. Além dos testes de registros específicos, outra recomendação é utilizar o ping para testar o funcionamento da resolução de nomes tentando pingar hosts cadastrados na zona.
