Date: Fri, 13 Nov 1998 03:51:09 -0800 (PST) From: Randy Bush <randy@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@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.