Centro de Difusão de Tecnologia e Conhecimento

BIND
Berkeley Internet Name System

Eliphas L. G. Siqueira

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful