[Pdns-users] Problems with ANY query
augie.schwer at gmail.com
Thu Jul 17 16:24:23 UTC 2008
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:
On Thu, Jul 17, 2008 at 3:28 AM, Martijn Grendelman <martijn at pocos.nl> wrote:
>> 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
> 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
>>> 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 22.214.171.124 (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,
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
Augie Schwer - Augie at Schwer.us - http://schwer.us
Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072
More information about the Pdns-users