[LINK] Top five reasons for Australia to Get a Root-Server.

Tom Koltai tomk at unwired.com.au
Tue Oct 13 12:37:58 AEDT 2009

> -----Original Message-----
> From: Kim Davies [mailto:kim at cynosure.com.au] 
> Sent: Tuesday, 13 October 2009 10:21 AM
> To: Tom Koltai
> Cc: link at anu.edu.au
> Subject: Re: [LINK] Top five reasons for Australia to Get a 
> Root-Server.
> Quoting Tom Koltai on Tuesday October 13, 2009:
> | > 
> | > While I find this highly unlikely, please share your
> | > empirical evidence and it will be addressed immediately. I am 
> | > in a position to do so.
> | 
> | It's a big job Kim. I have worked around the problem by using a 
> | Maryland US based proxy DNS. Mainly because I got fed up with the 
> | "page not found 404's" when I knew they were there.
> You have just proven that it has nothing to do with the DNS, 
> let alone the root servers. DNS alterations will never give 
> you a 404 message, or a "page not found" error, because 404 
> is at the HTTP layer and requires a successful TCP connection 
> be established with a web server. If the root zone was 
> tampered to remove a delegation you would get a "Host not 
> found" error.

Actually, you are correct. Host not found is definitely what I was
referring too. I don't know why I said 404's.

> | But here's a simple example - destination Akamai Whitehouse:
> | 
> | Tracing route to e2561.g.akamaiedge.net [] 
> What does this have to do with the root servers? Absolutely 
> nothing. I have no idea what you are trying to illustrate 
> except perhaps that Akamai has mirrors of the Whitehouse 
> website in different places, and that you are surprised from 
> different ISPs your traceroute goes to different mirrors.

I would have thought that all Australian routes would be travelling on
one of the four links out of the country.
For the Optus Looking glass to say- there is no ICMP route is initially
a routing error that somewhere along the chain must rely on a root

If Optus are taking their root-server data from Singtel who then in turn
are recovering it form the Japanese based M Server, that would suggest
there is a serious disconnect in Australian routing. Not merely because
Optus and Telstra don't peer, because they do.

However, it may well be that Optus routing policy is dictated by

> | Actually anycasting of multiple IP numbers to multiple different 
> | hosts.

Here I was actually referring to an attack method and not a defence

> I am not sure if you know what anycast is, but it is 
> precisely not using "multiple IP numbers", rather the 
> contrary. 

And yes, Ausnet Services was using this method for cache resolution in
two continents in 1995.

>Anycast was particularly attractive for adding more 
> root server locations because there is a DNS technical limit 
> that stops the creation of an "N", "O", "P"... root server. 
> Anycast allowed the same IP address to be used at multiple sites.
> http://en.wikipedia.org/wiki/Anycast
> | If there is no difference between A to M and the clones of the 
> | f-servers and k-servers, then why are BCDEGHJ still in 
> America. (Note 
> | I omitted the A and the F)
> So what about "J" being present in Sydney is considered 
> "still in America"? Are you saying the operators of "J" 
> should stop providing service in America?

I didn't know the "J" was replicated in Sydney. I really thought we were
on the F.

So I learned something.
> Perhaps what you are really asking is why are US-based 
> organisations running these root server networks. Well, the 
> answer is historical. The root server operators were assigned 
> in a time when the Internet was rather US-centric and there 
> has been no compelling reasons to kick out any of the 
> operators because after almost 30 years, the DNS root server 
> ecosystem has operated practically flawlessly.
> | If the anycast clones are just as good, why don't the originals get 
> | redistributed and replaced with anycast clones?
> I don't get what you are saying... There is no difference 
> between "originals" and "anycast clones". What is the 
> distinction you are making? If an IP address is anycasted it 
> is not as though some instances are anycasted, and some are not.

I beg to differ.
> | The key to the U.S. government's influence is a master list of 
> | top-level domains that the California-based Internet 
> Corporation for 
> | Assigned Names and Numbers distributes to root servers, which guide 
> | traffic to each one of those top-level domains. The U.S. Commerce 
> | Department has final approval of the list.
> This comment refers to the contents of the root zone, not the 
> root servers. I hope you realise they are two different things.

Yes and no.
> | Kim, one final question, can you categorically tell me that 
> with the 
> | anycast f-server you have any control over spam, phishing 
> or malware 
> | via email distribution?
> I have no control over those things, and nothing one could do 
> in the root zone would impact them. Unless you want to delete 
> an entire top-level domain to curb spam (I guess if you 
> removed ".COM" or ".AU" you'd get less spam.)

OK I'm out of my depth. My experiments with caching the "J" root server
in Portland and Sydney in 1995 led me to a different understanding. (And
it was only 45 MB.)
Possibly technology has moved on to the point where Root Servers are not
the final arbiters of whether a spammer can deliver an email to
thousands of addresses. 

> | I would posit that with our own root server, Australia 
> would be able 
> | to instigate a far more rigorous defence against these attacks. 
> | Specifically if the new server was authoritative for all 
> APNIC address 
> | space.
> This makes no sense. Now I get a feeling you must be trying 
> to pull a leg - you aren't equating IP addresses with 
> top-level domains?

Again, I may have an older outdated understanding of how the technology

> And for what its worth, APNIC already funds a number of root 
> server instances throughout the Asia-Pacific.
> kim

Thanks. I should do more reading.


No viruses found in this outgoing message
Scanned by iolo AntiVirus

More information about the Link mailing list