Bind versão 9: Procedimento de Instalação e

Configuração
Thiago Alves da Silva <thiago@rnp.br>>
Rede Nacional de Ensino e Pesquisa (RNP)
Resumo
1. Introdução
1.1 Onde encontrar?
1.2 Requisitos
2. Compilação
3. Segurança com chroot
3.1 Criação de usuário e grupo
3.2 Criação da árvore de diretórios e arquivos necessários
3.3 Teste de configuração
4. Configurações do BIND
4.1 Seção "acl"
4.2 Seção "options":
4.3 Seção "server"
4.4 Seção "logging"
4.5 Seção "view":
4.6 Seção "zone":
4.7 Finalização
5. Ferramentas úteis
5.1 named-checkconf
5.2 named-checkczone
6. Dicas úteis
6.1 Escondendo a versão do BIND
6.2 "warning" com o named-checkconf
7. Conclusão
Referências bibliográficas

Resumo
O objetivo deste documento é mostrar quais foram as principais mudanças da versão 9 em relação a
versão 8 do software BIND, bem como a maneira correta de se configurar um servidor levando em
consideração essas mudanças, segurança e desempenho. Esta fora do escopo deste documento a
explanação do serviço DNS, como ele funciona e para que serve.
^

1. Introdução
Muitas foram as melhorias e mudanças nesta nova versão do BIND, entre elas podemos citar:
• Suporte a IPv6;
• DNSSEC e TSIG (Funções de segurança);
• Suporte a hardware com multiprocessadores;
• Dynamic update para uso em redes DHCP;
• Novos tipos de registros (RR – Resource Record);
• IXFR – Transferência de zonas incremental;
• Views (Permite várias visualizações do espaço de nomes);
 • Etc.
^

1.1 Onde encontrar?

O software BIND se encontra na versão 9.1.2.
Código fonte: ftp://ftp.isc.org/isc/bind9/9.1.2/bind-9.1.2.tar.gz
Assinatura PGP do código fonte: ftp://ftp.isc.org/isc/bind9/9.1.2/bind-9.1.2.tar.gz.asc
Chave Pública PGP do ISC: http://www.isc.org/ISC/isckey.txt
^

1.2 Requisitos
O código fonte do software já inclui os fontes do pacote de bibliotecas criptográficas OpenSSL
necessários para as funções de segurança disponíveis (DNSSEC e TSIG), mas para uma melhor
performance das operações de criptografia é indicado que o pacote seja instalado separadamente e
configurado através da opção do autoconf:
#./configure --with-openssl=PATH
Site oficial OpenSSL - www.openssl.org
^

2. Compilação
A plataforma utilizada foi SPARCStation 20 com sistema operacional SUN Solaris 8 e NetFinity
3500 com sistema operacional OpenBSD 2.8. A lista de sistemas compatíveis esta em:
http://www.isc.org/products/BIND/bind9.html.
Após baixar o arquivo e descomprimi-lo vem a tarefa de compilação. Existem várias opções que
podem ser usadas para compilar o BIND 9.1.2, para maiores informações, consulte:
$ ./configure --help
Iremos usar as seguintes opções:
$./configure --with-openssl=/usr/ssl --sysconfdir=/etc
$ make
$ su root
Importante: Antes de instalar os binários e bibliotecas recomendamos realizar o backup de todos os
arquivos relacionados ao BIND que se encontram na máquina.Isso é um texto simulado, indicando
o tratamento do texto.
• named.conf
• Diretório do BIND. Ex.: /usr/local/bind
• Binários: named, ndc, named-xfer, dig e outros.
# make install
^

3. Segurança com chroot

Para tornar seu sistema mais seguro contra possíveis invasões o ideal é fazer com que o daemon do
BIND rode em um ambiente protegido, mais conhecido como "in jail", e também como um usuário
não privilegiado..
A seguir estão os passos que devem ser tomados para a criação desse ambiente seguro:
^

3.1 Criação de usuário e grupo

Crie o usuário que será usado e o grupo ao qual ele pertencerá.
Nesse exemplo usaremos o usuário "named" e grupo "named".
^

3.2 Criação da árvore de diretórios e arquivos necessários

É importante lembrar que as modificações citadas abaixo não se referem aos arquivos principais do
sistema, deve-se apenas usá-los como base ou partir do zero. O que queremos dizer é que não se
deve mexer, por exemplo, no "/etc/passwd".
Os arquivos e diretórios devem ser criados sob o diretório que será designado raiz, em nosso
exemplo "/var/named".
dev/:
null
Para criar esse arquivo especial use o comando "mknod":
Exemplo:
# mknod null c x y
onde "x" e "y" são o "minor number " e o "major number", respectivamente.
Dica: Para descobrir os valores corretos de "x" e "y", faça:
# ls -l /dev/null
os valores serão listados no lugar do tamanho do arquivo.
etc/ : passwd (somente com root e named e senha igual a '*')
group (somente com sys e named)

shadow ou master.passwd (Somente com root e named e senha igual a `*´.)

named.conf
resolv.conf
localtime (link simbólico para o arquivo de `time zone´)

usr/ :
lib/ - Devem ser colocadas nesse diretório todas as bibliotecas usadas pelo
binário `named´.

share/zoneinfo/Brazil/East (Arquivo de `time zone´ usado)

Dica: Para descobrir as bibliotecas use o comando "ldd":

# ldd named
Resultado:
named lcrypto.2 => /usr/lib/libcrypto.so.2.4 (0x40182000)
lc_r.3 => /usr/lib/libc_r.so.3.1 (0x4022b000)
^
3.3 Teste de configuração
Com a configuração já feita precisamos testar se tudo está perfeito, para isso vamos executar o
comando "chroot":
# chroot /var/named /usr/local/sbin/named -u named -g
Esse comando irá executar o daemon do BIND "enjaulado", como usuário "named" e no modo de
depuração. A partir disso pode se constatar erros e realizar os acertos necessários.
Durante os testes alguns erros surgiram:
"No ld.so" – significa que a biblioteca "ld.so" esta faltando no diretório dentro do ambiente seguro,
ou seja, em /var/named/usr/lib ou /var/named/usr/libexec, dependo do sistema operacional;
"User 'named' unknown" – Em sistemas BSD é necessário que o arquivo master.passwd também
esteja no diretório "etc/", e mais, que o comando "pwd_mkdb" seja executado para a criação dos
arquivos de contas do sistema:
# pwd_mkdb -d /var/named/etc /var/named/etc/master.passwd
^

4. Configurações do BIND
Com os arquivos instalados vem o momento da configuração de várias diretivas do software. O
arquivo de configuração é o named.conf e deve ser criado no diretório especificado no momento da
compilação (--sysconfdir=DIR), no nosso caso "/etc".
Neste exemplo que segue iremos mostrar as configurações vitais de um servidor DNS, logging,
zonas, servidores secundários, diretivas de segurança e outros.
Algumas diretivas são, nesta versão, obrigatórias e precisam ser configuradas para que o servidor
possa ser inicializado:
• "$TTL" – Cada arquivo de zona deve conter essa diretiva;
Usado como padrão para todos os registros que não possuem TTL especificado. Deve constar na
primeira linha do arquivo de zona.
• "Serial Number" – O número serial deve ser um valor inteiro (Integer);
Versões anteriores a 9 permitiam usar o números seriais como este: "3.002".
Ocorreram muitas modificações no arquivo de configuração named.conf. Para saber detalhadamente
quais foram as mudança de sintaxe, novas opções e opções que não são mais suportadas, pesquise
na documentação distribuída com o BIND:
Caminho relativo: "doc/misc/options" ou em "doc/arm"
Para uma melhor explicação do named.conf foi feita uma divisão em seções, onde cada seção trata
de um tipo de configuração: opção de configuração, logging, zonas e outras.
^

4.1 Seção "acl"

Com as ACL's (Access Control Lists) podemos criar listas de endereços IP's e designarmos nomes a
essas listas, com o único objetivo de quando formos nos referenciar a endereços IP usarmos nomes
em vez de números. Algumas acl's já existem e podem ser usadas:
• any – Todos os hosts;
• none – Nenhum host;
 • localhosts – Todos os IP's das interfaces da máquina;
• localnets – A rede inteira a qual a máquina faz parte;
Outros exemplos:
acl intranet {
200.1.2.0/24;
200.1.3.0/24;
};

acl slaves {
200.4.5.6/32;
200.5.6.7/32;
};

4.2 Seção "options":

^

4.3 Seção "server"

Master - Deve ser configurado no servidor primário:
server 200.2.1.1 {
provide-ixfr yes;
transfer-format ( many-answers );
};

Slave - Deve ser configurado no servidor secundário:

server 200.2.1.2 {

request-ixfr yes;

};

A transferência de zona incremental (IXFR) tem como finalidade diminuir a quantidade de

informações trocadas, transferindo somente as mudanças feitas nas zonas do servidor primário para
o servidor secundário.
Com essa configuração estamos dizendo que o servidor primário fornecerá esse recurso de
transferência e o servidor secundário sempre que possível utilizará. Quando, por algum motivo, o
servidor primário recusar uma IXFR, uma AXFR, transferência de zona convencional, será
realizada.
^

4.4 Seção "logging"

Registro das mensagens do BIND. É importante saber que somente entrará em vigor as opções de
logging depois que todo o arquivo named.conf for lido e o servidor for inicializado, antes disso as
mensagens de erro serão enviadas para o sistema de syslog.
logging {
channel "named_log" {
syslog local3;
severity info;
};
category "security" {
"named_log";
};

category "xfer-out" {
"named_log";
};

category "xfer-in" {
"named_log";
};

category "general" {
"named_log";
};

O registro de logs no BIND 9 é divido da seguinte forma:

• "channel" – usado para especificar onde e que tipo de informação deve ser registrada –
níveis (error, info, dynamic, etc). Nele você pode configurar o BIND tanto para usar o
syslog, como um arquivo qualquer. No nosso exemplo utilizamos a categoria "local3" do
syslog.
• "category" – categorias de log do BIND. Existem várias categorias que podem ser usadas,
tais como: security, xfer-out, notify, xfer-in, network, etc. Como os próprios nomes dizem,
em security – informações de segurança, em notify – notificações de mudança na zonas
primárias, etc.
Diante disso especificamos como queremos registrar (channel) e o que queremos registar
(category): erros, informações de depuração, etc.
Alguns problemas foram detectados e reportados ao time de desenvolvedores do BIND, mas até a
data da publicação desse tutorial não havíamos obtido respostas. Um dos problemas diz respeito ao
modo como o novo BIND registra os eventos, por exemplo, a categoria "xfer-out" deveria registrar
as transferência de zona que são enviadas pelo servidor, mas isso não acontece, só conseguimos
registrar tais eventos com o nível de log igual a "severity debug 6", em "channel". Isso se torna
inviável visto que muitas outras informações também são registradas, informações desnecessárias.
Outra questão importante diz respeito ao conteúdo que é registrado. Somente informações
superficiais são registradas. Por exemplo, se alguém tentar realizar uma transferência de zona,
somente a mensagem "< IP#Porta > zone transfer denied" irá ser registrada. O nome da zona não
constará nos logs. Novamente, só conseguiremos tal feito se utilizarmos nível de depuração igual a
6.
Em nosso exemplo usamos o nível "info" para podermos registrar as informações das categorias
segurança, transferências de zona e "general" – informações que não estão classificadas em
nenhuma das outras categorias disponíveis. Fica a critério do administrador o modo de log do
BIND.
Como também, pretendemos utilizar o BIND em um ambiente seguro, não poderíamos mais contar
com o syslogd, pois não teríamos mais o socket unix "/dev/log" que é usado para receber as
entradas de log.
Isso pode ser contornado utilizando versões recentes do syslogd, onde um outro socket para
recebimento de informações pode ser utilizado na sua inicialização. Com a opção "-a" ou "-l",
dependendo da plataforma, você especifica onde se localiza o socket adicional:
# syslogd -a /var/named/dev
Outra forma seria fazer com que o BIND registre os logs em arquivos, mas ficaríamos
impossibilitados de usar um servidor de logs (loghost).
^

4.5 Seção "view":

Com essa nova opção de configuração pode-se fazer hoje o que antes era necessário com dois ou
mais servidores DNS.
A idéia principal por detrás desta nova opção é permitir que possa ser configurado o que se conhece
como "split DNS", ou seja, separar em dois ou mais servidores DNS os registros que podem ser
acessados por toda Internet e os que somente são de interesse da empresa. Isso é usado
principalmente em redes "desmilitarizadas", onde o servidor que se encontra na DMZ, de acesso
publico, contém somente os registros dos hosts "visíveis" na Internet e o interno, com os registros
da rede interna.
Bastante útil, também, em sites que implementam NAT.
Com a configuração abaixo ficará mais claro o entendimento deste novo recurso.
view "public" IN {
match-clients { any; };
zone-statistics yes;
recursion no;
zone "rnp.br" {
type master;
file "rnp-externo.br";
};
};

view "private" IN {
match-clients { 200.1.2.0/24; };
zone-statistics yes;
recursion yes;
zone "rnp.br" {
type master;
file "rnp-interno.db";
};
};

Neste exemplo, a zona "rnp-externo.db" contém o mapeamento dos hosts públicos e pode ser
acessada por todos. Já a zona "rnp-interno.db" somente é acessada pelos hosts internos, ou seja,
todos da rede 200.1.2.0.
Se nenhuma "view" for especificada, o BIND tratará, por default, as zonas como sendo da classe IN
(Internet). Esse fato é importante, pois voltaremos a falar sobre isso na seção de "Dica útil".
Dentro das "views" são especificadas a configuração das zonas primárias e secundárias.
^

4.6 Seção "zone":

Configuração das zonas as quais o servidor responderá. Nela se configura as zonas primárias,
secundárias, reversos e outros tipos. Também deve constar nessa configuração a zona "." do tipo
"hint", raiz da Internet.
zone "." {
type hint;
File "named.root";
};

zone "0.0.127.in-addr.arpa" {
type master;
 file "127.0.0.db";
};

zone "1.2.200.in-addr.arpa" {
type master;
file "200.2.1.db";
};

zone "rnp.br" {
type master;
file "rnp.br";
};

4.7 Finalização
Após a configuração deste arquivo, criação dos arquivos de zona, inclusive os de reverso, é
necessário que se obtenha a versão mais atual do arquivo (named.root) que contém o nome dos
servidores de mais alto nível, responsáveis pelo domínio raiz (".").
Para tal visite:
ftp://rs.internic.net/domain
Com o ambiente seguro e o arquivo de configuração criados, edite os arquivos de inicialização do
sistema para que o daemon possa ser inicializado, acrescentando a seguinte linha:
# named -t /var/named -u named
Parâmetros usados
-t - indica qual será a raiz do ambiente seguro;
-u - roda o daemon do BIND como o usuário especificado.
^

5. Ferramentas úteis
Juntamente com o BIND 9 é distribuído várias ferramentas que ajudam a solucionar problemas de
configuração, além de outras já conhecidas.
^

5.1 named-checkconf
Verifica a sintaxe do arquivo de configuração do BIND.
# named-checkconf [arquivo]
^

5.2 named-checkczone
Verifica a sintaxe e consistência dos arquivos de zona.
Sintaxe:
named-checkzone [-dq] [-c class] zona [arquivo]
Exemplo:
# named-checkzone rnp.br rnp.db
Irá verificar se o arquivo de zona "rnp.db" está correto para a zona "rnp.br".
^

6. Dicas úteis

6.1 Escondendo a versão do BIND

A maneira mais simples de ocultar aos olhos dos outros a versão do seu sistema é incluindo em
options a cláusula version:
version "Not Available";
Mas para podermos ir além disso e registrar as consultas à versão devemos criar uma zona especial
que conterá a seguinte configuração:
view "version" CHAOS {
match-clients { any; };
recursion no;
zone "." {
type hint;
file "/dev/null";
};
zone "bind" chaos {
allow-query { localhost; };
type master;
"file bind.db";
};
};

Como vimos anteriormente, o BIND tratará todas as zonas como pertencendo a uma única "view",
se essa não for especificada, de classe IN. Para que possamos então inserir uma zona de classe
diferente, CHAOS, precisamos criar uma "view" própria, e foi o que fizemos. Além disso, a zona
"." é obrigatória para todas as "views". Após configurar uma "view" é necessário que todas as
outras zonas também façam parte de uma.
^

6.2 "warning" com o named-checkconf

Após executar o comando "named-checkconf" o seguinte aviso é emitido:
"the default for the 'auth-nxdomain' option is now 'no'".
Nesta versão a opção auth-nxdomain é por default desligada, para evitar essa mensagem de aviso
acrescente esta linha na seção "options" do named.conf:
auth-nxdomain no;
^

7. Conclusão
Algumas funcionalidades não foram abordadas neste documento que visou principalmente a
migração da versão 8 para a 9 do software BIND, principais diferenças, aspectos de segurança e
melhorias.
Entre essas funcionalidades estão as que trazem mais segurança ao serviço de DNS (DNSSEC e
TSIG) e suporte a IPv6. Com toda a certeza depois que essas funcionalidades tiverem sido testadas
um outro documento será produzido.
Com os problemas referentes aos logs esperamos que os desenvolvedores do BIND possam corrigi-
los, pois as informações de transferência de zonas e consultas recusadas são fundamentais para
auditorias. Caso alguém não tenha paciência para esperar, o fonte esta a disposição para ser
alterado.
^

Referências bibliográficas
[1] Documentação fornecida com o software ; Em bind-9.x.x/doc/.
[2] Site oficial: http://www.isc.org/products/BIND
[3] Topics for System Administration, 1 - What's New in BIND9 – LISA 2000; Evi Nemeth –
University of Colorado;CAIDA – San Diego Supercomputer Center, UC San Diego;
[4] Chroot-BIND HOWTO; http://www.losurs.org/docs/howto/Chroot-BIND.html Scott Wunsch,
scott at wunsch.org;
^
NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004