< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

Re: [reSIProcate] Open issue rundown


(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@xxxxxxxxxxxxxxx]
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx, and destroy the original transmission and its attachments without reading or saving in any manner.