Sziasztok!
Adott egy tűzfal, rajta egy BIND, ami rendesen feloldja a belső és a külső címeket/neveket...
Ezen eddig voltak különböző belső tartományok, amiket rendesen le is kezelt master-ként.
Most az alhálózatok közül kiraktam alá egy másik szervert, amelyik több feladata mellett még BIND-et is futtat.
Erre a szerverre a saját tartományát áthoztam, azaz ez lett a master, az eredeti (a tűzfal) pedig slave lett ezekhez.
A tűzfalról kérdezve bármilyen cím/név (külső és belső is) simán feloldható.
Az új szerverről kérdezve a saját hálója és a külsős címek rendben feloldhatók, viszont bármilyen másik belső hálózat IP->név feloldására NXDOMAIN-t nyom...
Mit nézek be?
- 10010 megtekintés
Hozzászólások
Legközelebb érthetőbben írj, mert teljesen zűr és zavar, amit írsz.
Szerintem a válasz, hogy a tűzfalat állítsd be forwardernek az új szerveren.
- A hozzászóláshoz be kell jelentkezni
Részletekbe nem akartam menni, mert akkor az kb. 2 oldal beállítás lenne...
A hozzászólásodhoz: Már beállítottam... :D
No luck!
Alapban az új szerver csak a saját hálójáról tud, a többit a forward-er-en keresztül kérdezi meg... És a forwarder a tűzfal...
Az érdekes a dologban, hogy név->IP feloldás megy, IP->név viszont nem...
zones.rfc1918-ban kikommenteztem az adott tartományhoz tartozó sorokat az új szerveren, de semmi haszna...
Meg sem próbál kérdezni a tűzfaltól, hanem csak azt mondja rá, hogy NXDOMAIN...
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
"Részletekbe nem akartam menni, mert akkor az kb. 2 oldal beállítás lenne..."
Pedig általában célravezetőbb, mint számtalanszor visszakérdezni, pontosítani. Illetve próbáljunk meg kicsit szabatosabban fogalmazni!
"Alapban az új szerver csak a saját hálójáról tud"
Hálójáról?! Zónájáról, esetleg domainjéről. Vagy a reverse DNS-re gondolsz?
"név->IP feloldás megy, IP->név viszont nem..."
Igen, a reverse DNS feloldásra gondolsz.
"Meg sem próbál kérdezni a tűzfaltól, hanem csak azt mondja rá, hogy NXDOMAIN..."
Legegyszerűbb, ha a kérdéses zónára a tűzfal master lesz, a szerver pedig slave.
Másik lehetőségként megnézheted az empty-zones-enable és disable-empty-zone opciót.
- A hozzászóláshoz be kell jelentkezni
Nem szeretném ha a tűzfal lenne a master... Pont fordítva...
Nézem az ajánlott opciót! Köszi!
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
"Nem szeretném ha a tűzfal lenne a master... Pont fordítva..."
Lehet úgy is. Ez nem master-slave kérdés, hanem autoritás.
Viszont a fenti állításnak - miszerint a 0.168.192.in-addr.arpa zónára nem szeretnéd a tűzfalat masternek - ellentmond az, hogy jelenleg is az, és az írásból az tűnik ki, hogy ezen nem is akarsz változtatni. Viszont mint az előbb említettem, nem a master szerep a lényeg, hanem az, hogy autoritatív legyen. Az előző hozzászólásban is a második tagmondat volt a hangsúlyos.
Jó lenne már látni mindkét szerver releváns konfigrészleteit, mert még mindig nem egyértelmű. Tehát akkor összefoglalva:
Tűzfal (192.168.0.1, szerver1.a_subnet.cegnev.hu):
master: cegnev.hu (ebből a b_subnet.cegnev.hu delegálva a szerver2.b_subnet.cegnev.hu 192.168.1.1-re); 0.168.192.in-addr.arpa
slave: b_subnet.cegnev.hu; 1.168.192.in-addr.arpa
forwarder: -
Szerver (192.168.1.1, szerver2.b_subnet.cegnev.hu):
master: b_subnet.cegnev.hu; 1.168.192.in-addr.arpa
slave: -
forwarder: 192.168.0.1
Légy szíves, erősítsd meg, hogy jól szűrtem-e le az eddigiekből, és valóban így vannak beállítva a szervereid.
Ezen beállítások mellett...
a 192.168.0.1-et kérdezve:
szerver1.a_subnet.cegnev.hu: működik
szerver2.b_subnet.cegnev.hu: működik
rekurzív kérdés: működik
1.0.168.192.in-addr.arpa: működik
1.1.168.192.in-addr.arpa: működik
a 192.168.1.1-et kérdezve:
szerver1.a_subnet.cegnev.hu: működik
szerver2.b_subnet.cegnev.hu: működik
rekurzív kérdés: működik
1.0.168.192.in-addr.arpa: NXDOMAIN
1.1.168.192.in-addr.arpa: működik
Ha a 192.168.1.1-et nem akarod autoritatívvá tenni a 0.168.192.in-addr.arpa zónára, akkor még mindig javaslom megnézni a fent említett üres zónás opciókat. Sikerült kipróbálni? Lehet, hogy az RFC1918-as IP tartományok reverse zónáit a dokumentációban írtakkal ellentétben kivételként kezeli, és nem tiltja le ellentétben mégsem tiltja le. Milyen rendszeren futó milyen verziószámú ez a bind? (A stub zóna lehetőségét csak zárójelben említem meg.)
(Azt a kérdést inkább nem feszegetem, hogy valóban szükség van-e arra, hogy két DNS szerver ilyen konfigurációban működjön, illetve hogy ezt mennyire érdemes IP subnet alapján szétválasztani a DNS zónák autoritását.)
- A hozzászóláshoz be kell jelentkezni
Ok... Szerintem jobb, ha adok egy-két konfig részletet... :D
(A javasolt opció semmit nem segített...)
Ne zavarjon meg, hogy 192-es hálókat írtam korábban...
Tűzfalon (a zóna slave-je):
IP címei:
Publikus IP cím, 172.31.254.254, stb...
Zóna leírása:
server 172.31.254.140 {
keys { rndc-key; };
};zone "externals.cegnev.hu" {
type slave;
file "/etc/bind/db.externals.cegnev.hu";
masters { 172.31.254.140; };
allow-notify { 172.31.254.140; };
};zone "80.16.172.in-addr.arpa." {
type slave;
file "/etc/bind/db.80.16.172";
masters { 172.31.254.140; };
allow-notify { 172.31.254.140; };
};zone "81.16.172.in-addr.arpa." {
type slave;
file "/etc/bind/db.81.16.172";
masters { 172.31.254.140; };
allow-notify { 172.31.254.140; };
};Forwarderek:
ISP szerverei, 8.8.8.8, 8.8.4.4
Új szerveren (a zóna master-je):
IP címei:
172.31.254.140, 172.16.81.253
Zóna leírása:
server 172.31.254.254 {
keys { rndc-key; };
};zone "externals.cegnev.hu." {
type master;
file "/etc/bind/db.cegnev.hu";
allow-update { 127.0.0.1; key rndc-key; };
allow-transfer { 172.31.254.254; };
also-notify { 172.31.254.254; };
notify yes;
};zone "80.16.172.in-addr.arpa." {
type master;
file "/etc/bind/db.80.16.172";
allow-update { 127.0.0.1; key rndc-key; };
allow-transfer { 172.31.254.254; };
also-notify { 172.31.254.254; };
notify yes;
};zone "81.16.172.in-addr.arpa." {
type master;
file "/etc/bind/db.81.16.172";
allow-update { 127.0.0.1; key rndc-key; };
allow-transfer { 172.31.254.254; };
also-notify { 172.31.254.254; };
notify yes;
};Forwarderek:
172.31.254.254
A DNS szerverek a 172.31.254.0/24-es hálón (backend.cegnev.hu) látják egymást. Az tűfal autoratív a backend.cegnev.hu zónára (is)... Ezt a másik zónát fogom használni a további példákban is! (A backend.cegnev.hu nem látszik az Internet felől, de ez most nem számít!)
Névfeloldás a tűzfalon:
host ns.backend.cegnev.hu -> 172.31.254.254
host x1.backend.cegnev.hu -> 172.31.254.140
host ns.externals.cegnev.hu -> 172.16.81.253
host index.hu -> 217.20.130.97host 172.31.254.254 -> ns.backend.cegnev.hu
host 172.31.254.140 -> x1.backend.cegnev.hu
host 172.16.81.253 -> ns.externals.cegnev.hu
host 217.20.130.97 -> sportgeza.hu
Névfeloldás az új szerveren:
host ns.backend.cegnev.hu -> 172.31.254.254
host x1.backend.cegnev.hu -> 172.31.254.140
host ns.externals.cegnev.hu -> 172.16.81.253
host index.hu -> 217.20.130.97host 172.31.254.254 -> NXDOMAIN
host 172.31.254.140 -> NXDOMAIN
host 172.16.81.253 -> ns.externals.cegnev.hu
host 217.20.130.97 -> sportgeza.hu
(Azt a kérdést inkább nem feszegetem, hogy valóban szükség van-e arra, hogy két DNS szerver ilyen konfigurációban működjön, illetve hogy ezt mennyire érdemes IP subnet alapján szétválasztani a DNS zónák autoritását.)
A két szerver nem egy helyen dolgozik, hanem VPN-en keresztül látják egymást... Az externals tartományban az ns még DHCP szerver is... Így a saját zónáját el tudja látni mint egy DNS+DHCP kiszolgáló. De tényleg ne menjünk bele :D
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
host 172.31.254.254 -> ns.backend.cegnev.hu
host 172.31.254.140 -> x1.backend.cegnev.hu
host 172.31.254.254 -> NXDOMAIN
host 172.31.254.140 -> NXDOMAIN
Nem másoltad be, így visszakérdezek. Hol van, illetve hol kellene lennie a 254.31.172.in-addr.arpa zónának? Mert a tűzfal valahonnan ismeri a kérdezett rekordokat...
- A hozzászóláshoz be kell jelentkezni
A tűzfalon...
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
1.) Tehát a tűzfalon van a... konkrétan mi is? A 254.31.172.in-addr.arpa? Vagy a 31.172.in-addr.arpa?
2.) A szerverről a tűzfalat kérdezve a tűzfal rendben válaszol a 254.254.31.172.in-addr.arpa és 140.254.31.172.in-addr.arpa PTR rekordját firtatva?
3.) A 31.172.in-addr.arpa biztos nem maradt szerver helyi zónái között?
rndc dumpdb -zones ; grep 172.in-addr.arpa /var/cache/bind/named_dump.db4.) Kipróbáltam a te konfigoddal (nincs 31.172.in-addr.arpa zóna; forwarders beállítva), és szépen kimegy a kérés a forwarder felé. Forwarder nélkül is a root felé.
a)
Debian 7.0 Wheezy; bind9 1:9.8.4.dfsg.P1-6; BIND 9.8.4-rpz2+rl005.12-P1
named[22254]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones
Erre írtam az előző hozzászólásomban, hogy "Lehet, hogy az RFC1918-as IP tartományok reverse zónáit a dokumentációban írtakkal ellentétben kivételként kezeli, és nem tiltja le ellentétben mégsem tiltja le.". Most már biztos.
b)
Debian 6.0.7 Squeeze; bind9 1:9.7.3.dfsg-1~squeeze9; BIND 9.7.3
5.) Milyen rendszeren futó milyen verziószámú ez a bind?
6.) Ha sehogy máshogy nem megy, akkor esetleg vedd fel stubként.
- A hozzászóláshoz be kell jelentkezni
1. 254.32.172.in-addr.arpa... (És még sok más is...)
2. Igen... feloldja...
3. Sosem volt, mivel új szerver...
4-5. bind9 1:9.9.2.dfsg.P1-2 mindkét helyen
Amit még észrevettem, hogy a belső hálós nevek feloldása lassabban megy... (akarmi.cegnev.hu) De ez gondolom azért, mert első körben próbálja a cegnev.hu-ban megkeresni, de mivel ezek nem valós Internetes nevek, végül a forwarder-hez fordul... Viszont nem értem, hogy miért nem kérdezi meg (mert nincs forgalom) az általa nem ismert zónákról a forwarder-r...
Valószínű összefügg az empyt-zones dolgokkal... Viszont ahogy írtam egy korábbi hozzászólásban a zones.rfc1918-ban kikommenteltem ezeket a zónákat...
Még arra gondoltam, hogy forward-only-ba állítom az új szervert... Csak akkor meg mindenért (a saját zónájáért is?) a forwarder-hez fog fordulni?
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
1.) Remélem csak elírás, az a 32, mert előtte 31-ről beszéltünk.
2.) Azaz a tűzfal DNS szervere kiszolgálja a 254.31.172.in-addr.arpa-t a szerver számára, és visszaadja a megfelelő RR-t. Tehát a tűzfal biztosan nem hibás. Viszont az új szerveren futó bind nem ezt az RR-t, hanem NXDOMAIN-t ad az ő kliense felé, tehát a szerveren futó bind nem kérdez a 254.31.172.in-addr.arpa-ra vonatkozóan a tűzfalról.
3.) Ezt nem értem. Hogyhogy sosem volt?! Pont most említetted, hogy új installálás, és kikommentezted, ergo volt.
5.) Gondolom Ubuntu 13.04.
"Viszont nem értem, hogy miért nem kérdezi meg (mert nincs forgalom) az általa nem ismert zónákról a forwarder-r..."
Miért ne kérdezné meg? Hiszen az index.hu, és a 217.20.130.97 is ment neki valahonnan. És mivel forwardert állítottál be az egész szerverre, nem kérdés hogy honnan.
"Valószínű összefügg az empyt-zones dolgokkal... Viszont ahogy írtam egy korábbi hozzászólásban a zones.rfc1918-ban kikommenteltem ezeket a zónákat..."
Ez a két mondat hogy függ össze? Az empty zones pont arról szól, hogy ha neked a konfigban nincs is ilyen zónád, akkor is letiltja ezeket, és helyből NXDOMAIN-t mond a root nameserverek felesleges terhelésének csökkentése érdekében. Ha meg van ilyen zónád (alapból csak SOA és egy localhost NS), akkor meg azt szolgálja ki. Ez áll a dokumentációban, amit be is linkeltem. A tapasztalat pedig a 9.8.4-P1-ben az volt, hogy - szintén bemásoltam - ha nincs empty-zones-enable vagy disable-empty-zone opció a konfigban, akkor az RFC1918-asokat mégis engedi. Nem tudom, hogy ezt a működést megtartották-e az általad futtatott 9.9.2.-P1-ben. Ha nem, akkor te állítsd be. Bár azt mondtad, nem változott a működés.
"Még arra gondoltam, hogy forward-only-ba állítom az új szervert... Csak akkor meg mindenért (a saját zónájáért is?) a forwarder-hez fog fordulni?"
Miért akarod az egész szervert "forward only"-ba? Már kétszer írtam, hogy stub zóna, esetleg forward zóna. Illetve továbbra is kérdés, hogy miért nem felel meg a master-slave konstrukció, amikor az lenne a legegyszerűbb, és legcélszerűbb.
- A hozzászóláshoz be kell jelentkezni
1. Igen :D
2. Pontosan! Nincs is adatforgalom ebben az esetben!
3. Az új szerveren nem volt fent, viszont a zones.rfc1918-ból kikommenteztem azt a sort, amelyik a db.empty-re "irányítja" ezt a zónát... Azaz elvileg semmit nem tudhat erről az új szerveren lévő BIND...
Igen, kérdez a többi, általa ismeretlen zónákról, de erről/ezekről nem! Viszont ha megkérdezné a forwarder-t, akkor tudna róla...
Úgy függ össze az empty-zones dolgoKKal, hogy szerintem a disable-empty-zone segíthetne neki... De hiába próbáltam ki, nem jött össze...
forward-only-ba már csak végső próbaként tenném... Hátha segít... A master-slave opció nem igazán jó ötlet... Lesz még sok ilyen (7-8) zóna, aminél külön-külön szerverek lesznek autoratív master-ek egy-egy subnet zonáira..
Én úgy szeretném használni, hogy az adott subnet-jét csak a hozzá tartozó szerverek kezeljék... A tűzfal pedig legyen ezeknek a slave kiszolgálója és ha kell, akkor válaszoljon más subnet-ekből érkező kérdésekre...
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
Helyzetjelentés:
Downgrade-eltem az új szervert 1:9.8.4.dfsg.P1-re... És működik minden...
Kicsit bővebben:
a zones.rfc1918-ban ez (is) van: zone "31.172.in-addr.arpa" { type forward; forwarders { 172.31.254.254; }; };
Ezt az újabb verzió figyelembe sem veszi! Pontosabban a réginek sem kell, mert a 192.168.10-es címeket is simán feloldja...
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
Megpróbálom átfogalmazni.
"Adott egy tűzfal, rajta egy BIND, ami rendesen feloldja a belső és a külső címeket/neveket.."
Tehát feloldja azokat a neveket, amelyekre nézve ő autoritatív, valamint emellett rekurzív feloldást is végez a LAN-on lévő kliensek számára.
"Ezen eddig voltak különböző belső tartományok, amiket rendesen le is kezelt master-ként."
Ok.
"Most az alhálózatok közül kiraktam alá egy másik szervert, amelyik több feladata mellett még BIND-et is futtat."
Úgy értsük, hogy áttettél rá autoritatív zónákat?
"Erre a szerverre a saját tartományát áthoztam, azaz ez lett a master, az eredeti (a tűzfal) pedig slave lett ezekhez."
Mit jelent a "saját tartománya"? Egy adott zóna masterét a tűzfalról a szerverre tetted, a tűzfal pedig ennek az adott zónának a slave-je?
"A tűzfalról kérdezve bármilyen cím/név (külső és belső is) simán feloldható."
A tűzfalról a tűzfalon futó bindot, vagy a tűzfalról a szerveren futó bindot kérdezve?
"Az új szerverről kérdezve a saját hálója és a külsős címek rendben feloldhatók"
Az szerverről a szervert, vagy pedig a tűzfalat kérdezve?
"viszont bármilyen másik belső hálózat IP->név feloldására NXDOMAIN-t nyom..."
Ahogy fentebb javasolták, vagy állítsd be a szerveren forwarderként a tűzfalat, amely autorivatívként ismeri ezeket a zónákat, vagy a többi zónára a szervert tedd meg slave-nek.
- A hozzászóláshoz be kell jelentkezni
A legtöbb kérdésedre igennel tudok válaszolni.
Változtatás előtt:
A tűzfal eddig a belső hálókra (több /23-as subnet) autoratív volt és a külső cím/név fordításokra rekurzív feloldást végzett. Azaz egyedüli DNS kiszolgáló volt.
Változtatás után:
Az egyik ilyen subnet (autoratív reverse és forward) kiszolgálását áttettem az ebben a subnet-be telepített új szerverre. (Az új szerver ebben a subnet-ben kapott IP címet, az átjárója és a BIND forwarder-e a régi tűzfal.)
A régi tűzfalon (a tűzfalon lévő BIND-et kérdezve) bármilyen név->cím és cím->név feloldás működik.
Az új szerveren (a szerveren lévő BIND-et kérdezve) bármilyen név->cím feloldás működik.
Az új szerveren (a szerveren lévő BIND-et kérdezve) csak a külsős (Internetes) és a szerver autoratív zonájának feloldása működik, minden másra NXDOMAIN-t ad vissza.
Tehát ami mindenhonnan megy: (A példában a szerver IP címe 192.168.1.1 és neve szerver2.b_subnet.cegnev.hu)
host hup.hu -> 195.228.252.138
host 195.228.252.138 -> portal.fsn.hu
host szerver1.a_subnet.cegnev.hu -> 192.168.0.1
host szerver2.b_subnet.cegnev.hu -> 192.168.1.1
A hálózatban a szerver2 kivételével bárhonnan működő cím->név lekérdezések:
host 192.168.0.1 -> szerver1.a_subnet.cegnev.hu
host 192.168.1.1 -> szerver2.b_subnet.cegnev.hu
Ugyanez a szerver2-őn:
host 192.168.0.1 -> NXDOMAIN
host 192.168.1.1 -> szerver2.b_subnet.cegnev.hu
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
resolv.conf lesz a barátod! Persze ésszel, mert nálam okozott érdekességeket.
- A hozzászóláshoz be kell jelentkezni
Persze a barátom, de szerintem tévedsz....
Mindkét gépen a resolv.conf tartalma:
search xxx.akarmi.hu
nameserver 127.0.0.1
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
(gyenge sub)
- A hozzászóláshoz be kell jelentkezni