[PLUG] DNS Resolution Problems - 5 second delay

Steve Bonds 1s7k8uhcd001 at sneakemail.com
Wed Oct 8 16:09:02 UTC 2003


On Wed, 8 Oct 2003, AthlonRob AthlonRob-at-axpr.net |PDX Linux| wrote:

> Is that what we're looking at?  It waits five seconds then re-sends the
> packet?  That would explain it, then...
>
> It would also explain why, very rarely, it waits ten seconds before
> timing out altogether.

Yep, you'll see little quantii of time spent when DNS times out because of
packet loss.  This depends on the number of DNS servers listed in your
resolv.conf.  The default timeout in /usr/include/resolv.h is (big
surprise) 5 seconds.

> I'm on a wifi link, but only a few feet from my AP.  ifconfig reports 18
> dropped TX packets of 4MB sent, with one error.  iwconig reports 15
> 'missed beacon' but no other errors.
>
> How else might I determine if the packets are being sent, only to be
> dropped somewhere along the line?

First, set up both the client and server to be NTP time synced.  This
makes comparing packet traces easier.

Then start tcpdump on both systems.  I use "tcpdump -i eth0 -p -s 2048 -w
/tmp/<hostname>_dns.tcpdump".  Refer to the man page for details.  The
"2048" is not magic, but it needs to be bigger than your media maximum
transmit unit including all MAC/MAC-equivalent headers.

Run your test for a minute or so, then cancel both tcpdump captures.  Copy
to a convenient Linux host that has "ethereal" installed and look at them
using:

ethereal -t a -r <tcpdump capture file>

The filters in ethereal allow you to show only DNS packets, which is
likely to be helpful if your network is at all busy.

Now that you say you're on wireless I'm not at all surprised you get
ocassional DNS timeouts.  If your server is local you can work around this
typical packet loss by cranking down your DNS timeout to something like 1
second.  See "man resolv.conf" for details on this option.

  -- Steve

PS: To test your overall packet loss on the wifi link, I've had good luck
getting "netperf" from http://www.netperf.org/netperf/NetperfPage.html and
tcptrace from http://www.tcptrace.org/.  I'll run netperf while tcpdump is
running on the server end, then use tcptrace to analyze the connection and
measure the percent packet loss.  Anything over 5% will be noticable,
though this is a matter of opinion.  ;-)




More information about the PLUG mailing list