Para adicionar uma zona master em um servidor Bind, precisamos seguir dois passos principais:

1. Indicar ao Bind que ele será autoritativo daquela zona;
2. Configurar o banco de dados daquela zona;
3. Realizar os testes no servidor configurado;

O primeiro passo é feito editando o arquivo /etc/bind/named.conf.local. Nele deve-se adicionar as informações necessárias para que o Bind consiga reconhecer a zona em questão. Abaixo um exemplo do que deve ser adicionado no named.conf.local para uma zona chamada professor.eti.br

zone "professor.eti.br" {
        type master;
        file "db.professor.eti.br";
        allow-transfer {
                none;
        };
};

No exemplo acima, a opção allow-transfer indica quem tem permissão de transferir informações do banco de dados da zona. Quando se coloca none, o servidor não vai permitir que ninguém transfira nada dele.

Após o término da configuração, pode-se utilizar o comando named-checkconf para verificar a sintaxe do arquivo de configuração. Caso a sintaxe esteja correta, o comando não retornará nenhum erro. Abaixo o exemplo de como executar o comando para verificar o arquivo de configuração.

named-checkconf filename

Para o caso do exemplo desse tutorial, o comando seria:

named-checkconf /etc/bind/named.conf.local

O segundo passo é criar o arquivo db.professor.eti.br dentro da pasta /var/cache/bind. Esse arquivo corresponde ao banco de dados dessa zona. O nome do arquivo é apenas uma sugestão e segue o padrão geralmente utilizado. A única obrigação é que o nome do arquivo seja o mesmo do indicado na diretiva file do arquivo de configuração do Bind.

Abaixo um exemplo de um banco de dados para a zona professor.eti.br. Os únicos RR que são obrigatórios são o SOA e o NS. Os demais RR são colocados de acordo com as necessidades de cada zona. O exemplo está todo comentado, para facilitar o entendimento. Os comentários possuem um ; antes e podem ser retirados quando da criação do arquivos da base de dados no servidor.

$TTL    86400
@          IN      SOA     ns1.professor.eti.br.     tenpontes.gmail.com. (
                                2009112001            ; Serial
                                300                   ; Refresh
                                3600                  ; Retry
                                86400                 ; Expire
                                3600 )                ; Negative Cache TTL
;
@          IN      NS      ns1.professor.eti.br.      ; indica que o host ns1 é servidor DNS da zona em questão
@          IN      NS      ns2.professor.eti.br.      ; indica que o host ns2 é servidor DNS da zona em questão
;
@          IN      MX      10 mail.professor.eti.br.  ; indica que o host mail é servidor e-mail da zona em questão
;
ns1        IN      A       172.18.38.5                ; indica que o host ns1 possui endereço IP 172.18.38.5
ns2        IN      A       172.18.38.6                ; indica que o host ns2 possui endereço IP 172.18.38.6
mail       IN      A       172.18.38.4                ; indica que o host mail possui endereço IP 172.18.38.4
webserver  IN      A       172.18.38.3                ; indica que o host webserver possui endereço IP 172.18.38.3
;                                                       
www        IN      CNAME   webserver                  ; indica que o host www possui o mesmo IP do host webserver
webmail    IN      CNAME   webserver                  ; indica que o host www possui o mesmo IP do host webserver

Após o término da criação da base de dados ou após alguma modificação, pode-se utilizar o comando named-checkzone para verificar a sintaxe e a integridade do arquivo com o banco de dados da zona. Caso a sintaxe e a integridade estejam corretaw, o comando retornará um OK. Abaixo o exemplo de como executar o comando para verificar o banco de dados de uma zona qualquer.

named-checkzone zonename filename

Para o caso do exemplo desse tutorial, onde a zona criada foi professor.eti.br, e o arquivo com o banco de dados é o db.professor.eti.br, o comando seria:

named-checkzone professor.eti.br /var/cache/bind/db.professor.eti.br

Após o término das configurações e sempre que qualquer mudança for feita nos arquivos de configuração do bind, bem como no banco de dados de alguma zona, precisa-se reiniciar o serviço para que as novas configurações entrem em vigor. Para isso utilize o comando abaixo com poderes de root. Caso tudo tenha sido configurado corretamente, o serviço será reiniciado sem mensagens de erro.

/etc/init.d/bind9 restart

Para ter certeza que tudo está funcionando corretamente, deve-se utilizar algum utilitário de teste de funcionamento de resposta à requisições de resolução de nomes de servidores DNS. Existem diversas ferramentas que permitem esse teste, porém, a ferramenta mais utilizada é o utilitário dig.

Após instalado, o utilitário dig pode ser utilizado da seguinte forma:

dig <tipo_registro> <name>

Onde <tipo_registro> deve ser substituído pelo tipo de RR do domínio que se deseja pesquisar (por exemplo, o(s) registro(s) NS do domínio) e <name> deve ser substituído pelo nome do RR. Um exemplo de consulta aos registros NS do domínio utilizado nesse tutorial seria:

dig NS professor.eti.br

O resultado deve ser similiar ao quadro abaixo. Caso seja diferente, o servidor não está funcionando corretamente.

; <<>> DiG 9.7.3-P3 <<>> ns professor.eti.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3849
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;professor.eti.br.			IN	NS

;; ANSWER SECTION:
professor.eti.br.		49107	IN	NS	ns1.professor.eti.br.
professor.eti.br.		49107	IN	NS	ns2.professor.eti.br.

;; Query time: 81 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr  9 02:31:04 2012
;; MSG SIZE  rcvd: 92

Como pode ser visto no exemplo da pesquisa acima, a seção QUESTION SECTION indica que a pesquisa pelo registro NS do domínio 'professor.eti.br.' foi feita. Na seção ANSWER SECTION,podemos ver que as respostas foram 2 registros NS apontando para os hosts ns1.professor.eti.br e ns2.professor.eti.br. Perceba também que algumas informações sobre a pesquisa são exibidas a seguir, como o tempo de pesquisa (81 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 A www.professor.eti.br @localhost

No exemplo acima está sendo perguntando ao servidor localhost, ou seja, a própria máquina, pelo registro do tipo A com nome www.professor.eti.br. A resposta será o endereço IP do host www.professor.eti.br.