refused query on non-query socket from...

[Mark_Andrews at isc.org]

> Mark_Andrews at isc.org wrote:
> 
> >         There are BROKEN nameservers that fail to set "QR" when
> > they         respond to a EDNS query.  When BIND 8.3 sees a reply like
> > the         following it will generate a "refused query on non-query
> > socket"         message.
> >
> >         Mark
> 
> What does it mean exactly ?

	BIND 8.3 supports EDNS (RFC 2671: Extension Mechanisms for
	DNS) which allows for bigger UDP answers to be sent.  There
	is no way to know in advance if the remote server supports
	EDNS or not.  You just make a query and when you get a
	FORMERR/NOTIMP/SERVFAIL response to a ENDS query you cache
	the fact that the remote server does not understand (except
	for SERFAIL) and retry without EDNS.  You also retry without
	EDNS if the first query timesout as there are some server
	that fail to send back error messages when they detect
	something they don't understand.

	Now responses are *supposed* to have Query Response (QR)
	set in the header (RFC 1034 / RFC 1035).  This allows servers
	that use the same socket for both receiving and making
	queries sort the queries from the responses.

	The server in question is NOT setting QR and as named uses
	a different socket (by default) for making queries to the
	one in receives queries on it is detecting this error and
	logging the message.

> I'm also getting lots of messages like this.
> 
> Is it a problem of the dns that generates the log message or from the dns
> your querying ?

	It's a problem with the remote server.  It is also slowing
	up resolution because the message gets dropped and the
	nameserver has to timeout rather that performing a fast
	retry which it will when it gets a answer indicating the
	remote server does not understand EDNS.
 
	The reason you see a lot of errors is that the remote server
	is a load balancer.  The answers it returns have a low TTL
	so you have to query it a lot more.  Named also don't see a
	cachable indication that the remote server does not understand
	ENDS.  As far as named is concerned it is behind a link
	that is dropping packets.

	Mark

>         Cheers
> 
> J.J.D
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org