IPv6 Resolver (or: Slow rendering of Webpages using Konqueror)

[Melvyn Sopacua]

At 19:35 2-5-2003, David Malone wrote:

>On Fri, May 02, 2003 at 06:03:18PM +0200, Melvyn Sopacua wrote:
> > Let's keep the  flaming part to a minimum. I sent an email to DoubleClick
> > regarding the issue, and my support contact has forwarded the email to the
> > Networking guys and will follow up on it (and if he doesn't I will).
> > So essentially, we're working on the same end of the problem.
>
>Yay! I've mailed them about this before and never got a response
>from them. I was pretty polite with them,

Oops :P

>  and pointed out that the
>problem caused their ads to be missed by my users.

A quick calculation (AFAIK it only affects *BSD systems and BSD/OS 4.3+),
will show probably less than 1% of their visitors.

I therefore took another angle.

>  Since I got no
>response I just set up my nameserver to think it was authorititive
>for doubleclick.net and give it an empty zone, so lookups are much
>faster now. >-)

Hmm, that would be something to consider - allthough, it doesn't change
the issue for users.

> > My _personal_ opinion, is that it's just plain dumb, that these 
> 'loadbalancing
> > cowboys' can tie up system resources for such a lengthly period of time 
> and a
> > systems' administrator can do nothing about it, but patch applications.
> >
> > Imagine the implications, when your mailserver is presented with a 
> bunch of
> > 'MAIL FROM: foo at doubleclick.net'...
>
>Unfortunately, anyone with a non responding name server (v4 or v6,
>transport or records) generates a very similar looking problem, if
>DNS lookups in your service/application are single threaded.

Yes, true. And using standard tools, you can trace (and therefore fix or 
work-around)
the problem accordingly. IPv6 is not something you expect and even after I 
found the
issue, I checked every conf file I could think of, read quite a few 
manpages to check
if I didn't forget to turn off anything IPv6 related.

Additionally - according to FreeBSD's manpage,
/etc/resolv.conf does not support the options:
1) timeout - hard coded in /usr/include/resolv.conf to 5 secs
2) attempts - the number of times the resolver will send a query to its 
name servers
    before giving up and returning an error to the calling application. This is
    completely unimplemented (RES_DFLRETRY is not defined in 
/usr/include/resolv.h)

which would allow some finer grained runtime control over slowdowns (I actually
use this, when for instance a peering with a major consumer ISP is down and 
newsletters
are being sent out, backed up with a Smartrelay queue run to divide the 
load over
2 physical machines and the Smartrelay host does full lookups).

>         David.

With kind regards,

Melvyn Sopacua
<?php include("not_reflecting_employers_views.txt"); ?>