Akik követték a 1, 2da, 3 y 4ta A cikk egy része és a BIND-hez intézett konzultációk kielégítő eredményeket hoztak, ők már a téma szakértői. :-) És minden további nélkül térjünk rá az utolsó részre:
- A 10.168.192.in-addr.arpa “Inverse” típusú Main Master Zone fájl létrehozása
- hibaelhárítás
- Összegzés
A 10.168.192.in-addr.arpa “Inverse” típusú Main Master Zone fájl létrehozása
A terület neve elhozza neked, igaz? És a fordított zónák kötelezőek az internetes szabványoknak megfelelő helyes névfeloldáshoz. Nincs más választásunk, mint létrehozni a domainünknek megfelelőt. Ehhez sablonként használjuk a fájlt /etc/bind/db.127:
cp /etc/bind/db.127 /var/cache/bind/192.168.10.rev
Szerkesztjük a fájlt /var/cache/bind/192.168.10.rev és így hagyjuk:
; /var/cache/bind/192.168.10.rev; ; BIND fordított adatfájl a főzónához 10.168.192.in-addr.arpa; BIND adatfájlok a Master Zone (Reverse) számára 10.168.192.in-addr.arpa; $ TTL 604800 @ IN SOA ns.amigos.cu. root.amigos.cu. (2; Sorozat 604800; Frissítés: 86400; Újrapróbálkozás: 2419200; Lejárat: 604800); Negatív gyorsítótár TTL; @ IN NS ns. 10 IN PTR ns.amigos.cu. 1 IN PTR gandalf.amigos.cu. 9 IN PTR mail.amigos.cu. 20 IN PTR web.amigos.cu. 100 IN PTR fedex.amigos.cu. ; beírhatjuk a teljes IP-címet is. Volt:; 192.168.10.1 PTR-ben gandalf.amigos.cu.
- Figyelje meg, hogy ebben az esetben hagytuk-e az időket másodpercekben, ahogy alapértelmezés szerint létrejön, amikor a kötés9. Ugyanúgy működik. Ezek megegyeznek az aktában feltüntetett időkkel friends.cu.host. Ha kétségei vannak, ellenőrizze.
- Azt is vegye figyelembe, hogy csak azoknak a gazdagépeknek a fordított rekordjait deklaráljuk, amelyeknek a mi LAN-on van hozzárendelt vagy "valódi" IP-címe, és amelyek egyedileg azonosítják azokat.
- Ne felejtse el frissíteni a Reverse Zone fájlt MINDEN közvetlen IP-címmel, amelyet a Direct Zone-ban deklarált.
- Ne felejtse el növelni a Zóna sorozatszáma minden alkalommal, amikor módosítják a fájlt, és mielőtt újraindítanák a BIND-t.
Ellenőrizzük az újonnan létrehozott zónát:
named-checkzone 10.168.192.in-addr.arpa /var/cache/bind/192.168.10.rev
Ellenőrizzük a konfigurációt:
named-checkconf -z named-checkconf -p
Ha minden rendben van, akkor újraindítjuk a szolgáltatást:
szolgáltatás bind9 indítsa újra
Mostantól minden alkalommal, amikor a zónafájlokat módosítjuk, csak végre kell hajtanunk:
rndc újratöltés
Ehhez deklaráljuk a kulcsot /etc/bind/named.conf.options, nem?
hibaelhárítás
Nagyon fontos a fájl helyes tartalma / Etc / resolv.conf amint azt az előző fejezetben láttuk. Ne felejtse el feltüntetni benne legalább a következőket:
keresés az amigos.cu névkiszolgálón 192.168.10.20
parancs ás a csomagot dnsutil. Írja be a konzolra a # előtte lévő parancsokat:
# dig -x 127.0.0.1 ..... ;; VÁLASZSZEKCIÓ: 1.0.0.127.in-addr.arpa. 604800 IN PTR localhost. .... # dig -x 192.168.10.9 .... ;; VÁLASZSZEKCIÓ: 9.10.168.192.in-addr.arpa. 604800 IN PTR mail.amigos.cu. .... # host gandalf gandalf.amigos.cu címe 192.168.10.1 # host gandalf.amigos.cu gandalf.amigos.cu címe 192.168.10.1 # dig gandalf; << >> DiG 9.7.2-P3 << >> gandalf ;; globális opciók: + cmd ;; kapcsolat időtúllépés; egyetlen szervert sem sikerült elérni # dig gandalf.amigos.cu .... ;; VÁLASZ SZEKCIÓ: gandalf.amigos.cu. 604800 IN A 192.168.10.1 .... Ha hozzáférnek a kubai vagy a globális internethez, és a szállítmányozók helyesen vannak deklarálva, próbálkozzon: # dig debian.org .... ;; KÉRDÉS SZEKCIÓ :; debian.org. A-ban ;; VÁLASZ SZEKCIÓ: debian.org. 3600 IN A 86.59.118.148 debian.org. 3600 IN A 128.31.0.51 .... # host bohemia.cu bohemia.cu címe 190.6.81.130 # host yahoo.es yahoo.es címe 77.238.178.122 yahoo.es címe 87.248.120.148 yahoo.es levelek kezelése által 10 mx-eu.mail.am0.yahoodns.net. # dig -x 77.238.178.122 ;; VÁLASZSZEKCIÓ: 122.178.238.77.in-addr.arpa. 429 IN PTR w2.rc.vip.ird.yahoo.com.
… És általában a LAN-on kívüli más tartományokkal. Konzultáljon és találjon meg érdekes dolgokat az interneten.
Az egyik legjobb módszer a szerver teljesítményének ellenőrzésére kötés9, és általában bármely más telepített szolgáltatás, a Rendszernapló üzenetek a parancs segítségével tail -f / var / log / syslog futtatás felhasználókéntgyökér.
Nagyon érdekes látni a parancs kimenetét, amikor a helyi BIND-nek kérdést teszünk fel egy külső tartományról vagy gazdagépről. Ebben az esetben több forgatókönyv is bemutatható:
- Ha nincs hozzáférésünk az internethez, lekérdezésünk sikertelen lesz.
- Ha van hozzáférésünk az internethez, és NEM jelentettük be a szállítmányozókat, akkor valószínűleg nem kapunk választ.
- Ha van hozzáférésünk az internethez, és kijelentettük a szállítmányozókat, választ kapunk, mivel ők felelnek a szükséges DNS-szerver vagy -szerverek megkereséséért.
Ha azon dolgozunk, hogy a LAN bezárva amikor semmilyen módon lehetetlen külföldre menni és nincsenek bármilyen szállítmányozóink, megszüntethetjük a Gyökérszerverek A fájl "ürítése" /etc/bind/db.root. Ehhez először más néven mentjük a fájlt, majd töröljük az összes tartalmát. Ezután ellenőrizzük a konfigurációt és újraindítjuk a szolgáltatást:
cp /etc/bind/db.root /etc/bind/db.root.original cp / dev / null /etc/bind/db.root named-checkconf -z named-checkconf -p service bind9 restart
Összegzés
Eddig emberek, egy kis bemutatkozás a DNS szolgáltatásról. Amit eddig tettünk, az tökéletesen szolgálhat kisvállalkozásaink számára. A ház számára is, ha különböző operációs rendszerekkel és különböző IP-címmel készítünk virtuális gépeket, és nem IP-vel, hanem név szerint akarunk rájuk hivatkozni. Mindig telepítek egy BIND-t otthoni gazdagépemre a DNS-szolgáltatástól nagymértékben függő szolgáltatások telepítéséhez, konfigurálásához és teszteléséhez. Széles körben használom az asztali számítógépeket és a virtuális szervereket, és nem szeretek fájlt tartani / Etc / hosts mindegyik gépben. Túl sokat tévedek.
Ha még soha nem telepítette és konfigurálta a BIND-t, kérjük, ne halasztsa el, ha az első próbálkozáskor valami baj történik, és elölről kell kezdenie. Ezekben az esetekben mindig javasoljuk, hogy tiszta telepítéssel kezdje. Megér egy próbát!
Azok számára, akiknek magas rendelkezésre állásra van szükségük a névfeloldási szolgáltatásban, amelyet egy másodlagos mester szerver konfigurálásával lehet elérni, javasoljuk, hogy folytassa velünk a következő kalandot: Másodlagos mester DNS egy LAN számára.
Gratulálok azoknak, akik követték az összes cikket és elérték a várt eredményeket!
Végre! .. az utolsó hozzászólás: D!
Köszönöm, hogy megosztottad a barátomat!
Üdvözlet!
Nagyon érdekes, a cikkei, van egy hiteles DNS-em, amelyet egy freeBSD-ben állítottam fel egy .edu.mx domain számára, eddig tökéletesen működött nekem, de az elmúlt hónapban több támadást is észleltem a szerver felé, mi lenne a védekezési módszer Egy kitett DNS-t? És nem tudom, hogy lehet-e, a mester legyen kitéve az internetnek, és legyen egy másodlagos, amely kb. 60 számítógépből álló kis sávot szolgál ki, mindkettő összekapcsolva a DNS-t, vagy hogy képes legyen két zónát meghatározni, egy belső és egy külső, köszönhetően a fő-
A squeeze bind9 csomagnak problémája van a sambával való együttműködésben, a 9.8.4-es verzió már elérhető a squeeze backports ágában, a wheeze verzióval nincs ilyen probléma, a lenny venenux.net számára a backport fogja a csomagot.
Nagyon jó cikk.
Ez az egyetlen cikk, amely mindent jól megmagyaráz.
Meg kell jegyezni, hogy a spofing acl nem működik, mivel ugyanúgy befecskendezik a belső hálózatról, a megoldás az lenne, ha megtagadnánk az átirányításokat az ügyfelek számára, és létrehoznánk egy összetett acl-t, amely megakadályozza a nevek újbóli hozzárendelését (valami hasonló a statikus dns-hez)
KÜLÖNLEGES TIPP:
jó lenne egy extra konfiguráció arra, hogyan lehet a tűzfal helyett a dns szűrő tartalmát elkészíteni
Köszönöm, hogy hozzászóltál @PICCORO !!!.
Minden cikkem elején kijelentem, hogy nem tartom magam szakembernek. Sokkal kevésbé a DNS kérdésben. Itt mindannyian megtanuljuk. Az Ön ajánlásait figyelembe veszem, amikor DNS-t telepítek az internet felé, nem pedig normál és egyszerű LAN-ra.
Kiváló oktatóanyag !!! Nagy segítség volt számomra, mivel most indultam el ebben a szerverfordulóban, minden rendben működött. Köszönöm és folyamatosan publikálsz ilyen csodálatos oktatóanyagokat !!!
Fico, még egyszer gratulálok ehhez a nagyszerű anyaghoz.
Nem vagyok a BIND9 szakértője, bocsásson meg, ha tévedek a megjegyzéssel kapcsolatban, de úgy gondolom, hogy hiányzott a zóna meghatározása a fordított keresésekhez a named.conf.local fájlban
Kár, hogy Fico most nem tud válaszolni neked.
Üdvözlet és köszönet, Elav, és itt válaszolok. Mint mindig, ajánlom, hogy lassan olvassa el ... 🙂
A bejegyzésben: https://blog.desdelinux.net/dns-maestro-primario-para-una-lan-en-debian-6-0-iii/
A következőket írom:
Az /etc/bind/named.conf.local fájl módosítása
Ebben a fájlban deklaráljuk domainünk helyi zónáit. Minimálisan tartalmaznunk kell az előre és a hátramenet zónákat. Ne feledje, hogy az /etc/bind/named.conf.options konfigurációs fájlban deklaráljuk, hogy melyik könyvtárban fogjuk tárolni a Zónák fájlokat a könyvtár irányelv segítségével. Végül a fájlnak a következőnek kell lennie:
// /etc/bind/named.conf.local
//
// Itt végezzen bármilyen helyi konfigurációt
//
// Fontolja meg az 1918-as zónák ide történő hozzáadását, ha azokat nem használja a
// szervezet
// tartalmazza: "/etc/bind/zones.rfc1918";
// Az egyes zónák fájljainak neve a
// fogyasztói ízlés. A friends.cu.hostokat választottuk
// és 192.168.10.rev, mert világosságot adnak nekik
// tartalom. Nincs több rejtély 😉
//
// A zónák neve NEM VÁLASZTOTT
// és meg fognak felelni a domainünk nevének
// és a LAN alhálózatra
// Fő főzóna: «Közvetlen» típus
zóna «amigos.cu» {
típus mester;
fájl "amigos.cu.hosts";
};
// Fő főzóna: «inverz» típus
zóna "10.168.192.in-addr.arpa" {
típus mester;
fájl: "192.168.10.rev";
};
// A named.conf.local fájl vége
Jó, nagyon érdekes a dns-ről szóló bejegyzésed, segítettek abban, hogy elinduljak a témában, köszönöm. Tisztázom, hogy ebben a tekintetben újonc vagyok. De a közzétett információkat olvasva azt tapasztaltam, hogy azok fix címmel működnek a belső hálózat gazdagépein. A kérdésem az, hogy hogyan tenne egy dinamikus IP-címmel rendelkező belső hálózattal, amelyet egy dhcp szerver rendel, a "fő" és a "fordított" típusú fő master zóna fájljainak létrehozásához?
Hálás leszek azért a fényért, amelyet adhat a felvetett kérdésben. Köszönöm. Fv
Köszönöm a hozzászólást, @fabian. Az alábbi cikkeket tekintheti meg, amelyek remélem, segítenek egy dinamikus címmel rendelkező hálózat megvalósításában:
https://blog.desdelinux.net/servicio-de-directorio-con-ldap-2-ntp-y-dnsmasq/
https://blog.desdelinux.net/servicio-de-directorio-con-ldap-3-isc-dhcp-server-y-bind9/
Üdvözlet