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

[Chris Cox]

Neil Aggarwal wrote:
> 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.

A MAJOR, MAJOR BUG.  Sure wish I could convince the GNU
folks though (Chris == peon that is sometimes right, GNU = always right
even when they are wrong).

> 
> 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
>>
> 
> 
> 
> _______________________________________________
> https://ntlug.org/mailman/listinfo/discuss
> 
>