refused query on non-query socket from...

Joaquin J. Domens jdomens at corp.terra.es
Wed Mar 6 11:24:03 UTC 2002


Thanks Mark, Jose Mª .....it's a valuable information

        Cheers


Mark.Andrews at isc.org wrote:

> > 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



More information about the bind-users mailing list