Re: ares "feature": Ignores responses from unexpected sources
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
> > 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
> > 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
> > to just hang waiting for a response (it doesn't even timeout, from what
> > 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
> 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
- 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