Martijn, Your concerns sound familiar and I'm pretty sure they all got covered in the latest 2.9.21 release; check these bug reports to see if they match what you are seeing:
http://wiki.powerdns.com/cgi-bin/trac.fcgi/ticket/167 http://wiki.powerdns.com/cgi-bin/trac.fcgi/ticket/125 http://wiki.powerdns.com/cgi-bin/trac.fcgi/ticket/124 http://wiki.powerdns.com/cgi-bin/trac.fcgi/ticket/118 --Augie On Thu, Jul 17, 2008 at 3:28 AM, Martijn Grendelman <[EMAIL PROTECTED]> wrote: > Hi, > >> First let me say 2.9.20 has many issues that are fixed in 2.9.21. In any >> case 2.9.21 will behave differently with regards to the issue you are >> seeing. > > I once upraded tot 2.9.21, but then a critical problem concerning > wildcard cnames arised, IIRC, so we had to roll-back :-( > >> What is happening is that ns6.ilse.nl gets a 'recursion desired' query for >> ilsemedia.nl. It can answer without recursion however, because the server is >> authoritative for ilsemedia.nl. On answering, it discovers all the >> ilsemedia.nl records do not fit in the standard 512 byte UDP packet, and it >> sends back a truncated packet, with a flag that says 'ask over TCP'. > > Ah, thank you for this explanation! > >> Then dig retries over TCP, and then something unfortunate happens. TCP >> recursion desired queries are always handed over directily to the configured >> resolver ('recursor=' in the configuration), without looking at the local >> cache. And I think your recursor then fails to transfer all those records >> over TCP. > >>> If I try the ANY query with 'dig +norecurse', it works! >> >> That is correct. Luckily, the world at large will only ask +norecurse >> questions. The only people that won't are the people you resolve for, so for >> them it might be a problem. > > Well, as a matter of fact, I stumbled across this problem, because the > registration of a .fr domain failed. Apparently, AFNIC does nameserver > checks that are even worse than the ones from SIDN and it appears they > do an ANY query that fails on these servers, so I suspect they ask with > 'rd'. > >>> I just added a domain to the database, so the server is authoritative >>> for it. The domain has not yet moved, so the 'real world' nameserver is >>> in fact 'dns2.nettica.com'. >>> >>> Now if I query the server for it (from somewhere on the net, from an IP >>> that is NOT allowed to use recursion on this server): >>> >>> $ dig @ns6.ilse.nl spullenbank.net any >> >> Odd - more or less the same thing happens, a fallback to TCP, which causes >> the entire query to go to the recursor. Are you 100.00% sure you don't allow >> recursion for the world? Your server positively says it is willing to >> recurse for me. > > Over UDP it doesn't, as far as I can tell. If I ask it for 'xs4all.nl > any', I get SERVFAIL. The log says: "Not authoritative for 'xs4all.nl', > sending servfail to 213.207.104.11 (recursion was desired)". > > However, dig +tcp @ns6.ilse.nl xs4all.nl any gives me what I asked for. > >>> I get the results from dns2.nettica.com! If I do: >>> >>> $ dig +norecurse @ns6.ilse.nl spullenbank.net any >>> >>> I get the results from ns6.ilse.nl >> >> That is correct. >> >>> I hope the problem is clear. It appears that PowerDNS is recursing on >>> ANY queries (and not on other type queries), even though the client is >>> not allowed to recurse AND the domain in question CAN be answered >>> locally (and only when both of these conditions are met). >>> >>> Is this is known issue with 2.9.20? >> >> You might want to try with 2.9.21, but in general, mixing auth and resolver >> operation on 1 IP address is filled with issues like these. This is >> partially due to the PowerDNS design, partially due to the fundamentally >> confusing nature of mixing both modes of operation. > > I guess I can lose the whole recursor thing. > >> I see two "bugs" in the above: 1) that TCP recursion desired packets aren't >> filtered through the local database 2) that your server appears to be >> willing to recurse for the whole world over TCP. >> >> '2' might very well be solved in 2.9.21. > > I'll investigate if an upgrade is viable :-) > > Thank you for your help!! > > Best regards, > Martijn. > > > > > _______________________________________________ > Pdns-users mailing list > [email protected] > http://mailman.powerdns.com/mailman/listinfo/pdns-users > > -- Augie Schwer - [EMAIL PROTECTED] - http://schwer.us Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072 _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
