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

[Daniel Kalchev]

This argument inspired some comments from me:

On Jan 21, 2013, at 8:48 AM, David Conrad <drc at virtualized.org> wrote:

> Karl,
> 
> On Jan 20, 2013, at 6:52 PM, Karl Auerbach <karl at cavebear.com> wrote:
> 
>> 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).

Today, we call the software that modifies the DNS resolver behaviour "malware". This type of malware is quite popular and in fact, most of it is based on the "alternative root" concept. 

We fight this stuff fiercely. Why should we otherwise encourage the same behaviour?

Imagine, your ISP's name servers (those who they suggested you use) suddenly start resolving using a different root. How is this any different? How can you tell, whether their name servers are 

- misconfigured;
- intentionally configured this way;
- infected with malware?

In any case, you, the user is cheated. You have the option to either tell your ISP, send the police their way, or just switch ISPs. 

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


This reminded me of… 
For years, the FreeBSD named (BIND) configuration, has this common section:

// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/etc/namedb/named.root"; };

/*      Slaving the following zones from the root name servers has some
        significant advantages:
        1. Faster local resolution for your users
        2. No spurious traffic will be sent from your network to the roots
        3. Greater resilience to any potential root server failure/DDoS

        On the other hand, this method requires more monitoring than the
        hints file to be sure that an unexpected failure mode has not
        incapacitated your server.  Name servers that are serving a lot
        of clients will benefit more from this approach than individual
        hosts.  Use with caution.

        To use this mechanism, uncomment the entries below, and comment
        the hint zone above.

        As documented at http://dns.icann.org/services/axfr/ these zones:
        "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
        are availble for AXFR from these servers on IPv4 and IPv6:
        xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/

This is essentially suggesting, that instead of relying on a text file to list the root servers, you should actually become secondary for the root zone. That is, one of the root servers. 

Imagine, today, each FreeBSD server, or workstation (and these are *plenty*) is an actual, up to date root server for the network it serves.

I believe we can thank Doug Barton for this. Hi Doug. :)

So yes, alternative root servers is a technology practiced for years, for very good reasons and with very good results. But those alternative root servers resolve the same, singular root.


The case of alternative root servers, that provide different result from the "official" root just creates more burden on everyone. With DNSSEC, that burden increases significantly. This all, provided you know what you are doing -- most Internet users don't and would not care much.

Daniel


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