AW: [governance] DNSsec and allternative DNS system

Kleinwächter, Wolfgang wolfgang.kleinwaechter at medienkomm.uni-halle.de
Wed Nov 14 20:38:29 EST 2007


Thanks Karl
 
very helpful
 
wolfgang

________________________________

Von: Karl Auerbach [mailto:karl at cavebear.com]
Gesendet: Do 15.11.2007 01:24
An: governance at lists.cpsr.org; Dr. Francis MUGUET
Cc: WSIS CS WG on Information Networks Governance
Betreff: Re: [governance] DNSsec and allternative DNS system




Since you mentioned DNSSEC:  I have a question that has not been clearly
answered.

Suppose we have an internet with some very large DNSSEC signed zone
files - let's use .com as a hypothetical model with roughly 70,000,000
items today.

Suppose that due to some systemic failure - for instance a software
upgrade gone bad - that all or most of the servers for that zone go down
  (or worse, crash).

How long will it take for those servers to come up again and provide
name resolution services?  In other words how long for the systems to do
the necessary file system checks (fsck) and checking of the zone file
signatures?

Will it take only a few seconds?  Will it take hours?  Will it take longer?

> In complement to my short oral remark, there,
> I would like to underline the possibilities offered by the
> ( not often know ) fact that  BIND ( the standard resolver software )
> allows to carry different resolving system
> ( not to be confused with alternate root servers that are against RFCs ).

I tend to use the phrase "competing root systems" rather than
"alternate" to indicate that except in the minds of users there is
architecturally no primary and no subordinate roots.

And we must recognize that many of the non NTIA/ICANN/Verisign root
zones have been served up by operations for which the word "shoddy"
would be an excessively positive assessment.

Rather than focusing on whether there is a single root or many roots,
the question should be whether they are consistent with one another.

There are two broad definitions of consistency.  (We all know that DNS
even if singular does have short term inconsistencies as various peer
servers independently update their contents and as caches expire in
separate machines.  But what I'm about to write about isn't about this
kind of short term inconsistency.)

Some hold that "consistency" between root server systems requires that
they offer precisely the same set of TLDs and that for each such TLD its
contents are precisely the same (i.e. that the TLD delegations are the
same, no matter which root system is used.)

This is the ORSN model.  Very conservative and so far I have not heard
of any problems.

Then there is the broader view of consistency, a view that I hold: That
different root systems may offer different TLDs, but that where a TLD
name is in common (e.g. .net or .org or .com, etc) that it has precisely
the same contents, i.e. the delegation is the same.

Why do I adopt this latter view?  Because I believe that self interest
will drive root server operators to include in their inventory of TLDs
those TLDs that users want - and that means all of the core, legacy TLDs
  found in the NTIA/ICANN/Verisign root zone.

A root server operator would be stupid, and would probably soon go out
of business if it failed to include these in the set of TLDs it supported.

And here, trademark law is our friend - anybody who tried to create a
deviant version of .com or .org or .net, etc would soon find
himself/herself at the receiving end of legal actions based on existing
laws that prevent the misidentification of goods and services, mainly
trademark law.

But the looser definition of "consistency" that I advocate, new TLDs
could arise - I call them "boutique" TLDs - that strive for sunlight and
growth.  They would, at first be found only in a few root systems -
perhaps because they offer something interesting, perhaps they paid
their way in, whatever - that's the normal task of "building a brand"
that goes with any new product that seeks space on store shelves.

Over time some of these boutique TLDs will fail, some will remain tiny
boutiques that are visible only within the scope of the root system that
offers them, and some will grow to become new members of the "every root
must have" club.

This system permits natural growth of new TLDs without any central
ICANN-like authority.

This looser definition of consistency allows a system that depends on
the efforts of the proponents to make their new TLD a common name rather
than on back-room politics.  And the ultimate choice comes from users -
whether they chose to accept and use the new name or chose to ignore it.

Now some will say that "what if I get email from
somebody at someplace.boutique-tld, how am I to answer it?"

The answer is that "you don't".

If someone choses a boutique TLD they must recognize (or be given enough
information to recognize) that they are sailing out onto new seas and
that not everybody will be able to resolve their name.

That's life - And it is part of everyday internet life.  For example, am
I to be denied my SIP VoIP phone number because most of the existing
telephones of the world can not dial my SIP phone "number" (which does
not contain a single numeric digit)?

Technology grows in part by creating new areas that can't be used by
legacy users - rotary dial telephones could not readily use touch-tone
keypad services, particularly ones that required "#" or "*".

                --karl--
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance


____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance



More information about the Governance mailing list