Configuração DNS com

BIND 9
Carlos N. A. Corrêa
carlos.nilton@gmail.com
http://www.carlosnilton.com.br/
@cnacorrea
Resolução de nomes de host (1)

• Alguns serviços de nomes permitem traduzir os

hostnames que usamos em endereços de nível
mais baixo
• Nome  Endereço MAC (camada 2)
• Nome  Endereço IP (camada 3)  End. MAC

• Alguns serviços de nomes comuns

• Arquivos (/etc/hosts e /etc/networks)
• DNS
• NIS
Resolução de nomes de host (2)

• Vários mecanismos para resolução no cliente

• dig
• host
• nslookup
• “stub”
O resolvedor “stub” (1)

• Biblioteca de resolução disponível para todas as

aplicações
• Chamada através da função gethostbyname() e
de outras, providas pela glibc
• Não é capaz de controle de acesso sofisticado,
como assinatura de pacotes e criptografia

• Pode consultar qualquer serviço de nomes

suportado pela glibc
O resolvedor “stub” (2)

• Lê o arquivo /etc/nssswitch.conf para

determinar a ordem na qual os serviços de
nomes serão consultados, conforme exibido aqui
(default):

hosts: files dns

• O nome de domínio NIS e o domínio DNS

geralmente devem ser diferentes, para evitar
conflitos
Resolvedor DNS: host

• Nunca lê o arquivo /etc/nsswitch.conf

• Por default, olha para as linhas nameserver e

search no arquivo /etc/resolv.conf

• Saída mínima por default

Resolvedor DNS: dig

• Nunca lê o arquivo /etc/nsswitch.conf

• Por padrão, olha apenas para a linha

nameserver no arquivo /etc/resolv.conf

• A saída é feita em um formato de arquivo de

zona estipulado por uma RFC, tornando dig uma
ferramenta particularmente útil
Acompanhar uma consulta DNS (1)

• Usamos dig para isso

• dig +trace www.ubuntulinux.org

• Lê o arquivo /etc/resolv.conf para determinar
o servidor DNS
• Procura pelos servidores raízes
• Segue referências para obter cada nível de
resposta
• Cuidado: nosso firewall pode ser restritivo 

• Isto é uma consulta iterativa

Acompanhar uma consulta DNS (2)

• Observações iniciais
• Os nomes são organizados como uma árvore
invertida, com a raiz (.) no topo
• A hierarquia de nomes permite ao DNS cruzar
fronteiras organizacionais
• Nos registros DNS, nomes completamente
qualificados (“inteiros”), terminam com um ponto
Outras observações (1)

• No teste que fizemos, as respostas seguem o

formato de registros de recurso (resource
records)

• Cada RR tem cinco campos:

• domínio – o domínio ou subdomínio perguntado
• ttl – por quantos segundos o registro deve ficar em cache
• classe – a classificação do registro (IN)
• tipo – o tipo de registro, como A ou NS
• rdata – dados de recursos para o qual o domínio aponta
Outras observações (2)

• Conceitualmente, você faz perguntas por um

domínio (nome), e recebe um campo mapeado
rdata como resposta

• No exemplo de trace
• Os registros NS (name server) são referências
• O registro A (address) é a resposta final e o tipo de
consulta default do programa dig
Pesquisa direta

• dig www.whiplash.net
• Tenta consulta recursiva primeiro, conforme
indicado pelo flag rd na saída: se o servidor de
nomes permitir, então ele buscará a resposta e a
retornará para o cliente
• Se o servidor não permitir recursão, então ele
retornará uma referência para o servidor de nomes
raiz, o qual dig tentará consultar
Pesquisa direta: observações

• O tipo de pergunta default do dig é A; o campo

rdata para um registro A é um endereço IP

• Use -t AAAA para obter um rdata IPv6

• Quando bem-sucedido, o dig retorna um status

NOERROR, uma contagem de respostas, e
também indica quais servidores têm autoridade
sobre o nome
Pesquisa reversa

• dig -x 209.132.177.50

• Observações
• Na saída da tela, a seção de perguntas mostra que
o DNS inverte os octetos de um endereço e
acrescenta in-addr.arpa. para qualificar
completamente o registro
• A seção de resposta mostra que o DNS usa
registros do tipo PTR para consulta reversa
• O campo rdata de um registro PTR é um nome de
domínio plenamente qualificado
Consulta por servidores de e-mail

• Um registro MX mapeia um domínio para o

hostname de um servidor de e-mail

• É assim que o e-mail funciona na Internet!

• dig -t mx familiarestart.com
Consultas de e-mail: observações

• O campo rdata é estendido para incluir um pedaço a mais

de informação chamado prioridade

• A prioridade pode ser vista como distância: redes

preferem distâncias mais curtas

• Para evitar consultas desnecessárias, os servidores

tipicamente já fornecem uma resposta adicional a esta
consulta, com o registro A do servidor de e-mail apontado

• Juntos, o registro MX e o registro A permitem a entrega

de e-mails para aquele domínio
Consultas SOA

• Um registro SOA marca um servidor como

possuidor de autoridade “master” sobre um
domínio

• dig -t soa uol.com.br

Observações iniciais

• Observações iniciais
• O domínio é chamado de origin
• O campo rdata é estendido para suportar dados
adicionais, explicados a seguir
• Há tipicamente apenas um master em um domínio;
ele armazena a cópia “oficial” dos dados
• Outros servidores que possuem autoridade para o
domínio ou zona são listados como slaves: eles
sincronizam seus dados a partir do master
Dados rdata em um registro SOA

• FQDN do servidor de nomes master

• E-mail do contato
• Número serial
• Intervalo entre checagens do número serial
• Intervalo entre tentativas para servidores slave
• Expiração dos registros quando um slave não
consegue acessar seu(s) mestre(s)
• TTL mínimo para respostas negativas (host não
encontrado)
Possuindo autoridade

• O registro SOA meramente indica o servidor

master para a origem (domínio)

• O servidor possui autoridade se tem:

• Delegação do domínio pai: registro NS e registro A
• Uma cópia local dos dados do domínio, incluindo o
registro SOA

• Um servidor de nomes que tem a delegação

correta mas não possui os dados de um domínio
é chamado lame server
Consultando TUDO

• dig -t axfr altavista.com. @8.7.10.9

• Observações
• Todos os registros da zona são transferidos
• Os registros informam muito sobre a rede em si
• A resposta é muito grande para UDP; usa-se TCP

• A maioria dos servidores de nomes restringe este

tipo de transferência para apenas alguns hosts
selecionados (normalmente os slaves)
Explorando o DNS com host

• Para quaisquer das consultas abaixo, use a

opção -v para obter o resultado no formato de
zona
• Trace: não disponível
• Delegação: host -rt ns debian.org
• Forçar iterativo: host -r debian.org
• Consulta reversa: host 209.132.177.50
• Consulta MX: host -t mx debian.org
• Consulta SOA: host -t soa debian.org
• Transferências de zona: host -t axfr debian.org \
172.31.0.2 ou
host -t ixfr=<serial> debian.org. \
172.16.99.3
Compreendendo o servidor

• A imensa maioria das distribuições Linux inclui o

BIND, o Berkeley Internet Name Domain

• O servidor DNS mais usado na Internet!

• Uma infraestrutura estável e confiável na qual
basear um nome de domínio e associações de IP
• A implementação de referência para as RFCs de
DNS
• Roda em um ambiente chroot
Começando a trabalhar com BIND

• Instale os pacotes
• bind9 para os binários essenciais
• bind9-doc para que tenhamos a documentação
original instalada
• bind9-host para ter o comando host conforme
vimos aqui

• Um serviço básico será automaticamente

carregado

• Agora podemos prosseguir com a configuração

do named
Configuração named essencial

• Configure o resolvedor stub

• Defina sua configuração em

/etc/named.conf.options e
/etc/bind/named.conf.local
• Declare as listas de acesso
• Especifique as interfaces de servidor: listen-on e
listen-on-v6
• Que consultas devem ser permitidas?
• Iterativas: allow-query { lista-acesso; };
• Recursivas: allow-recursion { lista-acesso; };
• Transferências: allow-transfer { list-acess; };
Pra finalizar...

• Caso necessário, adicione dados através dos

arquivos de zona

• Teste!
Configurando o resolvedor stub

• No servidor de nomes:
• Edite /etc/resolv.conf para especificar
nameserver 127.0.0.1
• Preste atenção caso o arquivo esteja sendo
mantido pelo programa gráfico de gerenciamento de
rede (NetworkManager)! É preciso reconfigurá-lo!

• Vantagens:
• Garante consultas consistentes para todos
• Simplifica os controles de acesso e troubleshooting
Configurando chroot

• O chroot é um conceito existente em sistemas

UNIX-like que envolve “simular”, para um ou mais
programas, que um diretório do sistema é, na
verdade, o diretório raiz

• Esta “simulação” é apoiada pelo próprio kernel.

Desta forma, caso alguém obtenha acesso
malicioso a um dos programas protegidos, terá
acesso a um conjunto mínimo de arquivos – que
não corresponde ao sistema real.
Configurando chroot

• O Ubuntu inclui uma funcionalidade chamada

AppArmor, que se propõe a substituir o uso de
chroot com o BIND

• Apesar da pertinência da proposta, o uso de

chroot é prática estabelecida em várias outras
distribuições Linux

• Também é possível realizar configurações para

que o AppArmor e o chrooting do BIND sejam
compatíveis
Configurando chroot

• Uma longa explanação sobre o tema – incluindo

os passos para a configuração de chroot para o
BIND em sistemas Ubuntu – pode ser obtida em:

https://help.ubuntu.com/community/BIND9ServerHo
wto#Chrooting%20BIND9
Configurando um servidor de cache

• A configuração básica do BIND em sistemas

Ubuntu já deixa tudo pronto, bastando poucas
modificações

• Dicas
• Identifique o(s) servidor(es) DNS atual(is)
• Abra o arquivo /etc/named.conf.options
• Descomente a seção forwarders e substitua
0.0.0.0 pelo endereço de seu(s) servidor(es) DNS
• Salve o arquivo e reinicie o serviço (invoke-rc.d
bind9 restart)
Listas de acesso

• Listas de IPs e sub-redes separados por “;” e

usados em configurações de segurança do BIND

• Formato:
• Endereço IP: 192.168.0.1
• Ponto final: 192.168.0.
• CIDR: 192.168.0.0/24
• Use “!” para denotar inversão

• A lista é checada na ordem, parando na primeira

coincidência
Exemplo de lista de acesso

{
192.168.0.1;
192.168.0.;
192.168.1.0/24;
};
Fazendo as suas listas ACLs

• Podemos dar “nomes” para listas de acesso que

definimos

• Geralmente usamos esses nomes, em vez de

repetir toda uma lista várias vezes. E aninhá-las
também é possível!

• A melhor prática é defini-las logo no início da

configuração (named.conf.local)
Exemplos de ACLs

acl “servweb” { 192.168.1.21; };

acl “nossalan” { 192.168.0.0/24; servweb; };
acl “invasor” { 192.168.1.0/24; };
acl “servmaster” { 192.168.0.254; }
acl “ipslocais” { 127.0.0.1; 192.168.0.1; };
ACLs predefinidas

• O BIND predefine quatro ACLs

none - nenhum endereço casa
any - qualquer endereço casa
localhost - qualquer ip do próprio servidor
localnets - redes diretamente conectadas

• Qual a diferença entre a ACL built-in localhost

e a ACL ipslocais do exemplo anterior,
assumindo que o servidor possui vários
endereços?
Interfaces do servidor

• Opção
• listen-on port 53 { lista-acesso; };
• Liga o named a interfaces específicas

• Exemplo:
listen-on port 53 { myaddresses; };
listen-on-v6 port 53 { ::1; };

• Reinicie e verifique com:

netstat –tulpn | grep named
Perguntas...

• E se listen-on não incluir 127.0.0.1?

• De que forma mudar listen-on-v6 para “::”

(todas as interfaces IPv6) pode afetar a operação
IPv4?

• Default: se listen-on está ausente, o daemon

named ouve em todas as interfaces
Permitindo consultas

• Opção: allow-query { lista-acesso; };

• O servidor fornece tanto respostas com

autoridade quanto baseadas em cache para os
clientes especificados

• Exemplo:
allow-query { nossalan; invasor; };

• Se ausente, todos podem fazer consultas

Permitindo recursão

• Opção:
• allow-recursion { lista-acesso; };

• O servidor busca as respostas em nome dos

clientes especificados

• Exemplo:
allow-recursion { nossalan; !invasor; };
Perguntas sobre recursão

• O que acontece se 192.168.1.21 tenta uma

consulta recursiva?

• O que acontece se 127.0.0.1 tentar uma consulta

recursiva?

• Se allow-recursion estiver ausente, named

também permite recursividade para todos
Permitindo transferências

• Opção:
• allow-transfer { lista-acesso; };

• Clientes listados podem atuar como servidores

slave

• Exemplo:
allow-transfer { !invasor; nossalan; };
Perguntas sobre transferência

• O que acontece se 192.168.1.21 tenta uma

transferência de zona?

• O que acontece se 127.0.0.1 tentar uma

transferência de zona?

• Se allow-transfer estiver ausente, named

também permite transferência de zona para todos
Declaração de zonas slaves

zone “uniriotec.br” {
type slave;
masters { mymasters; };
file “slave/uniriotec.zone”;
};

(Em seguida, crie o diretório

/var/cache/bind/slave, ajuste seu dono
como bind:bind e reinicie o serviço!)
Explicando esta história...

• Isto informa ao servidor para:

• Agir como um servidor de autoridade para
uniriotec.br, onde uniriotec.br é a origem,
conforme especificado no campo domínio do
registro SOA
• Ser um slave para esta zona
• Realizar transferências de zona contra os
servidores na opção masters
• Armazenar os dados transferidos em
/var/cache/bind/slave/uniriotec.zone
Declaração de uma zona master

zone “uniriotec.br” {
type master;
file “uniriotec.zone”;
};
Explicando outra história...

• Isto informa ao servidor para:

• Agir como um servidor de autoridade para
uniriotec.br, onde uniriotec.br é a origem,
conforme especificado no campo domínio do
registro SOA
• Ser um master para esta zona
• Ler os dados da zona a partir de
/var/cache/bind/uniriotec.zone

• Os dados da zona precisam ser criados

manualmente antes desta configuração ser
ativada
Criação de arquivos de zona

• Conteúdo de um arquivo de zona:

• Uma coleção de registros, começando com SOA
• O símbolo @ é uma variável que representa o valor
da origem
• Comentários seguem o estilo assembly (;)

• Cuidados:
• BIND acrescenta o valor de origem a todos os
hostnames que não terminarem com “.”
• Se o campo domínio estiver faltando em um
registro, BIND usa o valor do registro anterior
• Lembre-se de incrementar seu serial!!!
Dicas para arquivos de zona

• Não comece do zero – copie um arquivo já

instalado, como o /etc/bind/db.local

• Para poupar trabalho, coloque $TTL 86400 no

início do arquivo de zona, e omita esta
informação nos registros individuais

• BIND permite que você divida dados

multivalorados em várias linhas, se eles
estiverem entre parênteses
Testando

• Operação
• Selecione dig, host ou nslookup e use-os bem
para verificar a operação de seu servidor de nomes
• Rode tail -f /var/log/daemon.log em um
shell separado quando reiniciar um serviço
Tópicos avançados com BIND

• Remote Name Daemon Control (rndc)

• Daemon para controle remoto de seu servidor de
nomes

• Delegação de subdomínios

• Split DNS e views

rndc

• Provê gerenciamento local e remoto do named

• O pacote bind9 o configura!

• Ouve apenas nas interfaces loopback (v4 e v6)
• Lê a chave a partir de /etc/rndc.key
• Se a chave não casa, não pode parar ou carregar o
serviço named
• Nenhuma configuração adicional é necessária para
uma instalação default local

• Ex.: rndc flush (zera o cache do servidor)

Delegando subdomínios

• Passos
• No servidor “filho”, crie os arquivos de zona com os
dados do subdomínio
• No “pai”, adicione um registro NS
• No “pai”, adicione um registro A para completar a
delegação

• Registros “cola” (glue)

• Se o nome canônico de um filho está no
subdomínio que ele próprio gerencia, o registro A é
chamado de glue record (registro “cola”)
Split DNS e views

• Permitem responder consultas de forma diferente

dependendo de quem pergunta

• match-clients e match-destinations

• Opções e zonas definidas dentro do comando

view

• A existência de um único comando view exige

que TODAS as zonas pertençam a views
 Obrigado!!!
Carlos N. A. Corrêa
carlos.nilton@gmail.com
http://www.carlosnilton.com.br/
@cnacorrea