[NTLUG:Discuss] Slow to access local named virtual host URLs

[Neil Aggarwal]

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
>