Recursive queries fail if query source port is not fixed

[Steven Stromer]

I doubt that this is at all pertinent, but I was experiencing similar  
behavior once I patched a client a few weeks ago and took them off  
port 53. Recursive requests were failing three out of every four  
times they were made, yet digs with trace worked. The company uses a  
crappy Netgear firewall that I can't wait to trash. However, the fix  
ended up coming from turning off tcp and udp flood protection on the  
firewall. In this case the firewall was located between a DMZ area  
and the company LAN, with the recursive nameserver located in the  
DMZ, so the network was probably slightly different... However, the  
symptoms sound so familiar that I thought I'd mention it. Maybe your  
Cisco router is interpreting all the randomized UDP activity as a  
flood. Apologies if this is off track with your issue - good luck  
finding a fix!

Steven



> At Fri, 15 Aug 2008 10:27:13 +1000,
> Mark Andrews <Mark_Andrews at isc.org> wrote:
>
>>>>> fctx 0x87b7b20(images.yandex.ru/A'): query
>>>>> fctx 0x87b7b20(images.yandex.ru/A'): done
>>>>
>>>> This seems to indicate creating a query socket somehow failed.  Can
>>>> you build BIND by hand to see if you can reproduce the problem with
>>>> it?  Then we may add some ad-hock patch to provide more detailed  
>>>> log
>>>> information.
>>>
>>> Can you run sockstat and see if there are a large number of
>>> listening UDP sockets from another process or processes that
>>> maybe named is attempting to BIND to as well (and failing) when
>>> sourcing the queries? I'm not sure how BIND determines (if it
>>> does) if a port is free before attempting to bind to it when
>>> sourcing a query. I know you can specify port ranges to not
>>> use. Maybe the issue is that the port is being used by another
>>> process and eventually after a retry or two, you source from a
>>> port that is not being consumed by another process and it works.
>>
>> 	The -P2's won't bind(2) to a port that is in use.
>
> And the failure of bind(2) doesn't well explain why "any" recursive
> queries failed.  This could happen in theory, but since named retries
> bind(2)ing with different sockets many times before finally giving up,
> the chance of happening this for all queries should be extremely
> small in practice.  There should be something unexpected behind the
> scene.
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
>
>