cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: ares "feature": Ignores responses from unexpected sources

From: Mark Pizzolato <curl-library-20031003_at_reg.pizzolato.net>
Date: Thu, 16 Oct 2003 10:58:40 -0700

On Thursday, October 16, 2003 8:15 AM, 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.
> >
> > The "standard" DNS lookup tools and libraries (nslookup, dig, libresolv)
> > happily accept this and completes the name lookup. Ares doesn't - it
appears
> > to just hang waiting for a response (it doesn't even timeout, from what
I
> > can see).
>
> 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?

Well, the behavior of ignoring responses from sources that weren't directly
requested is viewed as a security advantage. It has existed as an option
(RES_INSECURE1) for a long time in the libresolv code.

I recall recently reading an RFC which describes ignoring such answers as
the best current practice (certainly a SHOULD and maybe a MUST). I'll see
if I can find the particular RFC.

As I recall, that same RFC suggested that a bug exists in a name server
which returns an answer from an interface that it didn't receive a request
on. Upgrading to recent versions of BIND or DJBdns stuff, should fix these
issues if these are the software in use. Meanwhile, if the name server
involved is a Microsoft one, then this issue may never go away. I've had a
case open with them and they admitted that the behavior existed, but decided
that I wasn't a big enough fish to change the code for. The end result is
that a Microsoft name server should never be run on a multi homed machine.

Meanwhile there may be a bug in the ares resolver if it doesn't eventually
timeout .

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