was i asleep when the gtld servers had the worse problem today?

Fri Nov 13 16:43:34 UTC 1998

> Date: Fri, 13 Nov 1998 03:51:09 -0800 (PST)
> From: Randy Bush <randy at psg.com>
> 
> if i understand, f.root-servers.net was having problems doing an axfr
> from a.root-servers.net.  has anyone determined a technical reason why?

for four days, tcpdump on my side shows behaviour consistent with lost ACKs;
pathchar from my side shows that A's first mile is a lossy 3Mb/s bottleneck.

i've switched F from axfr to ftp for now, and rz.internic.net is showing
the same lossage. i'm sending a lot of duplicate ACKs. transfer is slow.

08:33:01.038694 198.41.0.19.20 > 204.152.184.251.3022: . 58236:59696(1460)
	ack 1 win 8760 (DF) [tos 0x8]
08:33:01.038984 204.152.184.251.3022 > 198.41.0.19.20: . ack 58236
	win 33580 (DF)
08:33:01.039100 204.152.184.251.3022 > 198.41.0.19.20: . ack 62616
	win 29200 (DF)
08:33:01.039176 204.152.184.251.3022 > 198.41.0.19.20: . ack 62616
	win 33580 (DF)

> Date: Fri, 13 Nov 1998 13:21:36 +0100
> From: Ray Davis <ray at carpe.net>
> 
> Aren't NSI's nameservers running bind?  If not, then that's scary.
> If so, then why wouldn't they also become lame rather than insane?

they were having different problems.  their operators had to restart named
but that the zone file itself had transferred cleanly.  they weren't lame.

in other words, NSI's servers' problems were because of me (or: my code)
and my server's problems were because of NSI (or: their transit pipe.)

right now i'm looking at the code, and they're working on their link.