techno-politics was Re: [governance] Bloomberg - The Overzealous

David Conrad drc at virtualized.org
Mon Jan 21 01:48:55 EST 2013


Karl,

On Jan 20, 2013, at 6:52 PM, Karl Auerbach <karl at cavebear.com> wrote:
> I agree.  And it is a self-interested techno-political statement; there
> are several bodies - such as ISOC, IETF, ICANN - that benefit from cash
> flows derived from the belief that the internet requires a singular,
> catholic (lower case 'c') DNS root.

In order to maintain a coherent (that is, non-conflicting) namespace, the DNS protocol itself requires a single root.  Really.  Your suggesting otherwise is merely confusing folks who don't understand the technical details. I presume you understand the technical details. I don't understand why you persist in trying to spread confusion.

How that single root is implemented, whether it is done via single organization or some sort of consortia of cooperative entities that agree to some mechanism by which collisions are avoided, is of course up for debate but the DNS _protocol_ really truly does require a single root in order to maintain a collision-free namespace.

> For many years there have been competing root systems.

There have been "_alternate_ root systems" (consisting of both an alternate set of root servers along with an alternate namespace) since the first split DNS implementation was fielded back around 1986 or so to deal with internal vs. external domain names. ISC BIND version 9, the development of which I had a small role, included configuration language called "views" that made this easy to deploy, but the key factor in these alternate root systems are that the namespaces represented by different views are explicitly understood to be disjoint.

There have also been folks who have tried to field "_competitive_ root systems", typically using browser plug-ins but also different sets of root name servers, to present a different namespace than the actual root, but as far as I am aware, they have been failures (at least in the business sense -- I'm sure some feel they have been political successes).

> But that is not true for all - for example there was the ORSN in Europe
> (which even had some of the legacy root operators among its members.)

As I mentioned back when you raised ORSN on this list previously, they were an alternative root _name service_ provider which mirrored the actual root _namespace_.  ORSN reserved for themselves the right to refuse to accept a change of the actual root, but they never actually did this and never described what would happen to the folks who used their service if that situation came to pass.

> An interesting twist to its rules was that it promised not to remove any
> ccTLD even if ICANN did - this was in deference to the question whether
> .su should continue to exist even though the Soviet Union has itself ceased.

And you believe it appropriate that the fact that the ISO-3166 Maintenance Agency, you know, the UN agency the defines what the 2 letter code points actually are, had explicitly stated "Code element deleted from ISO 3166-1; stop using ASAP" should be completely irrelevant?

And what would happen in the DNS if sometime after SU was removed from ISO-3166 when ISO-3166/MA _reallocated_ the code point like what happened with CS? In your world, should IANA refuse to delegate the new SU?  Should IANA revoke SU from the folks who held the ISO-3166/MA deleted code point and then give it to the new delegatee?

For very good reasons that should be obvious now after the new gTLD applications, Jon Postel and others decided to use ISO-3166 as the basis for ccTLDs which means they put control of that particular namespace in the hands of others who could be deemed authoritative. You seem to be suggesting that ICANN should decide what is or is not a country. This doesn't seem like a very good idea to me.

> And for many years both ISPs and individuals have run roots for their
> own benefit or to control the quality of root-level resolutions for
> their customers.

Yes, and there are two cases:

1) where the ISP or individuals mirror the actual DNS _namespace_ so the only change is a reduction in need to go to the 13 root server IP addresses; _or_

2) where the ISP or individual make modifications to the DNS _namespace_, typically in the form of redirection for purposes of inserting/modifying content or advertisements.  

I personally believe the former case is a great idea as it improves performance and resiliency and, in fact, when it is pushed down to the individual machine is the only way to ensure DNS responses have not been modified in flight (even with DNSSEC since DNSSEC only protects to the validating resolver, not from the validating resolver to the application).  ORSN was a form of (1), albeit they did not agree to fully mirror the namespace and if they had actually carried through with their refusal, the idea is less great.

The latter case however is deemed by most to be more problematic, particularly by those who feel censorship of Internet content by ISPs is inappropriate. Not sure why you think it is such a good idea.

> Well run competing roots delegate to TLDs with exactly the same set of
> NS and glue records as do the legacy roots.  So all that a root system
> really is is a portal into an array of TLD servers.

This is _not_ a "competing root" in any meaningful sense.  This is alternate root name service.

> The big issue is not SINGULARITY of DNS roots but rather CONSISTENCY.

To be specific, the big issue is _NAMESPACE CONSISTENCY_.  Particularly with DNSSEC, it simply does not matter from where you get your TLD referrals.  What matters is that for a given name and at a given point in time (sequence number) _everyone gets consistent referrals_.  In practice, even consistent referrals are less important these days since glue consistency is less critical as long as the underlying namespace is consistent. That is, it doesn't matter if a name server is at 10.1.1.1 or 192.164.1.53 as long as the answers returned for example.com lead to identical services.

> Users will reject root systems that lead to surprising
> results.  And the laws of trademark and fraud will insure that that
> rejection would be backed by lawyers and law enforcement.

Right, because that has worked so well in the world of cache poisoning, phishing, and spamming.

> The definition of "consistency" is an interesting one.  Roots such as
> the ORSN defined "consistency" as being "same as the ICANN/NTIA/Verisign
> root zone" with the exception of the root servers themselves (and with
> the proviso about .su that I mentioned above.)

It is worth noting that ORSN shut down before ever exercising their self-proclaimed editorial right.  You may also note that SU was moved by ISO-3166/MA from "transitionally reserved" to "exceptionally reserved" and .SU continues to exist in the root zone (whether one thinks this is a good idea or not is another matter).

> But there is a more broad definition, which is that two roots are
> consistent if:
> 
>  - For each TLD in common between the two roots the delegation (NS and
> glue) records are the same.

Your version of "consistent" would fail where content delivery networks provide different name servers based on geographic location for performance/load-balancing reasons.

> This definition allows roots to differ at the edges, i.e. in the
> "boutique" TLDs that they chose to carry.  

And what happens when the ICANN new gTLD program after a year or two allocates the "boutique" TLD string to a different entity than the one that runs the TLD "at the edge"? 

Regards,
-drc


-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t


More information about the Governance mailing list