Re: [ga-roots] TLD Clusters

[Stefan Probst <stefan.probst@opticom.v-nam.net>]

Jim,

thank you for clarification. I was thinking already, that with "TLD 
Clusters" you mean the sum of all conflicting TLDs with the same name.

Now let me try to put your post into "DNS terms" ;)
The comments below are from two parses of your mail. Some comments on top 
are written after explaining comments below were given....

At 10:30 15.06.01 -0500, Jim Fleming wrote:
-------------------------

>TLD Clusters exist now.

They exist since there are nameservers, which work in master/slave 
(primary/secondary) configuration. I assume this is since the very early 
days of the DNS system.

>Most TLDs (including .COM) have their own Cluster
>of machines that handle queries for SLD.TLD names.

*All* SLDs in the gTLDs need a "cluster" of at least 2 name servers.
I assume, that no TLD is delegated without a minimum of 2 name servers. I 
guess they are required to have even more. "Most" *might* apply to 
alt.roots. It does not for the ICANN root. There it is an "every".

In fact, I wouldn't wonder, if the name servers which serve the gTLDs (and 
the root) (i.e. the single members of your "cluster") are in fact clusters 
of several machines which share the load and are hidden behind a single IP.

>In many cases, 5 or 6 systems are more than enough to form the TLD Cluster.

Your "TLD Cluster" is obviously the group of nameservers which answer 
authoritatively for a TLD, and to which the TLD was delegated by a root.

>As shown below, the .TV TLD appears to have 5 servers in its TLD Cluster.

It is served by 5 authoritative name servers.

>You can  use the tools here, to find the TLD Clusters.
>http://root-dns.org

Do a nslookup or a dig at the root and you should get the same.

>Legacy Root Servers : 198.41.0.4
>VueDig Results : Answer = 5 : Authority = 0 : Additional = 5.
>TV. 2D IN NS NS1.NIC.TV.
>TV. 2D IN NS NS2.NIC.TV.
>TV. 2D IN NS NS4.NIC.TV.
>TV. 2D IN NS NS6.NIC.TV.
>TV. 2D IN NS NS7.NIC.TV.
>
>The so-called "root servers" point to these TLD Clusters.

the TLDs are delegated to be served by those 5 name servers.

>Internally, the members of the TLD Cluster, know about all of the other 
>members
>of the TLD Cluster.

Because there are NS records in the zone file for that TLD. And those NS 
records *should* be consistent with the delegation records in the parent 
domain (i.e. in the root) Besides that, there should be glue records (i.e. 
A records with point to those authoritative name servers).

>In the example above, you could ask NS4.NIC.TV
>who are the members of the TLD Cluster and it will tell you.

As long as the master is configured properly.
Do you consider a hidden (non published) master as a member of your "cluster"?

>  As the TLD
>Cluster is changed, the members of the TLD Cluster are the FIRST to know.

That is because the hostmaster, which handles that domain will have to edit 
the zone file in his master (primary) name server. He would then reload 
that server and initiate a notify to his slaves (secondary), or gets the 
slaves manually to get the zone file from the master. If he doesn't do 
that, then it will take up to the TTL until the slaves know it.

>The "root servers" find out about the changes later.

Actually no. The root servers don't find it out at all. Until their 
hostmaster (IANA in the past) changes the delegation (ns) records and/or 
the glue, they will point forever to the old "cluster" as you call it. I 
speak out of experience with the .vn domain. The result is called "lame 
delegations".

If a TLD wants to change the name servers for their TLD, then they have to 
notify the root's hostmaster (IANA), and shouldn't change all servers at 
once, but one by one, to reduce "no reply/host not found" traffic.

If the hostmaster of the TLD knows, when the root servers are reloaded, 
then he/she can time the own relaod and thus avoid longer outages. Prior to 
that (a week or so before) he/se should reduce the times in the SOA record 
of the concerned zone file in order to speed up propagation.

>Some ISPs deal directly
>with the TLD Cluster, it is more accurate, up-to-date, stable, etc.

They can configure stub zones for the mostly used TLDs, because that 
reduces traffic and speeds up resolution time. The disadvantage is, that 
they have to keep track manually (or via a robot) about changes to those 
"clusters" and furthermore, each time there is a new TLD, they have to 
configure it manually.
If they stick with a root, they don't need to do that, but only very 
occasionally change their root file (which changes very rarely).

>Historically, there has been an enormous amount of FUD spread around
>about the "root" and TLDs. One of the reasons this was able to be done
>was because the .COM TLD Cluster was on the SAME servers as the
>"legacy root". This caused people to refer to the .COM servers as "the
>root".

I know, that the gTLDs were previously served from some (not all!) of the 
x.root-servers.net hosts. I was not aware, that this caused confusion 
amongst the people, but might well be as you describe, and would explain 
some wrong conceptions.

>Technically, that used to be correct, logically it was not.
>
>.COM has now been migrated off of the "legacy root servers".

All of them (at least the "public" ones: .com, .net, .org) are now handled by
x.gTLD-servers.net

(snip)

>It also obscurs the discussions about the "load on the root". If one steps
>back and looks at "the root" as a dozen servers seperate from all TLD
>Clusters, then "the root" is very lightly loaded.

As far as I remember, there were statistics shown during the recent ICANN 
meeting in Stockholm.

>Once an ISP finds out
>where a TLD Cluster is located, it may not ask again, if ever.

The ISP's name server will ask the root again, once the TTL has expired. I 
had to look it up, but expect it to be roughly around 2 days.

>With other software, one never has to ask "the root" where a TLD Cluster is.

As long as there are no stub zones, the next name server will do it.

>Because of the wide-spread caching in the DNS,

Cached info expires after the TTL (time to live). If a record is expired, 
the name server has to go back to the root and ask for that TLD...

>it turns out that many servers
>know where (for example) the .TV Cluster is, and again, once that .TV
>Cluster is found, software radar can lock on it, and use it as the source
>for the best information on itself.

End-users rarely run servers. ISPs which run servers wouldn't patch their 
server to behave like you describe.
You can of course patch your resolver at the user's PC that it works like 
that, i.e. that it ignores the TTL for example and asks only, if it doesn't 
get a reply for a SLD. But this is surely not according to RFCs. And you 
run the high risk that you get outdated info (or fall prey to cache 
poisoning), if they change their name servers. How do you want to get the 
resolver then to look for the real, actual data?

>As it evolves, it knows about the changes.
>
>For more on "Multiple TLD Clusters"...
>http://www.ietf.org/mail-archive/ietf/Current/msg12215.html
>"Multiple TLD Clusters are new."

What do you consider as *Multiple* TLD Clusters?
This post doesn't describe it very clearly. Is this the sum of all 
conflicting TLDs with the same name?

Best Regards,
Stefan

--
This message was passed to you via the ga-roots@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-roots" in the body of the message).
Archives at http://www.dnso.org/archives.html