Strange error in logs

[Chris Hanlon]

No, that's nothing in my config - these are name servers that have been
running upwards of 8 years, and I only started getting this message about a
month ago, on 2 of them...and always from teh same 5 IP addresses.  They've
pretty much got to be specifying port 53 from their end.

----- Original Message ----- 
From: "Kevin Darcy" <kcd at daimlerchrysler.com>
To: <comp-protocols-dns-bind at isc.org>
Sent: Tuesday, August 10, 2004 3:58 PM
Subject: Re: Strange error in logs


> As Mark Andrews pointed out, "query on non-query socket" can happen if
> you force your query source port to be 53 (i.e. same as your listening
> port). Are you configured this way? If so, is there any reason why you
> have to be configured this way? Mark's hypothesis seems much more likely
> than the speculations I threw out in my last message.
>
> - Kevin
>
> Mipam wrote:
>
> >On Mon, 9 Aug 2004, Kevin Darcy wrote:
> >
> >
> >
> >>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.
> >>
> >>
> >
> >I am getting such messages regularly. Allthough it seems unlikely someone
> >is sending queries on purpose to ports which were opened by bind
> >temporarly to receive an answer, because that someone had to know what
> >source port(s) were used, or he must have been sending probes to lots of
> >ports. An other and i guess more likely possibility could indeed be
> >something at the remote end.
> >I am not worried about it too much. Often ppl will be trying to see what
> >bind version is running and see if they can do some "stuff" with it.
> >There are no known unresolved published bugs in bind9 i believe, but
> >likely some will be found as time progresses, all software contains bugs.
> >Time to stop cause i'm way off topic already.
> >Bye,
> >
> >Mipam.
> >
> >
> >
> >
> >>
> >>                                                         - 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.)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
>
>
>
>