RE: [reSIProcate] DNS feature request
I agree it should be fixed properly in ares... but if we are caching the
lookups then the negative side effects of this problem are greatly reduced
in some scenarios. Ie. Multiple lookups of localhost will not cause the
/etc/hosts file to be opened and parsed every time - since it would be
cached and subsequent requests for localhost wouldn't even hit ares.
If I remember correctly ares has some unimplemented methods that are
supposed to provide some sort of caching. We may be able to use that
framework as part of a solution (ie. Load entire /etc/hosts file into ares
cache) - but it needs formal investigation. : )
-----Original Message-----
From: derek [mailto:derek@xxxxxxxx]
Sent: Thursday, March 10, 2005 7:25 PM
To: 'Robert Sparks'; 'Scott Godin'
Cc: 'Cullen Jennings'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] DNS feature request
The caching will run on top of DnsInterface&ExternalDns, which is the
abstraction that hides ares. It won't even know /etc/hosts exists; I think
we'll have to fix ares.
--Derek
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx]
> Sent: Thursday, March 10, 2005 3:17 PM
> To: Scott Godin
> Cc: 'Cullen Jennings'; 'derek'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] DNS feature request
>
> I don't think we were planning to cache results out of /etc/hosts,
> but even if we were, there are environments where caching
> must be turned off, so the caching work being done now by itself
> is an insufficient solution.
>
> RjS
>
>
> On Mar 10, 2005, at 5:11 PM, Scott Godin wrote:
>
> > Derek - will your DNS caching idea - eliminate this issue?
> >
> > -----Original Message-----
> > From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx]
> > Sent: Thursday, March 10, 2005 6:07 PM
> > To: Scott Godin
> > Cc: 'Cullen Jennings'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [reSIProcate] DNS feature request
> >
> > On many systems this will hose your resolver.
> > (Long ago and far away, "lookup" could go into resolv.conf
> > nowdays it only makes sense on a handful of platforms and on
> > most of those it has moved to other places (and is called order,
> > and the b below is because the arguments to lookup or order are
> > "bind" and "file"))
> >
> > That said - I did some digging through ares this morning and
> > see _deep trouble_ with this part of that code. (written from
> > a *nix centric pov - make appropriate substitutions where appropriate)
> >
> > 1) It will completely crap out if it encounters a v6 address in
> > /etc/hosts
> >
> > 2) on ->every<- call to ares_gethostbyname that happens to invoke
> > the look into the file (say, you changed the default order to "fb"
> > for example), it opens /etc/hosts, then for each line (until it
> > finds a match)
> > mallocs a hostent and fully parses the line into it. Again it does
> > this for
> > every line in the file until it finds a match. EVERY CALL.
> > Amazing waste when trying to touch "localhost".
> >
> > This is a big deal. Most DNS setups you run into in the wild won't
> > resolve
> > localhost. So with the default build, testSpeed will report horrible
> > numbers
> > (you first fail out of DNS, then have to parse /etc/hosts for every
> > transaction).
> >
> > The long term fix will be to replace the file_lookup code with
> > something
> > that initializes an efficient memory structure based on the file at
> > startup,
> > works from memory, and watches the file system for changes to the file.
> >
> > For the short term, I suggest hardcoding something that says:
> > if (name=="localhost") return 127.0.0.1
> >
> > That'll help _immensely_ with the folks that are doing a sniff-test on
> > the
> > stack for the first time with something like testSpeed
> >
> > v6 won't work anyhow, so we're not breaking that worse than it already
> > is.
> >
> > comments?
> >
> > RjS
> >
> > On Feb 10, 2005, at 3:29 PM, Scott Godin wrote:
> >
> >> Hi Cullen,
> >>
> >>
> >>
> >> BTW: It looks like there is a way to change the ares precedence (DNS
> >> vs hosts file). If you put the following line into /etc/resolv.conf:
> >>
> >> lookup f b
> >>
> >> you are telling ares to look in host (f)ile before DNS(b) servers. (I
> >> have no idea why it?s ?b? and not ?d?.)
> >>
> >>
> >>
> >> Scott
> >>
> >>
> >> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx]
> >> Sent: Thursday, February 10, 2005 1:56 PM
> >> To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [reSIProcate] DNS feature request
> >>
> >>
> >>
> >>
> >> Cool - thanks. I tried with a domain that existed and did not realize
> >> it tried DNS *first* then would fall back to hosts.
> >>
> >> On 2/7/05 2:24 PM, "Scott Godin" <slgodin@xxxxxxxxxxxx> wrote:
> >>
> >> Hi Cullen,
> >> I tried it out - and ares does seem to look in /etc/hosts if it fails
> >> to
> >> find the entry via a DNS lookup. It will look in /etc/inet/hosts if
> >> you
> >> have ETC_INET defined.
> >>
> >> Looking at this I'm thinking of making the hosts file location for
> >> Win32
> >> more Windows friendly. To do this I need to lookup the hosts file
> >> location
> >> from the registry.
> >>
> >> Scott
> >>
> >> -----Original Message-----
> >> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx]
> >> Sent: Saturday, February 05, 2005 10:56 AM
> >> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: [reSIProcate] DNS feature request
> >>
> >>
> >> Right now Areas does not look in /etc/hosts which means you can't
> >> type in
> >> manual overrides for stuff. This is often a real haste in testing
> >> situations. Would be nice if if it looked in /etc/hosts for A and
> >> AAAA type
> >> stuff.
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >>
> >>
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >