Hali!
Bár igazából a bind9 is mindent tud ezen a téren, egyre több helyen olvasom, hogy a PowerDNS-t ajánlják helyette. Valakinek esetleg tapasztalata vele? Érdemes váltani? Ha igen miért? Illet ilyen kisebb munkahelyi hálózatokon cache-elésre és a belső háló belső domainneveinek kiosztására is preferálható? A poweradmin például elég pofásnak tűnik nekem, szemben a bind zone fájljaival (persze azok is tökéletesen ellátnak minden funkciót...), illetve hogy akár mysqlben tárolja az adatait...
Vélemények? Érvek?
- 6035 megtekintés
Hozzászólások
subs
- A hozzászóláshoz be kell jelentkezni
Nálunk min. 3 éve fut a PowerDNS mint DNS és mint caching-only DNS szerver BIND backend-el. Én azt szeretem benne, hogy egyszerű a configja, ugyanakkor a számunkra fontos beállításokat mégis megtaláltuk benne. Ill. munin statisztikák szerint caching szerverként kevesebb memóriával beéri. Mi úgy indultunk neki, hogy nézzük meg, meglássuk... Így maradtunk.
DNS-ként nincs nagy forgalma (konkrét számot nem tudok), caching-ként csúcsidőben másodpercenként 8-10 kérést szolgál ki.
Szóval worksforme :)
Mik
- A hozzászóláshoz be kell jelentkezni
~1-1.5 éve megy PowerDNS. Master NS gentoon, Slave NS Debianon. Mindkettő MySQL backenddel.
Közel 400 domaint kezel jelenleg. Webfelületen birizgáljuk. Nincs gond vele.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy nem értek hozzá, de pont múlt héten (mellesleg 3-4 év szolgálat és egy dist-upgrade után) olyat csinált, hogy nem tudtam hol keressem a baját. Csak a pdns-nat nem ment, kifele minden rendben volt. 2 pdns (nat és nélküle) restart után megoldódott. Magától. Persze közben az ügyfél odavolt, hogy nem megy a net.
Ilyet közel 10 éves bind tapasztalattal még nem láttam.
Pozitívum, hogy tud pl. bind file-okat is olvasni. Meg mysql + bind zone kevergetése (más-más domain) is működik.
- A hozzászóláshoz be kell jelentkezni
Eddig nem volt olyan problemam se bind-al se pdns-el, h vmi nem ugy mukodott volna ahogy kell benne. Biztonsagi hibakat idonkent talalnak mind2-ben.
Ami megkulonboztetheti oket sztem az a tudasban lehet:
- pdns-hez konnyebb backendeket tenni (adatbazis vagy akar bind configok is), de igazabol ezeknek akkor lehet haszna ha nem csak 1-2 admin van aki modosithat benne, hanem nagyobb csoportoknak kell kiadni kulonfele jogosultsagokkal es kezelhetobb felulettel.
- pdns tud idonkenti config ujraolvasast, igy modositas eseten nem kell ujrainditani
- nagy teljesitmenyigeny eseten lehetnek gondok allitolag a bind-al (>10k keres/sec)
Ezek egy kissebb cegnel sztem nem szempontok, akkor meg felesleges valtani.
Ami a poweradmint vagy egyeb webes feluletet illet pdns-hez, javaslom felejtsd el, evek ota nem fejlesztettek egyiket se es mindegyik eleg tre modon van osszerakva.
--
Don't Panic if you see me laughing,
that's not a bug, just a feature.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a válaszokat. A caching részt amúgy egy powerdns alap installban csinálja/tudja? Ez valahogy nekem homályos maradt a leírások olvasása után... vagy alapból tartalmazza a pdns-recursor-t?
- A hozzászóláshoz be kell jelentkezni
mik@mik-home:~$ apt-cache search pdns
pdns-recursor - PowerDNS recursor
pdns-server - extremely powerful and versatile nameserver
Két külön csomag, két külön service. Egymás mellé ugyanarra az IP-re nem tudod mind a kettőt feltenni...
- A hozzászóláshoz be kell jelentkezni
Biztos? Nálam egy IP-n fut a pdns és a precursor.
- A hozzászóláshoz be kell jelentkezni
És mind a kettő az 53-as udp porton figyel?
- A hozzászóláshoz be kell jelentkezni
Nem, úgy nézem, hogy a recursor sockettel csatlakozik, annak ellenére, hogy a configban mindkettőnél port=53 szerepel.
# netstat -alpn | grep pdns
tcp 0 0 x.x.x.x:53 0.0.0.0:* LISTEN 26900/pdns_server-i
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 4536/pdns_recursor
tcp 0 0 127.0.0.1:35444 127.0.0.1:3306 ESTABLISHED 26900/pdns_server-i
tcp 0 0 127.0.0.1:35440 127.0.0.1:3306 ESTABLISHED 26900/pdns_server-i
tcp 0 0 127.0.0.1:59628 127.0.0.1:3306 ESTABLISHED 26900/pdns_server-i
tcp 0 0 127.0.0.1:35443 127.0.0.1:3306 ESTABLISHED 26900/pdns_server-i
tcp 0 0 127.0.0.1:35442 127.0.0.1:3306 ESTABLISHED 26900/pdns_server-i
udp 0 0 0.0.0.0:28460 0.0.0.0:* 26900/pdns_server-i
udp 0 0 x.x.x.x:53 0.0.0.0:* 26900/pdns_server-i
udp 0 0 127.0.0.1:53 0.0.0.0:* 4536/pdns_recursor
udp 0 0 127.0.0.1:44608 127.0.0.1:53 ESTABLISHED 26900/pdns_server-i
unix 2 [ ACC ] STREAM LISTENING 10119 4281/pdns_server /var/run/pdns.controlsocket
unix 2 [ ] DGRAM 10714 4536/pdns_recursor /var/lib/powerdns/pdns_recursor.controlsocket
unix 3 [ ] STREAM CONNECTED 74882355 26900/pdns_server-i
unix 3 [ ] STREAM CONNECTED 36876370 4281/pdns_server
unix 3 [ ] STREAM CONNECTED 30307166 4536/pdns_recursor
A daemon.logba pedig időnként benyom egy statisztikát:
Nov 1 09:44:38 pdns_recursor[4536]: stats: 108703 questions, 3301 cache entries, 8 negative entries, 47% cache hits
Nov 1 09:44:38 pdns_recursor[4536]: stats: throttle map: 4, ns speeds: 19
Nov 1 09:44:38 pdns_recursor[4536]: stats: outpacket/query ratio 124%, 27% throttled, 0 no-delegation drops
Nov 1 09:44:38 pdns_recursor[4536]: stats: 69 outgoing tcp connections, 1 queries running, 15981 outgoing timeouts
- A hozzászóláshoz be kell jelentkezni
Nem, rosszul tudod. Nézd át a konfigokat. Ez két különböző IP. Sztenderd konfig.
- A hozzászóláshoz be kell jelentkezni
és kit érdekelt ez a tesztkérdés/válasz? Talán nem konkurens szolgáltatás? Talán nem ütközne? Legritkább esetben futtatják azonos IP-n, és más porton.
- A hozzászóláshoz be kell jelentkezni
Nem egyszer előfordult már, hogy egy hasonló visszakérdezésre az volt a válasz, hogy "ja, nem tudom, nem néztem csak gondoltam". Na ezért volt a kérdés.
- A hozzászóláshoz be kell jelentkezni
És bebizonyítottad, hogy nálad nem ugyanazon az IP-n fut?
- A hozzászóláshoz be kell jelentkezni
Azt nem bizonyítottam, gyanítottam elég ha azt mondom. Tekintve, hogy mindössze 1 db IP van felhúzva a gépre.
Ha azon lovagolunk, hogy 1 IP 53-as portjára nem lehet felhúzni 2 szolgáltatást, akkor igen. Igazad van. Ez nem is cáfolható. Hozzászólásom arra irányult, hogy 1 IP-vel rendelkező gépre ennek ellenére felhúzható mindkét szolgáltatás és használható.
- A hozzászóláshoz be kell jelentkezni
Én minimum 2 IP-t látok az általad prezentált netstat-ban
- A hozzászóláshoz be kell jelentkezni
Értem. Akkor félreértettem az eredeti felvetést & téged. Elnézést.
Nálam a pdns local-address egy publikus IP, a resursoré pedig localhost. Ezért megy 1 gépen.
"Egymás mellé ugyanarra az IP-re nem tudod mind a kettőt feltenni.."
Ezt valamiért rögtön úgy értettem, hogy 1 publikus IP-vel rendelkező gépen nem mehet a kettő (localhostról megfeledkezve). Elnézést.
- A hozzászóláshoz be kell jelentkezni
A recursor külön szerviz, de a authoratív ns proxy-t képezhet a recursor felé. Így a hozzá érkező kéréseket a recursor felé küldi. A recursor nem kötelezően pdns recursor, bármi más lehet.
- A hozzászóláshoz be kell jelentkezni
Amennyiben tényleg minimálisak az elvárások én ránéznék a Dnsmasq-ra is. Ez egy dhcp és dns szerver egyben, direkt kis belső hálózatokhoz fejlesztették
- A hozzászóláshoz be kell jelentkezni
Eléggé régi a topic, de hátha. :)
80req/s mit lehet kezdeni powerdns-nek mennyire tetszene? Tudom őrületes kérésmennyiség de sajnos ez van :(
Tapasztalatok ?
- A hozzászóláshoz be kell jelentkezni
80 req/s az pont semekkora keresmennyiseg. Hacsak nem valami oskovulet vason akarod futtatni. Szoval eszre sem venne, ergo biztos, hogy nem tetszene neki. :D
- A hozzászóláshoz be kell jelentkezni
cache re gondoltam elsősorban.
- A hozzászóláshoz be kell jelentkezni
Nem írtál valami túl sokat így csak kérdéseim vannak...
- A 80req/s az normális forgalom vagy esetleg a szerveredet DNS amplificationhoz használják?
- Saját domainokat szolgál ki vagy Caching szerverként funkcionál belső hálóra?
ui: Nem igazán tűnik vészesnek egy 80req/s gyakoriság, átlag vason is mennie kellene simán.
- A hozzászóláshoz be kell jelentkezni
Ez az átlagos fogalom néha megugrik 100ra.
only cache natolt háló miatt :S
Nincs sajád domain használva.
Az a bajom, hogy ez már más kategória ahogy látom.. Kipróbáltam OpenDNS-t, google-t de ez a mennyiség már sok mind a kettőnek.
Laggol, képek nem jönnek be stb. szolgáltatóé ugyanez a baj.
Ezért keresek erre valamilyen megoldást, amit lehetőleg nem nekem kell etetnem árammal stb...
Most VPS+ powerdns megoldáson agyalok.
- A hozzászóláshoz be kell jelentkezni
ha cache, akkor unbound
- A hozzászóláshoz be kell jelentkezni
Láttam már nagyobb löketeket is, gond nélkül megy. Egy kevés RAM és némi proci kell hozzá, igazából magától is jól cache-el alatta.
Ha a kiválasztott backend támogatja és nem változtatgatod túl gyakran a rekordokat (értsd: nem kell állandóan pl. SQL-ben ellenőrizgetni és újratöltögetni minden rekordot) akkor röhögve kiszolgálja. Ha mégis változtatgatod, akkor meg jó eséllyel SQL query cache a barátod, de ez meg offtopic már. Bár gyanús, hogy egy 2Ghz Xeon-on ez se röccenti meg a procit túlzottan. Összefoglalva viszonylag statikus domain adatoknál a 80 req/s szerintem semmi.
-
- A hozzászóláshoz be kell jelentkezni
Hali,
Tapasztalt PowerDNS használóktól kérdezem, hogy hogyan lehet megcsinálni PowerDNS-ben azt, hogy kifelé és befelé más zónákat szolgáljon ki, úgy mint BIND-ben a view "internal" és view "external" megoldás? Tehát mondjuk feltelepíteném a tűzfalra és a belső lábán figyelne a recursor befelé, és mondjuk a config-jában egy forward-zones-recurse=belso.domain=KULSO IP-vel a KULSO_IP-n figyelő auth szervertől feloldaná a belső zónát, kifelé meg auth szerverként kiszolgálna 100+ domaint. De hogy tiltom meg, hogy a belső zónát ne lehessen kívülről lekérdezni? Vagy ezt nem így kell itt megoldani? Már szétolvastam oda-vissza a Manualt, de erre nem jövök rá.
- A hozzászóláshoz be kell jelentkezni
Futtass két powerdns-t?
- A hozzászóláshoz be kell jelentkezni
Ezt szerettem volna elkerülni, amúgy is master/slave beállítás kell legyen. Nincs kedvem még 2x annyit futtatni. Azt hittem ez egy triviális dolog egy DNS szervertől. Bár chroot-al ezt könnyű megcsinálni. Ha nincs más választás, lehet, hogy az lesz, mert a mysql backend és a több felhasználós adminisztráció fontos, ami a PowerAdminnal teljesen jól megoldott dolog.
- A hozzászóláshoz be kell jelentkezni