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

Tue Mar 4 15:29:24 UTC 2014

+1.  Thank you for taking a turn.  It gets exhausting after a while.

Adding to the challenge is that these emails are written as if they are "authoritative," (so to speak, i.e., written in a declarative, factual manner) but they are in fact "non-authoritative" (i.e., incorrect and full of sociopolitical fantasy)  (Apologies for the misuse of "authoritative" and "non-authoritative" in the service of a larger point.)  If left unrefuted, they sit on the record as if they were statements of fact, and perhaps even get counted in the "digest" as statements reflecting reality.

Greg Shatan

-----Original Message-----
From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of manning bill
Sent: Tuesday, March 04, 2014 3:48 AM
To: David Conrad
Cc: 1 Net List
Subject: Re: [discuss] Root servers yet again (Re: Roadmap for globalizing IANA)

David, you are doing romans work here.

/bill
Neca eos omnes.  Deus suos agnoscet.

On 3March2014Monday, at 23:20, David Conrad <drc at virtualized.org> wrote:

> 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_.

Or you can use the fresh/salt water analogy.  In the fresh water,some species live,  in salt water, other species live - a few species can live in brackish water and some migrate between the two.

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

I concur with you David,  Hebe, can you document the source for you assertion that NTIA decides?

>
> 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.
>

Are you suggesting that the child and not the parent is authoritative?  If so, you clearly do not understand the protocol.

> 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
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss

_______________________________________________
discuss mailing list
discuss at 1net.org
http://1net-mail.1net.org/mailman/listinfo/discuss

                                                                * * *

This E-mail, along with any attachments, is considered
confidential and may well be legally privileged. If you have received it in
error, you are on notice of its status. Please notify us immediately by reply
e-mail and then delete this message from your system. Please do not copy it or
use it for any purposes, or disclose its contents to any other
person. Thank you for your cooperation.

                                                                * * *

To ensure compliance with Treasury Department regulations, we
inform you that, unless otherwise indicated in writing, any U.S. Federal tax
advice contained in this communication  (including any attachments) is not
intended or written to be used, and cannot be used, for the purpose of (1)
avoiding penalties under the Internal Revenue Code or applicable state
and local provisions or (2) promoting, marketing or recommending to another
party any tax-related matters addressed herein.
                                                                        Disclaimer Version RS.US.20.10.00