[Pdns-users] Problems with ANY query

[Augie Schwer]

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 <martijn at pocos.nl> 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
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users
>
>



-- 
Augie Schwer - Augie at Schwer.us - http://schwer.us
Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072