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

[Chris Cox]

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.