DNS Mestre Primari per a una LAN en Debian 6.0 (V) i final

Els que van seguir la 1era2da3era y 4ta part d'aquest article i les consultes fetes a la seva BIND van tornar resultats satisfactoris, ja són experts en el tema. :-) I sense més dilació entrem en l'última part:

  • Creació de l'arxiu de la Zona Principal Mestra de l'tipus "Inversa" 10.168.192.in-addr.arpa
  • Solució de problemes
  • Resum

Creació de l'arxiu de la Zona Principal Mestra de l'tipus "Inversa" 10.168.192.in-addr.arpa

El nom de la zona se les porta, no ?. I és que les Zones Inverses són obligatòries per tenir una resolució de noms correcta d'acord amb les normes d'Internet. No ens queda més remei que crear la corresponent al nostre domini. Per a això fem servir com a plantilla l'arxiu db.127:

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

Editem l'arxiu /var/cache/bind/192.168.10.rev i ho deixem així:

; /var/cache/bind/192.168.10.rev; ; BIND reverse data file for màster zone 10.168.192.in-addr.arpa; Arxius de dades de l'BIND per a la Zona Mestra (Inversa) 10.168.192.in-addr.arpa; $ TTL 604800 @ IN SOA ns.amigos.cu. root.amigos.cu. (2; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800); Negative Cache TTL; @ 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. ; podem escriure també l'adreça IP completa. Ex:; 192.168.10.1 IN PTR gandalf.amigos.cu.
  • Observin com en aquest cas hem deixat els temps en segons tal com es crea per defecte quan s'instal·la el lligar9. Funciona igual. Són els mateixos temps que els indicats a l'arxiu amics.cu.host. Davant el dubte, comproveu.
  • Observin a més que només declarem els registres inversos dels hosts que tenen una IP assignada o "real" en la nostra LAN, i que la identifica de forma unívoca.
  • Recordin actualitzar l'arxiu de la Zona Inversa amb TOTS els adreces IP correctes declarades a la Zona Directa.
  • Recordin incrementar el Nombre de Sèrie de la Zona cada vegada que modifiquin l'arxiu i abans de reiniciar el BIND.

Comprovem la zona acabada de crear:

named-checkzone 10.168.192.in-addr.arpa /var/cache/bind/192.168.10.rev

Comprovem la configuració:

named-checkconf -z named-checkconf -p

Si tot va sortir OK, reiniciem el servei:

service bind9 restart

Pel endavant, cada vegada que modifiquem els arxius de les zones, només hem d'executar:

rndc reload

Per això declarem la clau en /etc/bind/named.conf.options, ¿No?

Solució de problemes

Molt important és el correcte contingut de l'arxiu /etc/resolv.conf com ja vam veure en capítol anterior. Recordin indicar-hi al menys el següent:

search amigos.cu nameserver 192.168.10.20

comando cavar de l'paquet dnsutil. En una consola, escriviu les ordres precedits per #:

# Dig -x 127.0.0.1 ..... ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 604800 IN PTR localhost. .... # dig -x 192.168.10.9 .... ;; ANSWER SECTION: 9.10.168.192.in-addr.arpa. 604800 IN PTR mail.amigos.cu. .... # host Gandalf gandalf.amigos.cu has address 192.168.10.1 # host gandalf.amigos.cu gandalf.amigos.cu has address 192.168.10.1 # dig Gandalf; << >> DiG 9.7.2-P3 << >> Gandalf ;; global options: + cmd ;; connection timed out; no servers could be reached # dig gandalf.amigos.cu .... ;; ANSWER SECTION: gandalf.amigos.cu. 604800 IN A 192.168.10.1 .... Sí tenen sortida a Internet Cubana o Global, i els Forwarders estan correctament declarats provin: # dig debian.org .... ;; QUESTION SECTION:; debian.org. IN A ;; ANSWER SECTION: debian.org. 3600 IN A 86.59.118.148 debian.org. 3600 IN A 128.31.0.51 .... # host bohemia.cu bohemia.cu has address 190.6.81.130 # host yahoo.es yahoo.es has address 77.238.178.122 yahoo.es has address 87.248.120.148 yahoo.es mail is Handled by 10 mx-eu.mail.am0.yahoodns.net. # Dig -x 77.238.178.122 ;; ANSWER SECTION: 122.178.238.77.in-addr.arpa. 429 IN PTR w2.rc.vip.ird.yahoo.com.

... i en general amb altres dominis externs a la nostra LAN. Consulteu i assabenti de coses interessants d'Internet.

Una de les millors formes de comprovar el funcionament d'un servidor lligar9, I en general de qualsevol altre servei instal·lat, és llegint la sortida dels Missatges de Registre de el Sistema mitjançant la comanda cua -f / var / log / syslog executat com l'usuariroot.

És molt interessant veure la sortida d'aquest comando quan li fem una pregunta al nostre BIND local sobre un domini o host extern. En aquest cas se'ns pot presentar diversos escenaris:

  • Sinó tenim accés a Internet nostra consulta serà fallida.
  • Si tenim accés a Internet i NO tenim declarats Forwarders, el més probable és que no obtinguem una resposta.
  • Si tenim accés a Internet i tenim declarats els Forwarders, obtindrem una resposta ja que ells s'encarregaran de consultar a l'o als servidors DNS que siguin necessaris.

Si estem treballant en una LAN Tancada en la qual és impossible de qualsevol forma sortir a l'exterior i no tenim Forwarders de cap tipus, podem eliminar els missatges de recerca dels Servidors Arrels "Buidant" l'arxiu /etc/bind/db.root. Per això primer guardem l'arxiu amb un altre nom i després esborrem tot el seu contingut. Després vam comprovar la configuració i reiniciem el servei:

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

Resum

Fins aquí, col·legues, una petita introducció a el servei DNS. El que hem fet fins ara ens pot servir perfectament per a la nostra petita empresa. També per a la casa si vam crear màquines virtuals amb diferents sistemes operatius i diferents adreces IP, i no volem referir-nos a elles per la IP sinó pel seu nom. Sempre instal un BIND al host de casa meva per instal·lar, configurar i provar serveis que depenen fortament de el servei DNS. Faig ús extensiu de Taules i servidors virtuals, i no m'agrada mantenir un arxiu / Etc / hosts en cadascuna de les màquines. M'equivoco massa.

Si mai han instal·lat i configurat un BIND, si us plau, no d'desanimi si a el primer intent li surt alguna cosa malament i hagi de començar des de zero novament. Recomanem sempre en aquests casos partir d'una instal·lació neta. Val la pena intentar-ho!

Per a aquells que necessitin d'una alta disponibilitat en el servei de resolució de noms, la qual es pot aconseguir mitjançant la configuració d'un servidor Mestre Secundari, recomanem continuïn amb nosaltres en la pròxima aventura: DNS Mestre Secundari per a una LAN.

Felicitats als que van seguir tots els articles i van obtenir els resultats esperats!


11 comentaris, deixa el teu

Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   st0rmt4il va dir

    A la fi! .. el post final: D!

    Gràcies per compartir-amic!

    Salutacions!

  2.   Rafael Hernàndez va dir

    Molt interessant, els teus articles, tinc un DNS autoritatiu muntat en un FreeBSD per a un domini .edu.mx, de moment m'ha funcionat perfecte, però en l'últim mes detecti diversos atacs, cap al servidor, ¿quals serien els mètodes de defensa per un DNS exposat ?, i no sé si es pugui, tenir el màster exposat a internet i un secundari que serveixi a una paqueña len d'uns 60 ordinadors, interconnectat tots dos DNS, o poder definir dues zones una interna i una altra externa, gràcies al màster

  3.   PICCORO va dir

    El paquet bind9 de squeeze té un problema a l'funcionar amb samba, ja està disponible una versió 9.8.4 en la branca backports de squeeze, la versió wheeze no té aquest problema, per lenny venenux.net backportara el paquet.

    Molt bon article.

    Aquest és l'únic article que realitza tot ben explicat ..

    Cal destacar que el acl per spofing no serveix ja que d'igual manera serà injectat des de la xarxa interna, la solucio seria denegar l'redireccions per als clients, i crear una acl complexa que impedeixi reasignacion de noms (una cosa semblant a dns estàtic)

    SUGGERIMENT ESPECIAL:

    seria bo XNUMX config extra de com fer perquè el dns filtrés contingut en lloc de el tallafocs

    1.    Federico Antonio Valdés Toujague va dir

      Gràcies per comentar @PICCORO !!!.
      Declaro a l'inici de tots els meus articles que no em considero un especialista. Molt menys en el tema DNS. Aquí aprenem tots. Tindré en compte les teves recomanacions per quan instal·li un DNS cara a Internet i no per a una LAN normal i senzilla.

  4.   Frank Davila va dir

    EXCEL·LENT TUTORIAL !!! Em va resultar de gran ajuda ja que acabo de iniciar-me en aquest gir de servidors, tot em va funcionar OK. Gràcies i que segueixis publicant tan magnífics estatuts !!!

  5.   Jesús Fenández Toledo va dir

    Fico, de nou torno a felicitar-te per aquest gran material.

    Jo no sóc expert en bind9, perdoneu si m'equivoco pel comentari, però crec que t'ha faltat definir la zona per recerques inverses a l'arxiu named.conf.local

    1.    ILAV va dir

      És una pena que Fico no pugui respondre't a hores d'ara ..

      1.    Federico Antonio Valdés Toujague va dir

        Salutacions i Gràcies, ILAV, i aquí estic responent. Com sempre recomano que llegeixin poc a poc ... 🙂

    2.    Federico Antonio Valdés Toujague va dir

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

      Escric el següent:
      Canvis a l'arxiu /etc/bind/named.conf.local

      En aquest arxiu declarem les zones locals del nostre domini. Hem d'incloure les Zones Directa i Inversa com a mínim. Recordin que a l'arxiu de configuració /etc/bind/named.conf.options declarem en qual directori allotjarem els arxius de les Zones mitjançant la directiva directory. A la fin, l'arxiu ha de quedar de la següent manera:

      // /etc/bind/named.conf.local
      //
      // Do any local configuration here
      //
      // Consider adding the 1918 zones here, if they are not used in your
      // organització
      // include «/etc/bind/zones.rfc1918»;
      // Els noms dels arxius de cada zona, són a
      // gust de consumidor. Vam escollir amigos.cu.hosts
      // i 192.168.10.rev per que ens donen claredat de les seves
      // continguts. No hi ha més misteri 😉
      //
      // Els Noms de les Zones no són arbitraris
      // i correspondran a el nom del nostre domini
      // ia la subnet de la LAN
      // zona principal Mestra: tipus «Directa»
      zone «amics.cu» {
      tipus mestre;
      file «amics.cu.hosts»;
      };
      // zona principal Mestra: tipus «Inversa»
      zone «10.168.192.in-addr.arpa» {
      tipus mestre;
      file «192.168.10.rev»;
      };
      // Fi de l'arxiu named.conf.local

  6.   Fabián Valery va dir

    Bones, molt interessants les teves post sobre dns, m'han ajudat a iniciar-me sobre el tema, gràcies. Aclareixo que sóc novell a l'respecte. Però llegint la seva informació publicada he observat que es treballa amb adreces fixes en els tècnics d'una xarxa interna. La meva inquietud és ¿com es faria amb una xarxa interna amb adreces IP dinàmiques, assignades per un servidor dhcp, per crear els arxius de la zona principal mestra de tipus «directa» i «inversa»?

    Agrairé la llum que vostè pugui donar a l'respecte de la inquietud plantejada. Gràcies. FV

    1.    Federico A. Valdés Toujague va dir

      Gràcies per comentar, @fabian. Pots consultar els següents articles, els quals espere t'ajudin a implementar una xarxa amb adreces dinàmiques:

      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/

      Salutacions