On Wed, 3 Sep 2003 at 18:56 +0200, Boudewijn Visser wrote:
[knip A query ] [re : wcard-clarify draft RFC ]
Diverse bind versies hebben verschillend gedrag gehad, en (wie anders...) Dan Bernstein Is Het Er Niet Mee Eens.
Leg uit, blijkbaar mis ik een stukje essentiele informatie :)
Welk deel, de details van wat er verschilt in wildcard gedrag tussen diverse bind versies en bv djbdns , of waarom de combinatie Niet Mee Eens en de persoon Dan Bernstein nog wel eens bij elkaar zitten ? Wat betreft het eerste, zo nauwkeurig heb ik me niet verdiept in de details, maar het lijkt te gaan over het teruggeven van NXDOMAIN vs NODATA voor antwoorden die vanwege een wildcard gegenereerd worden. Het 'clarify' gedeelte wordt beschreven als de meest logische uitleg van RFC1034 (die daar dus niet helemaal expliciet over is), en een strakke definitie schijnt vooral voor DNSSEC wel noodzakelijk te zijn. Diverse bind versies hebben daarin wat verschillends gedaan, (wat in latere versies gewoon als bug is beschreven, en dus gefixed). Nou ja, voor de details, lees dus namedroppers ( http://ops.ietf.org/lists/namedroppers/namedroppers.2003/ ), of de usenet gateway ervan. Hm, ik kan me nauwelijks voorstellen dat je de naam & reputatie van Dan Bernstein niet zou kennen, maar goed, voor het geval van niet : Dan Bernstein (z'n hoofberoep is wiskundige), maar daarnaast vooral bekend als auteur van software. (met name Qmail en DJBDNS, en syncookies). Hij is *zeer* capabel, maar ook erg rechtlijnig. Z'n redenaties zijn gewoonlijk geen speld tussen te krijgen, als je maar uitgaat van de door hem gekozen premisse(n). En discussie met hem wordt nogal vaak een flamewar die bol staat van de persoonlijke aanvallen en beledigingen. Z'n software, papers, etc ( die inderdaad van erg hoge kwaliteit zijn )kun je vinden op http://cr.yp.to/ Mocht je wat flamefests willen lezen, gebruik dan google om z'n usenet bijdragen te vinden. [knip workaround voor wildcard blokkade werkt] [..]
Anyhow, problem solved :)
Mooi, HTH, Boudewijn
Hoi Boudewijn, Ahum. Mijn bek is opengebroken, yaay ! Dan schrijft matige code waarbij het wiel doelbewust opnieuw wordt uitgevonden. Hij heeft letterlijk schijt aan alle gevestigde bcp, zoals het gebruiken van /usr/local/ of misschien /opt/ voor 3rd party programma's, of misschien generieke code zoals dat er is in de vorm van libc. djbdns heeft een resolver. Die is erg snel, maar onder grote load zie je dat er iets heel debiels in zit. Bij het maken van een uitgaande query wordt er in een lineaire lijst van #define 200 lengte een leeg slot gezocht. Bij < 50 uitstaande queries is dit niet zo duur. Load je je resolver met 150-200 uitstaande queries (bv omdat je een webcrawler schrijft die naar Asie gaat wandelen), dan gaat het ding op een dikke CPU gewoon 45% CPU draaien. Het blijkt dan dat hij van die tijd 30% bezig is met door die lijst heen fietsen... een hash op query type/label is triviaal te bedenken. Patches worden niet geaccepteerd. IPv6 support wordt niet ingebouwd door Dan, omdat 'niemand daar behoefte aan heeft'. Fout. Ik heb er behoefte aan binnen onze ISP. Het voortstuwen van DNSSec waarbij NXT door NSEC wordt omgeschreven en ueberhaupt het standardiseren van dit protocol wordt met een hele reeks argumenten weerlegd. Als uiterste redmiddel wordt het standpunt van de dag 'cant do this because it breaks existing implementations'. Kom nou toch. Obscuriteit van de sourcecode tot daar aan toe, gebrek aan inzichtelijke documentatie is nog een ander punt, maar ik zou heel die zooi al boycotten wegens onuitstaanbaar arrogante (ja haast asociale) houding van de auteur. Pim -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
On Thu, 4 Sep 2003, Pim van Pelt wrote:
djbdns heeft een resolver. Die is erg snel, maar onder grote load zie je dat er iets heel debiels in zit. Bij het maken van een uitgaande query wordt er in een lineaire lijst van #define 200 lengte een leeg slot gezocht. Bij < 50 uitstaande queries is dit niet zo duur. Load je je resolver met 150-200 uitstaande queries (bv omdat je een webcrawler schrijft die naar Asie gaat wandelen), dan gaat het ding op een dikke CPU gewoon 45% CPU draaien. Het blijkt dan dat hij van die tijd 30% bezig is met door die lijst heen fietsen... een hash op query type/label is triviaal te bedenken. Patches worden niet geaccepteerd.
Idd, met veel queries wil je die maxudp opschroeven en deze http://ppetru.net/djbdns/ patch eroverheen gooien om zn poll gedrag wat slimmer te maken. ( loste de problemen op de zonnet dnscache dozen, die erg loaded zijn, op )
IPv6 support wordt niet ingebouwd door Dan, omdat 'niemand daar behoefte aan heeft'. Fout. Ik heb er behoefte aan binnen onze ISP.
Het vervelende is ook dat de ipv6 patches die er zijn van een duitser komen die minstens net zo erg is als djb, aka rare bugs, geen documtentatie.
Obscuriteit van de sourcecode tot daar aan toe, gebrek aan inzichtelijke documentatie is nog een ander punt, maar ik zou heel die zooi al boycotten wegens onuitstaanbaar arrogante (ja haast asociale) houding van de auteur.
Het is een keuze, klein en zelf modden, of groot en features. Omdat je software bij gebruik binnen een isp bijna altijd toch moet tunen, veranderen, is het in sommige gevallen zo dat het mooi met djb software op te lossen is. -- Sten Spans There is a crack in everything that's how the light gets in.
participants (3)
-
bvisser-nlnog＠xs4all.nl -
pim＠bit.nl -
sten＠blinkenlights.nl