On Thursday, October 16, 2003 2:33 PM, Henrik Storner wrote:
> On Thu, Oct 16, 2003 at 05:15:07PM +0200, Daniel Stenberg wrote:
> > On Wed, 8 Oct 2003, Henrik Storner wrote:
> >
> > > I have a DNS server that accepts queries on one IP-address, but sends
the
> > > answers with a different source-IP. A network trace says (IP's and
> > > domain-names changed):
> > >
> > > 10.29.31.155 -> 10.29.37.21 DNS C dns01a.foo.com. Internet Addr ?
> > > 10.29.10.5 -> 10.29.31.155 DNS R dns01a.foo.com. Internet Addr
10.29.37.21
> > >
> > > Note that the request is sent to 10.29.37.21, but the answer
> > > originates from 10.29.10.5.
> >
> > I would say this is a bug. At least it should timeout,
> >
> > If you're still able to repeat this "effect", can you dig into
> > ares_process.c:process_answer() and see what it does to discard to
response
> > and possible how it can be patched?
>
> I don't think ARES sees the response packet at all; it is probably
> dropped by the OS/libc socket library. While browsing the ares source
> code I noticed that it does a connect() on the socket used to
> communicate with the DNS servers, even though it is a UDP SOCK_DGRAM
> socket. My connect(2) man page says:
>
> If the socket is of type SOCK_DGRAM then the serv_addr address is the
> address to which datagrams are sent by default, and the only address
> from which datagrams are received.
>
> Note that last sentence. So I guess it never sees the response
> packets.

This is good and reasonable. The libresolv code can do a datagram based
connect() also. It does this based on a compile time the lack of a #define
of CANNOT_CONNECT_DGRAM. The reason for this is not to explicitly avoid the
oddly sourced return packets, but to provide a quick detection of a Name
Server that really is not listening on UDP Port 53. This works since if a
receiving system doesn't have a UDP listener on a particular port an ICMP
port unreachable response is generated to the sending system. Some IP
stacks are implemented such that a "connected" socket will cache this
information, and will return a ECONNREFUSED on the next socket operation.
You then know not to bother with future retry operations, Note, given the
"sense" of CANNOT_CONNECT_DGRAM, it would seem to be a default/desired
behavior. This is how the libresolv code looks as of the latest BIND 8
libresolve code. However, I seem to recall this code being activated on a
somewhat opposite condition in earlier libresolv code (i.e. it wasn't the
default, and thus RES_INSECURE1 had meaning.

- Mark Pizzolato

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Received on 2003-10-17