Re: progress?

[Harald Alvestrand <Harald@Alvestrand.no>]

At 13:05 05/09/2000 -0400, Randy Bush wrote:
> > the greatest problem in monitoring is to get traceroute to do reverse-
> > lookup on the aroot.psg.com host consistently (58 = 10% "failure", 53 of
> > which were reverse-lookup failures).
>
>hmmmm.  the in-addr.arpa primary for aroot.psg.com's ip address is in normal
>unicast space close to the core of a not-so-small backbone.  monitoring this
>failure, and seeing if it could be failure to get the parent, might be
>interesting itself.

I suspect losses & timeouts - my dns resolver config seems to have a low 
retransmission count. Note that all 3 nameservers are at delays > 200 msecs 
from the monitoring machine.
They also fate-share the first 10 hops on the traceroute (heading to 
Stockholm), and all are carried on the qwest backbone after that.

Is it correct that the NS records for 230.83.192.in-addr.arpa come straight 
out of the in-addr.arpa zone?

Here's the current status of another of my silly-monitor attempts.... 
looking up the NS records for "asdfgh.com" at the root servers for .COM; 
this has been running since January. No plots, I'm afraid.

Server               Samp  Min  Ave  Max   0 1.0 2.0 3.0 4.0 5.0 6.0
A.GTLD-SERVERS.NET    146  140  204 5232 
145                   1
A.ROOT-SERVERS.NET    149  139  163  433 
149
B.GTLD-SERVERS.NET    150  328  481 5339 
146                   4
C.GTLD-SERVERS.NET    147  148  176  433 
147
E.GTLD-SERVERS.NET    144  196  227  481 
144
F.GTLD-SERVERS.NET    147  211  245  486 
147
F.ROOT-SERVERS.NET    143  196  265 5210 
142                   1
G.GTLD-SERVERS.NET    147  152  238 5220 
145                   2
I.GTLD-SERVERS.NET    126   31 1056 5216 
101                  25
J.GTLD-SERVERS.NET    143  139  199 5161 
142                   1
K.GTLD-SERVERS.NET    147  142  238 1454 
143   4
M.GTLD-SERVERS.NET    141  367  574 5591 136   2               3

The total number of queries is 153. All of the servers were asked every time.
The "5.0" is responses that took between 5 and 6 seconds, indicating a 
retransmission.
There were no responses indicating a third transmission, which probably 
means my DIG config defaults to 2 transmissions, and then gives up.

Conclusion: Servers for .com lose packets. 2 retransmissions is not enough.
Want a twist on this to see how well the in-addr.arpa zone is handled?







--
Harald Tveit Alvestrand, alvestrand@cisco.com
+47 41 44 29 94
Personal email: Harald@Alvestrand.no