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.

I'll try to figure out why it doesn't time out, then.

-- 
Henrik Storner <henrik_at_hswn.dk> 
-------------------------------------------------------
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