Hoi, Wij gebruiken al sinds jaar en dag dnscache van Dan Bernstein. Deze software blijkt voor ons een beetje uitgeschaald te zijn. Er zitten een paar patches overheen, maar onze caches beginnen tekenen te tonen van dropped queries. We overwegen een switch naar een ander softwarepakket. Deze moet IPv4 en IPv6 aan kunnen en kunnen bind()en aan een specifiek IPv4 en/of IPv6 adres. We draaien op dezelfde dozen ook onze authoritatieve nameservers (FYI, dit is bind9). What's out there? What do you use? How many queries/second? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
Hoi Pim, On 16 mei 2006, at 23:31, Pim van Pelt wrote:
What's out there? What do you use? How many queries/second?
PowerDNS schijnt best hard te gaan. Enkele collega's van je op deze lijst zijn reeds over, naast een mooie lijst grotere ondernemingen uit het buitenland. Ik weet niet of het harder gaat dan djbdns aangezien dat wel erg `lean and mean' is, dus misschien heb je meer aan een Alteon of twee... Voor mij specifiek mist PowerDNS "views", maar dat schijnt nog niet triviaal te implementeren te zijn. Voor de rest voldoet het volgens mij wel aan je eisen. Vind ahu op IRCnet, OFTC of freenode. Groeten, -- Niels Bakker Tel: +31 205 141 716 Amsterdam Internet Exchange Mobile: +31 651 902 772 http://www.ams-ix.net/ E-mail: Niels.Bakker at ams-ix.net
On Wed, 17 May 2006, Niels Bakker wrote:
Hoi Pim,
On 16 mei 2006, at 23:31, Pim van Pelt wrote:
What's out there? What do you use? How many queries/second?
PowerDNS schijnt best hard te gaan. Enkele collega's van je op deze lijst zijn reeds over, naast een mooie lijst grotere ondernemingen uit het buitenland.
Ik weet niet of het harder gaat dan djbdns aangezien dat wel erg `lean and mean' is, dus misschien heb je meer aan een Alteon of twee...
djbdns is gemaakt op 200 uitstaande queries, ga je hier overheen dan begint het allemaal wat vervelend te worden. Primair omdat de lijst uitstaande queries dan vergroot moet worden. Maar ook omdat de polling inplementatie dan performance problemen gaat geven, waardoor een aantal "vervelende" clients genoeg is om je nameserver onderuit te halen. Op het internet zwerven wat patches om deze 2 problemen wat aan te pakken, maar eigenlijk wil je als isp toch liever een product waar wel een actieve maintainer achter zit. Uit een sessie google, volgen dan 2 primaire kandidaten, Nominum Caching Nameserver ( door ontwikkelde bind, payware) en powerdns ( in het verleden wat lompe issues in de recursor, maar nu opgenomen door een flink aantal isps ). Vandaar de vraag van pim of er hier mensen zitten die willen vertellen over hun ervaringen met de powerdns recursor. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem
Hoi,
Wij gebruiken al sinds jaar en dag dnscache van Dan Bernstein. Deze software blijkt voor ons een beetje uitgeschaald te zijn. Er zitten een paar patches overheen, maar onze caches beginnen tekenen te tonen van dropped queries.
We overwegen een switch naar een ander softwarepakket. Deze moet IPv4 en IPv6 aan kunnen en kunnen bind()en aan een specifiek IPv4 en/of IPv6 adres. We draaien op dezelfde dozen ook onze authoritatieve nameservers (FYI, dit is bind9).
What's out there? What do you use? How many queries/seco
Hoe zeker ben je uberhaupt dat je dnscache je probleem is ? Dwz : Je draait het samen met een andere applicatie (bind9) op dezelfde doos, en blijkbaar begin je nu ergens wat resources tekort te komen. De aanname dat een andere dnsresolver in deze omstandigheden (zelfde doos, gedeeld met bind9 als authoritive) met minder toe kan volgt niet meteen, in elk geval niet uit je mail. Overigens ben ik wel nieuwsgierig naar de load (q/s) (en hw/os) bij welke je problemen begint te zien. Boudewijn
On Wed, May 17, 2006 at 01:01:09PM +0200, Boudewijn Visser wrote:
What's out there? What do you use? How many queries/seco
Hoe zeker ben je uberhaupt dat je dnscache je probleem is ? Niet 100% zeker, maar aangrenzende waarschijnlijkheid is van toepassing.
Dwz : Je draait het samen met een andere applicatie (bind9) op dezelfde doos, en blijkbaar begin je nu ergens wat resources tekort te komen. De bind server eet wel een beetje memory (30k zones), maar krijgt niet veel queries (100/sec ofzo).
De aanname dat een andere dnsresolver in deze omstandigheden (zelfde doos, gedeeld met bind9 als authoritive) met minder toe kan volgt niet meteen, in elk geval niet uit je mail. Dat klopt, ik heb ook niet alle informatie gegeven :-)
Overigens ben ik wel nieuwsgierig naar de load (q/s) (en hw/os) bij welke je problemen begint te zien. We draaien FreeBSD 4.11 en per server hebben we 4 dnscache instanties, waarvan de grootste 300MB is en ongeveer 1000qps krijgt. djbdns gebruikt IIRC een statisch en ongesorteerd array van lengte 200 voor het opslaan van uitstaande queries. Hij gaat bij hoge uitstaande waarden relatief lomp door de lijst heen op zoek naar (a) de oudste query en (b) een leeg slot. Vindt hij geen leeg slot, dan vervangt de nieuwe query de oudste en de originele vrager heeft dan pech.
De andere drie caches zijn (1) interne resolver voor onze eigen servers (300 qps), (2) backup resolver die op lo0 gebind is zodat we nscache1 kunnen overfalen naar nscache2 door middel van een static op de upstream router (~0 qps) en (3) een IPv6 resolver (<100qps). Ik denk dat we per doos ongeveer 1000-1500 qps afhandelen. Er droppen dan queries, waarbij ik gehoord heb dat er een stuk of 10 verschillende foutcondities door djbdns worden afgedaan als 'servfail * input/output error', waarbij niet duidelijk wordt verteld wat voor IO error er optrad. Ik denk dat djbdns om verschillende redenen voor ons heeft afgedaan. De nieuwe setup wordt: 3x FreeBSD6 dozen die twee belangrijke verbeteringen hebben: (1) We gaan CARP draaien zodat nscaches elkaar kunnen overnemen bij onderhoud en storing, (2) We gaan met PF NATten zodat alle queries (dmz, ipv4 front, ipv6 front) op dezelfde cache uitkomen. We kunnen dan dnscache blijven gebruiken, maar in verband met logging en een onbekende hoeveelheid patches die bij DJB nodig zijn om de software in de praktijk bij een ISP te laten werken, valt djbdns af in termen van beheersbaarheid. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
On Wed, May 17, 2006 at 01:01:09PM +0200, Boudewijn Visser wrote:
[knip vragen etc]
Overigens ben ik wel nieuwsgierig naar de load (q/s) (en hw/os) bij welke je problemen begint te zien. We draaien FreeBSD 4.11 en per server hebben we 4 dnscache instanties, waarvan de grootste 300MB is en ongeveer 1000qps krijgt. djbdns gebruikt IIRC een statisch en ongesorteerd array van lengte 200 voor het opslaan van uitstaande queries. Hij gaat bij hoge uitstaande waarden relatief lomp door de lijst heen op zoek naar (a) de oudste query en (b) een leeg slot. Vindt hij geen leeg slot, dan vervangt de nieuwe query de oudste en de originele vrager heeft dan pech.
Een snelle blik op de source en google laat dat zien je inderdaad default 200 uitstaande UDP queries kunt hebben. Als je de pech hebt dat een fors aantal queries relatief lang in deze queue blijven bezetten (omdat ze naar iets vragen wat een timeout, of traag antwoord geeft) kan die vollopen en moet dnscache queries gaan droppen. Eerste voor de hand liggende optie is om die 200 wat groter te maken, naar 1000. uit google : [http://www.tnpi.biz/internet/dns/dnscache-article.shtml ] Array van 1000 lijkt me nog steeds een getal waarbij de manier van zoeken geen echt groot probleem is. Maar goed, je onderstaande plannen en wensen zijn zeker valide argumenten om naar andere opties te kijken. Je zou een recompile voor meer uitstaande queries als quick fix kunnen gebruiken. Boudewijn
De andere drie caches zijn (1) interne resolver voor onze eigen servers (300 qps), (2) backup resolver die op lo0 gebind is zodat we nscache1 kunnen overfalen naar nscache2 door middel van een static op de upstream router (~0 qps) en (3) een IPv6 resolver (<100qps). Ik denk dat we per doos ongeveer 1000-1500 qps afhandelen. Er droppen dan queries, waarbij ik gehoord heb dat er een stuk of 10 verschillende foutcondities door djbdns worden afgedaan als 'servfail * input/output error', waarbij niet duidelijk wordt verteld wat voor IO error er optrad.
Ik denk dat djbdns om verschillende redenen voor ons heeft afgedaan. De nieuwe setup wordt: 3x FreeBSD6 dozen die twee belangrijke verbeteringen hebben: (1) We gaan CARP draaien zodat nscaches elkaar kunnen overnemen bij onderhoud en storing, (2) We gaan met PF NATten zodat alle queries (dmz, ipv4 front, ipv6 front) op dezelfde cache uitkomen.
We kunnen dan dnscache blijven gebruiken, maar in verband met logging en een onbekende hoeveelheid patches die bij DJB nodig zijn om de software in de praktijk bij een ISP te laten werken, valt djbdns af in termen van beheersbaarheid.
-- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
On Thu, May 18, 2006 at 10:09:58AM +0200, Boudewijn Visser wrote: [over djbdns dnscache]
Eerste voor de hand liggende optie is om die 200 wat groter te maken, naar 1000. Hij staat bij ons al zo hoog of zelfs hoger dan dat. Het probleem is hierbij dat er geen huishouding in het array gebeurt, dus hoe langer je de lijst maakt, hoe harder het CPU gebruik gaat stijgen, en het probleem wordt niet opgelost op een drukke resolver IMO. Bij 2000 worden bij hoge queryload (hoog is in mijn ogen >1kqps) veel queries tientallen milliseconden langer dan strict noodzakelijk, omdat alle operaties op inkomende en uitgaande queries dan lineair door die lijst moeten lopen en de complexiteit O(^2) maakt (1000qps * avg(2000)) is al gauw > 1M iteraties per seconde, terwijl dit heel prima ook O(1) kan en lineair groeit bij queryload in plaats van exponentieel. Kun je het hier mee eens zijn, denk je ?
Je zou een recompile voor meer uitstaande queries als quick fix kunnen gebruiken. Thanks for the tip, maar dat gaat 'm niet worden vrees ik.
-- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
On Thu, May 18, 2006 at 10:09:58AM +0200, Boudewijn Visser wrote: [over djbdns dnscache]
Eerste voor de hand liggende optie is om die 200 wat groter te maken, naar 1000. Hij staat bij ons al zo hoog of zelfs hoger dan dat. Het probleem is hierbij dat er geen huishouding in het array gebeurt, dus hoe langer je de lijst maakt, hoe harder het CPU gebruik gaat stijgen, en het probleem wordt niet opgelost op een drukke resolver IMO. Bij 2000 worden bij hoge queryload (hoog is in mijn ogen >1kqps) veel queries tientallen milliseconden langer dan strict noodzakelijk, omdat alle operaties op inkomende en uitgaande queries dan lineair door die lijst moeten lopen en de complexiteit O(^2) maakt (1000qps * avg(2000)) is al gauw > 1M iteraties per seconde, terwijl dit heel prima ook O(1) kan en lineair groeit bij queryload in plaats van exponentieel. Kun je het hier mee eens zijn, denk je ?
Natuurlijk, maar uit je reply maakte ik op dat je nog op de default 200 zou zitten. En zeker, als je array groter wordt wil/moet je slimmer dan lineair zoeken, het is alleen meer implementatie werk dan simpelweg de limiet van 200 verhogen. Mijn natte vinger gok was (en is) dat voor orde 1000 qps , array van 1000 en een beetje stevige server lineair nog wel acceptabel is. En in elk geval de moeite van het proberen waard.
Je zou een recompile voor meer uitstaande queries als quick fix kunnen gebruiken. Thanks for the tip, maar dat gaat 'm niet worden vrees ik.
tsja, als je de simpele inkoppertjes al gehad hebt wordt het echt werk :-) Boudewijn
Thanks for the tip, maar dat gaat 'm niet worden vrees ik.
tsja, als je de simpele inkoppertjes al gehad hebt wordt het echt werk :-)
Maar waarom vraag je het niet aan Bert Hubert (PowerDNS) zelf, je kan nog nederlands tegen hem praten ook :) Of informeer eens bij XS4all en True, aangezien deze clubs nauw betrokken zijn bij de ontwikkeling van PowerDNS. op http://ds9a.nl/tmp/rrd/ kun je wat grafiekjes zien van een caching nameserver, met een redelijke belasting. Maurice
On Thu, 2006-05-18 at 14:18 +0200, Maurice Sienema wrote:
Thanks for the tip, maar dat gaat 'm niet worden vrees ik.
tsja, als je de simpele inkoppertjes al gehad hebt wordt het echt werk :-)
Maar waarom vraag je het niet aan Bert Hubert (PowerDNS) zelf, je kan nog nederlands tegen hem praten ook :) Of informeer eens bij XS4all en True, aangezien deze clubs nauw betrokken zijn bij de ontwikkeling van PowerDNS.
Wie zegt dat dat niet gedaan is? :)
op http://ds9a.nl/tmp/rrd/ kun je wat grafiekjes zien van een caching nameserver, met een redelijke belasting.
Alleen zegt die pagina niets over de gebruikte hardware en de CPU- en memory-belasting die het veroorzaakt... Teun
On Thu, May 18, 2006 at 04:29:16PM +0200, Teun Vink wrote:
Maar waarom vraag je het niet aan Bert Hubert (PowerDNS) zelf, je kan nog nederlands tegen hem praten ook :) Of informeer eens bij XS4all en True, aangezien deze clubs nauw betrokken zijn bij de ontwikkeling van PowerDNS.
Wie zegt dat dat niet gedaan is? :)
Ik :-)
op http://ds9a.nl/tmp/rrd/ kun je wat grafiekjes zien van een caching nameserver, met een redelijke belasting.
Alleen zegt die pagina niets over de gebruikte hardware en de CPU- en memory-belasting die het veroorzaakt...
In tests blijkt dat je wegkomt met 5000qps gemiddeld op een dual xeon met 2G ram. 5000qps gemiddeld houdt in dat pieken naar 10000qps geen problemen opleveren. Op een dual opteron met Solaris 10 hebben we 80000qps gemeten, zonder drops. Alleen hadden we toen wel een park testmachines nodig om zoveel verkeer te genereren. Kabels werden ook wat warm :-) Het lijkt erop dat PowerDNS recursor performance vrijwel een functie is van je geheugenbandbreedte, en dan scoren dual opterons heel erg goed. Je kunt het geheugengebruik van PowerDNS limiteren, praktisch gezien eet een hele drukke recursor ongeveer een gig ram als je ongelimiteerd draait. Het is verstandig jezelf te beperken tot zo'n 5 miljoen cache entries, anders kan iemand plezier hebben met wildcard records en pogen al je ram op te eten. Als er meer vragen zijn hoor ik het graag. Naast performance is PowerDNS ook nog de nameserver die het moeilijkst te spoofen is, zie ook de draft-draft RFC op http://ds9a.nl/rfc/dns-anti-spoofing.html . BIND 8 of 9 draaien is eigenlijk niet verantwoord meer: The calculations above indicate the relative ease with which DNS data can be spoofed. For example, using the formula derived earlier on a domain with a 3600 second TTL, an attacker sending 7000 fake answer packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the first 24 hours, which rises to 50% after a week. For a domain with a TTL of 60 seconds, the 10% level is hit after 24 minutes, 50% after less than 3 hours, 90% after around 9 hours. Groeten, bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services
Ik heb deze vraag ooit eens op de powerdns list gegooid omdat een collega wat issues had met z'n powerdns, dat was 2 jaar geleden (rond versie 2.9.15), toen kwam er dit uit: --- For LDAP a lot depends on the LDAP server. Check if it is busy, if it has the correct indexes etc. PowerDNS itself has been tested up to 50.000 queries/second, but not with LDAP. This was the xbackend. --- Depends. I'm getting a maximum of 240 queries/s on my 600MHz notebook (PDNS and OpenLDAP on the same machine) if I disable caching completely. Remember that you will never get the same speed with a database backend as with an in-memory backend (bindbackend for example). The trick is to use high values for cache-ttl and and the other -ttl options to avoid lookups from the database. ---- Just another hint about what is possible: With cache-ttl and query-ttl set to 300, I get a queryperf result of around 8500 q/sec (everything running on my 600MHz notebook). queryperf needed 33%, pdns 60% and top 7% cpu. OpenLDAP wasn't queried any more after all results was in the cache. Norbert ---- At 23:31 16-5-2006, you wrote:
Hoi,
Wij gebruiken al sinds jaar en dag dnscache van Dan Bernstein. Deze software blijkt voor ons een beetje uitgeschaald te zijn. Er zitten een paar patches overheen, maar onze caches beginnen tekenen te tonen van dropped queries.
We overwegen een switch naar een ander softwarepakket. Deze moet IPv4 en IPv6 aan kunnen en kunnen bind()en aan een specifiek IPv4 en/of IPv6 adres. We draaien op dezelfde dozen ook onze authoritatieve nameservers (FYI, dit is bind9).
What's out there? What do you use? How many queries/second? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) _______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog
Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolo.nl
On Thu, 18 May 2006, Jeroen Wunnink wrote:
Ik heb deze vraag ooit eens op de powerdns list gegooid omdat een collega wat issues had met z'n powerdns, dat was 2 jaar geleden (rond versie 2.9.15), toen kwam er dit uit:
De discussie gaat over powerdns-recursor, niet de authoritive nameserver. Dit zijn seperate producten. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem
participants (8)
-
bert.hubert＠netherlabs.nl -
bvisser-nlnog＠xs4all.nl -
jeroen＠easyhosting.nl -
niels.bakker＠ams-ix.net -
pim＠bit.nl -
sienema＠io.nl -
sten＠blinkenlights.nl -
teun＠teun.tv