Configuração DNS com          BIND 9        Carlos N. A. Corrêa     carlos.nilton@gmail.com  http://www.carlosnilton.com.b...
Resolução de nomes de host (1)• Alguns serviços de nomes permitem traduzir os  hostnames que usamos em endereços de nível ...
Resolução de nomes de host (2)• Vários mecanismos para resolução no cliente     •   dig     •   host     •   nslookup     ...
O resolvedor “stub” (1)• Biblioteca de resolução disponível para todas as  aplicações     • Chamada através da função geth...
O resolvedor “stub” (2)• Lê o arquivo /etc/nssswitch.conf para  determinar a ordem na qual os serviços de  nomes serão con...
Resolvedor DNS: host• Nunca lê o arquivo /etc/nsswitch.conf• Por default, olha para as linhas nameserver e  search no arqu...
Resolvedor DNS: dig• Nunca lê o arquivo /etc/nsswitch.conf• Por padrão, olha apenas para a linha  nameserver no arquivo /e...
Acompanhar uma consulta DNS (1)• Usamos dig para isso• dig +trace www.ubuntulinux.org     • Lê o arquivo /etc/resolv.conf ...
Acompanhar uma consulta DNS (2)• Observações iniciais     • Os nomes são organizados como uma árvore       invertida, com ...
Outras observações (1)• No teste que fizemos, as respostas seguem o  formato de registros de recurso (resource  records)• ...
Outras observações (2)• Conceitualmente, você faz perguntas por um  domínio (nome), e recebe um campo mapeado  rdata como ...
Pesquisa direta• dig www.whiplash.net    • Tenta consulta recursiva primeiro, conforme      indicado pelo flag rd na saída...
Pesquisa direta: observações• O tipo de pergunta default do dig é A; o campo  rdata para um registro A é um endereço IP• U...
Pesquisa reversa• dig -x 209.132.177.50• Observações    • Na saída da tela, a seção de perguntas mostra que      o DNS inv...
Consulta por servidores de e-mail• Um registro MX mapeia um domínio para o  hostname de um servidor de e-mail• É assim que...
Consultas de e-mail: observações• O campo rdata é estendido para incluir um pedaço a mais  de informação chamado prioridad...
Consultas SOA• Um registro SOA marca um servidor como  possuidor de autoridade “master” sobre um  domínio• dig -t soa uol....
Observações iniciais• Observações iniciais     • O domínio é chamado de origin     • O campo rdata é estendido para suport...
Dados rdata em um registro SOA• FQDN do servidor de nomes master• E-mail do contato• Número serial• Intervalo entre checag...
Possuindo autoridade• O registro SOA meramente indica o servidor  master para a origem (domínio)• O servidor possui autori...
Consultando TUDO• dig -t axfr altavista.com. @8.7.10.9• Observações     • Todos os registros da zona são transferidos     ...
Explorando o DNS com host• Para quaisquer das consultas abaixo, use a  opção -v para obter o resultado no formato de  zona...
Compreendendo o servidor• A imensa maioria das distribuições Linux inclui o  BIND, o Berkeley Internet Name Domain• O serv...
Começando a trabalhar com BIND• Instale os pacotes     • bind9 para os binários essenciais     • bind9-doc para que tenham...
Configuração named essencial• Configure o resolvedor stub• Defina sua configuração em  /etc/named.conf.options e  /etc/bin...
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...
Configurando chroot• O chroot é um conceito existente em sistemas  UNIX-like que envolve “simular”, para um ou mais  progr...
Configurando chroot• O Ubuntu inclui uma funcionalidade chamada  AppArmor, que se propõe a substituir o uso de  chroot com...
Configurando chroot• Uma longa explanação sobre o tema – incluindo  os passos para a configuração de chroot para o  BIND e...
Configurando um servidor de cache• A configuração básica do BIND em sistemas  Ubuntu já deixa tudo pronto, bastando poucas...
Listas de acesso• Listas de IPs e sub-redes separados por “;” e  usados em configurações de segurança do BIND• Formato:   ...
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 v...
Exemplos de ACLsacl   “servweb”      {   192.168.1.21; };acl   “nossalan”     {   192.168.0.0/24; servweb; };acl   “invaso...
ACLs predefinidas• O BIND predefine quatro ACLsnone        -   nenhum endereço casaany         -   qualquer endereço casal...
Interfaces do servidor• Opção     • listen-on port 53 { lista-acesso; };• Liga o named a interfaces específicas• Exemplo:l...
Perguntas...• E se listen-on não incluir 127.0.0.1?• De que forma mudar listen-on-v6 para “::”  (todas as interfaces IPv6)...
Permitindo consultas• Opção: allow-query { lista-acesso; };• O servidor fornece tanto respostas com  autoridade quanto bas...
Permitindo recursão• Opção:     • allow-recursion { lista-acesso; };• O servidor busca as respostas em nome dos  clientes ...
Perguntas sobre recursão• O que acontece se 192.168.1.21 tenta uma  consulta recursiva?• O que acontece se 127.0.0.1 tenta...
Permitindo transferências• Opção:     • allow-transfer { lista-acesso; };• Clientes listados podem atuar como servidores  ...
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...
Declaração de zonas slaveszone “uniriotec.br” {  type slave;  masters { mymasters; };  file “slave/uniriotec.zone”;};(Em s...
Explicando esta história...• Isto informa ao servidor para:     • Agir como um servidor de autoridade para       uniriotec...
Declaração de uma zona masterzone “uniriotec.br” {  type master;  file “uniriotec.zone”;};
Explicando outra história...• Isto informa ao servidor para:     • Agir como um servidor de autoridade para       uniriote...
Criação de arquivos de zona• Conteúdo de um arquivo de zona:     • Uma coleção de registros, começando com SOA     • O sím...
Dicas para arquivos de zona• Não comece do zero – copie um arquivo já  instalado, como o /etc/bind/db.local• Para poupar t...
Testando• Operação    • Selecione dig, host ou nslookup e use-os bem      para verificar a operação de seu servidor de nom...
Tópicos avançados com BIND• Remote Name Daemon Control (rndc)     • Daemon para controle remoto de seu servidor de       n...
rndc• Provê gerenciamento local e remoto do named• O pacote bind9 o configura!     • Ouve apenas nas interfaces loopback (...
Delegando subdomínios• Passos     • No servidor “filho”, crie os arquivos de zona com os       dados do subdomínio     • N...
Split DNS e views• Permitem responder consultas de forma diferente  dependendo de quem pergunta• match-clients e match-des...
Obrigado!!!      Carlos N. A. Corrêa   carlos.nilton@gmail.comhttp://www.carlosnilton.com.br/          @cnacorrea
Aula dns
Próximos SlideShares
Carregando em…5
×

Aula dns

2.588 visualizações

Publicada em

Publicada em: Educação, Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.588
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
86
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Aula dns

  1. 1. Configuração DNS com BIND 9 Carlos N. A. Corrêa carlos.nilton@gmail.com http://www.carlosnilton.com.br/ @cnacorrea
  2. 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. 3. Resolução de nomes de host (2)• Vários mecanismos para resolução no cliente • dig • host • nslookup • “stub”
  4. 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. 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. 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. 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. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. Consultas SOA• Um registro SOA marca um servidor como possuidor de autoridade “master” sobre um domínio• dig -t soa uol.com.br
  18. 18. 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
  19. 19. 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)
  20. 20. 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
  21. 21. 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)
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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; };
  26. 26. Pra finalizar...• Caso necessário, adicione dados através dos arquivos de zona• Teste!
  27. 27. 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
  28. 28. 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.
  29. 29. 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
  30. 30. 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
  31. 31. 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)
  32. 32. 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
  33. 33. Exemplo de lista de acesso{ 192.168.0.1; 192.168.0.; 192.168.1.0/24;};
  34. 34. 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)
  35. 35. Exemplos de ACLsacl “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; };
  36. 36. ACLs predefinidas• O BIND predefine quatro ACLsnone - nenhum endereço casaany - qualquer endereço casalocalhost - qualquer ip do próprio servidorlocalnets - 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?
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. Permitindo recursão• Opção: • allow-recursion { lista-acesso; };• O servidor busca as respostas em nome dos clientes especificados• Exemplo:allow-recursion { nossalan; !invasor; };
  41. 41. 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
  42. 42. Permitindo transferências• Opção: • allow-transfer { lista-acesso; };• Clientes listados podem atuar como servidores slave• Exemplo:allow-transfer { !invasor; nossalan; };
  43. 43. 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
  44. 44. Declaração de zonas slaveszone “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!)
  45. 45. 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
  46. 46. Declaração de uma zona masterzone “uniriotec.br” { type master; file “uniriotec.zone”;};
  47. 47. 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
  48. 48. 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!!!
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. 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)
  53. 53. 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”)
  54. 54. 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
  55. 55. Obrigado!!! Carlos N. A. Corrêa carlos.nilton@gmail.comhttp://www.carlosnilton.com.br/ @cnacorrea

×