Recursive queries fail if query source port is not fixed

[Andrey G. Sergeev (AKA Andris)]

Hello Hans,


On 14.08.2008 11:48, Hans F. Nordhaug wrote:
> * Mark Andrews <Mark_Andrews at isc.org> [2008-08-14]:
>>> * Mark Andrews <Mark_Andrews at isc.org> [2008-08-14]:
>>>> 	Does "dig ns . @198.41.0.4" succeed when run from the box
>>>> 	running the nameserver?
>>> Yes.
>>>
>>> I still don't understand why most recursive queries only works after
>>> many, many tries - argh. Oh, I just tested doing one query, waiting 
>>> 30 seconds and then trying - success. Hm, maybe there is a time-out 
>>> issue after all? 
>>>
>>> And "dig porttest.dns-oarc.net txt" never seems to work ;-) Because it
>>> changes all the time ...
>>>
>>> Hans
>> 	I suspect that you are overwhelming some state table in
>> 	one of the firewalls.
> 
> Hm, that actually seems like a plausible reason. I don't get any
> obvious reports from the Cisco ASA, but I'll dig into it.
> 
>> 	With "port 53" you didn't need to keep state in the firewall
>> 	as you were allowing all packets to port 53 which includes
>> 	reply packets.
> 
> (Or with port 40053 which I also tested.)
> 
>> 	When you remove "port 53" then the firewall needs to keep
>> 	state to allow the reply to come back in. 
>>
>> 	When you make the second or third request of the nameserver
>> 	it starts its lookups from deeper in the heirachy which allows
>> 	it to succeed before the firewall is overhelmed.
> 
> OK, that makes sense, but we aren't talking 2-3 requests - sometimes I
> have to make 10-20 requests before I get a reply.

Assuming that your name servers aren't authoritative for the, say, 
yandex.ru, ku.dk and asahi.co.jp zones, please post here the results of 
doing at least one command suggested below without the query-source 
directive specified in your named.conf.

dig images.yandex.ru. a +tra
dig ku.dk. mx +tra
asahi.co.jp. ns +tra


-- 

Yours sincerely,

Andrey G. Sergeev (AKA Andris)     http://www.andris.name/