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 <[EMAIL PROTECTED]> 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. > >
