Este documento fornece uma introdução aos conceitos básicos de resolução de nomes no DNS, incluindo: 1) Como o DNS mapeia nomes de host para endereços IP; 2) Ferramentas como dig e host para consultar o DNS; 3) Tipos de registros como A, MX, NS e SOA.

1. Configuração DNS com
BIND 9
Carlos N. A. Corrêa
carlos.nilton@gmail.com
http://www.carlosnilton.com.br/
@cnacorrea

2. 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

3. Resolução de nomes de host (2)
• Vários mecanismos para resolução no cliente
• dig
• host
• nslookup
• “stub”

4. 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

5. 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

6. 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

7. 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

8. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. Consultas SOA
• Um registro SOA marca um servidor como
possuidor de autoridade “master” sobre um
domínio
• dig -t soa uol.com.br

19. 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

20. 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)

21. 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

22. 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)

23. 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

24. 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

25. 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

26. 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; };

27. Pra finalizar...
• Caso necessário, adicione dados através dos
arquivos de zona
• Teste!

28. 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

29. 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.

30. 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

31. 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

32. 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)

33. 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

34. Exemplo de lista de acesso
{
192.168.0.1;
192.168.0.;
192.168.1.0/24;
};

35. 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)

36. 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; };

37. 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?

38. 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

39. 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

40. 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

41. Permitindo recursão
• Opção:
• allow-recursion { lista-acesso; };
• O servidor busca as respostas em nome dos
clientes especificados
• Exemplo:
allow-recursion { nossalan; !invasor; };

42. 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

43. Permitindo transferências
• Opção:
• allow-transfer { lista-acesso; };
• Clientes listados podem atuar como servidores
slave
• Exemplo:
allow-transfer { !invasor; nossalan; };

44. 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

45. 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!)

46. 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

47. Declaração de uma zona master
zone “uniriotec.br” {
type master;
file “uniriotec.zone”;
};

48. 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

49. 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!!!

50. 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

51. 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

52. 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

53. 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)

54. 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”)

55. 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

56. Obrigado!!!
Carlos N. A. Corrêa
carlos.nilton@gmail.com
http://www.carlosnilton.com.br/
@cnacorrea