[NTLUG:Discuss] Slow to access local named virtual host URLs
Neil Aggarwal
neil at JAMMConsulting.com
Tue Apr 6 12:48:25 CDT 2004
Chris:
It turns out one of my DNS servers was down and it was
waiting for a timeout.
You are right. This is a stupid design of the resolver.
Thanks,
Neil
--
Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com
FREE! Valuable info on how your business can reduce operating costs by
17% or more in 6 months or less! => http://newsletter.JAMMConsulting.com
> -----Original Message-----
> From: discuss-bounces at ntlug.org
> [mailto:discuss-bounces at ntlug.org] On Behalf Of Chris Cox
> Sent: Monday, April 05, 2004 10:35 AM
> To: NTLUG Discussion List
> Subject: Re: [NTLUG:Discuss] Slow to access local named
> virtual host URLs
>
>
> Greg Edwards wrote:
> > Neil Aggarwal wrote:
> >
> >> Hello:
> >>
> >> This is strange.
> >>
> >> On RedHat 9, this did not seem to be a problem but it
> seems to be a
> >> problem on Fedora Core 1.
> >>
> >> I am finding that when I try to load a URL that goes to a
> virtual host
> >> on the same server it takes a
> >> LONG time (about 10 secs) to load. If I use a URL
> >> that does not require resolving the named virtual host,
> >> the URL loads very fast (milliseconds).
> ...
> >>
> >
> > Check your /etc/resolv.conf file for a "search" directive.
> My local
> > machines resolve faster without the search directive.
> >
>
> Here's some more insight on Linux resolver problems. I submitted this
> bug on libc.
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=95
>
> Basically the getaddrinfo routine (possibly others) do name resolution
> incorrectly.
>
> Resolvers should:
>
> 1. DNS resolutions always have "domain" or "search" options appended
> to them for unqualified addresses (unless ndots:0 in resolv.conf).
>
> e.g. (resolv.conf)
> nameserver 204.96.200.12
> nameserver 199.1.10.12
> search internal.local
>
> A lookup of "host-name" should cause "host-name.internal.local" to be
> queried against 204.96.200.12.
>
> Today, getaddrinfo queries "host-name" against 204.96.200.12 (which
> will always fail) and then queries "host-name" against 199.1.10.12
> (incorrect see #2), before trying with the "search" information.
>
> 2. DNS resolution via resolv.conf is not a FALL BACK style of
> operation.
> If a nameserver answers back, even if the result is NEGATIVE,
> the resolver
> SHOULD NOT attempt to find the record in the subsequent nameservers.
>
> e.g. (same resolv.conf as above)
>
> A lookup of "bad-name" queries 204.96.200.12 first, and if
> that namesever
> responds, even if it can't find the information for that
> zone, it should
> not send the same query to 199.1.10.12. However, it should
> attempt all
> of the "search" options... and as #1 shows, it really should never
> make the unqualified query unless ndots:0 inside of resolv.conf.
>
> Folks this is a MAJOR bug. Every (and I mean every) query using
> getaddrinfo (telnet, ssh, etc) will make a useless pass THROUGH all
> nameservers listed looking for an unqualified name before trying
> either the "domain" or "search" options when querying DNS. Consider
> the case where the secondary nameserver is DOWN... that means you
> make a meaningless pass on the first nameserver, followed by a
> painfully slow pass through the second (a query which NEVER should
> have happened... but it's a bad query anyway) while the dead server
> times out, then finally a qualified query through the first.
>
> Now.. it's actually even more complicated, because an
> unqualified query
> may make perfect sense on certain sources of name resolution.
> For example
> if nsswitch.conf contains hosts: files dns, then an unqualified lookup
> through /etc/hosts is warranted, but as soon as we consider dns, we
> MUST append the domain or elements of search to the name.
>
> I'm guessing that somebody "simplified" this code without thinking
> and the result is the libc we have... which btw, this has been broken
> for at least several years now.
>
> I welcome anyone else's analysis and if anyone wants to contribute
> the patch for bug#95... please feel free to do so.
>
> This is MAJOR black-eye against Linux vs. commercial *ix.
>
>
>
>
>
>
> _______________________________________________
> https://ntlug.org/mailman/listinfo/discuss
>
More information about the Discuss
mailing list