[reSIProcate] Open issue rundown

[Robert Sparks]

(trimming the discussion back to just the list - the "also copy" was  
getting out of control)

There is (very poor) code in ares to read /etc/hosts.

There is (broken) code in ares to configure ares to use /etc/hosts  
first then fail over to being a DNS client
Off and on, a little over a year ago, we had a round of patches that  
tried to keep ares from failing to /etc/hosts
when it didn't find a record working as a DNS client (because the  
very poor code mentioned above can be
murderously slow). I don't remember whether we ended up with a  
default where we look in DNS then in the
hosts file, or a default where we look in DNS and then stop.

It's clear from this conversation that we don't have a good  
collective picture of what this particular subsystem
is doing. We need to look at the tests carefully and make sure they  
are meaningful, and we should put some
real effort into documenting how to configure it, and what the user  
should expect to have happen.

RjS

ps. Just to put it down somewhere again, what "very poor" means is  
that for every lookup, ares will open
the hosts file, scan/parse each row, doing string comparisons for  
what you're looking for. Here's the
code:

static int file_lookup(const char *name, struct hostent **host)
{
   FILE *fp;
   char **alias;
   int status;

#ifdef WIN32
   fp = fopen(w32hostspath, "r");
#else
   fp = fopen(PATH_HOSTS, "r");
#endif
   if (!fp)
     return ARES_ENOTFOUND;

   while ((status = ares__get_hostent(fp, host)) == ARES_SUCCESS)
     {
       if (strcasecmp((*host)->h_name, name) == 0)
         break;
       for (alias = (*host)->h_aliases; *alias; alias++)
         {
           if (strcasecmp(*alias, name) == 0)
             break;
         }
       if (*alias)
         break;
       ares_free_hostent(*host);
     }
   fclose(fp);
   if (status == ARES_EOF)
     status = ARES_ENOTFOUND;
   if (status != ARES_SUCCESS)
     *host = NULL;
   return status;
}


On Aug 14, 2006, at 7:31 PM, Scott Godin wrote:

> Ares does have support for reading the local hosts file, and it did  
> used to work before the DNS caching stuff was added.  A list member  
> has already noted this and has posted a fix that re-enables the  
> host file lookup, but I haven’t had a chance to examine it closely.
>
>
>
> From: Rohan Mahy [mailto:rohan.mahy at plantronics.com]
> Sent: Monday, August 14, 2006 5:32 PM
> To: Cullen Jennings; Byron Campen
> Cc: resiprocate-devel; Scott Godin; Robert Sparks; Alan  
> Hawrylyshen; Jason Fischl; Matthias Granberry; Derek McDonald; Adam  
> Roach
> Subject: Re: Open issue rundown
>
>
>
> Hi,
>
> To be clear, there is not and has never been support for looking up  
> hosts in the /etc/hosts file.  Ares is an async *DNS* library.  You  
> would need something like a new feature to load /etc/hosts and  
> store this in the DnsRRCache data structure.
>
> I don't think we should bother doing this yet.
>
> thanks,
> -rohan
>
>
>
> On 8/14/06 2:04 PM, "Cullen Jennings" <fluffy at cisco.com> wrote:
>
> 16.   No support for /etc/hosts file
>
>
> Status:
> 16. Cullen says this is working on OS X. Not tested (AFAIK).
>
> Not tested - I looked at code (this is all in ares) and on windows  
> it uses the registry to find the path - this probably needs be  
> tested separately on each OS and  on each major version of windows.
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any  
> documents, files or previous e-mail messages attached to it, may  
> contain information that is confidential and/or legally privileged.  
> If you are not the intended recipient, or a person responsible for  
> delivering it to the intended recipient, please DO NOT disclose the  
> contents to another person, store or copy the information in any  
> medium, or use any of the information contained in or attached to  
> this transmission for any purpose. If you have received this  
> transmission in error, please immediately notify the sender by  
> reply email or at mailto:privacy at plantronics.com, and destroy the  
> original transmission and its attachments without reading or saving  
> in any manner.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060815/1eecdbe6/attachment.htm>