DNS Response Time analysis - NS2.PBI.NET

Slowdowns at the main PacBell DNS server will affect all PBI customers, including dialup, DSL, and T1. That's because all reverse IP lookups from anywhere on the net must resolve through either NS1 or NS2.PBI.NET. There is no escape for PacBell and SBC internet customers.

Web surfing response for all customers is impacted as well, even if they don't directly use PBI's problematic main DNS server, because most web servers do reverse lookups on all ip addresses to log visitors. Visible hourly load spikes even in the wee hours are probably some web servers doing delayed processing of their IP logs. Most servers do it immediately, which is why web surfing response depends heavily on the ISP's primary DNS server.

PacBell disclaims that they are not responsible for slowdowns of remote servers, presumably due to net congestion. The charts below show that PBI's DNS servers may be largely to blame. A slow main DNS server has the effect of limiting PacBell's overall bandwidth requirements, especially at peak load times, by slowing down the users. SBC press releases about fiber and other high bandwidth options seem rather empty, given that those technologies will also suffer the same DNS delays and timeouts.

Consider what's happening when the chart shows an averaged response time of two seconds. For each quick response which should nominally take about a tenth of a second, there must be one lagged by four seconds or more. When there are load spikes from remote web servers, all customers really are affected.

Any Pacbell hosted sites will be especially slow to respond to remote visitors, since all lookups must go through the overloaded DNS.

DNS failures (shown as packet loss) mean freezes and missing content.

Unlike the ping graphs, this is a plot of averaged response time. Several quick responses will reduce the effect of a four second (4000 ms) delay. Failed responses are not factored into the average at all, so any packet loss is a sign of severe problems. The other graphs show optionally dropped ping packets. If a DNS server is dropping requests, then a trouble ticket should be opened.

Target IP 206.13.29.11 Secondary PacBell DNS server in San Francisco Alternate recursive DNS servers available to SBC customers: 206.13.28.11 SF heavily loaded ns1.pbi.net 206.13.28.12 SF heavily loaded main customer DNS for SF area 206.13.29.11 LA heavily loaded ns2.pbi.net 206.13.29.12 "" 206.13.30.11 San Diego slow 206.13.30.12 "" 206.13.31.11 Sacramento slow 206.13.31.12 "" 198.83.19.241 ns3.prodigy.net 198.83.19.244 ns4.prodigy.net 209.30.0.9 ns1.flash.net 209.30.0.100 ns2.flash.net
Blue represents the percentage of failed lookup requests.
Green shows the average response time. Tracking was started on March 15, 2002.
Every five minutes, 25 randomized reverse lookup requests are made at one second intervals (a trivial load on the server.) The SF DNS server is three hops (15 ms min) away within the PBI network.

Back to the PacHell pageThe statistics were last updated Saturday, 22 August 2009 at 0:23,
at which time 'unknown' had been up for unknown.

`Daily' Graph (5 Minute Average)

	Max	Average	Current
RTT in ms:	9 ms	0 ms	0 ms
ping:	141 ms	44 ms	23 ms
Percentage	10.0 %	1.0 %	0.0 %

`Weekly' Graph (30 Minute Average)

	Max	Average	Current
RTT in ms:	15 ms	0 ms	0 ms
ping:	298 ms	27 ms	21 ms
Percentage	100.0 %	1.0 %	0.0 %

`Monthly' Graph (2 Hour Average)

	Max	Average	Current
RTT in ms:	6 ms	0 ms	0 ms
ping:	139 ms	24 ms	20 ms
Percentage	6.0 %	0.0 %	0.0 %

`Yearly' Graph (1 Day Average)

	Max	Average	Current
RTT in ms:	2 ms	0 ms	0 ms
ping:	132 ms	76 ms	53 ms
Percentage	6.0 %	0.0 %	1.0 %

2.15.2

Tobias Oetiker <tobi@oetiker.ch>
and Dave Rand <dlr@bungi.com>