Date: Sat, 03 May 2003 00:31:39 +0200 From: Melvyn Sopacua <freebsd-stable@webteckies.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: IPv6 Resolver (or: Slow rendering of Webpages using Konqueror) Message-ID: <5.1.0.14.2.20030503000112.04a59138@pop.nyvlem.mine.nu> In-Reply-To: <20030502173549.GA10527@walton.maths.tcd.ie> References: <200305021803.18757.freebsd-stable@webteckies.org> <200305021105.h42B5p1G012593@drugs.dv.isc.org> <200305021803.18757.freebsd-stable@webteckies.org>
index | next in thread | previous in thread | raw e-mail
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@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"); ?>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.2.20030503000112.04a59138>