DNS og DHCP i CentOS 7 - SMB Networks

Generell indeks for serien: Datanettverk for SMB: Introduksjon

Hei venner!. Vi vil se i denne artikkelen hvordan vi kan implementere det viktige paret av tjenester for nettverk som utgjøres av DNS og DHCP på CentOS - Linux, spesielt i versjon 7.2.

  • Noen artikler om DNS viser til at implementeringen av denne tjenesten er litt uklar og vanskelig. Jeg er ikke veldig enig i den uttalelsen. Jeg vil heller si at det er litt konseptuelt, og at mange av konfigurasjonsfilene har masete syntaks. Heldigvis har vi verktøy for å kontrollere, trinnvis, syntaksen til hver konfigurasjonsfil som vi endrer. Derfor vil vi prøve å gjøre lesingen av dette innlegget så hyggelig og hyggelig som mulig..

For de som leter etter det grunnleggende om begge tjenestene, anbefaler vi sterkt å starte søket på Wikipedia, både i den spanske og engelske versjonen. Det er ikke mindre sant at artikler på engelsk nesten alltid er mer komplette og sammenhengende. Likevel er Wikipedia et veldig godt utgangspunkt.

For de av dere som virkelig vil lære om DNS og BIND, anbefaler vi å lese boka «OReilly - DNS og BIND 4ed" skrevet av Paul albitz y Cricket Liu, eller en senere utgave som helt sikkert eksisterer.

Vi har allerede publisert en artikkel om emnet med tittelen «DNS og DHCP i openSUSE 13.2 Harlequin - SME Networks»For elskere av det grafiske miljøet. Fra nå av vil de imidlertid møte artikler om dette emnet - ikke om andre - skrevet med mye bruk av emulatoren til en terminal eller konsoll. Wow, i den klassiske stilen som brukes av UNIX® / Linux systemadministratorer.

Hvis du vil vite mer om etternavnet på tittelen på denne artikkelen «SMB-nettverk»Du kan besøke siden i denne bloggen«SMB-nettverk: første virtuelle kutt«. I den finner du lenker til mange andre publiserte artikler.

  • Etter at installasjonen av operativsystemet CentOS 7 er ferdig med pakkene vi anbefaler, el katalogen /usr/share/doc/bind-9.9.4/ Den inneholder en god mengde dokumentasjon som vi anbefaler at du konsulterer før du drar på et internett-søk uten å vite at du lett kan finne det du leter etter.

Installasjon av basesystemet

Generelle data for domenet og DNS-serveren

Domenenavn: desdelinux.fan
DNS-servernavn: dns.fromlinux.fan
IP-adresse: 192.168.10.5
Subnetmaske: 255.255.255.0

Installasjon

Vi starter med en ny eller ren installasjon av CentOS 7-operativsystemet som angitt i forrige artikkel «CentOS 7 Hypervisor I - SMB-nettverk«. Vi trenger bare å gjøre følgende endringer:

  • I Imagen 22 «VALG AV PROGRAMVARE«, Vi anbefaler å velge i venstre kolonne«Basemiljø»Alternativet som tilsvarer en«Infrastruktur server«, Mens du er i høyre kolonne«Plugins for valgt miljø»Merk av for«DNS-navneserver«. Vi installerer DHCP-serveren senere.
  • La oss huske erklæringen om de ekstra arkivene som vist i Imagen 23, etter innstilling av «NETTVERK & LAGSNAVN".
  • Bildene som refererer til partisjonene vi skal lage på harddisken vår, er bare gitt som guider. Velg gjerne skillevegger etter eget skjønn, praksis og god dømmekraft.
  • Til slutt, i Bilde 13 «NETTVERK & LAGSNAVN», må vi endre verdiene i henhold til de generelle parametrene for det deklarerte domenet og DNS-serveren, uten å glemme å spesifisere vertsnavnet - i dette tilfellet «dns«- etter at nettverkskonfigurasjonen er fullført. Det er positivt å gjøre ping -fra en annen vert- til den angitte IP-adressen etter at nettverket er aktivt:

DNS og DHCP på CentOS

Det er veldig få og veldig åpenbare endringer som vi må gjøre med hensyn til forrige artikkel.

Innledende kontroller og justeringer

Etter at vi har installert operativsystemet, må vi gjennomgå følgende filer i det minste, og for dette starter vi en økt via SSH fra datamaskinen vår sysadmin.fromlinux.fan:

buzz @ sysadmin: ~ $ ssh 192.168.10.5
buzz@192.168.10.5 passord: Siste innlogging: Lør 28 jan 09:48:05 2017 fra 192.168.10.1
[buzz @ dns ~] $

Ovennevnte operasjon kan ta lengre tid enn normalt, og det skyldes hovedsakelig at vi ennå ikke har DNS på LAN. Sjekk igjen senere at DNS fungerer.

[buzz @ dns ~] $ cat / etc / hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 :: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6

[buzz @ dns ~] $ cat / etc / hostname
dns

[buzz @ dns ~] $ cat / etc / sysconfig / network-scripts / ifcfg-eth0
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=eth0
UUID=946f5ac9-238a-4a94-9acb-9e3458c680fe
DEVICE=eth0
ONBOOT=yes
IPADDR=192.168.10.5
PREFIX=24
GATEWAY=192.168.10.1
DNS1=127.0.0.1
DOMAIN=desdelinux.fan

[buzz @ dns ~] $ cat /etc/resolv.conf 
# Generert av NetworkManager-søk fra linux.fan nameserver 127.0.0.1

Hovedkonfigurasjonene svarer på våre valg. Merk at selv på en server Red Hat 7 - CentOS 7, er konfigurert som standard når Network slik at dette er den som administrerer nettverksgrensesnittene, enten de er kablet eller trådløs (WiFi), VPN-tilkoblinger, PPPoE-tilkoblinger og andre nettverkstilkoblinger.

[buzz @ dns ~] $ sudo systemctl status nettverksadministrator
[sudo] passord for buzz: ● networkmanager.service Lastet: ikke funnet (Årsak: Ingen slik fil eller katalog) Aktiv: inaktiv (død)

[buzz @ dns ~] $ sudo systemctl status NetworkManager
● NetworkManager.service - Network Manager Loaded: lastet (/usr/lib/systemd/system/NetworkManager.service; aktivert; leverandørinnstilling: aktivert) Aktiv: aktiv (kjører) siden lør 2017-01-28 12:23:59 EST; 12 minutter siden Hoved-PID: 705 (NetworkManager) CGroup: /system.slice/NetworkManager.service 705─XNUMX / usr / sbin / NetworkManager --no-daemon

Red Hat - CentOS lar deg også koble til og koble fra nettverksgrensesnitt ved hjelp av de klassiske kommandoene ifup e ifdown. La oss kjøre på en serverkonsoll:

[root @ dns ~] # ifdown eth0
Enheten 'eth0' ble frakoblet.

[root @ dns ~] # ifup eth0
Tilkobling aktivert (D-Bus aktiv bane: / org / frigjort skrivebord / NetworkManager / ActiveConnection / 1)
  • Vi foreslår ikke endre standardinnstillingene som CentOS 7 tilbyr med hensyn til Network.

Vi erklærer definitivt lagringsplassene vi skal bruke og oppdaterer om nødvendig operativsystemet:

[buzz @ dns ~] $ su Passord: [root @ dns buzz] # cd /etc/yum.repos.d/
[root @ dns yum.repos.d] # ls -l
totalt 28 -rw-r - r--. 1 rotrot 1664 9. desember 2015 CentOS-Base.repo -rw-r - r--. 1 rotrot 1309 9. desember 2015 CentOS-CR.repo -rw-r - r--. 1 rotrot 649 9. desember 2015 CentOS-Debuginfo.repo -rw-r - r--. 1 rotrot 290 9. desember 2015 CentOS-fasttrack.repo -rw-r - r--. 1 rotrot 630 9. desember 2015 CentOS-Media.repo -rw-r - r--. 1 rotrot 1331 9. desember 2015 CentOS-Sources.repo -rw-r - r--. 1 rotrot 1952 9. desember 2015 CentOS-Vault.repo

Det er sunt å lese innholdet i de originale deklarasjonsfilene fra CentOS anbefalte arkiver. Endringene vi gjør her skyldes at vi ikke har tilgang til Internett, og vi jobber med lokale arkiver lastet ned fra WWW Village, av kolleger som gjør livet vårt litt lettere. 😉

[root @ dns yum.repos.d] # mkdir original
[root @ dns yum.repos.d] # mv CentOS- * original /

[root @ dns yum.repos.d] # nano centos-repos.repo
[centos-base]
name=CentOS-$releasever
baseurl=http://10.10.10.1/repos/centos/7/base/
gpgcheck=0
enabled=1

[centos-updates]
name=CentOS-$releasever
baseurl=http://10.10.10.1/repos/centos/7/updates/x86_64/
gpgcheck=0
enabled=1

[root @ dns yum.repos.d] # yum rens alt
Lastede plugins: raskeste speil, langpacks Rengjøringslagre: centos-base centos-oppdateringer Rydder opp i alt

[root @ dns yum.repos.d] # yum oppdatering
Lastede plugins: raskeste speil, langpakker med centos-base | 3.4 kB 00:00 cent-oppdateringer | 3.4 kB 00:00 (1/2): centos-base / primær_db | 5.3 MB 00:00 (2/2): centos-oppdateringer / primær_db | 9.1 MB 00:00 Bestemme raskeste speil Ingen pakker merket for oppdatering

Meldingen «Ingen (det er) pakker merket for oppdatering» - «Ingen pakker merket for oppdatering»Indikerer at de mest oppdaterte pakkene ble installert ved å erklære de mest oppdaterte lagringene som var tilgjengelige for oss under installasjonen.

Om SELinux-konteksten og brannmuren

Vi kommer til å fokusere denne artikkelen - fundamentalt - på implementering av DNS og DHCP-tjenester, som er hovedmålet.

Hvis noen lesere valgte en sikkerhetspolicy under installasjonsprosessen, som angitt i Imagen 06 av referanseartikkelen «CentOS 7 Hypervisor I - SMB-nettverk»Brukt til installasjon av denne DNS - DHCP-serveren, og du finner ut at du ikke vet hvordan du skal konfigurere SELinux og CentOS-brannmuren, foreslår vi at du utfører følgende:

Endre filen / etc / sysconfig / selinux og endre SELINUX = håndheving av SELINUX = deaktiver

[root @ dns ~] # nano / etc / sysconfig / selinux
# Denne filen kontrollerer tilstanden til SELinux på systemet. # SELINUX = kan ta en av disse tre verdiene: # håndheving - SELinux sikkerhetspolicy håndheves. # permissive - SELinux skriver ut advarsler i stedet for å håndheve. # deaktivert - Ingen SELinux-policyer er lastet inn.
SELinux = deaktivert
# SELINUXTYPE = kan ta en av tre to verdier: # målrettet - Målrettede prosesser er beskyttet, # minimum - Endring av målrettet policy. Bare valgte prosesser er pr $ # mls - Multi Level Security protection. SELINUXTYPE = målrettet

Kjør deretter følgende kommandoer

[root @ dns ~] # setenforce 0
[root @ dns ~] # service firewalld stop
Omdirigering til / bin / systemctl stopp firewalld.service

[root @ dns ~] # systemctl deaktiver firewall
Fjernet symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service. Fjernet lenke /etc/systemd/system/basic.target.wants/firewalld.service.

Hvis du implementerer en DNS-server som vender mot Internett, bør du IKKE gjøre det ovenfor, men konfigurere SELinux-konteksten og brannmuren riktig. Se "Serverkonfigurasjon med GNU / Linux, av forfatteren Joel Barrios Dueñas" eller selve CentOS-dokumentasjonen - Red Hat

Vi konfigurerer BIND - navngitt

  • El katalogen /usr/share/doc/bind-9.9.4/ inneholder en god mengde dokumentasjon som vi anbefaler at du konsulterer før du drar på et internett-søk uten å vite at du, lett tilgjengelig og i ditt eget hjem, kan finne det du leter etter

I mange distribusjoner kalles DNS-tjenesten som er installert gjennom BIND-pakken navngitt (Navn Daemon). I CentOS 7 er den installert deaktivert som standard, i henhold til utdataene fra følgende kommando, der den sier at statusen er «deaktivert«, Og at denne tilstanden er forhåndsdefinert av sin« selger »- forhåndsinnstilt leverandør. For ordens skyld er BIND fri programvare.

Aktivering av den navngitte tjenesten

[root @ dns ~] # systemctl-status navngitt
● named.service - Berkeley Internet Name Domain (DNS) lastet: lastet (/usr/lib/systemd/system/named.service; deaktivert; forhåndsinnstilt leverandør: deaktivert) Aktiv: inaktiv (død)

[root @ dns ~] # systemctl-aktivering navngitt
Opprettet symlink fra /etc/systemd/system/multi-user.target.wants/named.service til /usr/lib/systemd/system/named.service.

[root @ dns ~] # systemctl start navngitt

[root @ dns ~] # systemctl-status navngitt
● named.service - Berkeley Internet Name Domain (DNS) lastet: lastet (/usr/lib/systemd/system/named.service; aktivert; forhåndsinnstilt leverandør: deaktivert)
   Aktiv: aktiv (kjører) siden lør 2017-01-28 13:22:38 EST; 5 minutter siden Prosess: 1990 ExecStart = / usr / sbin / heter -u med navnet $ OPTIONS (kode = avsluttet, status = 0 / SUCCESS) Prosess: 1988 ExecStartPre = / bin / bash -c hvis [! "$ DISABLE_ZONE_CHECKING" == "ja"]; deretter / usr / sbin / named-checkconf -z /etc/named.conf; annet ekko "Kontroll av sonefiler er deaktivert"; fi (kode = avsluttet, status = 0 / SUCCESS) Hoved-PID: 1993 (kalt) CGroup: /system.slice/named.service └─1993 / usr / sbin / named -u heter 28. januar 13:22:45 [1993]: feil (nettverk som ikke kan nås) løser './NS/IN': 2001: 500: 2f :: f # 53 Jan 28 13:22:47 dns med navn [1993]: feil (nettverk som ikke kan nås) løser './ DNSKEY / IN ': 2001: 500: 3 :: 42 # 53 28. januar 13:22:47 dns med navnet [1993]: feil (nettverk kan ikke nås) løser' ./NS/IN ': 2001: 500: 3 :: 42 # 53 28. jan 13:22:47 dns kalt [1993]: feil (nettverk utilgjengelig) ved å løse './DNSKEY/IN': 2001: 500: 2d :: d # 53 28. jan 13:22:47 dns kalt [1993 ]: feil (nettverk som ikke kan nås) løser './NS/IN': 2001: 500: 2d :: d # 53 28. januar 13:22:47 dns med navn [1993]: feil (nettverk kan ikke nås) ved å løse './DNSKEY/ IN ': 2001: dc3 :: 35 # 53 Jan 28 13:22:47 dns navngitt [1993]: feil (nettverk utilgjengelig) løser' ./NS/IN ': 2001: dc3 :: 35 # 53 Jan 28 13: 22:47 dns kalt [1993]: feil (nettverk utilgjengelig) løser './DNSKEY/IN': 2001: 7fe :: 53 # 53 Jan 28 13:22:47 dns kalt [1993]: feil (nettverk utilgjengelig) res olving './NS/IN': 2001: 7fe :: 53 # 53 28. januar 13:22:48 dns med navn [1993]: managed-keys-zone: Kan ikke hente DNSKEY-sett '.': tidsavbrutt

[root @ dns ~] # systemctl omstart navngitt

[root @ dns ~] # systemctl-status navngitt
● named.service - Berkeley Internet Name Domain (DNS) lastet: lastet (/usr/lib/systemd/system/named.service; aktivert; leverandør forhåndsinnstilling: deaktivert)
   Aktiv: aktiv (kjører) siden lør 2017-01-28 13:29:41 EST; 1s siden Prosess: 1449 ExecStop = / bin / sh -c / usr / sbin / rndc stop> / dev / null 2> & 1 || / bin / kill -TERM $ MAINPID (code = exited, status = 0 / SUCCESS) Prosess: 1460 ExecStart = / usr / sbin / named -u heter $ OPTIONS (code = exited, status = 0 / SUCCESS) Prosess: 1457 ExecStartPre = / bin / bash -c hvis [! "$ DISABLE_ZONE_CHECKING" == "ja"]; deretter / usr / sbin / named-checkconf -z /etc/named.conf; annet ekko "Kontroll av sonefiler er deaktivert"; fi (kode = avsluttet, status = 0 / SUKSESS) Hoved-PID: 1463 (kalt) CGroup: /system.slice/named.service └─1463 / usr / sbin / named -u heter Jan 28 13:29:41 dns heter [1463]: managed-keys-zone: journal file er utdatert: fjerning av journalfil 28. jan 13:29:41 dns med navn [1463]: managed-keys-zone: lastet serie 2. jan 28 13:29:41 dns navngitt [1463]: sone 0.in-addr.arpa/IN: lastet serie 0 28. januar 13:29:41 dns kalt [1463]: sone localhost.localdomain / IN: lastet serie 0 28. januar 13:29:41 dns navngitt [1463]: sone 1.0.0.127.in-addr.arpa/IN: lastet serie 0 28. januar 13:29:41 dns navngitt [1463]: sone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .6.ip0.arpa / IN: lastet seriell 28 Jan 13 29:41:1463 dns navngitt [0]: sone localhost / IN: lastet seriell 28 Jan 13 29 : 41: 1463 dns kalt [28]: alle soner lastet 13. jan 29:41:1463 dns kalt [28]: kjører 13. jan 29:41:1 dns systemd [XNUMX]: Startet Berkeley Internet Name Domain (DNS).

Etter at vi aktiverer tjenesten navngitt og vi starter den for første gang, output av kommandoen systemctl status navngitt viser feil. Når vi starter tjenesten på nytt nedenfor, navngitt oppretter alle konfigurasjonsfilene som standard er nødvendige for at den skal fungere korrekt. Derfor når vi utfører kommandoen igjen systemctl status navngitt ingen flere feil vises.

  • Kjære, dyre og krevende Leser: Hvis du vil finne ut - i det minste - hvilken vei som fører til slutten av kaninhullet, kan du lese de detaljerte resultatene av hver kommando rolig. 😉 Artikkelen vil sikkert virke litt lang, men benekt ikke at den får forklaring og klarhet.

Vi endrer filen /etc/named.conf

Mange leserkommentarer uttrykker -Jeg sier det ikke- manien som vedlikeholdere av forskjellige Linux-distribusjoner har, å plassere systemkonfigurasjonsfiler i mapper med forskjellige navn, avhengig av distro. De har rett. Men hva kan vi, de enkle brukerne som bruker disse distribusjonene, gjøre? Tilpasse! 😉

Forresten, i FreeBSD, UNIX®-klon «The Origin», er filen i /usr/local/etc/namedb/named.conf; mens du er i Debian, i tillegg til å dele inn i de fire filene named.conf, named.conf.options, named.conf.default-zones, og named.conf.local, er i mappen / etc / bind /. De som vil vite hvor openSUSE plasserer det, les «DNS og DHCP i openSUSE 13.2 Harlequin - SME Networks«. Leserne har rett! 😉

Og som vi alltid gjør: før vi endrer noe, lagrer vi den opprinnelige konfigurasjonsfilen under et annet navn.

[root @ dns ~] # cp /etc/named.conf /etc/named.conf.original

For å gjøre livet lettere, i stedet for å generere nøkkelen TSIG for dynamiske DNS-oppdateringer av DHCP, kopierer vi den samme nøkkelen rndc.key som dhcp.key.

[root @ dns ~] # cp /etc/rndc.key /etc/dhcp.key

[root @ dns ~] # nano /etc/dhcp.key
nøkkel "dhcp-key" {algoritme hmac-md5; hemmelig "OI7Vs + TO83L7ghUm2xNVKg =="; };

Slik at navngitt kan lese filen som nettopp er kopiert, endrer vi eiergruppen:

[root @ dns ~] # chown root: named /etc/dhcp.key [root @ dns ~] # ls -l /etc/rndc.key /etc/dhcp.key -rw-r -----. 1 rot med navnet 77 jan 28 16:36 /etc/dhcp.key -rw-r -----. 1 rot kalt 77 Jan 28 13:22 /etc/rndc.key

Små detaljer som den forrige er det som kan gjøre oss sprø når vi prøver å finne ut, nå ... hvor er problemet ...? med noen flere adjektiv, som vi ikke skriver av respekt for den respektable.

Nå hvis vi endelig endrer filen /etc/named.conf. Endringene eller tilleggene vi har gjort, med hensyn til originalen, er i dristig. Ta en titt på hvor få.

[root @ dns ~] # nano /etc/named.conf
// // named.conf // // Levert av Red Hat bind-pakke for å konfigurere ISC BIND navngitt (8) DNS // server som bare navneserver for hurtigbufring (kun som en lokal vert DNS-oppløsning). // // Se / usr / share / doc / bind * / sample / for eksempel navngitte konfigurasjonsfiler. //

// Tilgangskontrolliste som erklærer hvilke nettverk som vil kunne konsultere
// den navngitte serveren min
acl mired {
 127.0.0.0 / 8;
 192.168.10.0 / 24;
};

alternativer {
 // Jeg erklærer at den navngitte demonen også lytter etter grensesnittet
 // eth0 som har IP: 192.168.10.5
    lytte på port 53 {127.0.0.1; 192.168.10.5; };
    lytte-på-v6-port 53 {:: 1; }; katalog "/ var / named"; dump-fil "/var/named/data/cache_dump.db"; statistikkfil "/var/named/data/named_stats.txt"; memstatistikk-fil "/var/named/data/named_mem_stats.txt";

 // Speditørerklæring
 // speditører {
 // 0.0.0.0;
 // 1.1.1.1;
 //};
    // frem først;

    // Jeg tillater bare spørsmål til min mired ACL
    allow-query {mired; }; // For å sjekke med kommandoen grave fra linux.fan axfr // fra SysAdmin arbeidsstasjon og bare localhost // Vi har ikke slave DNS-servere. Vi trenger det ikke ... før nå.
 tillat-overføring {localhost; 192.168.10.1; };

    / * - Hvis du bygger en AUTORITATIVE DNS-server, må du IKKE aktivere rekursjon. - Hvis du bygger en RECURSIVE (caching) DNS-server, må du aktivere rekursjon. - Hvis den rekursive DNS-serveren din har en offentlig IP-adresse, MÅ du aktivere tilgangskontroll for å begrense spørsmål til dine legitime brukere. Hvis du ikke gjør det, vil serveren din bli en del av store DNS-forsterkningsangrep. Implementering av BCP38 i nettverket ditt vil i stor grad redusere en slik angrepsflate * /
    // Vi ønsker en AUTHORITY-server for LAN - SME
    rekursjon nr;

    dnssec-aktivere ja; dnssec-validering ja; / * Sti til ISC DLV-nøkkel * / bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/ var / named / dynamic"; pid-fil "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging av {channel default_debug {file "data / named.run"; alvorlighetsgrad dynamisk; }; }; sone "." IN {type hint; fil "named.ca"; }; inkluderer "/etc/named.rfc1912.zones"; inkluderer "/etc/named.root.key";

// Vi inkluderer TSIG-nøkkelen for dynamiske DNS-oppdateringer // av DHCP
inkluderer "/etc/dhcp.key";

// Erklæring om navn, type, sted og oppdateringstillatelse
// av DNS-registersonene // Begge sonene er MASTERS
sone "desdelinux.fan" {
 type master;
 fil "dynamisk / db.fromlinux.fan";
 tillat-oppdatering {nøkkel dhcp-nøkkel; };
};

sone "10.168.192.in-addr.arpa" {
 type master;
 fil "dynamisk / db.10.168.192.in-addr.arpa";
 tillat-oppdatering {nøkkel dhcp-nøkkel; };
};

Vi sjekker syntaksen

[root @ dns ~] # named-checkconf 
[root @ dns ~] #

Siden kommandoen ovenfor ikke returnerer noe, er syntaksen OK. Men hvis vi utfører den samme kommandoen, men med alternativet -z, vil utdataene være:

[root @ dns ~] # named-checkconf -z
sone localhost.localdomain / IN: lastet seriell 0 sone localhost / IN: lastet seriell 0 sone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: lastet seriell 0-sone 1.0.0.127.in-addr.arpa/IN: lastet seriell 0-sone 0.in-addr.arpa/IN: lastet seriell 0-sone fra linux.fan/IN: lasting fra master file dynamic / db.fromlinux.fan mislyktes: filen ble ikke funnet sone fralinux.fan/IN: ikke lastet på grunn av feil. _default / desdelinux.fan / IN: filen ble ikke funnet sone 10.168.192.in-addr.arpa/IN: lasting fra hovedfil dynamisk / db.10.168.192.in-addr.arpa mislyktes: filen ble ikke funnet sone 10.168.192 .in-addr.arpa / IN: ikke lastet på grunn av feil. _default / 10.168.192.in-addr.arpa / IN: filen ble ikke funnet

Selvfølgelig er det feil som oppstår fordi vi ennå ikke har opprettet DNS-registreringssonene for domenet vårt.

  • For mer informasjon om kommandoen named-checkconf, løpe mann som heter-checkconf, før du leter etter annen informasjon på Internett. Jeg forsikrer deg om at det vil spare mye tid.

Vi oppretter Direct Zone-filen fra linux.fan

... ikke uten litt teori først. 😉

Som en mal for å lage sondatafilen, kan vi ta /var/named/named.empty, eller /usr/share/doc/bind-9.9.4/sample/var/named/named.empty. Begge er identiske.

[root @ dns ~] # cat /var/named/named.empty 
$ TTL 3H @ IN SOA @ rname.invalid. (0; seriell 1D; oppdater 1H; prøv 1W; utløper 3H); minimum eller negativ cachetid for å leve NS @ A 127.0.0.1 AAAA :: 1

Livstid - På tide å leve TTL SOA-rekord

La oss ta en parentes for å forklare TTL - På tide å leve fra registeret SOA - Start of Authority av en hovedsone. Det er interessant å kjenne deres betydning for når vi vil endre noen av deres verdier.

$ TTL: Livstid - Tid til å leve for alle poster i filen som følger erklæringen (men går foran enhver annen $ TTL-erklæring) og ikke har en eksplisitt TTL-erklæring.

serie~~POS=TRUNC: Serienummer for sonedataene. Hver gang vi endrer en DNS-post manuelt i en sone, må vi øke antallet med 1, spesielt hvis vi har slave- eller sekundære servere. Hver gang en sekundær eller slave DNS-server kontakter masterserveren sin, ber den om serienummeret til masterdataene. Hvis slavens serienummer er lavere, er dataene for den sonen på slaveserveren utdaterte, og slaven utfører en soneoverføring for å oppdatere seg selv.

refresh: Den forteller slaveserveren tidsintervallet den skal sjekke om dataene er oppdatert med hensyn til masteren.

prøve på nytt: Hvis masterserveren ikke er tilgjengelig - for den ble syk, la oss si - til slaven etter et tidsintervall refresh, prøve på nytt Den forteller slaven hvor lenge å vente før han prøver å kontakte sin herre igjen.

utløper: Hvis slaven ikke kan kontakte sin mester i et tidsrom utløperSå hvis slave-master soneforholdet ble skrudd opp, og slave-serveren ikke har noe annet valg enn å utløpe den aktuelle sonen. Utløpet av en sone av en slave-DNS-server betyr at den vil slutte å svare på DNS-spørsmål relatert til den sonen, fordi tilgjengelige data er for gamle til å være nyttige.

  • Ovennevnte lærer oss indirekte og lastet med god sunn fornuft - den minst vanlige av sansene - at hvis vi ikke trenger slave-DNS-servere for driften av våre SMB, implementerer vi den ikke, med mindre de er strengt nødvendige. La oss alltid prøve å gå fra det enkle til det komplekse.

minimun: I versjoner før BIND 8.2, den siste posten SOA Det indikerer også standard levetid - Standard tid for å leve, og negativ cache levetid - Negativ bufringstid for å leve for sonen. Denne gangen refererer til alle negative svar gitt av den autoritative serveren for sonen.

Sonefil /var/named/dynamic/db.fromlinux.fan

[root @ dns ~] # nano /var/named/dynamic/db.fromlinux.fan
$ TTL 3H @ IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. (1; seriell 1D; oppdater 1H; prøv 1W på nytt; utløper 3H); minimum eller; Negativ bufringstid for å leve; @ IN NS dns.fromlinux.fan. @ IN MX 10 mail.fromlinux.fan. @ IN TXT "FromLinux, bloggen din dedikert til fri programvare"; sysadmin IN A 192.168.10.1 ad-dC IN A 192.168.10.3 fileserver IN A 192.168.10.4 dns IN A 192.168.10.5 proxyweb IN A 192.168.10.6 blog IN A 192.168.10.7 ftpserver IN A 192.168.10.8 mail IN A 192.168.10.9

Vi sjekker /var/named/dynamic/db.fromlinux.fan

[root @ dns ~] # named-checkzone fra linux.fan / var / named / dynamic / db. fromlinux.fan
sone fra linux.fan/IN: lastet serie 1 OK

Vi oppretter Reverse Zone-filen 10.168.192.in-addr.arpa

  • SOA-posten for denne sonen er den samme som for Direct Zone uten å ta hensyn til MX-posten..
[root @ dns ~] # nano /var/named/dynamic/db.10.168.192.in-addr.arpa
$ TTL 3H @ IN SOA dns.fromlinux.fan. root.dns.fromlinux.fan. (1; seriell 1D; oppdater 1H; prøv 1W på nytt; utløper 3H); minimum eller; Negativ bufringstid for å leve; @ IN NS dns.fromlinux.fan. ; 1 IN PTR sysadmin.fromlinux.fan. 3 IN PTR ad-dc.fromlinux.fan. 4 IN PTR fileserver.fromlinux.fan. 5 IN PTR dns.fromlinux.fan. 6 IN PTR proxyweb.desdelinux.fan. 7 IN PTR blog.desdelinux.fan. 8 IN PTR ftpserver.fromlinux.fan. 9 IN PTR mail.fromlinux.fan.

[root @ dns ~] # named-checkzone 10.168.192.in-addr.arpa /var/named/dynamic/db.10.168.192.in-addr.arpa 
sone 10.168.192.in-addr.arpa/IN: lastet serie 1 OK

Før vi starter den nevnte på nytt, kontrollerer vi konfigurasjonen

  • Inntil vi er sikre på at konfigurasjonsfilene til navngitte named.conf, og sonefilene ikke er riktig konfigurert, foreslår vi at du ikke starter den navngitte demonen på nytt. Hvis vi gjør dette og senere endrer en sonefil, må vi øke serienummeret til den modifiserte sonen med 1.
  • La oss se på "." på slutten av domenenavn og vertsnavn.
[root @ dns ~] # named-checkconf 
[root @ dns ~] # named-checkconf -z
sone localhost.localdomain / IN: lastet seriell 0 sone localhost / IN: lastet seriell 0 sone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: lastet seriell 0-sone 1.0.0.127.in-addr.arpa/IN: lastet seriell 0-sone 0.in-addr.arpa/IN: lastet seriell 0-sone fra linux.fan/IN: lastet serie 1 sone 10.168.192.in-addr.arpa/IN: lastet serie 1

Alle gjeldende navngitte konfigurasjoner

For å få klarhet, og selv om artikkelen blir lang, gir vi fullstendig resultat av kommandoen named -checkconf -zp:

[root @ dns ~] # named-checkconf -zp
sone localhost.localdomain / IN: lastet seriell 0 sone localhost / IN: lastet seriell 0 sone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .ip6.arpa / IN: lastet seriell 0-sone 1.0.0.127.in-addr.arpa/IN: lastet seriell 0-sone 0.in-addr.arpa/IN: lastet seriell 0-sone fra linux.fan/IN: lastet serie 1 sone 10.168.192.in-addr.arpa/IN: lastede serie 1-alternativer {bindkeys-file "/etc/named.iscdlv.key"; session-keyfile "/run/named/session.key"; katalog "/ var / named"; dump-fil "/var/named/data/cache_dump.db"; lytte på port 53 {127.0.0.1/32; 192.168.10.5/32; }; lytte-på-v6-port 53 {:: 1/128; }; managed-keys-directory "/ var / named / dynamic"; memstatistikk-fil "/var/named/data/named_mem_stats.txt"; pid-fil "/run/named/named.pid"; statistikkfil "/var/named/data/named_stats.txt"; dnssec-aktivere ja; dnssec-validering ja; rekursjon nr; allow-query {"mired"; }; tillat overføring {192.168.10.1/32; }; }; acl "mired" {127.0.0.0/8; 192.168.10.0/24; }; logging av {channel "default_debug" {file "data / named.run"; alvorlighetsgrad dynamisk; }; }; nøkkel "dhcp-key" {algoritme "hmac-md5"; hemmelig "OI7Vs + TO83L7ghUm2xNVKg =="; }; sone "." IN {type hint; fil "named.ca"; }; sone "localhost.localdomain" IN {type master; fil "named.localhost"; tillat-oppdatering {"none"; }; }; sone "localhost" IN {type master; fil "named.localhost"; tillat-oppdatering {"none"; }; }; sone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {type master; fil "named.loopback"; tillat-oppdatering {"none"; }; }; sone "1.0.0.127.in-addr.arpa" IN {type master; fil "named.loopback"; tillat-oppdatering {"none"; }; }; sone "0.in-addr.arpa" IN {type master; fil "named.empty"; tillat-oppdatering {"none"; }; }; sone "desdelinux.fan" {type master; fil "dynamisk / db.fromlinux.fan"; tillat-oppdatering {nøkkel "dhcp-nøkkel"; }; }; sone "10.168.192.in-addr.arpa" {type master; fil "dynamisk / db.10.168.192.in-addr.arpa"; tillat oppdatering {nøkkel "dhcp-nøkkel"; }; }; administrerte nøkler {"." nøkkel initial-257 3 "AwEAAagAIKlVZrpC8Ia6gEzahOR + 7W9euxhJhVVLOyQbSEW29O0gcCjF FVQUTf8v6fLjwBd58YI0EzrAcQqBGCzh / RStIoO0g8NfnfL0MTJRkxoX bfDaUeVPQuYEhg2NZWAJQ37VnMVDxP / VHL9M / QZxkjf496 / Efucp5gaD X2RS6CXpoY6LsvPVjR68ZSwzz0apAzvN1dlzEheX9ICJBBtuA7G6LQpz W3hOA5hzCTMjJPJ2LbqF8dsV6DoBQzgul6sGIcGOYl0OyQdXfZ7relS Qageu + ipAdTTJ57AsRTAoub25ONGcLmqrAmRLKBP8dfwhYB1N4knNnulq QXA + Uk7ihz1 ="; };
  • Etter prosedyren for å endre heter.konf I henhold til våre behov og sjekk, og opprette hver sonefil og sjekke den, tviler vi på at vi må møte store konfigurasjonsproblemer. Til slutt innser vi at det er et guttespill, med mange konsepter og masete syntaks,

Sjekkene ga tilfredsstillende resultater, derfor kan vi starte BIND på nytt - navngitt.

Vi starter det navngitte på nytt og sjekker statusen

[root @ dns ~] # systemctl start med navnet. service
[root @ dns ~] # systemctl status med navnet.service

Hvis vi får noen form for feil i utgangen fra den siste kommandoen, må vi starte navngitt.tjeneste og sjekk på nytt status. Hvis feilene er borte, startet tjenesten vellykket. Hvis ikke, må vi foreta en grundig gjennomgang av alle endrede og opprettet filer, og gjenta prosedyren.

Riktig utgang av statusen skal være:

[root @ dns ~] # systemctl status med navnet.service
● named.service - Berkeley Internet Name Domain (DNS) Lastet: lastet (/usr/lib/systemd/system/named.service; aktivert; leverandør forhåndsinnstilling: deaktivert) Aktiv: aktiv (kjører) siden søn 2017-01-29 10:05:32 EST; 2min 57s siden Prosess: 1777 ExecStop = / bin / sh -c / usr / sbin / rndc stop> / dev / null 2> & 1 || / bin / kill -TERM $ MAINPID (code = exited, status = 0 / SUCCESS) Prosess: 1788 ExecStart = / usr / sbin / named -u heter $ OPTIONS (code = exited, status = 0 / SUCCESS) Prosess: 1786 ExecStartPre = / bin / bash -c hvis [! "$ DISABLE_ZONE_CHECKING" == "ja"]; deretter / usr / sbin / named-checkconf -z /etc/named.conf; annet ekko "Kontroll av sonefiler er deaktivert"; fi (kode = avsluttet, status = 0 / SUCCESS) Hoved-PID: 1791 (kalt) CGroup: /system.slice/named.service └─1791 / usr / sbin / named -u heter 29. januar 10:05:32 dns kalt [1791]: sone 1.0.0.127.in-addr.arpa/IN: lastet serie 0 29. januar 10:05:32 dns med navn [1791]: sone 10.168.192.in-addr.arpa/IN: lastet serie 1. januar 29 10:05:32 dns kalt [1791]: sone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN : lastet serie 0 jan 29 10:05:32 dns kalt [1791]: sone desdelinux.fan/IN: lastet serie 1 jan 29 10:05:32 dns kalt [1791]: sone localhost.localdomain / IN: lastet serie 0 29. jan 10:05:32 dns kalt [1791]: sone localhost / IN: lastet serie 0 29. jan 10:05:32 dns kalt [1791]: alle soner lastet
29. jan 10:05:32 dns kalt [1791]: rennende
29. jan 10:05:32 dns systemd [1]: Startet Berkeley Internet Name Domain (DNS). 29. jan 10:05:32 dns med navnet [1791]: sone 10.168.192.in-addr.arpa/IN: sending varsler (serie 1)

Sjekker

Kontrollene kan kjøres på samme server eller på en maskin som er koblet til LAN. Vi foretrekker å gjøre dem fra teamet sysadmin.fromlinux.fan som vi ga uttrykkelig tillatelse til å gjøre soneoverføringer til. Filen / Etc / resolv.conf av det teamet er følgende:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf 
# Generert av NetworkManager-søk fra linux.fan nameserver 192.168.10.5

buzz @ sysadmin: ~ $ dig fra linux.fan axfr
; << >> DiG 9.9.5-9 + deb8u1-Debian << >> desdelinux.fan axfr ;; globale alternativer: + cmd fra linux.fan. 10800 I SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 1 86400 3600 604800 10800 fra linux.fan. 10800 IN NS dns.fromlinux.fan. fra linux.fan. 10800 IN MX 10 mail.fromlinux.fan. fra linux.fan. 10800 IN TXT "FromLinux, bloggen din dedikert til fri programvare" ad-dc.desdelinux.fan. 10800 IN A 192.168.10.3 blog.desdelinux.fan. 10800 IN A 192.168.10.7 dns.fromlinux.fan. 10800 IN A 192.168.10.5 fileserver.fromlinux.fan. 10800 IN A 192.168.10.4 ftpserver.fromlinux.fan. 10800 IN A 192.168.10.8 mail.fromlinux.fan. 10800 IN A 192.168.10.9 proxyweb.fromlinux.fan. 10800 IN A 192.168.10.6 sysadmin.fromlinux.fan. 10800 IN til 192.168.10.1 fra linux.fan. 10800 I SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 1 86400 3600 604800 10800 ;; Spørringstid: 0 msek ;; SERVER: 192.168.10.5 # 53 (192.168.10.5) ;; NÅR: Søn 29. jan 11:44:18 EST 2017 ;; XFR-størrelse: 13 poster (meldinger 1, byte 385)

buzz @ sysadmin: ~ $ dig 10.168.192.in-addr.arpa axfr
; << >> DiG 9.9.5-9 + deb8u1-Debian << >> 10.168.192.in-addr.arpa axfr ;; globale opsjoner: + cmd 10.168.192.in-addr.arpa. 10800 I SOA dns.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 10.168.192.in-addr.arpa. 10800 IN NS dns.fromlinux.fan. 1.10.168.192.in-addr.arpa. 10800 IN PTR sysadmin.fromlinux.fan. 3.10.168.192.in-addr.arpa. 10800 IN PTR ad-dc.fromlinux.fan. 4.10.168.192.in-addr.arpa. 10800 IN PTR fileserver.fromlinux.fan. 5.10.168.192.in-addr.arpa. 10800 IN PTR dns.fromlinux.fan. 6.10.168.192.in-addr.arpa. 10800 IN PTR proxyweb.fromlinux.fan. 7.10.168.192.in-addr.arpa. 10800 IN PTR blog.desdelinux.fan. 8.10.168.192.in-addr.arpa. 10800 IN PTR ftpserver.fromlinux.fan. 9.10.168.192.in-addr.arpa. 10800 IN PTR mail.fromlinux.fan. 10.168.192.in-addr.arpa. 10800 I SOA dns.fromlinux.fan.10.168.192.in-addr.arpa. root.dns.fromlinux.fan.10.168.192.in-addr.arpa. 1 86400 3600 604800 10800 ;; Spørringstid: 0 msek ;; SERVER: 192.168.10.5 # 53 (192.168.10.5) ;; NÅR: Søn 29. jan 11:44:57 EST 2017 ;; XFR-størrelse: 11 poster (meldinger 1, byte 352)

buzz @ sysadmin: ~ $ dig IN SOA fra linux.fan
buzz @ sysadmin: ~ $ dig IN MX fra linux.fan buzz @ sysadmin: ~ $ dig IN TXT fra linux.fan
buzz @ sysadmin: ~ $ host dns
dns.fromlinux.fan har adresse 192.168.10.5
buzz @ sysadmin: ~ $ host sysadmin
sysadmin.desdelinux.fan har adresse 192.168.10.1 ... Og andre sjekker vi trenger
  • Så langt har vi grunnlaget for en DNS-server i vårt SMB-nettverk. Vi håper du likte hele prosedyren, som var ganske enkel, ikke sant? 😉

Vi installerer og konfigurerer DHCP

[root @ dns ~] # yum install dhcp
Lastede plugins: raskeste speil, langpakker med centos-base | 3.4 kB 00:00:00 centos-oppdateringer | 3.4 kB 00:00:00 Laster speilhastigheter fra hurtigbufret vertsfil Løse avhengigheter -> Kjører transaksjonstest ---> Pakke dhcp.x86_64 12: 4.2.5-42.el7.centos må installeres -> Løse avhengigheter avsluttet Løst avhengighet ================================================= ==================================================== ==================================== Pakke Arkitektur Versjon Repository Størrelse =========== ==================================================== ==================================================== ====================== Installering: dhcp x86_64 12: 4.2.5-42.el7.centos-base 511k Transaksjon Sammendrag ==== ==================================================== ==================================================== ============================= Installere 1 pakke Total nedlastingsstørrelse: 511k Installert størrelse: 1.4 M Er dette ok [y / d / N]: y Nedlasting av pakker: dhcp-4.2.5-42.el7.centos.x86_64.rpm | 511 kB 00:00:00 Kjører transaksjonskontroll Kjører transaksjonstest Transaksjonstest vellykket Kjører transaksjon Installasjon: 12: dhcp-4.2.5-42.el7.centos.x86_64 1/1 Kontroll: 12: dhcp-4.2.5-42. el7.centos.x86_64 1/1 Installert: dhcp.x86_64 12: 4.2.5-42.el7.centos Ferdig!

[root @ dns ~] # nano /etc/dhcp/dhcpd.conf
# # DHCP Server-konfigurasjonsfil. # se /usr/share/doc/dhcp*/dhcpd.conf.example # se dhcpd.conf (5) manside # ddns-update-style interim; ddns-oppdateringer på; ddns-domenenavn "desdelinux.fan."; ddns-rev-domainname "in-addr.arpa."; ignorere klientoppdateringer; autoritær; alternativet ip-videresending av; alternativ domenenavn "desdelinux.fan"; # alternativ ntp-servere 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org; inkluderer "/etc/dhcp.key"; sone fra linux.fan. {primær 127.0.0.1; nøkkel dhcp-nøkkel; } sone 10.168.192.in-addr.arpa. {primær 127.0.0.1; nøkkel dhcp-nøkkel; } redlokal for delt nettverk {subnet 192.168.10.0 netmask 255.255.255.0 {option routers 192.168.10.1; opsjon undernettmaske 255.255.255.0; alternativ kringkastingsadresse 192.168.10.255; opsjon domenenavnservere 192.168.10.5; opsjon netbios-name-servers 192.168.10.5; rekkevidde 192.168.10.30 192.168.10.250; }} # END dhcpd.conf

[root @ dns ~] # dhcpd -t
Internet Systems Consortium DHCP Server 4.2.5 Copyright 2004-2013 Internet Systems Consortium. Alle rettigheter forbeholdes. For info, besøk https://www.isc.org/software/dhcp/ Søker ikke LDAP siden ldap-server, ldap-port og ldap-base-dn ikke ble spesifisert i konfigurasjonsfilen

[root @ dns ~] # systemctl aktiver dhcpd
Opprettet symlink fra /etc/systemd/system/multi-user.target.wants/dhcpd.service til /usr/lib/systemd/system/dhcpd.service.

[root @ dns ~] # systemctl start dhcpd

[root @ dns ~] # systemctl status dhcpd
● dhcpd.service - DHCPv4 Server Daemon lastet: lastet (/usr/lib/systemd/system/dhcpd.service; aktivert; leverandør forhåndsinnstilling: deaktivert) Aktiv: aktiv (kjører) siden dom 2017-01-29 12:04:59 Dens T; 23s siden Dokumenter: mann: dhcpd (8) mann: dhcpd.conf (5) Hoved-PID: 2381 (dhcpd) Status: "Send pakker ..." CGroup: /system.slice/dhcpd.service └─2381 / usr / sbin / dhcpd -f -cf /etc/dhcp/dhcpd.conf -bruker dhcpd -gruppe dhcpd --no-pid 29. jan 12:04:59 dns dhcpd [2381]: Internet Systems Consortium DHCP Server 4.2.5 29. jan 12 : 04: 59 dns dhcpd [2381]: Copyright 2004-2013 Internet Systems Consortium. 29. jan 12:04:59 dns dhcpd [2381]: Alle rettigheter forbeholdt. 29. jan 12:04:59 dns dhcpd [2381]: For info, vennligst besøk https://www.isc.org/software/dhcp/ 29. jan 12:04:59 dns dhcpd [2381]: Søker ikke LDAP siden ldap -server, ldap-port og ldap-base-dn ble ikke spesifisert i konfigurasjonsfilen 29. jan 12:04:59 dns dhcpd [2381]: Skrev 0 leieavtaler til leiefil. 29. jan 12:04:59 dns dhcpd [2381]: Lytter på LPF / eth0 / 52: 54: 00: 12: 17: 04 / redlocal 29. jan 12:04:59 dns dhcpd [2381]: Sender på LPF / eth0 / 52: 54: 00: 12: 17: 04 / redlocal 29. jan 12:04:59 dns dhcpd [2381]: Sending on Socket / fallback / fallback-net 29. jan 12:04:59 dns systemd [1]: Startet DHCPv4 Server Daemon.

Hva gjenstår å gjøre?

Enkel. Start en Windows 7 eller annen klient med fri programvare og start testing og kontroll. Vi gjorde det med to klienter: seven.fromlinux.fan y suse-desktop.fromlinux.fan. Kontrollene var som følger:

buzz @ sysadmin: ~ $ vert syv
seven.fromlinux.fan har adresse 192.168.10.30

buzz @ sysadmin: ~ $ host seven.fromlinux.fan
seven.fromlinux.fan har adresse 192.168.10.30

buzz @ sysadmin: ~ $ dig IN TXT seven.fromlinux.fan
.... ;; SPØRSMÅLSSNITT :; seven.fromlinux.fan. IN TXT ;; SVAR-AVSNITT: seven.desdelinux.fan. 3600 IN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"....

Vi omdøper teamet "syv" til "LAGER" og starter på nytt. Etter å ha startet den nye LAGER på nytt, sjekker vi:

buzz @ sysadmin: ~ $ vert syv
Vert sju ble ikke funnet: 5 (NEGNT)

buzz @ sysadmin: ~ $ host seven.fromlinux.fan
Vert sju.desdelinux.fan ikke funnet: 3 (NXDOMAIN)

buzz@sysadmin: ~ $ vert lager
lager.desdelinux.fan har adresse 192.168.10.30

buzz@sysadmin: ~ $ vert lager.fromlinux.fan
lager.desdelinux.fan har adresse 192.168.10.30

buzz @ sysadmin: ~ $ dig IN TXT lager.fromlinux.fan
.... ;; SPØRSMÅLSSNITT :; lager.fromlinux.fan. IN TXT ;; SVAR-DEL: lager.fromlinux.fan. 3600 IN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"....

Når det gjelder suse-desktop-klienten:

buzz @ sysadmin: ~ $ host suse-dektop
Host suse-dektop ikke funnet: 5 (REFUSED)

buzz @ sysadmin: ~ $ host suse-desktop
suse-desktop.desdelinux.fan har adresse 192.168.10.33

buzz @ sysadmin: ~ $ vert suse-desktop.fromlinux.fan
suse-desktop.desdelinux.fan har adresse 192.168.10.33

buzz @ sysadmin: ~ $ vert 192.168.10.33
33.10.168.192.in-addr.arpa domenenavn peker suse-desktop.desdelinux.fan.

buzz @ sysadmin: ~ $ vert 192.168.10.30
30.10.168.192.in-addr.arpa domenenavnpeker LAGER.desdelinux.fan.
buzz @ sysadmin: ~ $ dig -x 192.168.10.33
.... ;; SPØRSMÅL: 33.10.168.192.in-addr.arpa. IN PTR ;; SVARSDEL: 33.10.168.192.in-addr.arpa. 3600 IN PTR suse-desktop.fromlinux.fan. ;; MYNDIGHETSSNITT: 10.168.192.in-addr.arpa. 10800 IN NS dns.fromlinux.fan. ;; EKSTRA SEKSJON: dns.fromlinux.fan. 10800 IN A 192.168.10.5 ....

buzz @ sysadmin: ~ $ dig IN TXT suse-desktop.fromlinux.fan ....
; suse-desktop.desdelinux.fan. IN TXT ;; SVAR-AVSNITT: suse-desktop.desdelinux.fan. 3600 IN TXT "31b78d287769160c93e6dca472e9b46d73"

;; MYNDIGHETSDEL: desdelinux.fan. 10800 IN NS dns.fromlinux.fan. ;; EKSTRA SEKSJON: dns.fromlinux.fan. 10800 IN A 192.168.10.5
....

La oss også kjøre følgende kommandoer

[root @ dns ~] # grave fra linux.fan axfr
; << >> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 << >> desdelinux.fan axfr ;; globale alternativer: + cmd fra linux.fan. 10800 I SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800 fra linux.fan. 10800 IN NS dns.fromlinux.fan. fra linux.fan. 10800 IN MX 10 mail.fromlinux.fan. fra linux.fan. 10800 IN TXT "FromLinux, bloggen din dedikert til fri programvare" ad-dc.desdelinux.fan. 10800 IN A 192.168.10.3 blog.desdelinux.fan. 10800 IN A 192.168.10.7 dns.fromlinux.fan. 10800 IN A 192.168.10.5 fileserver.fromlinux.fan. 10800 IN A 192.168.10.4 ftpserver.fromlinux.fan. 10800 IN A 192.168.10.8 LAGER.fromlinux.fan. 3600 IN TXT "31b7228ddd3a3b73be2fda9e09e601f3e9"LAGER.fromlinux.fan.   3600 I A 192.168.10.30 mail.fromlinux.fan. 10800 IN A 192.168.10.9 proxyweb.fromlinux.fan. 10800 IN A 192.168.10.6 suse-desktop.fromlinux.fan. 3600 IN TXT "31b78d287769160c93e6dca472e9b46d73"suse-desktop.desdelinux.fan. 3600 I A 192.168.10.33 sysadmin.fromlinux.fan. 10800 IN til 192.168.10.1 fra linux.fan. 10800 I SOA dns.fromlinux.fan. root.dns.fromlinux.fan. 6 86400 3600 604800 10800

I utgangen ovenfor markerte vi videre dristig den TTL -i sekunder- for datamaskiner med IP-adresser gitt av DHCP-tjenesten de som har en eksplisitt erklæring om TTL 3600 gitt av DHCP. Faste IP-er styres av $ TTL på 3H -3 timer = 10800 sekunder - deklarert i SOA-posten til hver sonefil.

De kan sjekke omvendt sone på samme måte.

[root @ dns ~] # dig 10.168.192.in-addr.arpa axfr

Andre ekstremt interessante kommandoer er:

[root @ dns ~] # named-journalprint /var/named/dynamic/db.desdelinux.fan.jnl
[root @ dns ~] # named-journalprint /var/named/dynamic/db.10.168.192.in-addr.arpa.jnl
[root @ dns ~] # journalctl -f

Manuell endring av sonefiler

Etter at DHCP spiller inn dynamisk oppdatering av sonefilene til navngittHvis vi noen gang trenger å endre en sonefil manuelt, må vi utføre følgende prosedyre, men ikke før vi vet litt mer om hvordan verktøyet fungerer rndc for navneserverkontroll.

[root @ dns ~] # mann rndc
....
       fryse [sone [klasse [visning]]]
           Suspendere oppdateringer til en dynamisk sone. Hvis ingen sone er spesifisert, blir alle soner suspendert. Dette gjør at manuelle redigeringer kan gjøres i en sone som normalt oppdateres av dynamisk oppdatering. Det fører også til at endringer i journalfilen blir synkronisert i hovedfilen. Alle dynamiske oppdateringsforsøk vil bli nektet mens sonen er frossen.

       tine [sone [klasse [visning]]]
           Aktiver oppdateringer til en frossen dynamisk sone. Hvis ingen sone er spesifisert, er alle frosne soner aktivert. Dette fører til at serveren laster sonen på nytt fra disk, og aktiverer dynamiske oppdateringer på nytt etter at belastningen er fullført. Etter at en sone er tint, vil ikke dynamiske oppdateringer lenger nektes. Hvis sonen har endret seg og alternativet ixfr-fra-forskjeller er i bruk, vil journalfilen oppdateres for å gjenspeile endringene i sonen. Hvis ikke sonen er endret, vil eksisterende journalfil bli fjernet. ....

Hva, trodde du at jeg kom til å transkribere hele manualen? ... et stykke, og de kjører med bil. Resten overlater jeg til deg. 😉

utgangspunktet:

  • rndc fryse [sone [klasse [visning]]], avbryter den dynamiske oppdateringen av en sone. Hvis en ikke er spesifisert, vil alt fryse. Kommandoen tillater manuell redigering av den frosne sonen eller av alle soner. Enhver dynamisk oppdatering vil bli nektet mens den er frossen.
  • rndc tine [sone [klasse [visning]]], muliggjør dynamiske oppdateringer på en tidligere frossen sone. DNS-serveren laster inn sonefilen fra disken, og dynamiske oppdateringer aktiveres på nytt etter at omlastingen er fullført.

Forsiktighetsregler som skal tas når vi manuelt redigerer en sonefil? Det samme som om vi opprettet det, uten å glemme å øke serienummeret med 1 eller serie~~POS=TRUNC før du lagrer filen med de endelige endringene.

Eksempel:

[root @ dns ~] # rndc fryser fra linux.fan

[root @ dns ~] # nano /var/named/dynamic/db.fromlinux.fan
Jeg endrer sonefilen av en eller annen grunn, nødvendig eller ikke. Jeg lagrer endringene

[root @ dns ~] # rndc tine fra linux.fan
En soneopplasting og tining ble startet. Sjekk loggene for å se resultatet.

[root @ dns ~] # journalctl -f
29. jan 14:06:46 dns kalt [2257]: tinesone 'desdelinux.fan/IN': suksess
29. jan 14:06:46 dns med navn [2257]: sone fra linux.fan/IN: sone seriell (6) uendret. sonen kan mislykkes i å overføres til slaver.
29. jan 14:06:46 dns med navn [2257]: sone desdelinux.fan/IN: lastet serie 6

Feilen i forrige utgang, som er vist i rødt på konsollen, skyldes at jeg "glemte" å øke serienummeret med 1. Hvis jeg hadde fulgt prosedyren riktig, ville utgangen ha vært:

[root @ dns ~] # journalctl -f
- Loggene begynner på søn 2017-01-29 08:31:32 EST. - 29. jan 14:06:46 dns kalt [2257]: sone desdelinux.fan/IN: lastet serie 6. jan 29 14:10:01 dns systemd [1]: Startet økt 43 av brukerrot. 29. jan 14:10:01 dns systemd [1]: Starter økt 43 i brukerrot. 29. jan 14:10:01 dns CROND [2693]: (root) CMD (/ usr / lib64 / sa / sa1 1 1) 29. jan 14:10:45 dns med navnet [2257]: mottatt kontrollkanalkommando 'fryse fra linux. fan '29. jan 14:10:45 dns kalt [2257]: frysesone' desdelinux.fan/IN ': suksess 29. jan 14:10:58 dns kalt [2257]: mottatt kontrollkanalkommando' tine desdelinux.fan 'jan 29 14:10:58 dns kalt [2257]: tining sone 'desdelinux.fan/IN': suksess 29. jan 14:10:58 dns kalt [2257]: sone desdelinux.fan/IN: journalfil er utdatert: fjerning av journalfil 29. jan 14:10:58 dns med navn [2257]: sone desdelinux.fan/IN: lastet serie 7
  • Leservenner, jeg gjentar at du må lese utdataene fra kommandoene nøye. For noe utviklerne brukte så mye arbeid på å programmere hver kommando, uansett hvor enkelt det er.

Oppsummering

Så langt har vi adressert implementeringen av DNS - DHCP-duoen, viktige og viktige tjenester for god ytelse til vårt SMB-nettverk, med henvisning til tildeling av dynamiske adresser gjennom DHCP og oppløsningen av datamaskiner og domenenavn gjennom DNS.

Vi håper seriøst at du likte hele prosedyren som vi gjorde. Selv om det kan virke vanskeligere å bruke konsollen, er det mye enklere og mer lærerikt å implementere en tjeneste i UNIX® / Linux med hjelpen.

De tilgir meg for enhver mistolkning av begreper som er tenkt, opprettet, skrevet, revidert, omskrevet og publisert på språket til Shakespeare, ikke Cervantes. 😉

Neste levering

Jeg tror litt mer av det samme - med teoretiske tillegg på DNS-poster - men i Debian. Vi kan ikke glemme den fordelingen, ikke sant?


Innholdet i artikkelen følger våre prinsipper for redaksjonell etikk. Klikk på for å rapportere en feil her.

15 kommentarer, legg igjen dine

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.   Cristian Merchan sa

    Tusen takk for ditt prisverdige arbeid med å skrive slike fruktbare artikler. Det vil være til stor nytte for meg

  2.   Federico sa

    Og tusen takk, Cristian, for at du fulgte meg og for din vurdering av dette innlegget. Suksesser!

  3.   Ismael Alvarez Wong sa

    Etter å ha tatt en første titt på dette nye innlegget av Federico, er den store profesjonaliteten som ses i «PYMES» -serien igjen merkbar; i tillegg til den store detaljene som illustrerer domenet ditt på to av de viktigste tjenestene (DNS og DHCP) i ethvert nettverk. Ved denne anledningen, og i motsetning til mine tidligere kommentarer, har jeg en 2. kommentar på vent etter å ha omsatt det som står i dette innlegget.

  4.   crespo88 sa

    Ingen kommentarer, pa '400 !!! Fico takk fordi du vet godt at jeg har lest innleggene dine, og vi kan ikke be om mer. Du starter med en veldig god organisasjon, fra hvordan du installerer og stiller inn det personlige skrivebordet til en bruker, arbeidsstasjonen er basen, det er følelsen av å være av de nettverkstjenestene du forklarer veldig bra. Du har klatret, og selv om det er sant at nivået øker, er det sant at du har skrevet og publisert for de som er mindre enn de som begynner, for de som har vært som meg en stund og for de mest avanserte.
    Over tid har jeg kommet til den konklusjonen at jeg vet at mange allerede har kommet, teorien, den som koster oss så mye å tilegne seg for det enkle faktum at vi ikke ønsker å lese, fordi utførelse allerede er mye lettere når vi vet hva vi gjør, hvorfor ???, spørsmålene, hvor du kan finne og hvordan komme ut av feilen som gir så mye hodepine når vi ikke en gang vet hvor de kommer fra, verdt redundansen.
    Av denne grunn vil jeg ikke at du skal legge igjen de teoretiske elementene du vil ta med om DNS-poster i neste publikasjon som du kunngjorde, langt mindre når det gjelder den kjære og elskede DEBIAN.
    TUSEN TAKK, og vi venter.

  5.   dhunter sa

    Utmerket som alltid Fico! Jeg venter på Debian-versjonen, jeg har spilt alt med den distroen i årevis.

  6.   Federico sa

    Wong: Din mening etter å ha lest er verdt mye. Jeg venter på kommentarene dine når du tester innholdet, fordi jeg vet at det er slik du liker å gjøre det. 😉

  7.   Federico sa

    Crespo: Som alltid blir kommentarene dine veldig godt mottatt. Jeg ser at du har fanget den generelle linjen som jeg har reist i komposisjonen til denne serien. Jeg håper at, som deg, mange allerede har lagt merke til det. Takk for kommentaren.

  8.   Federico sa

    Dhunter: Godt å lese deg igjen! Du slipper å vente lenge. Senest mandag - eller før - vil den være ferdig for publisering. Ikke tro at det er lett for meg å dekke tre forskjellige distroer, men den respektable leseren ber om det. Ikke bare Debian og Ubuntu, men de tre orientert mot SMB.

  9.   crespo88 sa

    Hvis du har publisert, er det fordi du kan, vi støtter deg, og vi vet at du vil følge den linjen.
    Som en dhunter venter jeg på Debian-utgivelsen med skarpe tenner. Det ville være fint om du dekket litt om NTP. Sl2 og en stor klem. Hvis lærerne mine hadde lært meg alt sånt, HAHAJJA, Platinum Degree, HAHAJJA.

  10.   Federico sa

    Detaljnivået i kommandoutgangene er nødvendig for å vise dens betydning. De sier mye. Det er sant at få artikler adresserer dette detaljnivået, fordi de tror at det ville være lange og tunge artikler å lese. En del av en SysAdmin-jobb er å lese de tunge og detaljerte resultatene, ikke bare i møte med et problem, men også i møte med kontroller.

  11.   Ismael Alvarez Wong sa

    Hei Federico, jeg hadde lovet tidligere å skrive noen kommentarer etter å ha studert det aktuelle innlegget nøye; Vel, her går de neste:
    - Flott teknikk for i stedet for å generere TSIG-nøkkelen for dynamiske DNS-oppdateringer av DHCP, kopiere den samme rndc.key-nøkkelen som dhcp.key, dette tilsynelatende "så enkelt" viser at målet ikke bare er det tekniske av HOWTO-INSTALL-DNS - & - DHCP men lærer oss å tenke, 5 STJERNER FOR FORFATTEREN.
    - Veldig interessant i DNS-konfigurasjonsfilen, heter.conf, tilstedeværelsen av linjen «allow-transfer {localhost; 192.168.10.1; }; » for å teste domenet «desdelinux.fan» bare fra SysAdmin-arbeidsstasjonen og localhost (selve DNS-serveren), og sett også inn TSIG-nøkkelen for å oppdatere DNS fra DHCP.
    - Veldig bra opprettelsen av de direkte og inverse sonene til DNS sammen med den "detaljerte" forklaringen av deres typer poster, samt utførelsen av kommandoen "# named-checkconf -zp" for å sjekke alle syntaksen til den navngitte før dens hard reset, samt eksempler på å kjøre "grave" -kommandoen for å verifisere forskjellige typer DNS-poster.
    . I DHCP-konfigurasjonen (ved hjelp av filen /etc/dhcp/dhcpd.conf):
    - Hvordan legge til vårt lokale nettverk med sitt utvalg for dynamiske IP-adresser å tilordne, definisjonen av navnetjeneren osv. samt hvordan du kan fortelle DHCP å oppdatere DNS-poster ved å bruke "ddns- ..." -linjene i konfigurasjonen.
    . Når alt allerede er i drift, 5 STJERNER FOR FORFATTEREN, i utførelsen av kommandoen "# dig desdelinux.fan axfr" for å sjekke TTL for datamaskiner på LAN som har statisk IP av de som har dynamisk IP tildelt.
    . Til slutt, STOR, manuell modifisering av sonefiler ved å fryse dem først med "# rndc freeze desdelinux.fan", deretter gjøre modifikasjonen og til slutt frigjøre dem med "# rndc thaw desdelinux.fan"
    . OG DET BESTE, ALT ble gjort fra terminalen.
    Fortsett Fico.

    1.    Joy sa

      Hei,
      Jeg kom ikke se, det fordi jeg prøvde å bakhente hvordan det kan deles og fjernes blir på min datamaskin selv mine bilder. Jeg har totalt ingen kontroll over min egen datamaskin på mobilen.
      Het zit m dus ook in het dns in dhcp. Jeg vet virkelig ikke hvordan jeg må løse og kan fjerne. Misschien dat iemand mij wil help? Dit is namelijk buiten mij om geinstalleerd. Walgelijk gedrag vind ik het.

  12.   Federico sa

    Wong: kommentaren din utfyller artikkelen. Seriøst, det viser at du har studert det grundig. Ellers kunne du ikke kommentere det detaljnivået du gjør. Bare legg til det tillat-overføring Den brukes hovedsakelig når vi har en DNS-slave, og vi tillater overføring av soner fra masteren til den. Jeg bruker det på den måten fordi det er en enkel å implementere mekanisme for å utføre ikke-farlige kontroller fra en enkelt datamaskin. Tusen takk for 5-vurderingen. Hilsen! og jeg vil fortsette å vente på deg i mine neste artikler.

  13.   IgnacioM sa

    Hei Federico. Jeg vet at jeg er litt sen, men jeg vil gjerne stille deg et spørsmål.
    Vil denne fremgangsmåten hjelpe meg hvis jeg vil peke et domene til vps-serveren min?

    Hvert 15. minutt får jeg disse systemmeldingene:

    DHCPREQUEST på eth0 til port 67 (xid =…)
    DHCPACK fra (xid =…)
    bundet til - fornyelse på 970 sekunder.

    Og etter det jeg forstår, bør jeg opprette en A-post med domenet mitt og ip til den dedikerte serveren min.

    * Jeg gratulerer og takker for denne artikkelen, jeg vet ikke om det er det jeg lette etter, men jeg syntes det var veldig interessant og godt forklart. Jeg fikk også anbefalingen fra "DNS og BIND" om at jeg allerede har sladret litt, og det virker veldig interessant.

    Hilsener fra Argentina!

    1.    antonio valdes toujague sa

      vennligst kontakt meg gjennom valdestoujague@yandex.com