Adam,

thanks for replying, whilst avoiding what was the real issue of my response.
its good to see that you're still up to your old tricks of misspelling
names too.  'lincoln' must be pretty hard to get right.

onto the real issue here.  larry's assertion was that: (and i quote)
  ".aus which doesn't exist for (almost) all intents and purposes".

your response was: (and i quote)
  "Larry that is EXTREMELY MISLEADING.  .AUS exists to some 20,000,000
  estimated users world wide, in just about every country.".

the issue i was raising was that despite some "20M estimated users world
wide" who have access to .AUS, there doesn't seem to be many in the
home country of .AUS who do.

maybe you'd like to make an estimate of the percentage of those in
australia who do?  hmm, maybe you don't want to.


now, as far as your response ...

In message <3.0.5.32.19980618181603.01c0de00&#167;alpha.ah.net>, Adam Todd writes:
>Lincolne, am I not still waiting for you to do that Hop count test frmo two
>months ago to show me whos Root Servers are on the shortest hops from the
>average AU ISP?

i assumed that you knew how caching nameservers worked.  that is, the root
nameservers are only initially asked questions when the caching nameserver
doesn't already know the answer of where the gTLD/ccTLD is, or it has
expired the answer.

it is academic what the 'hop count' is --
if i'm asking my caching nameserver for the MX of 'telstra.com.au', and my
nameserver has already had a previous query for a 'com.au' entry, it already
knows it can bypass using the root (".") nameservers, since it already knows
where ".au" is stored.  given it has already also seen a 'com.au' entry,
it already knows, from past transactions with the '.au' nameservers who
is authoritive for ".com.au". (you did know this already, didn't you??)

if you must know however, the closest root nameserver to me is 10 hops,
most are at 11 hops away, reachable via at least 3 different cable paths
via 3 telstra uplink providers.

from where i am, your .aus fake nameservers are the following:
  ns4.ah.net: 10 hops away, rtt: 1154.655 ms  737.388 ms  1341.134 ms
  ns2.ah.net: 10 hops away, rtt: 1068.262 ms  911.998 ms  1009.482 ms
  eek.httpd.com: 15 hops away, rtt: 369.013 ms  539.792 ms  394.665 ms
  mx.alternic.net: 18 hops away, rtt: 553.594 ms  534.844 ms  539.605 ms

.. i think i'll stick with the current root nameservers thanks.  most of
them are <300msec rtt from where i am.

(as a side note, doesn't "dig mx alternic.net" instantly rule out half of your
nameservers being RFC2010 compliant?  as far as testing your {ns2,ns4}.ah.net
for RFC2010 compliance, it is probably pointless given the queueing delay
within your network's upstream capacity.  its hardly due to be in the
ballpark of RFC2010 section 2.8.  feel free to correct me if you think it'll
pass -- i'll go and test it when i have a free moment).

>Or was that Rick?

huh?

>Oh incidenlty when was the last time you could buy a Vodaphone Mobile
>account from Telstra or Optus?

i've got no idea what you're talking about.


cheers,

lincoln.

PS. it isn't *my* network, provider, or uplink, that is slow:
  spam.ltd:/var2/home/ltd$ /usr/sbin/traceroute ns4.ah.net.
  traceroute to ns4.ah.net (203.21.205.20), 30 hops max, 40 byte packets
   1  ltd-cablemodem (24.192.15.1)  20.694 ms  17.861 ms  19.854 ms
   2  bdr3-fddi-4-1 (24.192.2.2)  10.036 ms  13.165 ms  14.886 ms
   3  Serial6-4.lon3.Melbourne.telstra.net (139.130.5.69)  24.629 ms  19.418 ms  28.036 ms
   4  Fddi0-0.lon-core1.Melbourne.telstra.net (139.130.239.226)  14.219 ms  20.232 ms  8.859 ms
   5  Atm5-1-0-1.pad-core1.Sydney.telstra.net (139.130.249.25)  37.920 ms  39.896 ms  23.166 ms
   6  Fddi0-0.pad11.Sydney.telstra.net (139.130.249.229)  31.255 ms  50.403 ms  34.308 ms
   7  Ethernet0.pad2.Sydney.telstra.net (139.130.249.67)  25.621 ms  28.568 ms  51.155 ms
   8  amaze1.lnk.telstra.net (139.130.33.6)  602.557 ms  303.525 ms  330.097 ms
   9  ip16.amaze.net.au (203.31.216.16)  439.465 ms  432.873 ms  829.980 ms
  10  ns4.ah.net (203.21.205.20)  1154.655 ms  737.388 ms  1341.134 ms

  of course, you've probably previously used the traceroute-gateway i run here
  anyway, to show the above.