Strange error in logs

[Kevin Darcy]

Nope. "refused query on non-query socket" is a whole different animal 
than a simple "query denied". What named means by "non-query socket" is 
that a query packet came in on a port that was being used to *send* 
rather than receive DNS packets. This is a problem on the remote end, or 
with something doing port forwarding or some other kind of manipulation 
(e.g. resetting the QR bit, thus making responses look like queries, 
perhaps?) in between the client and the server, or simple packet 
corruption (although I would expect a wider variety of error messages in 
the case of corruption).

If it were me, I'd start sniffing the packets to find out what's really 
going on.

                                                                         
                                                         - Kevin
BOG wrote:

>Greetings Chris,
> What you see here, is that your NS is rejecting queries from 216.52.184.230.
>This could be caused by several reasons, which are almost always related
>to your ACL settings. More specifically; your setup refuses queries based
>on certain criteria you've setup in your copy(ies) of named.conf. For example:
>
>zone "domain.dom"
>    type master;
>    file "domain.dom.zone"
>    allow-transfer { trusted; };
>    allow-query { any; };
>
>Indicates that domain.dom will allow transfers from all IP's listed in the
>"trusted" clause, and will allow queries from *any* host/domain. Your best
>approach (if security is a concern) here would be to use:
>
>    allow-query { acl; };
>
>Then you would create an ACL clause listing any IP's you *trust* to make
>queries. Most notably; all your NS's - ie; your Secondaries. The same should
>be an *absolute* where the "allow-transfer" is concerned.
>
>Hope this clears things up for you.
>Best wishes,
> Chris
>
>"Chris Hanlon" <chanlon at mergetel.com> wrote in message news:<cf0h44$1ggo$1 at sf1.isc.org>...
>  
>
>>For the last couple of weeks I've been getting messages like these in my
>>message log:
>>
>>Aug  6 13:02:49 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [216.52.184.230].53
>>Aug  6 13:02:53 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [63.251.163.102].53
>>Aug  6 13:02:53 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [216.52.184.230].53
>>Aug  6 13:02:57 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [63.251.163.102].53
>>Aug  6 13:02:59 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [63.251.83.36].53
>>Aug  6 13:03:03 mergex last message repeated 1 time
>>Aug  6 13:03:17 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [64.74.96.242].53
>>Aug  6 13:03:21 mergex last message repeated 1 time
>>Aug  6 13:03:35 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [212.118.243.118].53
>>Aug  6 13:03:39 mergex last message repeated 1 time
>>Aug  6 13:03:53 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [216.52.184.230].53
>>Aug  6 13:03:57 mergex last message repeated 1 time
>>Aug  6 13:04:01 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [63.251.163.102].53
>>Aug  6 13:04:05 mergex last message repeated 1 time
>>Aug  6 13:04:13 mergex named[26439]: [ID 295310 daemon.notice] refused query
>>on non-query socket from [63.251.83.36].53
>>Aug  6 13:04:17 mergex last message repeated 1 time
>>
>>They're nothing I've ever seen before - and I have them showing up at the
>>same times in the message logs of 2 of the 3 DNS servers I maintain ... and
>>never on the 3rd one.
>>
>>The IP addresses are always the same 5, according to ARIN they all are part
>>of netblocks owned by InterNAP and I think most are delegated to eNOM.
>>
>>Any idea what they are?  And should I do anything to my config to deal with
>>them?  (Running BIND 8.1.2 on one and  9.2.1 on the other.)
>>    
>>
>
>
>
>
>  
>