DNS mestre primário para uma LAN em Debian 6.0 (V) e final

Aqueles que seguiram o 2da y 4ta parte deste artigo e as consultas feitas ao seu BIND tiveram resultados satisfatórios, eles já são especialistas no assunto. :-) E sem mais delongas, vamos para a última parte:

  • Criação do arquivo de zona mestre principal tipo “Inverso” 10.168.192.in-addr.arpa
  • Solução de problemas
  • Resumo

Criação do arquivo de zona mestre principal tipo “Inverso” 10.168.192.in-addr.arpa

O nome da área traz para você, certo? E é que as zonas reversas são obrigatórias para ter uma resolução de nome correta de acordo com os padrões da Internet. Não temos escolha a não ser criar aquele que corresponde ao nosso domínio. Para isso usamos como modelo o arquivo /etc/bind/db.127:

cp /etc/bind/db.127 /var/cache/bind/192.168.10.rev

Nós editamos o arquivo /var/cache/bind/192.168.10.rev e deixamos assim:

; /var/cache/bind/192.168.10.rev; ; Arquivo de dados reversos BIND para a zona mestre 10.168.192.in-addr.arpa; Arquivos de dados BIND para Master Zone (Reverse) 10.168.192.in-addr.arpa; $ TTL 604800 @ IN SOA ns.amigos.cu. root.amigos.cu. (2; Serial 604800; Atualizar 86400; Tentar novamente 2419200; Expirar 604800); TTL de cache negativo; @ IN NS ns. 10 IN PTR ns.amigos.cu. 1 IN PTR gandalf.amigos.cu. 9 IN PTR mail.amigos.cu. 20 IN PTR web.amigos.cu. 100 IN PTR fedex.amigos.cu. ; também podemos escrever o endereço IP completo. Ex:; 192.168.10.1 IN PTR gandalf.amigos.cu.
  • Observe como, neste caso, deixamos os tempos em segundos como são criados por padrão quando o vincular9. Funciona da mesma forma. Eles são os mesmos que os indicados no arquivo friends.cu.host. Na dúvida, verifique.
  • Observe também que apenas declaramos os registros reversos de hosts que têm um IP atribuído ou "real" em nossa LAN e que o identifica de maneira única.
  • Lembre-se de atualizar o arquivo Reverse Zone com TODOS os endereços IP corretos declarados na Direct Zone.
  • Lembre-se de aumentar o Número de série da zona toda vez que eles modificam o arquivo e antes de reiniciar o BIND.

Vamos verificar a zona recém-criada:

zona de verificação nomeada 10.168.192.in-addr.arpa /var/cache/bind/192.168.10.rev

Nós verificamos a configuração:

named-checkconf -z named-checkconf -p

Se tudo correr bem, reiniciaremos o serviço:

reiniciar serviço bind9

A partir de agora, toda vez que modificarmos os arquivos de zona, só temos que executar:

recarregar rndc

Para isso, declaramos a chave em /etc/bind/named.conf.optionsNão?

Solução de problemas

Muito importante é o conteúdo correto do arquivo / Etc / resolv.conf como vimos no capítulo anterior. Lembre-se de indicar nele pelo menos o seguinte:

search amigos.cu nameserver 192.168.10.20

Comando cavar do pacote dnsutils. Em um console, digite os comandos precedidos por #:

# dig -x 127.0.0.1 ..... ;; SEÇÃO DE RESPOSTAS: 1.0.0.127.in-addr.arpa. 604800 IN PTR localhost. .... # dig -x 192.168.10.9 .... ;; SEÇÃO DE RESPOSTAS: 9.10.168.192.in-addr.arpa. 604800 IN PTR mail.amigos.cu. .... # host gandalf gandalf.amigos.cu tem o endereço 192.168.10.1 # host gandalf.amigos.cu gandalf.amigos.cu tem o endereço 192.168.10.1 # dig gandalf; << >> DiG 9.7.2-P3 << >> gandalf ;; opções globais: + cmd ;; conexão expirou; nenhum servidor foi encontrado # dig gandalf.amigos.cu .... ;; SEÇÃO DE RESPOSTAS: gandalf.amigos.cu. 604800 IN A 192.168.10.1 .... Se eles têm acesso à Internet cubana ou global, e os encaminhadores estão corretamente declarados tente: # dig debian.org .... ;; SEÇÃO DE PERGUNTAS :; debian.org. EM UM ;; SEÇÃO DE RESPOSTAS: debian.org. 3600 IN A 86.59.118.148 debian.org. 3600 IN A 128.31.0.51 .... # host bohemia.cu bohemia.cu tem o endereço 190.6.81.130 # host yahoo.es yahoo.es tem o endereço 77.238.178.122 yahoo.es tem o endereço 87.248.120.148 yahoo.es e-mail é tratado por 10 mx-eu.mail.am0.yahoodns.net. # dig -x 77.238.178.122 ;; SEÇÃO DE RESPOSTAS: 122.178.238.77.in-addr.arpa. 429 IN PTR w2.rc.vip.ird.yahoo.com.

… E em geral com outros domínios fora de nossa LAN. Consulte e descubra coisas interessantes na Internet.

Uma das melhores maneiras de verificar o desempenho de um servidor vincular9, e em geral de qualquer outro serviço instalado, está lendo a saída do Mensagens de registro do sistema usando o comando tail -f / var / log / syslog correr como usuárioraiz.

É muito interessante ver a saída desse comando quando perguntamos ao nosso BIND local sobre um domínio ou host externo. Nesse caso, vários cenários podem ser apresentados:

  • Se não tivermos acesso à Internet, nossa consulta falhará.
  • Se tivermos acesso à Internet e NÃO tivermos encaminhadores declarados, provavelmente não obteremos uma resposta.
  • Se tivermos acesso à Internet e declararmos os Forwarders, obteremos uma resposta, já que se encarregarão de consultar o servidor ou servidores DNS que sejam necessários.

Se estivermos trabalhando em um LAN fechada em que é impossível de qualquer forma viajar para o exterior e não temos Forwarders de qualquer tipo, podemos eliminar as mensagens de busca do Servidores Raiz "Esvaziando" o arquivo /etc/bind/db.root. Para fazer isso, primeiro salvamos o arquivo com outro nome e depois apagamos todo o seu conteúdo. Em seguida, verificamos a configuração e reiniciamos o serviço:

cp /etc/bind/db.root /etc/bind/db.root.original cp / dev / null /etc/bind/db.root named-checkconf -z named-checkconf -p serviço bind9 restart

Resumo

Até agora, pessoal, uma pequena introdução ao serviço DNS. O que fizemos até agora pode servir-nos perfeitamente para o nosso pequeno negócio. Também para a casa, se criarmos máquinas virtuais com diferentes sistemas operacionais e diferentes endereços IP, e não queremos nos referir a eles pelo IP, mas pelo nome. Sempre instalo um BIND em meu host doméstico para instalar, configurar e testar serviços que dependem muito do serviço DNS. Eu faço uso extensivo de desktops e servidores virtuais, e não gosto de manter um arquivo / Etc / hosts em cada uma das máquinas. Estou muito errado.

Se você nunca instalou e configurou um BIND, não desanime se algo der errado na primeira tentativa e você tiver que começar tudo de novo. Recomendamos sempre, nesses casos, começar com uma instalação limpa. Vale a tentativa!

Para aqueles que precisam de alta disponibilidade no serviço de resolução de nomes, o que pode ser obtido configurando um servidor mestre secundário, recomendamos que você continue conosco na próxima aventura: DNS mestre secundário para uma LAN.

Parabéns a todos que acompanharam todos os artigos e obtiveram os resultados esperados!


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.

  1.   st0rmt4il dito

    Enfim! .. o post final: D!

    Obrigado por compartilhar meu amigo!

    Saudações!

  2.   Rafael Hernandez dito

    Muito interessante, seus artigos, tenho um DNS autorizado configurado em um freeBSD para um domínio .edu.mx, até agora tem funcionado perfeitamente para mim, mas no último mês detectei vários ataques, contra o servidor, o que seria os métodos de defesa para um DNS exposto?, e não sei se pode ser, ter o master exposto na internet e um secundário que atende uma pequena lan de cerca de 60 computadores, ambos DNS interconectados, ou poder definir duas zonas, uma interna e outra externa, obrigado no mestre

  3.   PICCORUS dito

    O pacote squeeze bind9 tem um problema de funcionamento com samba, uma versão 9.8.4 já está disponível no ramo de backports do squeeze, a versão wheeze não tem esse problema, para lenny venenux.net backport do pacote.

    Artigo muito bom.

    Este é o único artigo que faz tudo bem explicado ..

    Deve-se observar que o acl para spofing não funciona, pois da mesma forma que será injetado da rede interna, a solução seria negar os redirecionamentos para os clientes, e criar um acl complexo que evite reatribuição de nomes (algo semelhante ao dns estático)

    DICA ESPECIAL:

    Seria uma boa configuração extra sobre como fazer o conteúdo do filtro de dns em vez do firewall

    1.    Frederico Antonio Valdés Toujague dito

      Obrigado por comentar @PICCORO !!!.
      Declaro no início de todos os meus artigos que não me considero um especialista. Muito menos na questão do DNS. Aqui todos nós aprendemos. Vou levar em consideração suas recomendações ao instalar um DNS voltado para a Internet e não para uma LAN normal e simples.

  4.   Frank davila dito

    EXCELENTE TUTORIAL !!! Foi uma grande ajuda para mim já que comecei neste turno do servidor, tudo funcionou bem. Obrigado e continuem publicando tutoriais tão magníficos !!!

  5.   Jesus Fenández Toledo dito

    Fico, mais uma vez parabenizo você por este ótimo material.

    Não sou um especialista em BIND9, perdoe-me se estou errado sobre o comentário, mas acho que você não definiu a zona para pesquisas reversas no arquivo named.conf.local

    1.    elav. dito

      É uma pena que Fico não possa responder agora.

      1.    Frederico Antonio Valdés Toujague dito

        Saudações e obrigado, Elav, e aqui estou respondendo. Como sempre, recomendo que você leia devagar ... 🙂

    2.    Frederico Antonio Valdés Toujague dito

      Na postagem: https://blog.desdelinux.net/dns-maestro-primario-para-una-lan-en-debian-6-0-iii/

      Eu escrevo o seguinte:
      Modificações no arquivo /etc/bind/named.conf.local

      Neste arquivo, declaramos as zonas locais de nosso domínio. Devemos incluir as zonas de avanço e reverso, no mínimo. Lembre-se de que no arquivo de configuração /etc/bind/named.conf.options nós declaramos em qual diretório hospedaremos os arquivos Zones usando a diretiva de diretório. No final, o arquivo deve ter a seguinte aparência:

      // /etc/bind/named.conf.local
      //
      // Faça qualquer configuração local aqui
      //
      // Considere adicionar as zonas 1918 aqui, se elas não forem usadas em seu
      // organização
      // inclui "/etc/bind/zones.rfc1918";
      // Os nomes dos arquivos em cada zona são um
      // gosto do consumidor. Escolhemos friends.cu.hosts
      // e 192.168.10.rev porque eles nos dão clareza de seus
      // conteúdo. Não há mais mistério 😉
      //
      // Os nomes das zonas NÃO SÃO ARBITRÁRIOS
      // e corresponderá ao nome do nosso domínio
      // e para a sub-rede LAN
      // Zona principal principal: tipo «direto»
      zona «amigos.cu» {
      tipo mestre;
      arquivo "amigos.cu.hosts";
      };
      // Zona principal principal: tipo «inverso»
      zona "10.168.192.in-addr.arpa" {
      tipo mestre;
      arquivo "192.168.10.rev";
      };
      // Fim do arquivo named.conf.local

  6.   Fabian Valery dito

    Bom, muito interessante seu post sobre dns, eles me ajudaram a começar no assunto, obrigado. Esclareço que sou um novato nesse aspecto. Mas lendo suas informações publicadas, observei que funciona com endereços fixos nos hosts de uma rede interna. Minha dúvida é: como você faria com uma rede interna com endereços IP dinâmicos, atribuídos por um servidor dhcp, para criar os arquivos da zona master principal do tipo "direto" e "reverso"?

    Serei grato pela luz que você pode dar sobre o assunto levantado. Obrigado. Fv

    1.    Federico A. Valdés Toujague dito

      Obrigado por comentar, @fabian. Você pode consultar os seguintes artigos, que espero que ajudem a implementar uma rede com endereços dinâmicos:

      https://blog.desdelinux.net/servicio-de-directorio-con-ldap-2-ntp-y-dnsmasq/
      https://blog.desdelinux.net/servicio-de-directorio-con-ldap-3-isc-dhcp-server-y-bind9/

      lembranças