[apnic-talk] Re: "Distributing K-Root Service"
Jim and all,
Of course your are quite right here by in large Jim. It is only very recently
that ICANN is becoming aware that they have been wrong in a number
of DNS related areas under discussion and debate for some time.
Many of us that have been around for awhile that ICANN was an outgrowth
of the failed IAHC and gTLD-MoU efforts that the DOC/NTIA shut down,
and quite correctly so as well. Yet many of the now ICANN staff
and BOD were self appointed leaders in those failed efforts and tried
to carry forward their technical and political ideology to what is now
ICANN in DNS and IP related issues and technical protocol areas
or aspects.
Now that the Homeland security department has been under consideration
and yesterday was passed by the senate of the US, ICANN is under
indirect advisement that they better get their ducks in a row or bail.
Jim Fleming wrote:
> http://www.ripe.net/ripe/draft-documents/k-root-anycasting.html
> "Distributing K-Root Service"
> ===
>
> Modern DNS software does not need any roots. TLD Clusters can be located
> in a variety of ways, then then the TLD Clusters can be closely tracked, because
> changes made to TLD Clusters have to be made there first, and any roots find out
> about that after the fact, and are therefore out of sync with the real TLD servers.
> The new 128-bit DNS software, uses a variety of ways of finding the Top 2,048
> TLDs, including queries sent to other sub-domains of key TLD clusters. That helps
> to spread the load around, and makes it much easier to add a new TLD to "the root".
>
> People still have to deal with the old, aging, legacy, geriatric 32-bit root servers.
> It is interesting that when faced with extinction, people begin to run untested experiments
> with the servers some claim must be stable and secure. It is interesting to note that the
> ICANN people who know little or nothing about DNS technology, are willing to wave
> red flags about stability and security with regard to adding TLDs, yet, seem unconcerned
> about distributing root servers all over on mirrored IP addresses, without concern about
> the differences in how UDP and TCP operate, and the fact that both UDP and TCP are
> generally supported by nameservers. Apparently, UDP-only is being assumed and the
> transactions are assumed to be "atomic". In other words, there is no state information left
> in a root server between queries. If state information is maintained between queries, then
> one of the distributed servers failing and withdrawing, can result in traffic going to one of
> the other instances, when that new instance has no synchronized knowledge of what was
> being handled by the failed server. The middle of a TCP session can end up being routed
> to the wrong server, since many servers are going to be using the same golden IP address.
>
> To combat those potential problems, ISPs can of course continue to do what they already
> do, which is to host their own root-server(s) on the "golden regional address" and set up a
> static route directly to it, thus keeping root traffic from leaving the ISP's network and allowing
> the ISP to augment the root zone with TLDs not in the legacy roots. In doing this, the
> "golden regional 32-bit address" then becomes a non-routable address which joins a slew
> of other non-routable addresses, that serve special purposes. Large companies have of
> course taken some large blocks and made them into non-routable holes in the 32-bit address
> spectrum, by making them part of the local LAN conventions which are later called standards,
> and registered by "the IANA" as reserved. APIPA is one example.
> http://www.iana.org/assignments/ipv4-address-space
>
> Large companies and RIRs can of course have their way with any of the .ARPA allocations
> because, after all, they combine to define the boundaries of .ARPA and to make 32-bit
> allocations difficult and expensive to obtain, by small companies. Large companies and RIRs
> apparently pay little or nothing. That of course only applies to the 32-bit AM(0) address
> space with TOS=0x00,0x*0,0x0*. The FM address space can be allocated based more on
> quality, as opposed to quantity or unwillingness to pay market value for DNS services and
> Internet resources.
>
> Jim Fleming
> 128-bit DNS is closer than you think...
> IPv16...NET...COM...AM...NZ...AE...FM...NR...SZ...AC...DE...FI...JM...NO...PR...ST...UZ
> http://ipv8.dyndns.tv
> http://ipv8.dyns.cx
> http://ipv8.no-ip.com
> http://ipv8.no-ip.biz
> http://ipv8.no-ip.info
> http://ipv8.myip.us
> http://ipv8.dyn.ee
> http://ipv8.community.net.au
Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1 at ix dot netcom dot com
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
* APNIC-TALK: General APNIC Discussion List *
* To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic dot net *