[discuss] Root servers yet again (Re: Roadmap for globalizing IANA)

[David Conrad]

Elisabeth

On Mar 4, 2014, at 2:42 AM, Elisabeth Blanconil <info at vgnic.org> wrote:
> At 02:45 04/03/2014, nathalie coupet wrote:
>> Could you, jefsey, Hebe, and others, please address the issue of leakage. How could you prevent it (do you want to prevent it)?
> 
> As David Conrad mentions it, the leakage is a pollution of DNS buffers by a different vision of the name space. This would occur in the top zone if there were two different identical TLDs, the zones of which would be different, documented by two different root server systems of thee same class. 

No.  "Pollution" (or perhaps more descriptively cross-contamination) would occur in caching servers (and applications that implemented their own resolvers like, say, most web browsers) when they queried the name servers that offered the different namespaces.  The end result, particularly for end users who have no idea what the DNS actually is, would be that it would be impossible to tell what a particular name pointed to at any given time.  That is, when you sit down at a coffee shop and try to browse "www.example.com" you could get something _completely unrelated_ to what you get when you browse "www.example.com" from your home. Worse, the end user _has no way to figure out which example.com she is going to go to_.

> Please note that:
> * The ICANN root is authoritative: the NTIA decides which servers are to be listed for the different TLDs.

Please stop spreading blatant and obvious misinformation.  It is not helping the discussion.

NTIA does NOT decide which servers are listed for TLDs. The TLD administrators decide this. NTIA ensures that ICANN follows its processes when proposing changes initiated by the TLD administrators. 

> * The ORSN root is non-authoritative: it reports the configuration authoritatively indicated by the TLD Managers. 

You are using the DNS term of art "non-authoritative" wrong.  Both ORSN and the normal root servers run authoritative servers and respond authoritatively to queries for the root zone. 

> it reports the configuration authoritatively indicated by the TLD Managers.

As does the normal root servers.

ORSN, by serving the root zone data generated by the existing root zone partners, does _NOTHING_ different that the normal root servers.  The only practical difference between ORSN and the normal root servers is the ORSN infrastructure is currently far weaker/less diverse than the existing root servers.

> This is the difference between monarchy and polycracy

This is pure fantasy.

> In a non-attacked class,

No idea what you mean by this.

> leaks can only happen if an authoritative root administrator decides the seizure of TLD.

No. Really. Just No.  If you actually believe this, you clearly do not understand the technology.

Imagine your coffee shop decides to use an alternative namespace.  Since very few people know/care about this alternative namespace, there are very few names in it.  Every time you try to go to something like Facebook, Amazon, Tmall, Maktoob, etc., you get "name does not exist" (NXDOMAIN) errors. Frustrated, you go home. However, because DNS responses are cached, when you connect to your home network and try to go to any of those names, you _still_ get "name does not exist". This is just one of the many forms of leakage (I described another form above).

It would be extremely helpful if you would stop attempting to confuse people.

> VGNICs reduce the risks from this happening.

Since I am still unclear as to what "VGNICs" are, I'll take your word on this.

> The DNS IETF model supports 65,365 roots, one for each class. The sole class that people discuss on this list is the "IN" ICANN/NTIA class. We call this attitude "the BUG", i.e. being unipolarly global.

I fail to see the value in attempting to redefine common terms.  For an actual definition of the term "bug", see http://www.anomalies-unlimited.com/Science/Grace%20Hooper.html

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140304/0a15162d/signature.asc>