Aula dns
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Aula dns

on

  • 2,159 views

 

Statistics

Views

Total Views
2,159
Views on SlideShare
2,159
Embed Views
0

Actions

Likes
1
Downloads
65
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Aula dns Presentation Transcript

  • 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
  • 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. 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. 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. 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. 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. 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. 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. 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. Consultas SOA• Um registro SOA marca um servidor como possuidor de autoridade “master” sobre um domínio• dig -t soa uol.com.br
  • 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. 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. 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. 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. 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. 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. 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. 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. Pra finalizar...• Caso necessário, adicione dados através dos arquivos de zona• Teste!
  • 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. 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. 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. 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. 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. 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. Exemplo de lista de acesso{ 192.168.0.1; 192.168.0.; 192.168.1.0/24;};
  • 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. 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. 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. 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. 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. 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. 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. 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. Permitindo transferências• Opção: • allow-transfer { lista-acesso; };• Clientes listados podem atuar como servidores slave• Exemplo:allow-transfer { !invasor; nossalan; };
  • 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. 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. 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. Declaração de uma zona masterzone “uniriotec.br” { type master; file “uniriotec.zone”;};
  • 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. 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. 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. 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. 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. 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. 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. 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. Obrigado!!! Carlos N. A. Corrêa carlos.nilton@gmail.comhttp://www.carlosnilton.com.br/ @cnacorrea