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