Primær Master DNS for et LAN på Debian 6.0 (V) og final

De som fulgte Første2daFørste y 4ta del av denne artikkelen og konsultasjonene til BIND deres ga tilfredsstillende resultater, de er allerede eksperter på emnet. :-) Og uten videre, la oss komme inn i den siste delen:

  • Oppretting av "Invers" -typen Main Master Zone-fil 10.168.192.in-addr.arpa
  • feilsøking
  • Oppsummering

Oppretting av "Invers" -typen Main Master Zone-fil 10.168.192.in-addr.arpa

Navnet på området bringer dem til deg, ikke sant? Og det er at omvendte soner er obligatoriske for å ha riktig navnoppløsning i henhold til internettstandarder. Vi har ikke annet valg enn å lage den som tilsvarer domenet vårt. For dette bruker vi filen som mal /etc/bind/db.127:

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

Vi redigerer filen /var/cache/bind/192.168.10.rev og vi lar det være slik:

; /var/cache/bind/192.168.10.rev; ; BIND omvendt datafil for hovedsone 10.168.192.in-addr.arpa; BIND-datafiler for hovedsone (omvendt) 10.168.192.in-addr.arpa; $ TTL 604800 @ IN SOA ns.amigos.cu. root.amigos.cu. (2; Seriell 604800; Oppdater 86400; Prøv 2419200 på nytt; Utløp 604800); Negativ hurtigbuffer TTL; @ IN NS ns. 10 IN PTR ns.amigos.cu. 1 IN PTR gandalf.amigos.cu. 9 I PTR mail.amigos.cu. 20 IN PTR web.amigos.cu. 100 IN PTR fedex.amigos.cu. ; vi kan også skrive hele IP-adressen. Eks :; 192.168.10.1 I PTR gandalf.amigos.cu.
  • Observer hvordan vi i dette tilfellet har forlatt tidene i sekunder da det er opprettet som standard når bind9. Det fungerer det samme. De er på samme tid som de som er angitt i filen friends.cu.host. Når du er i tvil, sjekk.
  • Vær også oppmerksom på at vi kun deklarerer de omvendte postene til verter som har en tildelt eller "ekte" IP på LAN, og som unikt identifiserer den.
  • Husk å oppdatere Reverse Zone-filen med ALLE riktige IP-adresser oppgitt i Direct Zone.
  • Husk å øke Sone Serienummer hver gang de endrer filen og før du starter BIND på nytt.

La oss sjekke den nyopprettede sonen:

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

Vi sjekker konfigurasjonen:

named-checkconf -z named-checkconf -p

Hvis alt gikk OK, starter vi tjenesten på nytt:

service bind9 start på nytt

Fra nå av må vi bare utføre hver gang vi endrer sonefilene:

rndc laste inn på nytt

For det erklærer vi nøkkelen /etc/bind/named.conf.options, Nei?

feilsøking

Veldig viktig er det riktige innholdet i filen / Etc / resolv.conf som vi så i forrige kapittel. Husk å angi minst følgende i det:

søk amigos.cu nameserver 192.168.10.20

kommando grave av pakken dnsutil. Skriv inn kommandoene foran # på en konsoll:

# dig -x 127.0.0.1 ..... ;; SVAR-DEL: 1.0.0.127.in-addr.arpa. 604800 I PTR lokal vert. .... # dig -x 192.168.10.9 .... ;; SVARSSNITT: 9.10.168.192.in-addr.arpa. 604800 IN PTR mail.amigos.cu. .... # vert gandalf gandalf.amigos.cu har adresse 192.168.10.1 # vert gandalf.amigos.cu gandalf.amigos.cu har adresse 192.168.10.1 # dig gandalf; << >> DiG 9.7.2-P3 << >> gandalf ;; globale alternativer: + cmd ;; tidsavbrudd for tilkobling; ingen servere kunne nås # dig gandalf.amigos.cu .... ;; SVAR-AVSNITT: gandalf.amigos.cu. 604800 IN A 192.168.10.1 .... Hvis de har tilgang til det kubanske eller globale internett, og speditørene er korrekt erklært, prøv: # dig debian.org .... ;; SPØRSMÅL: debian.org. I EN ;; SVAR-AVSNITT: debian.org. 3600 IN A 86.59.118.148 debian.org. 3600 IN A 128.31.0.51 .... # vert bohemia.cu bohemia.cu har adresse 190.6.81.130 # vert yahoo.es yahoo.es har adresse 77.238.178.122 yahoo.es har adresse 87.248.120.148 yahoo.es e-post blir håndtert av 10 mx-eu.mail.am0.yahoodns.net. # dig -x 77.238.178.122 ;; SVAR-DEL: 122.178.238.77.in-addr.arpa. 429 IN PTR w2.rc.vip.ird.yahoo.com.

... Og generelt med andre domener utenfor vårt LAN. Konsulter og finn ut om interessante ting på Internett.

En av de beste måtene å sjekke ytelsen til en server bind9, og generelt av alle andre installerte tjenester, leser utdataene fra Systemloggmeldinger ved hjelp av kommandoen hale -f / var / log / syslog kjøre som brukerroot.

Det er veldig interessant å se utdataene fra den kommandoen når vi stiller vårt lokale BIND et spørsmål om et eksternt domene eller vert. I så fall kan flere scenarier presenteres:

  • Hvis vi ikke har tilgang til Internett, mislykkes spørringen vår.
  • Hvis vi har tilgang til Internett og IKKE har erklært speditører, vil vi mest sannsynlig ikke få svar.
  • Hvis vi har tilgang til Internett og vi har erklært speditørene, vil vi få svar siden de vil ha ansvaret for å konsultere DNS-serveren eller serverne som er nødvendige.

Hvis vi jobber med en LAN Stengt der det på ingen måte er umulig å gå utenfor og vi ikke har speditører av noe slag, kan vi eliminere søkemeldingene til Root-servere "Tømme" filen /etc/bind/db.root. For å gjøre dette lagrer vi først filen med et annet navn og sletter deretter alt innholdet. Deretter sjekker vi konfigurasjonen og starter tjenesten på nytt:

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

Oppsummering

Så langt, folkens, en liten introduksjon til DNS-tjenesten. Det vi har gjort hittil, kan tjene oss perfekt for vår lille bedrift. Også for huset hvis vi lager virtuelle maskiner med forskjellige operativsystemer og forskjellige IP-adresser, og vi ikke vil referere til dem med IP, men etter navn. Jeg installerer alltid en BIND på hjemmeverten for å installere, konfigurere og teste tjenester som er avhengig av DNS-tjenesten. Jeg bruker omfattende skrivebord og virtuelle servere, og jeg liker ikke å lagre en fil / Etc / hosts på hver av maskinene. Jeg tar feil for mye.

Hvis du aldri har installert og konfigurert en BIND, må du ikke motløses hvis noe går galt ved første forsøk, og du må starte på nytt. Vi anbefaler alltid i disse tilfellene å starte med en ren installasjon. Det er verdt et forsøk!

For de som trenger høy tilgjengelighet i navneoppløsningstjenesten, som kan oppnås ved å konfigurere en Secondary Master-server, anbefaler vi at du fortsetter med oss ​​på neste eventyr: Sekundær Master DNS for et LAN.

Gratulerer til de som fulgte alle artiklene og fikk de forventede resultatene!


Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.

  1.   st0rmt4il sa

    Endelig! .. det siste innlegget: D!

    Takk for at du delte vennen min!

    Greetings!

  2.   Raphael Hernandez sa

    Veldig interessant, artiklene dine, jeg har en autoritativ DNS satt opp i en freeBSD for et .edu.mx-domene, så langt har det fungert perfekt for meg, men den siste måneden oppdaget jeg flere angrep mot serveren, hva som ville være forsvarsmetodene for en eksponert DNS?, og jeg vet ikke om det kan være, har mesteren eksponert for internett og en sekundær som serverer en liten lan på rundt 60 datamaskiner, begge DNS-sammenkoblede, eller for å kunne definere to soner, en intern og en ekstern, takk i mesteren

  3.   PICCORUS sa

    Squeeze bind9-pakken har et problem med å arbeide med samba, en versjon 9.8.4 er allerede tilgjengelig i backports-grenen av squeeze, wheeze-versjonen har ikke dette problemet, for lenny venenux.net støtter pakken.

    Veldig bra artikkel.

    Dette er den eneste artikkelen som gjør alt godt forklart ..

    Det skal bemerkes at acl for spofing ikke fungerer, siden på samme måte som det vil bli injisert fra det interne nettverket, vil løsningen være å nekte viderekoblinger for klientene, og lage en kompleks acl som forhindrer omfordeling av navn (noe ligner på statiske dns)

    SPESIELL TIPS:

    Det ville være bra å ha en ekstra konfigurasjon for hvordan du får dns til å filtrere innholdet i stedet for brannmuren

    1.    Federico Antonio Valdes Toujague sa

      Takk for at du kommenterer @PICCORO !!!.
      Jeg erklærer i begynnelsen av alle artiklene mine at jeg ikke anser meg selv som spesialist. Mye mindre på DNS-problemet. Her lærer vi alle. Jeg vil ta hensyn til anbefalingene dine når du installerer en DNS som vender mot Internett og ikke for et vanlig og enkelt LAN.

  4.   Frank davila sa

    UTMERKET veiledning !!! Det var en stor hjelp for meg siden jeg nettopp startet i denne serveren, alt fungerte OK. Takk og fortsett å legge ut slike flotte opplæringer !!!

  5.   Jesus Fenández Toledo sa

    Fico, nok en gang gratulerer jeg deg med dette flotte materialet.

    Jeg er ikke ekspert på BIND9, tilgi meg hvis jeg tar feil om kommentaren, men jeg tror du ikke har definert sonen for omvendte søk i filen named.conf.local

    1.    livlig sa

      Det er synd at Fico ikke kan svare deg akkurat nå.

      1.    Federico Antonio Valdes Toujague sa

        Hilsen og takk, Elav, og her svarer jeg. Som alltid anbefaler jeg at du leser sakte ... 🙂

    2.    Federico Antonio Valdes Toujague sa

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

      Jeg skriver følgende:
      Endringer i /etc/bind/named.conf.local filen

      I denne filen erklærer vi de lokale sonene i domenet vårt. Vi må inkludere Forward og Reverse Zones som et minimum. Husk at i konfigurasjonsfilen /etc/bind/named.conf.options erklærer vi i hvilken katalog vi skal være vert for Zones-filene ved hjelp av katalogdirektivet. Til slutt skal filen være som følger:

      // /etc/bind/named.conf.local
      //
      // Gjør noen lokal konfigurasjon her
      //
      // Vurder å legge til 1918-sonene her, hvis de ikke brukes i din
      // organisasjon
      // inkluderer "/etc/bind/zones.rfc1918";
      // Navnene på filene i hver sone er a
      // forbrukersmak. Vi valgte friends.cu.hosts
      // og 192.168.10.rev fordi de gir oss klarhet i sine
      // innhold. Det er ikke noe mer mysterium 😉
      //
      // Sonenes navn er IKKE ARBITRAR
      // og de vil svare til navnet på domenet vårt
      // og til LAN-nettverket
      // Master Hovedsone: «Direkte» type
      sone «amigos.cu» {
      type master;
      fil "amigos.cu.hosts";
      };
      // Master Main Zone: «Inverse» type
      sone "10.168.192.in-addr.arpa" {
      type master;
      fil "192.168.10.rev";
      };
      // Slutten på named.conf.local-filen

  6.   Fabian Valery sa

    Bra, veldig interessant innlegget ditt om dns, de har hjulpet meg med å komme i gang med temaet, takk. Jeg presiserer at jeg er en nybegynner i denne forbindelse. Men når jeg har lest den publiserte informasjonen, har jeg observert at den fungerer med faste adresser i vertene til et internt nettverk. Spørsmålet mitt er, hvordan ville det blitt gjort med et internt nettverk med dynamiske ip-adresser, tildelt av en dhcp-server, for å lage filene til hovedhovedsonen av typen "direkte" og "invers"?

    Jeg vil være takknemlig for det lyset du kan gi om saken. Takk skal du ha. Fv

    1.    Federico A. Valdes Toujague sa

      Takk for at du kommenterer, @fabian. Du kan se følgende artikler, som jeg håper vil hjelpe deg med å implementere et nettverk med dynamiske adresser:

      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/

      Hilsen