Bekijk Volledige Versie : Zonefile splitsen
Hallo allemaal,
Ik zal eerst even de situatie schetsen.
Wij hebben een server waar DirectAdmin op draait en tevens een IRC deamon.
In DirectAdmin hebben wij een subdomein aangemaakt welke een eigen zonefile heeft. Dit subdomein (met zonefile) wordt als blacklist gebruikt. Hier staan dus verbannen ip's in.
Deze zonefile wordt gegeneerd aan de hand van een MySQL database met een PHP script. Dit werkt allemaal prima. Alleen het PHP script loopt uit het geheugen omdat er TEVEEL ip's in de database staan.
Nu hadden wij het idee om de zonefile te splitsen in meedere bestanden. Zodat deze apart genereerd kunnen worden en het phpscript niet uit het geheugen loopt.
Echter heb ik geen mogelijkheid gevonden om een zonefile te splitsen. Dus daarom doe ik een beroep op jullie! Weet iemand hoe ik een zonefile op kan splitsen in meerdere bestanden.
Een andere oplossing is ook een mogelijkheid zolang ik de blacklist maar kan benaderen via het subdomein (en er dus niet meer bij komen).
In andere woorden: Het gaat er dus feitelijk om dat je de 'hoofd-zone dus kan blijven aanspreken, maar dat er op de achtergrond dus feitelijk naar gelang de query een 'deel-zone' word aangeboord
P.S de database kleiner maken is GEEN optie ;-)
Ik afwachting van jullie adviezen
Kun je een stukje van de zone hier geven (eventueel met fake IPs uit de 10.x.x.x range)?
Overwogen om je dns server rechtstreeks uit de DNS te laten putten?
Eigenlijk doe je niks anders dan kijken of het ip present is, en vervolgens de client niet toelaten.
Je script nakijken is wel een optie, je hebt niets anders dan een loop, schrijf en flush je tussendoor dit al naar het bestand of genereer je de complete zone alvorens je deze wegschrijft ?
Kun je een stukje van de zone hier geven (eventueel met fake IPs uit de 10.x.x.x range)?
Bij deze:
$TTL 14400
@ IN SOA **.***.**. ***.***.**. (
2008062501
14400
3600
1209600
86400 )
***.****. 14400 IN NS **.****.**.
0.100.18.76 14400 IN A 127.0.0.10
0.105.232.77 14400 IN A 127.0.0.10
0.112.232.77 14400 IN A 127.0.0.10
0.123.93.59 14400 IN A 127.0.0.10
0.129.122.84 14400 IN A 127.0.0.10
0.137.109.84 14400 IN A 127.0.0.10
0.151.208.77 14400 IN A 127.0.0.10
0.171.93.59 14400 IN A 127.0.0.10
0.194.205.99 14400 IN A 127.0.0.10
0.200.239.85 14400 IN A 127.0.0.10
0.209.97.59 14400 IN A 127.0.0.10
0.210.194.123 14400 IN A 127.0.0.10
0.216.93.59 14400 IN A 127.0.0.10
0.221.127.84 14400 IN A 127.0.0.10
0.227.54.151 14400 IN A 127.0.0.10
0.23.148.88 14400 IN A 127.0.0.10
0.23.234.72 14400 IN A 127.0.0.10
0.26.56.151 14400 IN A 127.0.0.10
0.4.125.77 14400 IN A 127.0.0.10
__
Overwogen om je dns server rechtstreeks uit de DNS te laten putten?
Eigenlijk doe je niks anders dan kijken of het ip present is, en vervolgens de client niet toelaten.
Wanneer je bedoelt of onze IRCd direct in de dns server kijkt of het IP present is, kan ik melden dat we dit reeds doen. Het gaat echter om het (dageijks) genereren van de zone-file aan de hand van de ip's in de database.
Wanneer je iets anders bedoelt snap ik niet precies wat je bedoelt.. Zou je dit dan nader kunnen toelichten s.v.p?
___
Je script nakijken is wel een optie, je hebt niets anders dan een loop, schrijf en flush je tussendoor dit al naar het bestand of genereer je de complete zone alvorens je deze wegschrijft ?
Het script is hier te vinden: http://www.wmcity.nl/forum_topic.php?id=630662
Zoals je ziet wordt de file in 1 keer weggeschreven. Mocht je suggesties hebben zijn die natuurlijk welkom!
Ramon Fincken
25/06/08, 21:05
kun je geen shell script maken dat als root draait of iig geen korte timeout heeft?
Daarnaast kun je natuurlijk ook kijken naar de performance van je script ..
kun je geen shell script maken dat als root draait of iig geen korte timeout heeft?
Daarnaast kun je natuurlijk ook kijken naar de performance van je script ..
additioneel zal ik even aanvullen omdat ik de situatie ken, en een deel van zijn vraag- / probleemstelling ook van mij afkomstig is...
In plaats van alles in 1 zone te blijven proppen, waardoor je ( geschat word dat de reccords in de blacklist-zone nog flink zal groeien) op lange termijn altijd al capactieitsproblemen zal krijgen met welke oplossing je ook kiest...
was mijn vraag of er niet zoiets zijn als dit :
- 1 zone die je aanspreekt ( en blijft aanspreken ) blacklist.blabla.iets vanuit de 'checker' ...
- daarachter word de request verdeeld/forwarded over private (deel-) zones
dus een
0.blacklist.blabla.iets
1.blacklist.blabla.iets
etc..
zodoende blijft het schaalbaar was mijn gedachte
bovendien is het dan ook te managen met manage- en generate-scripts omdat je de gehele load verdeeld over meerde zones die los kunnen worden bijgewerkt.
Deze gedachte kwam op omdat ik me persoonlijk niet kan voorstellen dat wat wij feitelijk doen/willen bereiken ook niet zo gedaan word op de public blacklists .. 1 mega-zonefile waar alles inzit .. neem aan dat ze ook een stukje 'load-balancing' doen mbt deel-zones oid....
als het goed is kan je in de DNS een deel van je resolving door delegeren naar een andere nameserver en zone.
Dit gebeurd onder andere weleens voor IN-ADDR.ARPA zones, om zo bijvoorbeeld een /25 resolving door te delegeren aan de nameservers van de gebruiker.
als het goed is kan je in de DNS een deel van je resolving door delegeren naar een andere nameserver en zone.
Dit gebeurd onder andere weleens voor IN-ADDR.ARPA zones, om zo bijvoorbeeld een /25 resolving door te delegeren aan de nameservers van de gebruiker.
howto's of docu over dergelijke methodes zeer welkom, dit lijkt in de de richting te komen van mijn gedachtengang....
mmm, zat even te bladeren in de bind 9.5 manual
http://www.isc.org/sw/bind/arm95/Bv9ARM.pdf hoofdstuk 6.3.5.2 doet wat anders dan ik beschreef, maar levert wel een optie voor datgene wat je wil.
mmm, zat even te bladeren in de bind 9.5 manual
http://www.isc.org/sw/bind/arm95/Bv9ARM.pdf hoofdstuk 6.3.5.2 doet wat anders dan ik beschreef, maar levert wel een optie voor datgene wat je wil.
*bladert gelijk ook ff *
Bij deze:
Zoals je ziet wordt de file in 1 keer weggeschreven. Mocht je suggesties hebben zijn die natuurlijk welkom!
Ik zat aan zoiets te denken
<?php
$fp = fopen('file.txt', 'w');
$count = 0;
$max = 25;
$loop = true;
while($loop)
{
fwrite($fp, $count.chr(10));
$count++;
sleep(1);
if($count == $max)
{
$loop = false;
}
}
?>
Bovenstaat is puur een testje geweest, met tail zie je namelijk dat elke keer het bestand bijgeschreven wordt. Ik denk dat je hiermee jouw geheugen probleem verhelpt... Nogmaals ik denk, proberen zal uitsluitsel geven.
Overigens, als elke zone dezelfde informatie bevat kun je ook een zone maken en daar alle domeinen aan hangen.
En een aanvulling over de pdf, ik weet niet of hetzelfde opgaat bij bind, apache kan bijvoorbeeld op teveel open files vastlopen door de limit die je os kent (file descriptors). Dit zou door de vele includes ook op kunnen treden ...? Maar is dan ook zonder problemen op te lossen :)
Is het niet mogelijk om de lijst die al in de database staat te gebruiken met een DNS die ook met een database werkt.
PowerDNS is geloof ik zo'n pakket wat z'n data uit een DB kan trekken...
Of is dit geen optie?
Overwogen om je dns server rechtstreeks uit de DNS te laten putten?
Eigenlijk doe je niks anders dan kijken of het ip present is, en vervolgens de client niet toelaten.
Wanneer je bedoelt of onze IRCd direct in de dns server kijkt of het IP present is, kan ik melden dat we dit reeds doen. Het gaat echter om het (dageijks) genereren van de zone-file aan de hand van de ip's in de database.
Wanneer je iets anders bedoelt snap ik niet precies wat je bedoelt.. Zou je dit dan nader kunnen toelichten s.v.p?
Wat ik bedoel is wat Paul Z. hier boven ook al aangeeft.
Met BIND kan het ook.
http://mysql-bind.sourceforge.net/
Introduction
The MySQL BIND SDB driver provides a MySQL database backend for the BIND 9 Domain Name Server (DNS). Normally, BIND is configured with complex configuration files that become difficult to maintain with large domains and are very error prone. BIND must also be restarted whenever changes are made to its configuration files.
The MySQL BIND SDB driver gets around these limitations by allowing the DNS server to read the domain information directly from a MySQL database. Any changes to the zones in the database are immediately seen by BIND making reloads unnecessary.
The code for this driver was derived from the example PostgreSql driver contained in the BIND distribution. It is similar in code and function to the unmaintained BIND-MySQL project and the database format is compatible since it appears to also have been derived from the PostgreSQL example driver.
p.s. de reden waarom ik hier MySQL+BIND aan haal is omdat DA zelf gebruik maakt van BIND, en TS het zelf al over MySQL heeft. Het is waarschijnlijk een kleine aanpassing voor hem om de tabel met verbannen ip's om te zetten naar een DNS tabel.
Moet je het probleem niet gewoon bij de bron aanpakken? dus zorgen dat het php script sneller is.
Wat doet dat php script trouwens want een lijstje outputten is nou niet echt lastig ook al is die lijst heel lang.
Daarnaast kun je het php script ook aanpassen zodat het via de commandline gestart kan worden dan heb je geen last van time-outs.
Is het niet mogelijk om de lijst die al in de database staat te gebruiken met een DNS die ook met een database werkt.
PowerDNS is geloof ik zo'n pakket wat z'n data uit een DB kan trekken...
Of is dit geen optie?
Wij (ik) zullen ons eerst moeten verdiepen in PowerDNS om te kijken of dit een optie is ja of nee. Wellicht dat we dit naast ons huidige systeem kunnen draaien voor alleen de blacklist. In ieder geval bedankt voor je bijdrage. Ik zal er is in duiken.
___
Wat ik bedoel is wat Paul Z. hier boven ook al aangeeft.
Met BIND kan het ook.
http://mysql-bind.sourceforge.net/
p.s. de reden waarom ik hier MySQL+BIND aan haal is omdat DA zelf gebruik maakt van BIND, en TS het zelf al over MySQL heeft. Het is waarschijnlijk een kleine aanpassing voor hem om de tabel met verbannen ip's om te zetten naar een DNS tabel.
Bedankt! We (ik) zullen eens kijken of het makkelijk is om die tabel met IP's om te zetten naar een DNS tabel. Dit zou inderdaad een mooie optie zijn om te gebruiken voor de blacklist. Dan hoeft er ook geen file meer gegeneerd te worden...
___
Moet je het probleem niet gewoon bij de bron aanpakken? dus zorgen dat het php script sneller is.
Wat doet dat php script trouwens want een lijstje outputten is nou niet echt lastig ook al is die lijst heel lang.
Daarnaast kun je het php script ook aanpassen zodat het via de commandline gestart kan worden dan heb je geen last van time-outs.
Het probleem bij de bron aanpakken hebben we reeds geprobeerd.. Er zijn enkele recodes geweest.. Het lijstje waar jij over spreekt is een lijst met zo'n 100.000 entry's (daarna cleanen we de database nu omdat die anders uit 't geheugen loopt).. We starten het script al via de command-line en we lopen ook neit tegen timeouts aan maar tegen 't mem limit van PHP. Wat we nu kunstmatig hoog gezet hebben in het script.
Ons script is (zoals eerder gezegt) gepost op: http://www.wmcity.nl/forum_topic.php?id=630662 Wanneer jij denkt een verbetering te zien is die natuurlijk welkom!
Ons script is (zoals eerder gezegt) gepost op: http://www.wmcity.nl/forum_topic.php?id=630662 Wanneer jij denkt een verbetering te zien is die natuurlijk welkom!
Ik heb je een werkende verbetering gegeven!
Het probleem bij de bron aanpakken hebben we reeds geprobeerd.. Er zijn enkele recodes geweest.. Het lijstje waar jij over spreekt is een lijst met zo'n 100.000 entry's (daarna cleanen we de database nu omdat die anders uit 't geheugen loopt).. We starten het script al via de command-line en we lopen ook neit tegen timeouts aan maar tegen 't mem limit van PHP. Wat we nu kunstmatig hoog gezet hebben in het script.
Volgens mij zijn er tal van mogelijkheden een paar suggesties:
-kijk wat het geheugen gebruik veroorzaakt 100.000 entry's is niet zoveel.
-schrijf de resultaten tussentijds weg
-hak het proces in stucjes (dus meerdere keren achter elkaar php opstarten) en dan achteraf de losse files aan elkaar plakken.
- maak een slim script wat alleen de aanpassingen doet dus niet steeds alle entries aflopen maar alleen de wijzigingen
Moet je het probleem niet gewoon bij de bron aanpakken? dus zorgen dat het php script sneller is.
Wat doet dat php script trouwens want een lijstje outputten is nou niet echt lastig ook al is die lijst heel lang.
Daarnaast kun je het php script ook aanpassen zodat het via de commandline gestart kan worden dan heb je geen last van time-outs.
Het getoonde script achter de link ( in TS zijn openingstopic ) is al een script wat gerunt word @ console met een cron
Er is dus geen interactie tav. timeouts of whatsoever , et draait, alleen et used zoveel resources dat er dus gezocht word naar die splitsing/andere methodieken.
enige wat wel aanwezig is op een http-interface is de add-form naar de Db zelf, dan word dat snachts per cron verwerkt in een zonefile die dan weer op zen plek gezet word en de zone opnieuw inleest....
@ Mikey
ga et gelijk bekijken ... :)
Volgens mij zijn er tal van mogelijkheden een paar suggesties:
-kijk wat het geheugen gebruik veroorzaakt 100.000 entry's is niet zoveel.
-schrijf de resultaten tussentijds weg
-hak het proces in stucjes (dus meerdere keren achter elkaar php opstarten) en dan achteraf de losse files aan elkaar plakken.
- maak een slim script wat alleen de aanpassingen doet dus niet steeds alle entries aflopen maar alleen de wijzigingen
Hebben er al veel aan gesleuteld, en er was ooit eens iemand die een php-class had gemaakt voor het afhandelen van dns-zone-files, ( PEAR::File_DNS (http://www.freshports.org/dns/pear-File_DNS/) )
echter heeft die class al heel lang :
1 - geen update meer gekregen
2 - zijn de huidige functionaliteiten nog niet dusdanig dat die voor deze opzet gebruik kon worden.
3 - creator aangeschreven maar et enige wat ik terug krijg is 'static'
en over het re-coden/optimizen van et script/set scripts word constant nagedacht, maar vragen wil wel es helpen om bepaalde dingen te doorbreken in plaats van altijd het wiel zelf maar opnieuw uit te vinden ....
vandaar ook de vraagstelling
al met al een hoop reacties gehad tot nu toe waardoor onze (mogenlijke) oplossing gerealiseerd kan worden lijkt me ...
kwestie is nu nog van 'wat is wijsheid' inzake de te kiezen oplossing...
- mysql-bind oplossing
Tricky op een RPM-based setup (CentOS 5).. requires recompile, en hoe gaat dat dan met je volgende updates van bind ...et feest weer overnieuw ?
- php recoden
Ja kan, maar geeft alleen nu een remedie, ik verwacht ( zoals aangegeven) een veel grotere DB, nu groeit de Db per dag met ca 500 ip's ( poster loopt bepaalde bronnen af om ip's op te snuffelen/adden)
- Include
Limitaties niet echt duidelijk aangegeven, dus kwestie van try
:X
marcussmit
07/07/08, 10:18
Misschien heb ik het helemaal verkeerd begrepen (zal ongetwijfeld, 't is nog vroeg..) maar wil je niet gewoon een firewall al dit verkeer laten blokkeren? Het gaat immers om verbannen ip's..