Ablakok.  Vírusok.  Jegyzetfüzetek.  Internet.  hivatal.  Segédprogramok.  Drivers

Figyelem

A dnsmasq megfelelő telepítéséhez és konfigurálásához lépjen a szuperfelhasználói munkamenetre:

Amikor a rendszer jelszót kér, adja meg a root felhasználó vagy a helyi rendszergazda jelszavát.

A DNS-gyorsítótár célja, hogy felgyorsítsa a weboldalak betöltését azáltal, hogy a memóriában tárolja IP-címeiket. A gyorsítótárazás konfigurálásához használja a segédprogramot dnsmasq.

Yum install dnsmasq

A vi vagy nano szövegszerkesztővel nyissa meg a fájlt a következő helyen: /etc/dnsmasq.conf

vi /etc/dnsmasq.conf

Nano /etc/dnsmasq.conf

Szerkessze a következő beállításokat:

resolv-file=/etc/resolv.dnsmasq no-poll listen-address=127.0.0.1 cache-size=150 conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig

Adja hozzá a következő paramétert is:

Minden szerver

  • resolv-fájl- fájl a DNS-kiszolgálók IP-címeivel
  • no-poll- egy paraméter, amely letiltja a változtatások automatikus alkalmazását a resolv nevű fájlokban.
  • hallgassa meg a címet- paraméter, amely jelzi, hogy melyik címet kell hallgatni.
  • gyorsítótár-méret- gyorsítótár mérete. Az alapértelmezett érték 150 gazdagép tárolását teszi lehetővé.
  • conf-dir- felelős paraméter további fájl konfigurációt.
  • minden szerver- átirányít egy dns kérést az összes elérhető DNS-kiszolgálóra, és választ küld az első válaszoló szervertől. A paramétert kézzel kell megadni.

A következő beállításokat is megadhatja:

  • no-negcache- ne gyorsítótárazza a szerverek negatív válaszait.
  • bind-interfészs- lehetővé teszi a folyamat másolatainak futtatását.
  • dns-forward-max- a dns kérések maximális száma. Az alapértelmezett érték 150. A paramétert kézzel kell megadni.

Most hozzon létre egy fájlt resolv.dnsmasq szövegszerkesztő segítségével vi vagy nanoés oda írd fel a dns szerverek címét.

Vi /etc/resolv.dnsmasq

Nano /etc/resolv.dnsmasq

Ezután adja hozzá az IP-címet 127.0.0.1 fájlhoz resolv.conf. Ehhez használja a segédprogramot « Hálózati kapcsolatok» található "Menü" → "Opciók" → "Hálózati kapcsolatok" grafikus környezetben Fahéj vagy "Rendszer" → "Beállítások" → "Hálózati kapcsolatok" grafikus környezetben Társ. Válassza ki az aktív kapcsolatot, kattintson a gombra "Változás", lépjen a lapra "IPv4 beállítások", változás "Módszer" tovább "Automatikus (DHCP, csak cím)"és a terepen" További DNS-kiszolgálók"írja a címet 127.0.0.1 , kattintson az Alkalmaz gombra, és indítsa újra hálózati menedzser.

A resolv.conf fájl szerkesztése segítséggel szövegszerkesztők Nem ajánlott. A fájl a rendszer következő újraindításával felülíródik.

A Systemctl indítsa újra a NetworkManager.service-t

Ellenőrizze a fájl tartalmát, és győződjön meg arról, hogy a módosítások életbe léptek. resolv.conf:

/etc/resolv.conf

A tartalom a következő legyen:

# A NetworkManager névszerver 127.0.0.1 által generált

A fent leírt műveletek lehetővé teszik az összes DNS-kérelem átirányítását a helyi gépre.

Szolgáltatás hozzáadása dnsmasq a munkamenet automatikus indítása és újrajelentkezése:

Systemctl enable dnsmasq.service --now

A gyorsítótár visszaállításához egyszerűen indítsa újra a szolgáltatást:

Systemctl indítsa újra a dnsmasq.service-t

Állapotfelmérés

Ellenőrizze, hogy a szolgáltatás engedélyezve van-e:

Systemctl állapot dnsmasq.service

Ellenőrizze az 53-as portot:

Netstat -ntlp | grep:53 tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 7319/dnsmasq tcp6 0 0:::53:::* LISTEN 7319/dnsmasq

Most próbálja meg többször használni a dig segédprogramot a webhely eléréséhez google.com

Dig google.com | grep "Lekérdezés ideje" ;; Lekérdezési idő: 135 ms

Ha a dns-query gyorsítótárazás működik, akkor szinte az összes következő kérésben a kiemelt sor lekérdezési idő nullával lesz egyenlő.

;; Lekérdezési idő: 0 msec

Ellenkező esetben minden új kéréssel 0-tól felfelé változik.

Ennek eredményeként a hálózat elsődleges DNS-kiszolgálója sokkal kevesebb terhelést fog tapasztalni.

Ha hibát talál, jelölje ki a szöveget, és kattintson Ctrl+Enter.

Jó időt, olvasók! Folytatva az elméleti anyagot, a jelenlegi cikkben egy gyakorlati példát szeretnék megfontolni telepítések és beállítások különböző BIND szerver konfigurációk. A cikkben leírom DNS beállítás-gyorsítótárés tele DNS főkiszolgáló. Ezzel kezdem a leírást általános fogalmakés a szükséges lépések megszervezéséhez bármely DNS szerverek.

Általános információ

Nevezett egy démon, amely része bind9 csomagés a lét domain név szerver. Démon nevű bármilyen típusú szerver funkcióját képes megvalósítani: mester, rabszolga, gyorsítótár. A fenti ábrán igyekeztem a főt a lehető legátláthatóbban megjeleníteni. hogyan működik a BIND DNS szerver. A munka nagy részét elvégző bináris benn található /usr/sbin/named. A beállításokat a főmenüből veszi át konfigurációs fájl, ami az úgynevezett named.confés a katalógusban található /etc/bind. fő konfigurációban leírta szerver munkakönyvtár, gyakran egy könyvtár /var/cache/bind, amelyben fekszenek zónaleíró fájlokés egyéb szolgáltatási fájlok. Levelezés zónanevekÉs zónaleíró fájl készletek zóna szakasz paraméterrel fájlt. zóna szakasz meghatározza a felelősség típusát is ezt a szervert zónánként (master, slave, stb.), és speciális paramétereket is meghatároz az aktuális zónához (például, hogy melyik interfészen kell feldolgozni az aktuális zónára vonatkozó kéréseket). Zónaleíró fájlokban zónák és erőforrásrekordok paramétereit tartalmazza (az ebben a bekezdésben jelzett útvonalak eltérhetnek, attól függ Linux disztribúció vagy paraméterek).

Ez általános séma olyan munkát, amely segít abban, hogy a jövőben ne tévedjen össze a konkrét konfigurációk mérlegelésekor.

A program 4. verziójának konfigurációs fájljának formátuma eltér a nyolcadik és kilencedik verzióban használttól BIND. Tekintettel arra, hogy nagyon várom az új telepítését DNS szerver, és régi verzió Nem látom értelmét a beállításnak, ezért megfontolom az új verzió konfigurációját.

Kezdeti adatok

Ahhoz, hogy a DNS megfelelően működjön, rendelkeznie kell egy . A cikkben szereplő DNS Debian disztribúción lesz beállítva, és a többi disztribúció sajátosságait is megjegyezzük. Az állvány hálózati konfigurációja a következő:

DNS: ~# CAT/ETC/Network/InterFaces Auto LO IFACE LOOLOPBACK AUTOE ETH0 INETCENTRES 10.0.0.152 NETMASK 255.255.255.0 GATEWAY 10.0.254 AUTO1 ITH1 ITHO AUTH1 ITH Facetic1. 5.255.255.0

Ahol 10.0.0.152/24 - külső interfész (a szolgáltató által kiosztott alhálózat), 192.168.1.1/24 - belső (Helyi hálózat). Az egyéni zóna neve example.com lesz. A példában -val slave szerver, a másodlagos szerver az IP-n lesz található 10.0.0.191 .

A BIND9 telepítése

A DNS-kiszolgáló működéséhez szüksége van köt 9 (egyes disztribúciókon - kötni ). Amint az az ábrán látható - a fő konfigurációs fájl BIND a fájl named.conf (adott fájl könyvtárba helyezhető /stb, néha be /etc/bind).

Paraméterek (szintaxis) named.conf

named.conf fájl szintaxisa betartja a következő szabályokat:

IP-címek- Az IP listát ";" jellel kell elválasztani , lehetőség van alhálózat megadására 192.168.1.1/24 vagy 192.168.1.1/255.255.255.0, formátumban (az IP kizárásához jelet kell elé rakni!), lehetőség van nevek megadására "bármilyen", "nincs", "localhost" dupla idézőjelben.

Hozzászólások- a #, // karakterekkel kezdődő és /* és */ közé zárt sorok megjegyzésnek minősülnek.

BAN BEN zónaleíró fájlok -szimbólum @ egy "változó", amely a konfigurációs fájlban megadott zóna nevét tartalmazza named.conf vagy a @ direktívában $ORIGIN az aktuális zóna leírása.

Minden egyes befejezett sor a paramétereknek karakterrel kell végződniük; .

Acl szakasz

Acl (hozzáférési lista)- lehetővé teszi a hálózatok névvel ellátott listájának beállítását. Szakasz formátum: acl "net_name" (ip; ip; ip; );

Opciók szakasz

Opciók szakasz készletek globális lehetőségek konfigurációs fájl, amely az összes zónát vezérli. Ennek a szakasznak a formátuma a következő: options(options_section_options);. Az opciók „beágyazhatók”. Zóna szakasz, miközben felülírja a globális beállításokat. Gyakran használt opciós nyilatkozatok:

  • enable-query ( ip_list} - Csak a következőtől származó lekérdezésekre ad választ ip_list. Ha nem, a szerver minden kérésre válaszol.
  • engedélyezés-rekurzió ( ip_list} - Rekurzív lekérdezéseket hajtanak végre az ip_listból származó kérésekre. A többi - iteratív. Ha a paraméter nincs beállítva, akkor a szerver rekurzív lekérdezéseket hajt végre az összes hálózaton.
  • átvitel engedélyezése ( ip_list} - Megadja azoknak a szervereknek a listáját, amelyek átvehetik a zónát a szervertől (alapvetően a szolga szerverek vannak itt feltüntetve)
  • /útvonal/munkahely/könyvtár- megadja a kiszolgáló munkakönyvtárának abszolút elérési útját. Ez az állítás csak az opciók részben érvényes.
  • szállítmányozók ( ip port ip port.} - jelzi a gazdagép címeket és szükség esetén a portokat, ahová a kéréseket továbbítani kell (általában az internetszolgáltatók DNS-szolgáltatóit tüntetik fel itt).
  • előre CSAK vagy előre ELSŐ - paraméter első utasítja a DNS-kiszolgálót, hogy próbálja meg feloldani a neveket a továbbítók paraméterben megadott DNS-kiszolgálókkal, és csak akkor kísérli meg magát a nevet feloldani, ha nem sikerül feloldania a nevet ezekkel a kiszolgálókkal.
  • értesítse IGEN|NEM - IGEN- értesítse a slave szervert a zóna változásairól, NEM- ne értesíts.
  • rekurzió IGEN|NEM - IGEN- rekurzív lekérdezések végrehajtása, ha az ügyfél kéri, NEM- ne hajtsa végre (csak iteratív lekérdezések). Ha a válasz a gyorsítótárban található, akkor a gyorsítótárból visszakerül. (csak a Beállítások részben használható)

Zóna szakasz

Megadja a zóna(k) leírását. Szakasz formátum: zóna( zone_section_statements}; Üzemeltetők amelyeket leggyakrabban használnak:

  • enable-update( ip_list} - Meghatározza azokat a rendszereket, amelyek dinamikusan frissíthetik az adott zónát.
  • fájlt "fájl név " - megadja a zónabeállítások fájl elérési útját (a könyvtár utasítással az opciók szakaszban megadott könyvtárban kell lennie)
  • mesterek ( ip_list} - megadja a főkiszolgálók listáját. (csak alárendelt zónákban megengedett)
  • típus" zóna_típus " - az aktuális részben leírt zóna típusát jelzi, a zone_type a következő értékeket veheti fel:
    • előre- megadja az átirányítási zónát, amely átirányítja az ebbe a zónába érkező kéréseket.
    • célzás- jelzi a segédzónát ( adott típus információkat tartalmaz a gyökérkiszolgálókról, amelyekkel a szerver kapcsolatba lép, ha nem találja a választ a gyorsítótárban)
    • fő-- azt jelzi, hogy az aktuális zóna főkiszolgálójaként működik.
    • rabszolga- Megadja, hogy az aktuális zónához szolgakiszolgálóként működjön.

További konfigurációs lehetőségek

Időértékek a zónafájlokban alapértelmezés szerint másodpercben van megadva, ha nem követi őket a következő betűk egyike: S - másodperc, M - perc, H - óra, D - nap, W - hét. Ennek megfelelően a bejegyzés 2 óra 20 óra 5 perc 2 óra 20 perc 5 másodperc lesz, és 8405 másodpercnek felel meg.

Bármely gazdagépnév/bejegyzések, amelyek nem végződnek pont számít nem FQDN név, és az aktuális zóna nevével egészül ki. Például az examle.com zónafájl domen-bejegyzése a domen.examle.com FQDN névre bővül. .

BAN BEN BIND konfigurációs fájlok a következők vonatkozhatnak irányelveket:

  • $TTL- meghatározza az alapértelmezett TTL-t az aktuális zóna összes rekordjához.
  • $ORIGIN- megváltoztatja a zóna nevét a named.conf fájlban megadottról. Ugyanakkor ennek a direktívának a hatálya nem terjed ki "felfelé" (vagyis ha a fájlt az $INCLUDE direktíva tartalmazza, akkor az $ORIGN hatálya nem terjed ki a szülőre)
  • $INCLUDE- tartalmazza a megadott fájlt a zónafájl részeként.

Külön szeretném leírni paraméter enable-transfer ( 10.0.0.191; );. Ez a paraméter azokat a szervereket írja le, amelyek számára engedélyezett a zóna másolatának letöltése - úgynevezett szerver szolga. A következő példában a beállítást elemezzük slave DNS.

A naplózás megfelelő működéséhez létre kell hoznia a megfelelő könyvtárat, és hozzá kell rendelnie a szükséges jogokat:

Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep nevű kötés 4298 0,0 3,4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0,0 0,1 3304 772 pts/4 S+ 18:19 0:00 grep named dns:~# chown bind /var/log/bind/ dns /var/log/bind/ dns 2 bind gyökér 4096 ÉS július 6 18:18 /var/log/bind/

Dns:~# cat /var/cache/bind/example.com $TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601 ; soros 8H ; frissítés 2H ; újrapróbálkozás 2W ; lejárat 1D ); minimum @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @

valamint az in-addr.arpa tartományban.

Dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. 152 IN PTR examle.com. 191 IN PTR ns.example.com. * A PTR examle.com webhelyen. dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. * A PTR examle.com webhelyen.

A hálózatunk kicsi, feltételezhető, hogy nagyon kevés gép van a hálózaton. Minden hálózati szolgáltatás ugyanazon a host example.com. címen található, így a fő DNS (ns.example.com.) és levelezőszerver(mx.example.com.) egy gépre mutat (10.0.0.152).

Másodlagos (szolga) mérvadó szerver a zónához

fő funkció szerver szolga- a zónaleírás automatikus szinkronizálása a főszerverrel. Ez a feladat dokumentum szabályozza RFC 1034 fejezetben 4.3.5. Alapján ez a dokumentum A szerverek közötti adatcsere AXFR kéréssel javasolt. Erre a kérésre egy TCP kapcsolat a teljes zónát át kell adni (RFC 1035).

Is, szolga DNS-kiszolgáló megosztja a terhelést a főkiszolgálóval, vagy átveszi a teljes terhelést az első szerver meghibásodása esetén.

Mielőtt folytatná a szolga DNS-kiszolgáló konfigurálása, ellenőriznie kell, hogy manuálisan lekérheti-e a zónát a másodlagostól a következő paranccsal:

Root@debian:~# [email protected] example.com. axfr ;<<>> DiG 9.7.3<<>> @10.0.0.152 example.com. axfr ; (1 szerver található) ;; globális beállítások: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 EGY 10.0.0.152 example.com-ban. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400;; Lekérdezési idő: 14 msec ;; SZERVER: 10.0.0.152#53(10.0.0.152) ;; MIKOR: 2011. július 8. péntek, 15:33:54 ;; XFR méret: 11 rekord (üzenetek 1, bájt 258)

  1. Másolat conf nevű konfigurációs fájl a fő szerverről;
  2. Cserélje ki típusú master paramétert tovább rabszolga típus
  3. Paraméter enable-transfer ( 10.0.0.191; ); cserélje ki tovább masters( 10.0.0.152;); azokban a zónákban, ahol ez másodlagos lesz;
  4. Zónák törlése, amelyet az aktuális szerver nem fog kiszolgálni, beleértve a gyökeret is, ha a slave nem válaszol a rekurzív kérésekre;
  5. Hozzon létre könyvtárakat naplókhoz, mint az előző példában.

Összességében megkapjuk a slave szerver konfigurációját:

[e-mail védett]:~# cat /etc/bind/named.conf options ("/var/cache/bind" könyvtár; allow-query ( any; ); // válaszol minden interfész lekérdezésére rekurziós szám; // rekurzív lekérdezések letiltása auth-nxdomain no; // RFC1035 kompatibilitás esetén nem kell IP6 (// no listen-on'tunv); 'ne jelenítse meg a DNS-kiszolgáló verzióját a válaszokon); // az alább ismertetett zónák a visszacsatolási // interfészekhez, valamint a broadcast zónákhoz (RFC 1912 szerint) zóna "localhost" ( master típusa; fájl "localhost"; ) határozza meg a szervert. zóna "127.in-addr.arpa" (típus master; fájl "127.in-addr.arpa"; ); zóna "0.in-addr.arpa" (típus master; fájl "0.in-addr.arpa"; ); zóna "255.in-addr.arpa" (típus master; fájl "255.in-addr.arpa"; ); // a főzóna zóna leírása "example.com" ( type slave; file "example.com"; masters ( 10.0.0.152; ); ); //fordított zónaleírás zóna "0.0.10.in-addr.arpa" ( típus slave; fájl "0.0.10.in-addr.arpa"; masters ( 10.0.0.152; ); ); // naplózási beállítások naplózása ( csatorna "misc" ( fájl "/var/log/bind/misc.log" verziók 4 méret 4m; nyomtatási idő IGEN; nyomtatási súlyosság IGEN; print-category YES; ); csatorna "query" ( fájl "/var/log/bind/query.log" alapértelmezett verziók 4 méret 4m; print-timectery NOES; print-timectery NO; print-timectery; "; ); kategória lekérdezések ( "query"; ); );

miután újraindítottuk a mi slave szerver biztonságosan másolja a szükséges információkat a fő szerverről, amint azt a fájlok jelenléte jelzi a könyvtárban:

[e-mail védett]:~# ls -la /var/cache/bind/ összesen 28 drwxrwxr-x 2 root bind 4096 július 8. 18:47 . drwxr-xr-x 10 gyökérgyökér 4096 júl 8 15:17 .. -rw-r--r-- 1 bind bind 416 júl 8 18:32 0.0.10.in-addr.arpa ...... -rw-r--r-- 1 bind .8 .45 bind8 .

Alapvetően a /stroallow-transfer (pngp slave szerver nem tárolhatja a zóna másolatát benne fájlrendszer. Erre a másolatra csak a DNS indításakor van szükség. A zóna másolata a fájlrendszerben megakadályozhatja az összeomlást, ha a fő kiszolgáló nem elérhető a szolga DNS indításakor. Ha nem adja meg a fájl beállítást a zóna részben, nem jön létre másolat.

A netfilter() beállítása a DNS BIND-hoz

Valójában a szerver beállítása után jó lenne megvédeni. Tudjuk, hogy a szerver az 53/udp porton fut. A cikk elolvasása és megismerése után létrehozhat hálózati forgalom szűrési szabályokat:

Dns ~ # iptables-save # általános iptables-szabályok a DNS-hez *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACNPUT ELFOGADJA -tstack hozzáférést helyi hálózat DNS-kiszolgálóhoz: -A BEMENET -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -o lo -j ACCEPT -PAC OUTP -APUTP -APUTP m udp --s port 32768:61000 -j ELFOGADÁS -A KIMENET -p tcp -m tcp --sport 32768:61000 -j ELFOGADÁS -A KIMENET -m conntrack --ctstate RELATED,ESTABLISHED -j OUTP ACCEPTA -udP ACCEPTA -p DNS hozzáférések engedélyezése -p --dport 53 -m conntrack -- ctstate ÚJ -j ELFOGADJA COMMIT

Ez egy tipikus példa! A feladatok és a hálózati konfiguráció iptables szabályainak beállításához meg kell értenie a netfilter működését Linux alatt a fenti cikkek elolvasásával.

Hibaelhárítás

A DNS-problémák azonosításának fő forrása a . Íme egy példa az indítási hibákra, amikor hibáztam a cím elérési útjában központi szerverek zónafájlja:

júl. 5 18:12:43 dns-szerver megnevezése: kezdő BIND 9.7.3 -u bind Jul 5 18:12:43 dns-szerver megnevezése: "--prefix=/usr" "--mandir=/usr/share/man" "--infodir=/sfcond"/infodir=/sf" --localstatedir=/var " "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gssapi=/usr" "--with-gssapi=/usr" "--with-gnozl-with-lgre" "--with-gnu-z-lgre" -mysql=no" "--with-dlz-bdb =yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" -IGno-CFGASEing -DDGSt2t LDFLAGS=" "CPPFLAGS=" júl. 5 18:12:4 3 dns-szerver megnevezett: a megnyitott fájlok korlátja 1024 és 1048576 között, július 5 18:12:43 dns-szerver neve: 1 CPU-t talált, 1 dolgozó szálat használva 5 júl. júl. 5 18:12:43 dns-server named: konfiguráció betöltése az "/etc/bind/named .conf" fájlból július 5 18:12:43 dns-server named: beépített megbízható kulcsok beolvasása az "/etc/bind/bind.keys" fájlból július 5. U. 5. U. 5. júl. 18. júl. 18:12:43 dns-szerver megnevezése: alapértelmezett UDP/IPv6 porttartomány használata: júl. 5 18:12:43 dns -szerver neve: figyel az IPv4 interfészen lo, 127.0.0.1#53 Jul 5 18:12:43 dns-server on IPv4 interfész, 18:12:43 dns-szerver 1 júl. 5 18:12:43 dns-server named: munkamenetkulcs generálása a dinamikus DNS-hez 5. júl. 18:12:43 dns-server named: nem tudta beállítani a gyökér tippeket a "/etc/bind/db.root"-ból: fájl nem található júl. 5 18:12:43 konfigurációs fájl nem található 5 júl 18:12:43 konfigurációs fájl:1 nem található 43 dns-szerver megnevezése: kilépés (végzetes hiba miatt) júl. 5 18:15:05 dns-szerver megnevezése: induló BIND 9.7.3 -u bind Jul 5 18:15:05 d ns-szerver neve: build with "--prefix=/usr"-/usr"-/usr"-/usr"-/usr"-/usr" hare/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" " --with-openssl=-/usg"ssapi "-with-openssl=/usr" --with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=y es CF" "---us-en-r"oip "---us-en-r" no-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" júl. 5 18:15:05 dns-server named: a megnyitott fájlok korlátja 1024 és 1048576 között 1024 és 1048576 között július 5 18:15:05 dns-server1 18: dns-server1 8. szál: 1 szál: talált 1. CPUd dns-server named: maximum 4096 socket használata júl 5 18:15:05 dns-server named: konfiguráció betöltése innen: "/etc/bind/named.conf" júl 5 18:15:05 dns-server named: alapértelmezett UDP/IPv4 kiszolgáló használata: alapértelmezett UDP/IPv4 port tartomány használata: júl.np5:serv1 port tartomány:18:15:15 szervernév 6 port tartomány: júl. 5 18:15:05 dns-szerver neve: figyel az IPv4 interfészen lo, 127. 0.0.1#53 júl. 5 18:15:05 dns-szerver megnevezése: figyel az IPv4 interfészen eth1, 192.168.1.1#53 júl. 5 18:15:05 dns-szerver neve: automatikus üres zóna: 254.169.IN-ADDRns:1ARPA name automata 5-0ARPA:automatikus AD5-5:serverd. üres zóna: 2.0 .192.IN-ADDR.ARPA júl. 5 18:15:05 dns-szerver neve: automatikus üres zóna: 100.51.198.IN-ADDR.ARPA Jul 5 18:15:05 dns-szerver neve: automatikus üres zóna: 0.0.0.0.0.0.0.0.0.0.0 " .0.0.0.IP6.ARPA 5 18:15:05 dns-szerver megnevezése: júl automatikus üres zóna: D.F.IP6.ARPA júl. 5 18:15:05 dns-szerver megnevezése: automatikus üres zóna: 8.E.F.IP6.ARPA júl. 5 18:15:05 Automatikus zóna IP dn.6:05. júl 5 : automatikus üres zóna: B.E.F.IP6.ARPA júl 5 18:15:05 dns-szerver neve: automatikus üres zóna: 8.B.D.0.1.0.0.2.IP6.ARPA július 5 18:15:05 dns-szerver neve: zóna betöltve 0.in-serial 5:0 júl. dns-szerver neve: 1. zóna 27.in-addr.arpa/IN: betöltött soros 1. július 5. 18:15:05 dns-szerver neve: zóna

Kiváló diagnosztikai eszközök.

Összegzés

Ebben a cikkben leírtam, hogyan kell beállítani az alapvető BIND-kiszolgáló DNS-konfigurációit. Ennek a cikknek az volt a célja, hogy képet adjon arról, hogyan működik a BIND szerver UNIX rendszeren. Gyakorlatilag nem érintettem a DNS biztonsági kérdéseket, és keveset érintettem az olyan specifikus beállításokat, mint a szerver működése él módban, amikor különböző hálózatok adott különféle információk a zónáról (zónákról). A mélyebb megértés érdekében adok egy listát a további forrásokról, amelyekben remélem sikerül beszerezni a szükséges információkat. ennek véget vetettem. Viszlát.

Domain név rendszer: http://citforum.ru/internet/dns/khramtsov/
RFC 1034- Domain nevek - Koncepciók és szolgáltatások: http://tools.ietf.org/html/rfc1034
RFC 1035- Domain nevek - Megvalósítás és specifikáció: http://tools.ietf.org/html/rfc1035
RFC 1537- Gyakori DNS-adatfájl-konfigurációs hibák: http://tools.ietf.org/html/rfc1537
RFC 1591- A domain névrendszer felépítése és delegálása: http://tools.ietf.org/html/rfc1591
RFC 1713- DNS-hibakeresési eszközök: http://tools.ietf.org/html/rfc1713
RFC 2606- Fenntartott legfelső szintű DNS-nevek: http://tools.ietf.org/html/rfc2606
DNS biztonság (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 Adminisztrátori kézikönyv: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Biztonságos BIND sablon: http://www.cymru.com/Documents/secure-bind-template.html
A konfigurációs paraméterek jól meghatározottakorosz: http://www.bog.pp.ru/work/bind.html
Zónafájl automatikus létrehozása: http://www.zonefile.org/?lang=en#zonefile

Évről évre nő az internet sebessége – mind az utolsó mérföld, mind a fő csatornák – sebessége. Csak egy dolog változatlan – a késleltetés már szembekerült a fizikai korlátokkal: a fénysebesség egy optikai szálban körülbelül 200 ezer kilométer/másodperc, és ennek megfelelően ~150 ms-nál gyorsabban belátható időn belül nem fogadható válasz az Atlanti-óceánon túli szerverről (bár persze vannak sallangok, például légmagos kommunikáció, optikai szál vagy rádiórelé nehezen elérhető).

Amikor például Oroszországból megpróbálunk megnyitni egy Egyesült Államokban található webhelyet (valószínűleg ott van az NS-kiszolgálója), és a domain nem található a szolgáltató DNS-gyorsítótárában, akkor még egy gigabites interneten is sokáig várni kell, talán egy egész másodpercet is: amíg meg nem kapjuk az óceánon túli tartomány NS-szervereinek nevét, amíg el nem küldjük és meg nem oldjuk a tényleges DNS-kérésüket,

Néhány éve a Google elindította nyilvános DNS-szervereit, és az ezekre való átállás elősegítése érdekében kifejlesztették a NameBench segédprogramot, amely DNS-teszteket futtat a böngészési előzményeken, és megmutatja, hogy a Google DNS mennyivel gyorsabb, mint az internetszolgáltató DNS-kiszolgálója.

De sikerült működésre bírnom a DNS szerveremet gyorsabb, mint a google Nyilvános DNS, és ebben a rövid megjegyzésben szeretném megosztani az eredményeket.

PDNSD

pdnsd- DNS-proxy gyorsítótárazása. A DNS-lekérdezések banális gyorsítótárazása mellett (a minimális TTL hardkódolásának lehetőségével - ez szükséges lehet nagyon rossz internet), egyidejűleg több „szülő” DNS-kiszolgálónak is elküldheti a kérést, és megadhatja az ügyfélnek az első visszaadott választ.

A párhuzamos szavazás alkalmazása jelenti a fő előnyt a gyorsaság terén., mert Ha bármelyik szolgáltató gyorsítótárában megtaláljuk az eredményt, nagyon gyorsan megkapjuk az eredményt, és nem várunk teljes és lassú feloldásra, ha az első szolgáltató nem válaszol a gyorsítótárban.

Ubuntuba telepítve - banális apt-get.

Pár dolog a konfigurációban

global ( perm_cache=10240; //A gyorsítótár maximális mérete kilobájtban. //Alapértelmezés szerint 1024 volt, az összes rekord nem fért el. cache_dir="/var/cache/pdnsd"; [...] min_ttl=60m; // A rekord gyorsítótárban való tárolásának minimális ideje kevesebb lesz, mint 6 perc, ha a TTL 0 perc = 6 perc lesz. //E 1w; // A rekord gyorsítótárban való mentésének maximális ideje neg_ttl=5m; //A negatív válaszok gyorsítótárazásának ideje (vagyis ha a tartomány nem található) [..] par_queries=3; //Egyszerre lekérdezett "szülő" DNS-szerverek száma ) szerver ( label = "main"; ip = 85.21 ha nem a kérés, akkor a válasz nem a 3, akkor a 3 /192.21. a 4.-re lesz elküldve, 213.234.192.7 //Az első 2 szerver a szolgáltatód szervere, és néhány szomszédos, 8.8.4.4 //Ez a Google Public DNS - minden ritka gyorsítótárban van, és gyorsan megoldják, 8.8.8.8 ; [..] )

A gyorsítótárazást elvileg kevésbé agresszívvé lehet tenni (pl. min_ttl=1m), de a működés évében nem volt különösebb probléma. Probléma esetén - ha szeretné, törölhet egy bejegyzést a gyorsítótárból:
sudo pdnsd-ctl rekord 3.14. törléssel vagy egyszerre:
sudo pdnsd-ctl üres gyorsítótár

Teszt eredmények a NameBenchben



Azt látjuk, hogy a lekérdezések 50%-ára 10 ms-nál rövidebb idő alatt kapunk választ, 85%-ban gyorsabban, mint a Google Public DNS, majd az eredmények természetesen egybeesnek a Google-lel.

A teszteredmények szerint NameBench boldogan közli velünk:

8.8.8.8 A SYS-192.167.0.98 lassabb replikája 8.8.4.4 A SYS-192.167.0.98 lassabb replikája

Így egy intelligens gyorsítótárazású DNS-proxy párhuzamos kérésekkel lehetővé teszi akár a 100 megabites internet felgyorsítását is. A lassú (rádió) kapcsolatoknál pedig nagy késleltetéssel és csomagvesztéssel a különbség olyan lehet, mint ég és föld között.

A DNS célja, hogy az emberek által könnyen megjegyezhető tartományneveket a számítógépek számára érthető IP-címekké fordítsa le. Ezt a folyamatot névfeloldásnak nevezik.
Mit ad nekünk a saját caching DNS szerverünk telepítése?!
Ez kissé felgyorsítja a webhelyek válaszát + a Linux nem érzékeli túl jól a NetBios neveket, és néha számítógépeket vagy nyomtatókat kell találnia a helyi hálózaton belül, de ezt név szerint akarja megtenni.
Az IP-címek megjegyezése nem kényelmes, de a DHCP-kiszolgáló naplójába való folyamatos mászás szintén nem a mi módszerünk. Ilyen esetekben DNS-re van szükség a helyi hálózatban.
Maga a bind9 csomag telepítése nem nehéz, a dugások általában a konfiguráció szakaszában merülnek fel, mert a rendszer könnyen olvasható konfigurációs fájljai után egy érthetetlen szintaxis esik az emberre, egyébként nagyon hasonló a C programozási nyelvhez. a szerver a helyi hálózaton belül fog működni, akkor nincs értelme chroot környezetbe vinni, és az egész beállítás nagyon kevés időt vesz igénybe.
Ezen a lírai rész befejezhető, folytatjuk a telepítést és a konfigurációt.
Telepítse a Bind9 DNS-kiszolgálót:
sudo apt-get install bind9
Miután elkészült, letöltöttük és telepítettük, módosítanunk kell a konfigurációs fájlt:
sudo nano /etc/bind/named.conf.options
Megtaláljuk a részt, a konfigurációs fájl legelején található, rajta kívül nincs más ...

Options ("/var/cache/bind" könyvtár; // Ha tűzfal van közted és azok között a névszerverek között, amelyekkel // beszélni szeretnél, akkor előfordulhat, hogy meg kell javítanod a tűzfalat, hogy több // port is kommunikálhasson. Lásd: http://www.kb.cert.org/vuls/id/800113 // Ha az internetszolgáltató egy vagy több untable IP-címet adott meg // a kiszolgálók /com továbbítóihoz. következő blokk, és helyezze be a // az all-0" helyőrzőjét helyettesítő címek. // továbbítók ( // 0.0.0.0; // ); auth-nxdomain no; # megfelel az RFC1035 listen-on-v6 ( any; ); );

A továbbítók részleg felelős azért, hogy hova kerüljön a névfeloldásra vonatkozó DNS-kérés, ha az nincs a saját adatbázisában. Az utóbbi időben egyáltalán nem vagyok elégedett, ezeknek a szervereknek a munkája a szolgáltatónál csatlakoztatható harmadik féltől származó szerverekhez, például Google-hoz, nagyon könnyű megjegyezni az IP 8.8-at.

Szerkesztjük a részt, először el kell távolítania a megjegyzéseket, és hozzá kell adnia harmadik fél DNS-ét, ha több szervert kell hozzáadni, például, ha a google szerver nem bírja a kéréseit, és megszakad :), akkor a többi szerver IP-je beírható egy oszlopba, akkor jelentősebb hibatűrést érhet el.
továbbítók ( 8.8.8.8; 193.58.251.251; //orosz DNS szolgáltatás -SkyDNS );
Ebben a részben jobb, ha megadja a fájlban megadott kiszolgáló IP-címét /etc/resolv.conf vagy írja be oda a szakaszba névszerver ezt az IP-t
Változtatások mentése és kilépés
Indítsa újra a szervert és ellenőrizze
Toborzás be parancs sor nslookup mail.ru
Ki kell adnia:

Nem hiteles válasz: Név: mail.ru Címek: 94.100.191.202
Ez arra utal, hogy nem a mi szerverünk a fő a zóna kiszolgálásában (mail.ru), de a kérések a gyorsítótárba kerültek!
Most létre kell hoznunk egy DNS zónát a hálózatunkhoz, hogy a gépek megtalálják a különféle hálózati szolgáltatásokat - lehetnek például hálózati nyomtatók, ezek lehetnek függetlenek vagy megosztottak más munkaállomásokon.
A mi zónánkat nevezhetjük orgname -i.e. A szervezet neve.
Először is létrehozunk egy zónát, ehhez szerkesztjük named.conf.local

sudo nano /etc/bind/named.conf.local
és adjuk hozzá a következőket:
zóna "orgname" (típus master; fájl "/etc/bind/db.orgname"; );
Mentés és kilépés
Most létre kell hoznunk egy zóna konfigurációs fájlt
sudo nano /etc/bind/db.orgname
és illessze be a következőket:
(Kérjük, ügyeljen a konfigurációs fájl szintaxisára, még a pontok is számítanak)

@ IN SOA szervezetnév. root.orgname. (20101015 4h ; ​​frissítési idő -4 óra 1h ; ismétlés óránként 1h ; mennyi ideig tárolják az információkat -1 hét 1d) ; TTL (élettartam) rekordok – 1 nap @ IN NS szervezetnév. ; névkiszolgáló neve @ IN A 192.168.10.1 ; A - rekord - az ezt a zónát kiszolgáló DNS-kiszolgálónk IP-címe, a @ azt jelenti, hogy ez a gyökérzóna. * IN CNAME @ nyomtató IN A 192.168.10.25 ; Létrehozhat DNS rekordot hálózati nyomtató amely a 192.168.10.25

Most, amikor újat ad hozzá hálózati eszköz, 2 dolgot kell tenned:
1) Foglaljon le egy IP-címet DHCP szerver hogyan kell ezt megtenni, elolvashatja a cikkben-
2) Hozzon létre egy DNS-zónát ehhez az IP-címhez, például eszköznevet A XXX.XXX.XXX.XXX. Ahol: eszköznév - az eszköz hálózati neve; A XXX.XXX.XXX.XXX a DHCP-kiszolgálón lefoglalt IP-cím.

Most szerkesztenünk kell a resolv.conf fájlt

sudo nano /etc/resolv.conf

És írd be oda:

Névszerver 127.0.0.1

Minden, ami ott volt, kommentálható a # beírásával

A szerver újraindítása

Ez úgy történik, hogy a szerver mindent a saját adatbázisában keres, és a BIND csak ezután irányítja át a kéréseket arra a 8.8.8.8-as szerverre, amelynek IP-címe be van írva a direktívába. szállítmányozók.

Most ellenőrizheti, hogy működik-e:

Ha a tesztelés Windows alatt történik:
ping eszköznév.szervezetnév

Ha Linux alatt teszteljük:
ping eszköznév.orgnév -c 4
A pingeknek az Ön által megadott IP-címre kell menniük a XXX.XXX.XXX.XXX helyett

Ezzel befejeződik a DNS-kiszolgáló beállítása.

Évről évre nő az internet sebessége – mind az utolsó mérföld, mind a fő csatornák – sebessége. Csak egy dolog változatlan – a késleltetés már szembekerült a fizikai korlátokkal: a fénysebesség egy optikai szálban körülbelül 200 ezer kilométer/másodperc, és ennek megfelelően ~150 ms-nál gyorsabban belátható időn belül nem fogadható válasz az Atlanti-óceánon túli szerverről (bár persze vannak sallangok, például légmagos kommunikáció, optikai szál vagy rádiórelé nehezen elérhető).

Amikor például Oroszországból megpróbálunk megnyitni egy Egyesült Államokban található webhelyet (valószínűleg ott van az NS-kiszolgálója), és a domain nem található a szolgáltató DNS-gyorsítótárában, akkor még egy gigabites interneten is sokáig várni kell, talán egy egész másodpercet is: amíg meg nem kapjuk az óceánon túli tartomány NS-szervereinek nevét, amíg el nem küldjük és meg nem oldjuk a tényleges DNS-kérésüket,

Néhány éve a Google elindította nyilvános DNS-szervereit, és az ezekre való átállás elősegítése érdekében kifejlesztették a NameBench segédprogramot, amely DNS-teszteket futtat a böngészési előzményeken, és megmutatja, hogy a Google DNS mennyivel gyorsabb, mint az internetszolgáltató DNS-kiszolgálója.

De sikerült létrehoznom egy saját DNS-szervert, amely gyorsabb, mint a Google Public DNS, és ebben a rövid megjegyzésben szeretném megosztani az eredményeket.

PDNSD

pdnsd- DNS-proxy gyorsítótárazása. A DNS-kérelmek banális gyorsítótárazásán túl (a minimális TTL hardkódolásának lehetőségével - nagyon rossz interneten szükséges lehet), egyidejűleg több „szülő” DNS-kiszolgálónak is elküldheti a kérést, és megadhatja az ügyfélnek az első visszaadott választ.

A párhuzamos szavazás alkalmazása jelenti a fő előnyt a gyorsaság terén., mert Ha bármelyik szolgáltató gyorsítótárában megtaláljuk az eredményt, nagyon gyorsan megkapjuk az eredményt, és nem várunk teljes és lassú feloldásra, ha az első szolgáltató nem válaszol a gyorsítótárban.

Ubuntuba telepítve - banális apt-get.

Pár dolog a konfigurációban

global ( perm_cache=10240; //A gyorsítótár maximális mérete kilobájtban. //Alapértelmezés szerint 1024 volt, az összes rekord nem fért el. cache_dir="/var/cache/pdnsd"; [...] min_ttl=60m; // A rekord gyorsítótárban való tárolásának minimális ideje kevesebb lesz, mint 6 perc, ha a TTL 0 perc = 6 perc lesz. //E 1w; // A rekord gyorsítótárban való mentésének maximális ideje neg_ttl=5m; //A negatív válaszok gyorsítótárazásának ideje (vagyis ha a tartomány nem található) [..] par_queries=3; //Egyszerre lekérdezett "szülő" DNS-szerverek száma ) szerver ( label = "main"; ip = 85.21 ha nem a kérés, akkor a válasz nem a 3, akkor a 3 /192.21. a 4.-re lesz elküldve, 213.234.192.7 //Az első 2 szerver a szolgáltatód szervere, és néhány szomszédos, 8.8.4.4 //Ez a Google Public DNS - minden ritka gyorsítótárban van, és gyorsan megoldják, 8.8.8.8 ; [..] )

A gyorsítótárazást elvileg kevésbé agresszívvé lehet tenni (pl. min_ttl=1m), de a működés évében nem volt különösebb probléma. Probléma esetén - ha szeretné, törölhet egy bejegyzést a gyorsítótárból:
sudo pdnsd-ctl rekord 3.14. törléssel vagy egyszerre:
sudo pdnsd-ctl üres gyorsítótár

Teszt eredmények a NameBenchben



Azt látjuk, hogy a lekérdezések 50%-ára 10 ms-nál rövidebb idő alatt kapunk választ, 85%-ban gyorsabban, mint a Google Public DNS, majd az eredmények természetesen egybeesnek a Google-lel.

A teszteredmények szerint NameBench boldogan közli velünk:

8.8.8.8 A SYS-192.167.0.98 lassabb replikája 8.8.4.4 A SYS-192.167.0.98 lassabb replikája

Így egy intelligens gyorsítótárazású DNS-proxy párhuzamos kérésekkel lehetővé teszi akár a 100 megabites internet felgyorsítását is. A lassú (rádió) kapcsolatoknál pedig nagy késleltetéssel és csomagvesztéssel a különbség olyan lehet, mint ég és föld között.

Ha hibát észlel, jelöljön ki egy szövegrészt, és nyomja meg a Ctrl + Enter billentyűket
OSSZA MEG: