Você está na página 1de 9

Centro de Difusão de Tecnologia e Conhecimento

BIND
Berkeley Internet Name System

Eliphas L. G. Siqueira

.................................................................... 3 Instalação.................................................................................... 4 Criação de mapas de resolução reversa ........... 3 DNS autoritativo ................... 7 Teste de mapas de zonas....................... 4 Criação dos mapas de zonas .................................................................... 6 Como testar a configuração.......................................... 3 Definição de zonas para o domínio ......................................................................................................................................................................................................................... 8 .......... 3 DNS para cache .......................................................................................................................................................................................................................... 8 Teste final...................................................................................................................................................................................................Conteúdo Introdução ao DNS ....................

A implementação do DNS-Berkeley. e permitindo a localização de hosts em um domínio determinado. um na Ásia e dois na Europa.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. DNS para cache A idéia de um servidor de nomes somente para cache. seu tamanho é ilimitado e o desempenho não degrada tanto quando se adiciona mais servidores nele. que apresenta uma arquitetura cliente/servidor. a criação de um servidor de nomes autoritativo para um domínio requer . 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. dez estão localizados nos Estados Unidos da América. o arquivo /etc/bind/named. 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. Na Internet. Existem 13 servidores DNS raiz no mundo todo e sem eles a Internet não funcionaria. Ou seja. é somente aproveitar o cache da resolução de nomes do servidor. como o próprio nome sugere.conf. Em virtude do banco de dados de DNS ser distribuído. Em um servidor de nomes desse tipo. o servidor de nome usado é o DNS. DNS autoritativo Um servidor de nomes autoritativo é um servidor de nomes que possui autoridade para um ou mais domínios e. 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. sendo assim. Num sistema livre o serviço é implementado pelo software BIND. Esse serviço geralmente se encontra localizado no servidor DNS primário.Introdução ao DNS O DNS (Domain Name System . 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. 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 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.3. O servidor DNS traduz nomes para os endereços IP e endereços IP para nomes respectivos. foram criadas réplicas localizadas por todo o mundo. Destes. responde às pesquisas de resolução de nomes para hosts que fazem parte dos domínios em questão. como superusuário do sistema: #apt-get install bind9 Após a instalação do pacote bind9. resolver nomes de servidores em endereços de rede (IPs). 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. baixando assim a carga em qualquer servidor que provê administração no sistema de nomeação de domínios. não é necessário criar mapas de zonas e lidar com nenhum tipo adicional de configuração. Ao contrário do caso do servidor de nomes somente para cache. inclusive no Brasil desde 2003. Para Aumentar a base instalada destes servidores. Instalação A instalação do BIND é feita através do seguinte comando. foi desenvolvido originalmente para o sistema operacional BSD UNIX 4. podendo envolver vários servidores DNS na resposta a uma consulta.

Criação dos mapas de zonas Após a definição da zona no arquivo /etc/bind/named. é necessário criar o mapa da zona. expire 43200. }.com. como uma zona.com. uma vez que.br.com.br.com. 4 .conf.conf. a criação dos mapas de zonas para resolução comum e reversa para o domínio.com. 2 .br" { type master.configuração do BIND e.com.dominio.com. default_ttl ) @ IN MX 5 mx01 . separados por dois pontos. file "db.servidor. É interessante listar. que somente receberá atualizações de mudanças feitas na zona diretamente na configuração do servidor master. relativo ao diretório padrão de mapas e zonas definido pelo parâmetro directory no início do arquivo /etc/bind/named. 3 . 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. utilizando a seguinte sintaxe: zone "dominio. ( 2007010601.1. O trecho acima declara uma nova zona. O arquivo deverá ser criado no diretório /var/cache/bind. o arquivo contendo toda a configuração da zona. os endereços de IP dos servidores de nomes escravos aqui.dominio.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.br.dominio. ou seja.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.com.br é o domínio gerenciado pela zona em questão. Vamos adotar um padrão bem conhecido. ou seja. o dominio. Habilitar esta opção é uma boa idéia. qualquer nome pode ser definido para os arquivos dos mapas de zonas. allow-transfer { 200. refresh 900.conf. dessa forma. a qual será utilizada para definir a estrutura do domínio de mesmo nome.br.2. Um exemplo de arquivo de mapa de zona seria: $TTL 43200 $ORIGIN dominio.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. ficando: db. @ IN SOA servidor. retry 1209600. o diretório /var/cache/bind.O parâmetro file indica o nome do arquivo onde a zona será definida. 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.br. 1 . serial 3600. com o mapeamento entre os endereços IP e nomes de hosts. notify yes.br. adicionalmente.com. onde dominio. }. 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. Tecnicamente.br". o arquivo /etc/bind/named.dominio. hostmaster. com o nome definido no parâmetro file da zona cadastrada no arquivo /etc/bind/named. ou seja. de nome dominio.conf.

Um TTL define um limite de tempo que o registro deve ser mantido em cache.2.br.2. Em adição. Cada RR pode possuir um tempo de vida.os registros de exemplo do tipo NS.br.servidor. hostmaster. ns1.1. Um exemplo é criar um segundo servidor de nomes no host de endereço IP 200.com.o registro do tipo MX.1. retry . como pode ser visto no exemplo de zona anterior. 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. ou Registro de Recurso (do inglês Resource Record). 200. definem que nossa zona terá dois servidores de nomes que poderão responder com autoridade.com. mx01.dominio.2. refresh 900.1. Esse registro é composto de vários campos.Registro SOA O registro SOA indica o início de uma zona com autoridade.5. www e ftp apenas indicam os nomes de exemplo dos hosts com os endereços IP 200.6 ftp IN A 200. É 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.3 ns2 IN A 200. Porém.br. como por exemplo. define o servidor de e-mails responsável pelas mensagens do domínio dominio. É aconselhável.@ IN NS ns1 @ IN NS ns2 @ IN A 200.$TTL Cada registro em uma zona é conhecido também como um RR. mx01.1. que gerencia o domínio de exemplo dominio.3 ns1 IN A 200.com.2. 200. onde ao host com o endereço 200.7.4 mx01 IN A 200.dominio. 2 . por motivos de segurança. 3 . pop.com. .com.com.dominio.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. 2 .br.2. o cabeçalho da zona é formado pelos seguintes elementos: 1 .os registros do tipo A: servidor.br.com.2.6 e 200.5 é atribuído o nome mx01.dominio. definido como um registro inteiro de 32 bits representado em unidades de segundos.com.2.1. define diversos registros: 1 .1.dominio.dominio.1. dominio.1.2.1. 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.dominio.1.br e smtp.2. o nome desse host é definido mais abaixo.2.br serem apelidos para o host de nome servidor.1.4.br.br.7 webmail IN CNAME ns1 pop IN CNAME ns1 smtp IN CNAME ns1 O mapa de zona de exemplo acima.2.2.3 servidor IN A 200.com.1. webmail.3. Segue abaixo o registro SOA do exemplo anterior para melhor vizualização e uma explicação posterior: @ IN SOA servidor.1. ns2.5 www IN A 200.br.com.os registros de exemplo do tipo CNAME indicam nomes alternativos (apelidos) através dos quais alguns hosts também são conhecidos. serial 3600. ns1 e ns2. 4 . eliminando a necessidade de criar o mapa de zonas no servidor escravo uma segunda vez. 200.1.2. ( 20070106.

na verdade. Sempre que uma zona é carregada em um servidor secundário.Serial O primeiro campo é conhecido como serial. respectivamente.1. na verdade. não possa ser completada.1209600. Criação de mapas de resolução reversa Em alguns casos. o mesmo poderá possuir um mapa de resolução reversa somente para a rede (interna ou externa) para a qual o mesmo possui autoridade. por qualquer motivo. terceiro e quarto campos são conhecidos como refresh.br que. Porém.arpa são feitas especificando somente o último octeto de um endereço IP. o campo serial é o campo checado. 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. temos cinco campos diferentes.é porque nenhuma mudança ocorreu e a espera pelo intervalo de refresh segundos será reiniciada. os servidores de nomes escravos entendem que a zona foi modificada e que uma nova transferência de zona é necessária. Após a abertura dos parênteses. Um exemplo de mapa de resolução reversa para a rede interna (inválida na internet) de exemplo 192. retry e expire. O campo serial deve conter um número inteiro que deve ser incrementado a cada modificação feita na 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. mapas de resolução reversa são criados para uma rede específica e não para um domínio.servidor.168. Se o mesmo possui um valor maior que o valor da cópia que possuem localmente.Refresh. Sendo assim. 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. default_ttl ) Na primeira linha indicamos.0 seria: $TTL 43200 . além da criação dos mapas de zonas. relacionando o mesmo ao nome do host correspondente. o mesmo assumirá que sua cópia da zona é obsoleta e a descartará.com. e de registros do tipo PTR no mapa de resolução reversa. Isso é conseguido através do uso de um domínio especial. hostmaster. Retry e Expire O segundo. o domínio in-addr. é necessária a criação de mapas de resolução reversa. Por exemplo: se o campo retry contém um valor de 3600. 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. Quando os servidores de nomes escravos checam a zona em busca de modificações.dominio. uma explicação da utilidade de cada um deles: 1 . em que XX representa a quantidade de vezes que a zona foi modificada no dia. mapas que possibilitem que o nome de um host seja encontrado dado o endereço de IP do mesmo. 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. Um bom padrão para o serial costuma ser: ANOMESDIAXX. Caso a checagem. A checagem é. expire 43200. apesar de um servidor de nomes poder possuir mapas de zonas de diversos domínios. novas checagens serão iniciadas a cada retry segundos. seria o endereço de e-mail (com o símbolo de @ substituído por um ponto) do contato responsável pela zona. 2 . As entradas do tipo PTR no domínio in-addr. pois 3600 segundos equivalem à 1 hora. ao contrário dos mapas de zonas. ou seja. após o nome totalmente qualificado do servidor de nomes. uma simples pesquisa pelo campo SOA da zona no servidor de nomes primário.arpa. A seguir. novas tentativas de checagem ocorrerão de 1 em 1 hora.

1". O mapa de resolução reversa acima é um mapa de exemplo para a rede de exemplo utilizada no exemplo da seção anterior. Caso exista algum erro de sintaxe no arquivo.com.168.168.in-addr.com.dominio. considere o erro a seguir: #named-checkconf /etc/bind/named. os três primeiros octetos) agora precisamos informar somente o último octeto de cada endereço IP para definir um registro do tipo PTR. 3 IN PTR ns1.0. serial 3600. o mesmo será exibido. como pode ser visto acima no arquivo de mapas de resolução reversa para nossa rede de exemplo.com. Teste do named. Como especificamos os octetos que definem a rede junto ao nome da zona para defini-la no arquivo /etc/bind/named. em /etc/bind/named. utilize a ferramenta de nome namedcheckconf.192. Assim como no caso do mapa de zonas. 6 IN PTR www. Para testar a validade das configurações feitas no arquivo de configuração principal do servidor de nomes no arquivo /etc/bind/named.@ IN SOA servidor.1.br.servidor.br.arpa é utilizada.conf:84:missing '. 5 IN PTR mx01.192. No exemplo acima.dominio.conf. 4 IN PTR ns2. }.br.dominio.br.br.arpa" { type master.br. informamos essa zona especial. refresh 900.com.conf estará configurado sintaticamente correto. como nossa rede de exemplo é 192. in-addr. o mapa de resolução reversa de nomes de uma rede deve ser definido no arquivo de configuração principal do BIND.br. após os três primeiros octetos de nossa rede de exemplo invertidos (ou seja.com. file "db. Para definir o mapa reverso de nossa rede de exemplo.dominio.192). hostname.' before 'zone' .com.arpa. default_ttl ) @ IN NS servidor.com. podemos ver que a zona especial in-addr. Como testar a configuração É imprescindível que sejam efetuados testes nos arquivos de configuração alterados antes de reiniciar os serviços relacionados. retry 1209600. (em nosso caso.conf /etc/bind/named.dominio. 2007010601. Por exemplo. os três primeiros octetos invertidos são 1.conf.conf.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. Essa ferramenta pode ser utilizada da seguinte forma: #named-checkconf /etc/bind/named. 7 IN PTR ftp. Um exemplo de como o mapa de rede de exemplo que utilizamos pode ser definido é: zone "1. expire 43200.dominio.br.168.dominio. o arquivo de configuração /etc/bind/named.dominio.conf Caso nenhum erro seja apresentado.168.com.

br.br seria: #dig NS cdtc..dominio. id: 25907 . esse utilitário é fornecido pelo pacote dnsutils.br.org. visto na seção anterior.. ANSWER SECTION: cdtc.br/IN: loaded serial 2007010601 OK Repare que a saída do comando simula o carregamento da zona dominio.com. No Debian.opcode: QUERY.org.com... Got answer: .com. indica o serial atual da mesma e exibe um sinal de OK caso nenhum erro de sintaxe seja detectado no mapa de zona. flags: qr rd ra.3. ANSWER: 3.br . <<>> DiG 9. o utilitário named-checkzone auxilia a encontrar problemas em um arquivo de mapa de zonas caso erros de sintaxe sejam encontrados.org. global options: printcmd . também fornecido junto com o pacote bind9. ADDITIONAL: 0 . . utilize o comando a seguir: #apt-get install dnsutils Após instalado.. 1798 IN NS dns1.br.br. ->>HEADER<<.cdtc. Assim como no caso do utilitário named-checkconf. outra ferramenta de grande ajuda na detecção e resolução de problemas relacionados à mapas de zonas é o utilitário de nome named-checkzone. Para instalá-lo. Um exemplo de consulta aos registros NS do domínio cdtc. AUTHORITY: 0.) está faltando antes da declaração de uma nova zona.com.2 <<>> NS cdtc. Porém.br . QUESTION SECTION: . além de indicar em qual linha do arquivo o erro pode ser encontrado.br /var/cache/bind/db.com. A maneira correta de utilizá-lo é executando-o da seguinte forma: #named-checkzone <nome_da_zona> <arquivo_da_zona> Veja a seguir um exemplo de saída do utilitário named-checkzone verificando a sintaxe do mapa da zona de exemplo domínio.O erro acima indica que o caractere de ponto e vírgula (.org.cdtc..org. a ferramenta mais utilizada é o utilitário dig. status: NOERROR. Teste de mapas de zonas Similarmente ao utilitário named-checkconf.br zone dominio. QUERY: 1. IN NS . o(s) registro(s) NS do domínio) e <domínio> deve ser substituído pelo próprio nome do domínio. o utilitário dig pode ser utilizado da seguinte forma: #dig <tipo_registro> <domínio> Onde <tipo_registro> deve ser substituído pelo tipo de registro do domínio que se deseja pesquisar (por exemplo.org.br: #named-checkzone dominio. Teste final Existem diversas ferramentas dedicadas ao teste de funcionamento de resposta a requisições de resolução de nomes de servidores de nomes.

cdtc. Na seção ANSWER SECTION.org. acrescente um parâmetro adicional à linha de comando que executa o utilitário dig. Perceba também que algumas informações sobre a pesquisa são exibidas a seguir. Um exemplo de pesquisa especificando o servidor de nomes para o qual enviar a requisição de pesquisa seria: #dig NS cdtc. 1798 IN NS dns0. . pesquise pelo registro NS do domínio cdtc.br. Query time: 92 msec .cdtc.org. outra recomendação é utilizar o ping para testar o funcionamento da resolução de nomes tentando pingar hosts cadastrados na zona.br. data e horário da pesquisa e o tamanho da mensagem recebida do servidor de nomes contendo a resposta da pesquisa. contendo o caractere @ seguido do endereço IP do servidor de nomes desejado.. 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.2..org. Para especificar a qual servidor de nomes a requisição de pesquisa deve ser enviada.2.cdtc.org.168.3.1#53(192.org. Devemos lembrar que.br @1. 1798 IN NS dns2.org. .br. podemos ver que as respostas foram 3 registros NS apontando para os hosts dns0..org.br.1) .conf. SERVER: 192.br.org.cdtc. dns1. a seção QUESTION SECTION indica que a pesquisa pelo registro NS do domínio cdtc.3.1..br e dns2. Além dos testes de registros específicos.168.org.br. como o tempo de pesquisa (92 milisegundos).br no servidor de nomes que possui o endereço IP 1. Isso pode ser conferido no arquivo /etc/resolv. cdtc. WHEN: Sun Jan 7 21:55:35 2007 .1.br foi feita.cdtc.4 Ou seja.cdtc.4. por padrão. MSG SIZE rcvd: 86 Como pode ser visto no exemplo da pesquisa acima.org.