Primär Master DNS för ett LAN på Debian 6.0 (V) och final

De som följde 1: a2da3: a y 4ta en del av den här artikeln och samråden med deras BIND gav tillfredsställande resultat, de är redan experter på ämnet. :-) Och utan vidare, låt oss gå in i den sista delen:

  • Skapande av filen för huvudhuvudzonen av typen ”invers” 10.168.192.in-addr.arpa
  • Felsökning
  • Sammanfattning

Skapande av filen för huvudhuvudzonen av typen ”invers” 10.168.192.in-addr.arpa

Namnet på området tar dem till dig, eller hur? Och det är att Reverse Zones är obligatoriska för att ha rätt namnupplösning enligt Internetstandarder. Vi har inget annat val än att skapa den som motsvarar vår domän. För detta använder vi filen som en mall /etc/bind/db.127:

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

Vi redigerar filen /var/cache/bind/192.168.10.rev och vi lämnar det så här:

; /var/cache/bind/192.168.10.rev; ; BIND-omvänd datafil för huvudzon 10.168.192.in-addr.arpa; BIND-datafiler för huvudzon (omvänd) 10.168.192.in-addr.arpa; $ TTL 604800 @ IN SOA ns.amigos.cu. root.amigos.cu. (2; Seriell 604800; Uppdatera 86400; Försök igen 2419200; Förfalla 604800); Negativ cache 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 också skriva hela IP-adressen. Ex:; 192.168.10.1 I PTR gandalf.amigos.cu.
  • Observera hur vi i det här fallet har lämnat tiderna i sekunder eftersom de skapas som standard när binda9. Det fungerar på samma sätt. De är samma tider som de som anges i filen vänner.cu.host. Om du är osäker, kontrollera.
  • Observera också att vi endast deklarerar de omvända posterna för värdar som har en tilldelad eller "riktig" IP på vårt LAN och som identifierar den unikt.
  • Kom ihåg att uppdatera Reverse Zone-filen med ALLA rätt IP-adresser som anges i Direct Zone.
  • Kom ihåg att öka Zons serienummer varje gång de ändrar filen och innan BIND startas om.

Låt oss kontrollera den nyligen skapade zonen:

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

Vi kontrollerar konfigurationen:

namngiven-checkconf -z namngiven-checkconf -p

Om allt gick bra startar vi om tjänsten:

service bind9 starta om

Från och med nu måste vi bara köra varje gång vi ändrar zonfilerna:

rndc ladda om

För det deklarerar vi nyckeln /etc/bind/named.conf.options, Nej?

Felsökning

Mycket viktigt är rätt innehåll i filen / Etc / resolv.conf som vi såg i föregående kapitel. Kom ihåg att ange åtminstone följande:

sök friends.cu nameserver 192.168.10.20

kommandot gräva av paketet dnsutils. Skriv kommandona före # på en konsol:

# dig -x 127.0.0.1 ..... ;; SVAR-AVSNITT: 1.0.0.127.in-addr.arpa. 604800 IN PTR localhost. .... # dig -x 192.168.10.9 .... ;; SVAR-AVSNITT: 9.10.168.192.in-addr.arpa. 604800 IN PTR mail.amigos.cu. .... # värd gandalf gandalf.amigos.cu har adress 192.168.10.1 # värd gandalf.amigos.cu gandalf.amigos.cu har adress 192.168.10.1 # dig gandalf; << >> DiG 9.7.2-P3 << >> gandalf ;; globala alternativ: + cmd ;; timeout för anslutning; inga servrar kunde nås # dig gandalf.amigos.cu .... ;; SVAR-AVSNITT: gandalf.amigos.cu. 604800 IN A 192.168.10.1 .... Om de har tillgång till det kubanska eller globala Internet och speditörerna förklaras korrekt försök: # dig debian.org .... ;; FRÅGA AVSNITT :; debian.org. I EN ;; SVAR-AVSNITT: debian.org. 3600 IN A 86.59.118.148 debian.org. 3600 IN A 128.31.0.51 .... # värd bohemia.cu bohemia.cu har adress 190.6.81.130 # värd yahoo.es yahoo.es har adress 77.238.178.122 yahoo.es har adress 87.248.120.148 yahoo.es post hanteras av 10 mx-eu.mail.am0.yahoodns.net. # dig -x 77.238.178.122 ;; SVAR-AVSNITT: 122.178.238.77.in-addr.arpa. 429 IN PTR w2.rc.vip.ird.yahoo.com.

... Och i allmänhet med andra domäner utanför vårt LAN. Konsultera och ta reda på intressanta saker på Internet.

Ett av de bästa sätten att kontrollera prestandan på en server binda9, och i allmänhet av alla andra installerade tjänster, läser utdata från Systemloggmeddelanden med kommandot svans -f / var / log / syslog kör som användarerot.

Det är väldigt intressant att se resultatet av det kommandot när vi frågar vår lokala BIND om en domän eller extern värd. I så fall kan flera scenarier presenteras:

  • Om vi ​​inte har tillgång till Internet misslyckas vår fråga.
  • Om vi ​​har tillgång till Internet och vi INTE har förklarat speditörer kommer vi troligen inte att få svar.
  • Om vi ​​har tillgång till Internet och vi har deklarerat vidarebefordrarna, kommer vi att få ett svar eftersom de kommer att ansvara för DNS-servern eller de servrar som är nödvändiga.

Om vi ​​arbetar på en LAN stängt där det på något sätt är omöjligt att gå ut och vi inte har speditörer av något slag, kan vi eliminera sökmeddelandena från Rootservrar "Tömma" filen /etc/bind/db.root. För att göra detta sparar vi först filen med ett annat namn och raderar sedan allt innehåll. Sedan kontrollerar vi konfigurationen och startar om tjänsten:

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

Sammanfattning

Hittills, folkens, en liten introduktion till DNS-tjänsten. Det vi hittills har gjort kan tjäna oss perfekt för vårt lilla företag. Också för huset om vi skapar virtuella maskiner med olika operativsystem och olika IP-adresser, och vi vill inte hänvisa till dem med IP utan efter namn. Jag installerar alltid en BIND på min hemvärd för att installera, konfigurera och testa tjänster som är starkt beroende av DNS-tjänst. Jag använder omfattande skrivbord och virtuella servrar, och jag gillar inte att hålla en fil / Etc / hosts i var och en av maskinerna. Jag har för fel för mycket.

Om du aldrig har installerat och konfigurerat en BIND ska du inte bli avskräckt om något går fel vid första försöket och du måste börja om från början. Vi rekommenderar alltid att i dessa fall börja med en ren installation. Det är värt ett försök!

För dem som behöver hög tillgänglighet i namnupplösningstjänsten, vilket kan uppnås genom att konfigurera en sekundär masterserver, rekommenderar vi att du fortsätter med oss ​​på nästa äventyr: Sekundär Master DNS för ett LAN.

Grattis till dem som följde alla artiklar och fick förväntade resultat!


Innehållet i artikeln följer våra principer om redaktionell etik. Klicka på för att rapportera ett fel här.

11 kommentarer, lämna din

Lämna din kommentar

Din e-postadress kommer inte att publiceras.

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   st0rmt4il sade

    Äntligen! .. det sista inlägget: D!

    Tack för att du delar min vän!

    Hälsningar!

  2.   Rafael Hernandez sade

    Mycket intressant, dina artiklar, jag har en auktoritativ DNS inställd i en freeBSD för en .edu.mx-domän, hittills har det fungerat perfekt för mig, men under den senaste månaden upptäckte jag flera attacker mot servern, vad skulle vara försvarsmetoderna för En exponerad DNS?, och jag vet inte om det kan vara, har befälhavaren exponerad för internet och en sekundär som serverar en liten lan på cirka 60 datorer, båda DNS sammankopplade, eller för att kunna definiera två zoner, en intern och en extern, tack i mastern

  3.   PICCORUS sade

    Squeeze bind9-paketet har problem med samba, en version 9.8.4 finns redan i backportsgrenen för squeeze, wheeze-versionen har inte det här problemet, för lenny venenux.net backport paketet.

    Mycket bra artikel.

    Det här är den enda artikeln som gör allt väl förklarat ..

    Det bör noteras att acl för spofing inte fungerar eftersom på samma sätt som det kommer att injiceras från det interna nätverket skulle lösningen vara att neka omdirigeringar för klienterna och skapa en komplex acl som förhindrar omfördelning av namn (något liknande statiska dns)

    SPECIALTIPS:

    En extra konfiguration skulle vara bra för hur man gör att dns filtrerar innehåll istället för brandväggen

    1.    Federico Antonio Valdes Toujague sade

      Tack för att du kommenterade @PICCORO !!!.
      Jag förklarar i början av alla mina artiklar att jag inte anser mig vara specialist. Mycket mindre i DNS-frågan. Här lär vi oss alla. Jag kommer att ta hänsyn till dina rekommendationer när du installerar en DNS som vetter mot Internet och inte för ett normalt och enkelt LAN.

  4.   Frank Davila sade

    UTMÄRKT TUTORIAL !!! Det var en stor hjälp för mig eftersom jag precis började i den här servern, allt fungerade OK. Tack och att du fortsätter att publicera sådana magnifika handledning !!!

  5.   Jesus Fenández Toledo sade

    Fico, än en gång gratulerar jag dig till detta fantastiska material.

    Jag är inte expert på BIND9, förlåt mig om jag har fel när det gäller kommentaren, men jag tror att du inte har definierat zonen för omvänd sökning i namnet.conf.local-filen

    1.    elav sade

      Det är synd att Fico inte kan svara dig just nu.

      1.    Federico Antonio Valdes Toujague sade

        Hälsningar och tack, Elav, och här svarar jag. Som alltid rekommenderar jag att du läser långsamt ... 🙂

    2.    Federico Antonio Valdes Toujague sade

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

      Jag skriver följande:
      Ändringar av filen /etc/bind/named.conf.local

      I den här filen förklarar vi de lokala zonerna för vår domän. Vi måste inkludera framåt- och bakåtzonerna som ett minimum. Kom ihåg att i konfigurationsfilen /etc/bind/named.conf.options deklarerar vi i vilken katalog vi kommer att vara värd för Zones-filerna med hjälp av katalogdirektivet. Till slut bör filen vara som följer:

      // /etc/bind/named.conf.local
      //
      // Gör någon lokal konfiguration här
      //
      // Överväg att lägga till 1918-zonerna här, om de inte används i din
      // organisation
      // inkluderar "/etc/bind/zones.rfc1918";
      // Namnen på filerna i varje zon är a
      // konsumentens smak. Vi valde friends.cu.hosts
      // och 192.168.10.rev eftersom de ger oss klarhet över sina
      // innehåll. Det finns inget mer mysterium 😉
      //
      // Namnen på zonerna ÄR INTE ARBITRÄR
      // och de kommer att motsvara namnet på vår domän
      // och till LAN-undernätet
      // Huvudzon: "Direkt" typ
      zon «amigos.cu» {
      typ mästare;
      fil "amigos.cu.hosts";
      };
      // Huvudhuvudzon: «invers» typ
      zon "10.168.192.in-addr.arpa" {
      typ mästare;
      fil "192.168.10.rev";
      };
      // Slutet på namnet.conf.local-fil

  6.   Fabian Valery sade

    Bra, väldigt intressant ditt inlägg om dns, de har hjälpt mig att komma igång med ämnet, tack. Jag klargör att jag är nybörjare i detta avseende. Men när jag läste din publicerade information har jag observerat att den fungerar med fasta adresser i värdarna för ett internt nätverk. Min fråga är, hur skulle det göras med ett internt nätverk med dynamiska ip-adresser, tilldelade av en dhcp-server, för att skapa filerna i huvudhuvudzonen av typen "direkt" och "invers"?

    Jag kommer att vara tacksam för det ljus som du kan ge i den fråga som tas upp. Tack. Fv

    1.    Federico A. Valdes Toujague sade

      Tack för att du kommenterade, @fabian. Du kan läsa följande artiklar, som jag hoppas hjälper dig att implementera ett nätverk med dynamiska 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/

      hälsningar