named, RedHat 6.2, and multicast interaction problem

Jim Reid jim at rfc1035.com
Mon Jun 12 09:52:58 UTC 2000


>>>>> "Antonio" == Antonio Querubin <tony at lava.net> writes:

    Antonio> On a Redhat Linux 6.2 system, named (BIND 8.2.2 P5-9)
    Antonio> syslogs numerous messages of the form:

    Antonio> "refused query on non-query socket from [x.x.x.x].1024"

    Antonio> where x.x.x.x is the address of a host from which it is
    Antonio> receiving a multicast UDP stream from.  These syslog
    Antonio> messages stop if there are no more processes that have
    Antonio> 'joined' the multicast group.  The multicast group
    Antonio> address 224.0.1.143 and the destination port is 1024.

    Antonio> A BSDI 4.x system does not exhibit this syslog problem
    Antonio> when it's receiving the same multicast stream.  So it
    Antonio> seems that this is peculiar to Redhat 6.2 and the version
    Antonio> of BIND that comes with it.  Is this a known problem and
    Antonio> a possible fix?

You're probably just unlucky. By default a BIND8 name server uses a
random, non-privileged port when making queries to another name
server. It gets upset if something sends packets to that port unless
those packets are answers to the queries it made. That's what causes
the error message above to be logged.

So it looks like your Linux name server has picked a random port
number for those queries (1024) that happens to be used by something
else for some multicast thing. Oh well. The name server on the BSDI
system will presumably be using some other random port number for its
query socket which doesn't conflict with this multicast thing. [Maybe
the name server was started after the multicast application on the
BSDI system's /etc/rc script?] Therefore it doesn't report that it
gets unexpected packets on that socket.

Try an ndc reload or ndc reconfig on the Linux box. These should get
the name server to use another port for its outgoing queries. [ndc
restart might have the same effect.] Another solution would be to use
a query-source in the name server's options{} statement so that the
name server used a port number and address of your choosing when it
queries another name server.



More information about the bind-users mailing list