É prática comum e recomendada a existência de pelo menos dois servidores de nomes para cada domínio registrado. Isto significa que teremos um outro servidor contendo uma cópia do banco de dados da zona. Essa cópia é feita através de uma transferência de zonas.

Neste contexto, o servidor que envia o banco de dados de uma zona para outros servidores é chamado de master. Os servidores que recebem esta transferência são chamados de slaves. Somente pode haver um servidor master, mas podem haver vários servidores slaves. Qualquer alteração nos arquivos de banco de dados da zona é feito no servidor master. O servidor slave é somente de leitura, pois obtém seus dados a partir do servidor master.

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

1. Indicar ao Bind que ele será autoritativo daquela zona;
2. Configurar o servidor master para permitir transferência de zona para o slave;
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 slave;
        file "db.professor.eti.br";
        allow-transfer {
                none;};
        masters {
                ip_do_seu_servidor_master; };
};

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. Já a opção masters indica ao servidor slave o endereço IP do servidor master, para que ele possa buscar o banco de dados.

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 consiste em configurar o master para permitir transferências para o slave. Para isso, altere a configuração do allow-transfer, para que ele permita tranferências para o slave. A configuração ficaria assim:

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

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

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.